proposta de extensÕes a mÉtodos e ferramentas … · distribuÍdos baseados em modelos dados pela...
TRANSCRIPT
GABRIELA WERNER CESCHINI
PROPOSTA DE EXTENSÕES A MÉTODOS E FERRAMENTAS DEDESENVOLVIMENTO DE SISTEMAS DE AUTOMAÇÃO
DISTRIBUÍDOS BASEADOS EM MODELOS DADOS PELA UML EPELA IEC 61499
Dissertação apresentada à EscolaPolitécnica da Universidade de São Paulopara obtenção do título de Mestre emEngenharia.
São Paulo2008
GABRIELA WERNER CESCHINI
PROPOSTA DE EXTENSÕES A MÉTODOS E FERRAMENTAS DEDESENVOLVIMENTO DE SISTEMAS DE AUTOMAÇÃO
DISTRIBUÍDOS BASEADOS EM MODELOS DADOS PELA UML EPELA IEC 61499
Dissertação apresentada à EscolaPolitécnica da Universidade de São Paulopara obtenção do título de Mestre emEngenharia.
Área de Concentração:Sistemas Digitais
Orientador:Prof. Livre-Docente Carlos EduardoCugnasca
São Paulo2008
AUTORIZO A REPRODUÇÃO E DIVULGAÇÃO TOTAL OU PARCIAL DESTETRABALHO, POR QUALQUER MEIO CONVENCIONAL OU ELETRÔNICO,
APENAS PARA FINS DE ESTUDO E PESQUISA, DESDE QUE CITADA A FONTE.
Dedicado à Família, aos Amigos e aos Professores, que constituem as minhas
verdadeiras riquezas e são aqueles em quem encontro apoio para seguir adiante,
hoje e sempre.
AGRADECIMENTOS
Sem dúvida, esta é a minha parte favorita da dissertação: é um dos poucos
momentos em que eu tenho a oportunidade de mostrar meu carinho por todos
aqueles que me ajudaram a alcançar mais esta vitória. Sendo assim, agradeço:
Em primeiro lugar, à minha família, em especial a meus pais, Mary e Carlos,
e ao meu irmão, João Carlos, que sempre estiveram presentes ao meu lado, dando-
me a força necessária para prosseguir (principalmente quando o cansaço e a
descrença pareciam prestes a me derrotar...). Obrigada por acreditarem em mim, e
perdão pelas ausências que se fizeram necessárias. Amo a todos.
À família Martins – em especial ao Samuel, claro – pelo apoio, companhia,
receptividade, palavras de alento e até pelos jantares! Foi muito importante contar
com o amor e carinho de todos vocês, os quais espero retribuir à altura.
Aos meus Professores – todos, absolutamente todos incluídos, desde a
escola até a faculdade, de todas as disciplinas, e mesmo das atividades extraclasse
– não somente por me instruírem, mas sobretudo por me ajudarem a ser uma
pessoa melhor. Em particular:
� Ao Professor Carlos Eduardo Cugnasca, meu orientador, por me
acompanhar durante este difícil percurso, pela paciência (apesar de todos os
meus tropeços), e pela fé quase “inabalável” depositada em mim – e que me
impulsionou sempre;
� Aos demais Professores do Laboratório de Automação Agrícola (Professores
Antonio Saraiva, André Hirakawa e Pedro Corrêa), pelo incentivo e pela
oportunidade de trabalhar nesse laboratório que eu adoro; e
� Aos Professores Selma Melnikoff, João José Neto e Moacyr Martucci Jr.,
pelo carinho de sempre e por me levarem a prosseguir mesmo nos
momentos de aflição, cada um à sua maneira.
Aos meus amigos, com quem tenho a felicidade de compartilhar a minha
vida e muitos dos meus sonhos. Em especial:
� Ao Eduardo Bertassi, por se fazer presente em todos os momentos
(independentemente da forma), pelas conversas de sempre (técnicas e não-
técnicas), pelas risadas infindáveis e também por repetir sempre que “a
força é forte” em mim, mesmo que às vezes eu duvide (obrigada pela
insistência);
� À Fabiana Nonogaki e ao Gustavo Marin, amigos a quem eu adoro e que,
embora distantes, têm lugar cativo no meu coração;
� À Professora Márcia Menegatti, ao Francisco e a todos os membros do
grupo de dança Formiga Amarela, pelo carinho e pela alegria que
compartilhamos. Espero que fiquemos juntos durante muito e muito tempo;
� Aos colegas do Laboratório de Automação Agrícola e do Laboratório de
Abelhas pela acolhida e pelo incentivo constante; e
� Ao José Garcia, por se interessar por meu trabalho e gentilmente me
fornecer material para levá-lo adiante.
Por fim, à empresa IBM, à iniciativa BrOffice e a todas as universidades e
pesquisadores citados no corpo desta dissertação, que me permitiram utilizar suas
ferramentas e documentos para o desenvolvimento desta pesquisa.
“If I have seen further it is by standing on ye shoulders of Giants”.
Isaac Newton
RESUMO
A motivação para o presente trabalho foi o desejo de investigar métodos e
ferramentas que fossem capazes de auxiliar engenheiros a desenvolver melhores
projetos de sistemas de automação. Investigaram-se então quais seriam as
contribuições da engenharia de software e da engenharia de controle para alcançar
esse objetivo: a primeira destacou-se pelos métodos e ferramentas aplicáveis às
fases de levantamento de requisitos e análise, em que os sistemas podem ser
expressos através da UML; a segunda contribuiu com blocos funcionais,
especialmente os orientados a eventos da norma IEC 61499, e ferramentas para
implementação e testes. Diversos autores sugerem a unificação entre as técnicas de
orientação a objetos expressas através da UML e o projeto de sistemas por meio de
blocos funcionais orientados a eventos da norma IEC 61499, para que os
engenheiros de cada uma das áreas citadas continuassem trabalhando com
técnicas e ferramentas próprias no desenvolvimento de sistemas de automação,
mas de maneira colaborativa. Nesta pesquisa estudou-se a maneira pela qual vêm
sendo feitos os mapeamentos entre a UML e a norma IEC 61499 do ponto de vista
teórico, embora com intenção de implementação de ferramentas para ajudar nessa
conversão. Estudaram-se também as ferramentas criadas para automatizar essa
transformação e para auxiliar no projeto de sistemas de automação distribuídos,
principalmente segundo a visão da norma IEC 61499. A partir daí, pôde-se oferecer
as seguintes contribuições: quanto aos métodos, sugerir um novo método de
mapeamento UML-IEC 61499 simplificado, com o uso, em UML, de um vocabulário
menos atrelado à norma IEC 61499 (ao contrário do que acontecia com os métodos
estudados); e sugerir a expressão de requisitos temporais quanto aos sistemas de
automação (também considerados no contexto da conversão UML-IEC61499);
quanto às ferramentas, comparar o modelo lógico da IEC 61499 com o da tecnologia
LonWorks; e, a partir daí, demonstrar a viabilidade de criação de uma ferramenta
para implementar sistemas de automação LonWorks expressados primeiramente em
abstrações da IEC 61499 (obtidas a partir das ferramentas vistas anteriormente).
Concluiu-se que é possível, teoricamente, criar uma ferramenta para cobrir todo o
ciclo de vida de desenvolvimento de um sistema de automação distribuído, com a
implementação deste sendo feita em uma tecnologia de controle de grande
aceitação no mercado. Apesar disso, identificou-se ainda que há várias
oportunidades de estudo em continuidade a essa pesquisa, como aprofundamento
da expressão dos requisitos de QoS e implementação da ferramenta idealizada.
Palavras-chave: sistemas de automação; modelagem; ferramentas de suporte a
projetos; UML; IEC 61499; LonWorks.
ABSTRACT
The main motivation of this research was to investigate tools and methods which
could help engineers to develop better automation system projects. So, with this aim,
the contributions of both software engineering and control engineering areas were
investigated: the first offered methods and tools to be used in the requisite elicitation
and system analysis project phases, in which the system could be designed in terms
of UML models; the latter contributed mainly through implementation and test tools,
related to the usage of function blocks, especially the IEC 61499 standard event-
oriented ones. Many authors suggest the unification between object-orientation
techniques expressed through UML and project methods done with the IEC 61499
event-driven function blocks, so that software engineers and control engineers could
keep working with their own area techniques and tools, in the context of an
automation system design, but in a collaborative sense. In this work, the mapping
between UML and IEC 61499 standard concepts was investigated from a theoretical
point of view, even though the intention behind that was to find or generate tools
which could automate this kind of conversion. Additionally, other tools related to help
engineers in the development of automation systems (particularly those which used
IEC 61499 standard abstractions) were also analyzed. After all that, some
contributions to this area could be proposed: as for the methods, a new simplified
UML-IEC61499 mapping, whose main features are the usage, in UML, of a less IEC
61499-constrained vocabulary (opposite to what happened in the other studied
techniques), and the way of expressing automation systems temporal requisites (still
related to the UML-IEC61499 conversion context); as for the tools, a comparison
between IEC 61499 and the LonWorks technology logical models, which led to the
conclusion that it would be possible to implement LonWorks automation systems
whose models were expressed at first through IEC 61499 abstractions (mainly those
resultant from the usage of UML-IEC61499 conversion tools). The conclusion of this
work is that with the development of all these tools and techniques it would be
possible to aid engineers through all automation system development phases, and
the implementation of such systems could be done with a broadly-accepted control
system technology. It was also identified that many other study opportunities were
raised by this research, such as discovering ways of expressing other QoS requisites
in automation system models, and trying to implement more complete engineering
project tools.
Keywords: automation systems; modeling; computer aided engineering; UML; IEC
61499; LonWorks.
LISTA DE ILUSTRAÇÕES
Figura 1: Diferentes estruturas de sistemas: centralizada (a), hierárquico (b) e
distribuído (c) – adaptado de Åström (1985).............................................40
Figura 2: Estrutura geral de um sistema de automação distribuído...........................43
Figura 3: Composição interna de um nó pertencente a um sistema de automação
distribuído.................................................................................................43
Figura 4: Exemplo de Diagrama de Classes..............................................................56
Figura 5: Exemplo de Diagrama de Estruturas Compostas.......................................57
Figura 6: Exemplo de Diagrama de Componentes....................................................57
Figura 7: Exemplo de Diagrama de Distribuição (Deployment).................................58
Figura 8: Exemplo de Diagrama de Pacotes.............................................................59
Figura 9: Exemplo de Diagrama de Casos de Uso....................................................60
Figura 10: Exemplo de Diagrama de Máquinas de Estados (da classe Sensor).......61
Figura 11: Exemplo de Diagrama de Atividades (da classe Controlador)..................62
Figura 12: Exemplo de Diagrama de Seqüência.......................................................63
Figura 13: Exemplo de Diagrama de Colaboração/Comunicação.............................64
Figura 14: Exemplo de Diagrama de Visão Geral das Interações.............................64
Figura 15: Exemplo de outros elementos e mecanismos gerais da UML: nota,
estereótipo, valor rotulado e restrição.......................................................66
Figura 16: Composição de um IPMCS da norma IEC 61499 (em UML)....................72
Figura 17: Especificação estrutural de um tipo de bloco funcional da norma IEC
61499 (em UML).......................................................................................73
Figura 18: Subclassificação dos tipos de blocos funcionais (em UML).....................73
Figura 19: Bloco funcional básico da norma IEC 61499 – traduzido de Christensen
(2002))......................................................................................................74
Figura 20: Diagrama de controle de execução de um bloco funcional básico da
norma IEC 61499 – adaptado de Christensen (2002)...............................75
Figura 21: Bloco funcional composto da norma IEC 61499 – traduzido de
Christensen (2002)....................................................................................75
Figura 22: Bloco funcional de interface de serviços da norma IEC 61499 (aspecto
externo idêntico aos dos demais blocos) e especificação da seqüência de
primitivas de um serviço – adaptado de Christensen (2002)....................76
Figura 23: Diagrama de Classes de um sistema de automação genérico para
demonstração do uso dos estereótipos do mapeamento de Thramboulidis
(estereótipos FB, IPT, SIFB e RWO)........................................................88
Figura 24: Diagramas de Classes do sistema de automação de um condicionador de
ar (fan coil) para demonstração do uso dos relacionamentos de
agregação (a) e dependência (b), elaborado segundo o mapeamento de
Thramboulidis...........................................................................................90
Figura 25: Parte dos estereótipos ligados a blocos funcionais (modelo em UML) –
traduzido de Thramboulidis (2001)...........................................................91
Figura 26: Diagrama de Colaboração do sistema de automação de um condicionador
de ar (fan coil), elaborado segundo o mapeamento de Thramboulidis e
com os ícones dos estereótipos do CORFU ESS.....................................92
Figura 27: Diagrama de Seqüência do sistema de automação de um condicionador
de ar (fan coil), elaborado segundo o mapeamento de Thramboulidis e
com os ícones dos estereótipos do CORFU ESS.....................................93
Figura 28: Diagrama de blocos funcionais obtido a partir do diagrama de seqüência
descrito na Figura 27 (gerado com a ferramenta CORFU ESS)...............93
Figura 29: Diagramas de Classes do sistema de automação de um condicionador de
ar (fan coil) para demonstração do uso de relacionamentos de agregação
e generalização, além de estereótipos e composições das classes,
elaborado segundo o mapeamento de Dubinin e Vyatkin.........................97
Figura 30: Diagrama de Colaboração do sistema de automação de um condicionador
de ar (fan coil), elaborado segundo o mapeamento de Dubinin e Vyatkin.
..................................................................................................................98
Figura 31: Exemplo de hierarquia de objetos (a) e a sua estrutura implícita de blocos
funcionais aninhados (b) – retirado de Dubinin, Vyatkin e Pfeiffer (2005).
Note-se que as conexões dadas por uma linha tracejada são conexões
locais, e a conexão dada por uma linha contínua – em (a) – é uma
conexão de trânsito (transformada, em (b), em quatro conexões locais). 99
Figura 32: Diagrama de Componentes e sua transformação na interface externa de
um bloco funcional segundo o mapeamento de Panjaitan e Frey – retirado
de Panjaitan e Frey (2006a)....................................................................101
Figura 33: Diagrama de Estruturas Compostas e sua transformação na interface
externa de um bloco funcional composto e na rede de blocos funcionais
interna a ele, segundo o mapeamento de Panjaitan e Frey – retirado de
Panjaitan e Frey (2006a).........................................................................102
Figura 34: Diagrama de Distribuição elaborado segundo o mapeamento de Panjaitan
e Frey......................................................................................................103
Figura 35: Diagrama de Máquinas de Estados segundo o mapeamento de Panjaitan
e Frey – retirado de Panjaitan e Frey (2006a)........................................104
Figura 36: Diagrama de Seqüência segundo o mapeamento de Panjaitan e Frey –
adaptado de Panjaitan e Frey (2006a)....................................................105
Figura 37: Relação entre os estereótipos DataConnection e EventConnection com as
metaclasses Connector e InformationItem da UML (a), e exemplo de
Diagrama de Estrutura Composta segundo o mapeamento de Zhang,
Diedrich e Halang – retirado de Zhang, Diedrich e Halang (2005).........108
Figura 38: Diagrama mostrando a relação entre a classe SEQ_MVC (que representa
um tipo de bloco funcional composto) e seus objetos internos ctrl:SEQ e
v:SEQV (que cumprem o papel de instâncias de blocos funcionais) (a), e
exemplo de Diagrama de Colaboração/Comunicação (entre uma instância
anônima da classe SEQ_MVC e os dois objetos citados anteriormente)
segundo o mapeamento de Zhang, Diedrich e Halang – retirado de
Zhang, Diedrich e Halang (2005)............................................................110
Figura 39: Conexão entre objeto, FBA e bloco funcional – adaptado de Heverhagen,
Tracht e Hirschfeld (2003).......................................................................110
Figura 40: Editor de Tipos de Blocos Funcionais (Function Block Type Editor) da
ferramenta CORFU ESS – neste caso, exibindo a interface externa e o
diagrama de controle de execução (ECC) de um bloco funcional..........123
Figura 41: Rede de blocos funcionais descrita no Editor de Diagramas de Blocos
Funcionais (Function Block Diagram Editor) da ferramenta CORFU ESS.
................................................................................................................124
Figura 42: Execução da rede de blocos funcionais através do Editor de Diagramas
de Blocos Funcionais (Function Block Diagram Editor) da ferramenta
CORFU ESS...........................................................................................125
Figura 43: Sistema de dispositivos e IPT projetado por meio do Editor da Camada de
Sistema (System Layer Editor) da ferramenta CORFU ESS..................127
Figura 44: Gerenciador do Recurso de Transformação (Transformation Facility
Manager) da ferramenta CORFU ESS...................................................127
Figura 45: Representação do efeito dos conversores UML-FB...............................130
Figura 46: Interface da ferramenta FBench (exibindo a execução de um sistema).134
Figura 47: Interface da ferramenta FBDK (exibindo um bloco funcional de interface
de serviços).............................................................................................135
Figura 48: Distribuição de uma aplicação em dois dispositivos através da ferramenta
4DIAC-IDE..............................................................................................137
Figura 49: Distribuição de uma aplicação da norma IEC 61499 na ferramenta
ISaGRAF – adaptado de Chouinard e Brennan (2006)..........................139
Figura 50: Exemplo de Diagrama de Classes segundo o mapeamento UML-
IEC61499 simplificado............................................................................147
Figura 51: Exemplo de conversão de método com parâmetros e valor de retorno
para uma rede de blocos funcionais (a) e detalhe da interface externa de
um dos blocos funcionais (b), segundo o mapeamento UML-IEC61499
simplificado.............................................................................................149
Figura 52: Exemplos de blocos funcionais de interface de serviços, para interações
iniciadas pela aplicação (a) e para interações iniciadas pelo recurso (b) –
retirado de International Electrotechnical Commission (2005a)..............151
Figura 53: Diagrama de Seqüência (da UML 2.X) com ênfase nas observações de
tempo e duração, e nas restrições de tempo e duração – traduzido de
Object Management Group (2007).........................................................157
Figura 54: Diagrama de Temporização (da UML 2.X) com ênfase nas observações
de tempo e duração, e nas restrições de tempo e duração – traduzido de
Object Management Group (2007).........................................................158
Figura 55: Representação teórica de um bloco funcional LonWorks.......................162
Figura 56: Representação de um perfil funcional LonWorks...................................164
Figura 57: Relacionamento entre modelos lógicos LonWorks.................................166
Figura 58: Arquitetura de um dispositivo..................................................................192
Figura 59: Arquitetura de um recurso......................................................................192
Figura 60: Arquitetura de um sistema distribuído segundo a norma IEC 61499......193
LISTA DE TABELAS
Tabela 1: Identificação dos diagramas da UML utilizados para expressar os
conceitos da norma IEC 61499 segundo os mapeamentos de
Thramboulidis, de Dubinin e Vyatkin, de Panjaitan e Frey e de Zhang,
Diedrich e Halang....................................................................................115
Tabela 2: Identificação dos principais elementos da UML utilizados para expressar
os conceitos da norma IEC 61499 segundo os mapeamentos de
Thramboulidis, de Dubinin e Vyatkin, de Panjaitan e Frey e de Zhang,
Diedrich e Halang....................................................................................116
Tabela 3: Identificação dos principais relacionamentos da UML utilizados para
expressar os conceitos da norma IEC 61499 segundo os mapeamentos
de Thramboulidis, de Dubinin e Vyatkin, de Panjaitan e Frey e de Zhang,
Diedrich e Halang....................................................................................117
Tabela 4: Cobertura das ferramentas estudadas quanto às fases de
desenvolvimento do projeto de sistemas de automação........................142
LISTA DE ABREVIATURAS E SIGLAS
4DIAC
ANSI American National Standard Institute
AXE Archimedes eXecution Environment
BFB Basic FB
BNF Backus-Naur Form
CD Control-Dependency
CEA Consumer Electronics Association
CFB Composite FB
CLP Controlador Lógico ProgramávelCORBA Common Object Request Broker Architecture
CORFU
CP Configuration Property
CPT CP Type
CPAS Collaborative Process Automation Systems
CSIFB Communication SIFB
DD Data-Dependency
DDC Digital Direct Control
DTD Document Type Definition
ECC Execution Control Chart
EIA Electronic Industries Alliance
Enhanced-4LCA Enhanced four Layer CORFU Architecture
ESS Engineering Support System
FB Function Block
FBA Function Block Adapter
FBDK Function Block Development Kit
FDCML Field Device Configuration Markup Language
FORTEFP Functional Profile
FPT FP Template
Fuber FUnction Block Execution Runtime
HVAC Heating, Ventilating and Air Conditioning
LD Ladder Diagram
IDE Integrated Development Environment
IEC International Electrotechnical Commission
IPMCS Industrial-Process Measurement and Control Systems
Framework for Distributed Industrial Automation and Control
Common Object-oriented Real-time Framework for the Unified development of distributed IPMCS applications
4DIAC-Run-time Environment
IPP Industrial Process Parameter
IPT Industrial Process Terminator
ISO International Organization for Standardization
NCES Net Condition/Event Systems
NV Network Variable
NVT Network Variable Type
OCL Object Constraint Language
OMG Object Management Group
OMT Object Modeling Technique
OOONEIDA
OOSE Object-Oriented Software Engineering
OSI Open Systems Interconnection
PSIFB Process SIFB
QoS Quality of Service
RAM Random Access Memory
RedeBF Rede de Blocos FuncionaisROM Read-Only Memory
RTE Run-time Environment
RTL Real-Time Logic
RWO Real-World Object
SCPT Standard CPT
SFC Sequential Function Chart
SFPT Standard FTP
SIFB Service Interface Function Block
SNVT Standard NVT
ST Structured Text
TFM Transformation Facility Manager
TIC Target Independent Code
TSIFB Timer SIFB
UML Unified Modeling Language
ViEd Visual Editor
ViVe Visual Verifier
VLSI Very Large Scale Integration
XML EXtensible Markup Language
Open, Object-Oriented kNowledge Economy for Intelligent Distributed Automation
SUMÁRIO
1. INTRODUÇÃO.......................................................................................................25
1.1. Motivação.......................................................................................................25
1.2. Justificativa.....................................................................................................29
1.3. Objetivos.........................................................................................................33
1.4. Organização do documento............................................................................33
1.5. Considerações sobre estilo e formatação do texto.........................................34
2. PROJETO DE SISTEMAS DE AUTOMAÇÃO DISTRIBUÍDOS............................35
2.1. Sistemas de automação.................................................................................35
2.1.1. Definição..................................................................................................35
2.1.2. Histórico...................................................................................................39
2.1.3. Necessidades latentes dos sistemas de automação distribuídos............46
2.2. Ciclo de vida de projeto de sistemas de automação distribuídos...................47
2.2.1. Projetos de engenharia de software........................................................48
2.2.2. Projetos de engenharia de controle e automação...................................66
2.3. Comentários sobre os projetos de sistemas de automação distribuídos........80
3. MAPEAMENTO DE DIAGRAMAS DA UML EM DIAGRAMAS DE ABSTRAÇÕES
DA NORMA IEC 61499..............................................................................................84
3.1. Tendências no mapeamento UML-IEC61499.................................................84
3.1.1. Mapeamento de Thramboulidis...............................................................85
3.1.2. Mapeamento de Dubinin e Vyatkin..........................................................94
3.1.3. Mapeamento de Panjaitan e Frey............................................................99
3.1.4. Mapeamento de Zhang, Diedrich e Halang...........................................106
3.1.5. Mapeamento de Heverhagen, Tracht e Hirschfeld................................110
3.2. Comparação entre mapeamentos UML-IEC61499 e comentários...............113
4. FERRAMENTAS COMPUTACIONAIS PARA SUPORTE ÀS ATIVIDADES DE
ENGENHARIA VOLTADAS AO DESENVOLVIMENTO DE SISTEMAS DE
AUTOMAÇÃO DISTRIBUÍDOS...............................................................................118
4.1. Apresentação geral das ferramentas............................................................118
4.1.1. CORFU ESS..........................................................................................119
4.1.2. Conversores UML-FB............................................................................129
4.1.3. FBench..................................................................................................132
4.1.4. FBDK.....................................................................................................134
4.1.5. 4DIAC-IDE.............................................................................................135
4.1.6. ISaGRAF...............................................................................................138
4.1.7. Fuber.....................................................................................................140
4.1.8. Archimedes ESS...................................................................................141
4.2. Comparação entre as ferramentas...............................................................142
5. PROPOSTA DE EXTENSÕES AOS MAPEAMENTOS UML-IEC61499 E
FERRAMENTAS......................................................................................................144
5.1. Extensões aos mapeamentos UML-IEC61499.............................................144
5.1.1. Mapeamento UML-IEC61499 simplificado............................................144
5.1.2. Mecanismos para representação de parâmetros temporais em modelos
de sistemas de automação..............................................................................154
5.2. Extensões das ferramentas computacionais para suporte às atividades de
engenharia voltadas ao desenvolvimento de sistemas de automação distribuídos
.............................................................................................................................160
5.2.1. Compatibilidade entre as abstrações da norma IEC 61499 e das
abstrações previstas pela tecnologia LonWorks para o projeto de sistemas de
automação distribuídos...................................................................................161
5. Implementação de ferramenta computacional para suporte ao
desenvolvimento de sistemas de automação distribuídos LonWorks........171
6. CONSIDERAÇÕES FINAIS.................................................................................177
6.1. Conclusões...................................................................................................177
6.2. Contribuições................................................................................................178
6.3. Melhorias......................................................................................................179
6.4. Trabalhos futuros..........................................................................................181
6.5. Encerramento...............................................................................................182
25
1. INTRODUÇÃO
Neste capítulo, apresenta-se a motivação, a justificativa e os objetivos da
dissertação. Para isso, descreve-se brevemente o que é um sistema de automação
distribuído, quais são algumas das abordagens provenientes das áreas de
engenharia de sistemas e de software, e de engenharia de controle e automação,
que podem ser usadas para guiar o desenvolvimento desses sistemas
(correspondendo, respectivamente, à descrição dos mesmos em Unified Modeling
Language (UML) durante as fases iniciais do ciclo de vida – que abrangem desde o
levantamento de requisitos ao projeto, e à caracterização dos sistemas em termos
de abstrações da norma International Electrotechnical Commission (IEC) 61499
durante as etapas finais, ou seja, do projeto à manutenção), e, a partir daí, quais são
os trabalhos mais relevantes a respeito da integração dessas técnicas. Por fim, o
foco do trabalho é posto na investigação e expansão de métodos para o
mapeamento entre descrições de sistemas em UML e descrições em termos de
modelos da norma IEC 61499, assim como no estudo e aprimoramento de
ferramentas que tratam tanto dessa transposição quanto do suporte às atividades de
engenharia em geral.
1.1. MOTIVAÇÃO
Segundo Samad, McLaughlin e Lu (2007), os sistemas de automação de
processos (ou simplesmente sistemas de automação) são os responsáveis por
monitorar, controlar e supervisionar, de forma precisa e conveniente, a operação de
um sistema físico complexo e dinâmico, usualmente representado por um processo
industrial ou planta (sendo essa aplicação o que o distingue de um sistema de
automação de escritórios). Uma das áreas em que se utilizam os sistemas de
automação é na integração de sistemas prediais (como sistemas de
condicionamento de ar e iluminação, por exemplo) para a obtenção de edifícios
inteligentes (aqueles em que se constrói um ambiente eficiente, produtivo e seguro
26
por um custo mínimo) (GUSTIN, 2005).
Os sistemas de automação podem ser divididos, segundo sua topologia, em
três tipos principais: sistemas de automação centralizados, hierárquicos ou
distribuídos. Conforme citado por Åström (1985), enquanto nos sistemas
centralizados o responsável pelo tratamento das medições é um processador
central, em um sistema hierárquico o processamento das informações é
descentralizado, e, em um sistema distribuído, é feito localmente em cada laço de
controle. Neste último, as entidades computacionais autônomas responsáveis pelo
tratamento das informações são chamadas nós ou módulos.
Apesar da existência dessas três topologias principais, os sistemas
distribuídos têm sido preferidos por oferecerem algumas características muito
desejáveis em um sistema de automação: segundo Samad, McLaughlin e Lu (2007),
devido à multiplicidade de nós de processamento, tais sistemas são mais confiáveis
(pela inexistência de um ponto central de falha); possibilitam simplificação do
cabeamento (XIE; PU; MOORE, 1998); facilitam a manutenção e alteração do
sistema (SAMAD; MCLAUGHLIN; LU, 2007) e, por serem escaláveis, causam menor
impacto nos custos iniciais de implementação.
Embora apresentem tais vantagens, os sistemas de automação distribuídos
caracterizam-se também por serem de difíceis concepção e implementação: a
modularidade dos mesmos, tanto física quanto lógica, ao mesmo tempo em que é
um de seus trunfos, aumenta a complexidade do projeto por demandar o
particionamento da aplicação e sua distribuição nos nós – tarefa em que diversos
fatores influenciam as decisões dos projetistas, entre eles os requisitos funcionais e
não-funcionais do sistema, as características dos módulos (quanto a entradas e
saídas físicas conectadas a eles e capacidade de processamento, por exemplo) e a
própria experiência do pessoal responsável. Devido a isso, tais sistemas provocam a
necessidade de haver processos de desenvolvimento que guiem os projetos de
engenharia, para que, ao fim, obtenham-se sistemas de boa qualidade (sendo esta
considerada em diversos sentidos, como para garantir que se obtenham projetos
que satisfaçam às necessidades do usuário, que não fiquem obsoletos rapidamente,
que possam ser mantidos de forma adequada, que não ultrapassem limites de
orçamento e prazo de execução, entre outros aspectos).
Frente ao cenário exposto e às afirmações tanto de Mahalik e Lee (2002)
quanto de Xie, Pu e Moore (1998) sobre a falta de ferramentas para apoiar o
27
processo de descentralização das aplicações, surge o interesse pela investigação do
estado atual da pesquisa nessa área, de forma a garantir que todo o ciclo de vida de
desenvolvimento dos sistemas de automação seja coberto (abrangendo as fases de
levantamento de requisitos, análise, projeto, implementação, testes, instalação e
manutenção do sistema). Parte-se, então, para dois caminhos: verificar as técnicas
existentes na área de engenharia de sistemas e de software e aquelas fornecidas
pela engenharia de controle e automação.
Sob o prisma da engenharia de sistemas e de software, percebe-se uma
abundância de ferramentas e de descrições na literatura sobre como tratar as fases
de levantamento de requisitos, análise e projeto, em que se realizam o entendimento
das necessidades e a modelagem dos sistemas em geral (aplicáveis também aos
sistemas de automação).
Para a divisão da funcionalidade global dos sistemas de automação
distribuídos entre componentes de software autônomos e cooperativos durante a
modelagem do sistema (cujos potenciais benefícios são o reuso, a escalabilidade e a
possibilidade de realizar modificações e manutenção nas aplicações, entre outros
(MAHALIK; LEE, 2003)), uma das abordagens mais populares é o uso de técnicas
de orientação a objetos, principalmente pela fácil comparação e passagem “intuitiva”
de objetos do mundo real para objetos de software: segundo Armstrong (2006),
objetos são itens individuais e identificáveis, tanto reais quanto abstratos, que
contêm dados sobre si e descrições da forma pela qual os mesmos devem ser
manipulados.
No âmbito das técnicas de orientação a objetos, a UML tornou-se o padrão
de facto para a representação de sistemas (BORDBAR; DERRICK; WATERS, 2002),
destacando-se por ser expressiva, extensível, de aplicação geral e fácil
compreensão. De acordo com Booch, Rumbaugh e Jacobson (1998), a UML é uma
linguagem gráfica que pode ser utilizada para visualizar, especificar, construir e
documentar artefatos de sistemas dos mais diversos domínios, cobrindo a descrição
tanto de seu comportamento quanto de sua estrutura. Devido a todas essas
características, a UML tem provocado crescente interesse por parte dos
pesquisadores da área de sistemas de automação distribuídos, em que começam a
surgir trabalhos relacionados à geração de seus modelos como apoio às fases de
levantamento de requisitos, análise e projeto (ainda que inicial) dos sistemas.
Quanto ao suporte dessas atividades de projeto por meio de ferramentas, ele ocorre
28
predominantemente através do uso das ferramentas de aplicação geral para
modelagens em UML já existentes no mercado (ou seja, não se tem informações
sobre a existência de ferramentas que visem especialmente ao mercado de sistemas
de automação).
A partir da fase de implementação, no entanto, a área de software não
possui muitos elementos com os quais contribuir para os projetos específicos de
sistemas de automação distribuídos: em geral, as linguagens e técnicas de
programação não se revelam adequados para a obtenção do software dos módulos
funcionais desses sistemas, nem para a sua distribuição. Também não parece haver
ferramentas que ajudem na implementação e na manutenção, tanto das aplicações
quanto da estrutura física, dos sistemas de automação: portanto, vê-se que, até
então, a área de software ofereceria suporte somente às fases de levantamento de
requisitos, análise e projeto de tais sistemas.
Segue-se, então, para a verificação das técnicas oferecidas pela área de
engenharia de controle e automação para descrever os sistemas de automação
distribuídos: além de teorias adequadas para o bom projeto dos laços de controle
(incluindo sua modelagem matemática), observa-se a existência de abundantes
ferramentas para permitir o desenvolvimento de software, a especificação da
arquitetura física do sistema (ou seja, quais são e como estão interligados os nós de
automação), a passagem de softwares para os módulos de processamento, a
configuração e a manutenção da rede de controle e dos nós, a interligação lógica
dos módulos de software (entre si, e com as entradas e saídas físicas de seus nós),
e a supervisão da aplicação de automação, conforme pode ser visto em Echelon
Corporation (2006), Honeywell International Inc. (2005), TourAndoverControls (2006)
e VisualControl, LLC (2003).
Nesse âmbito, nota-se que, em grande parte dos casos, a modularização do
software dos sistemas de automação é feita por meio de blocos funcionais, que são,
segundo Lewis1 (2001 apud TRANORIS; THRAMBOULIDIS, 2003a), mecanismos de
abstração que permitem o encapsulamento de algoritmos industriais de forma que os
mesmos possam ser rapidamente entendidos e aplicados pelos engenheiros,
mesmo que eles não sejam especialistas na implementação de algoritmos
complexos. Dai, Shih e Vyatkin (2006), por sua vez, descrevem o bloco funcional
1 LEWIS, R. Modeling control systems using IEC 61499. [S.l.]: The Institute of ElectricalEngineers, 2001.
29
como uma cápsula (normalmente de software, mas, de maneira geral, uma
propriedade intelectual), que consiste de variáveis de entrada e saída, variáveis
internas e descrição de seu comportamento interno, cuja interligação resulta na
aplicação a ser posta em um dispositivo. Nesse contexto, uma das normas que
padronizam o uso de blocos funcionais em sistemas de automação distribuídos é a
IEC 61499, publicada em 2005, que define, além disso, uma arquitetura genérica e
apresenta recomendações específicas para cobrir desde a fase de projeto até a fase
de implementação desses sistemas por meio de modelos apropriados.
Dessa forma, observa-se que a área de engenharia de controle e automação
tem oferecido bastantes recursos em termos de procedimentos e ferramentas para
auxiliar nas etapas de desenvolvimento que vão da implementação à manutenção
dos sistemas de automação distribuídos, ainda que se deva ressaltar a falta de
suporte às fases de levantamento de requisitos, análise e projeto. No entanto, como
visto anteriormente, estas fases são justamente aquelas que podem ser supridas
pelas técnicas de engenharia de sistemas e de software.
1.2. JUSTIFICATIVA
Embora houvesse a possibilidade de estender as técnicas de software ou de
controle para as fases de projeto em que ainda apresentam deficiências, tem-se
notado que muitos autores começam a propor a unificação dessas diferentes
abordagens, tanto para reaproveitamento de legado quanto para que os
profissionais dessas áreas passem a colaborar entre si (mesmo mantendo os
recursos e linguagens próprios de suas áreas). Percebe-se, especificamente, uma
tendência em se aproximar os elementos de orientação a objetos, com modelos
gerados em UML, das descrições de sistemas por meios de blocos funcionais, em
especial daquelas dadas segundo a norma IEC 61499 (já que esta especifica um
modelo de bloco funcional especial, orientado a eventos). Portanto, justifica-se assim
o interesse pelos estudos tanto do mapeamento entre diagramas da UML e
diagramas de abstrações da norma IEC 61499, quanto de ferramentas que facilitem
essa transposição, bem como as demais atividades de engenharia, visando à
disponibilidade de técnicas e ferramentas que cubram todo o ciclo de
30
desenvolvimento de projeto de sistemas de automação.
A seguir, são listadas as principais referências que revelam o estado da arte
da pesquisa nessa área. Para clareza, optou-se pelo uso de tópicos e pela
apresentação das mesmas em ordem cronológica:
� Mapeamento de diagramas da UML em diagramas de abstrações da norma
IEC 61499:
Tranoris e Thramboulidis (2002): sugere extensões à UML e regras de
transformação de diagramas da UML para diagramas de abstrações da
norma IEC 61499, além de mostrar um exemplo de como essa
transformação é feita;
Heverhagen, Tracht e Hirschfeld (2003): mostra os adaptadores para
blocos funcionais (Function Block Adapters – FBA), que permitem a
compatibilização entre classes dos diagramas da UML e blocos
funcionais da norma IEC 61499;
Dubinin e Vyatkin (2004): descreve a linguagem UML-Function Block
(UML-FB), que estende a UML de forma a tornar possível a
representação de abstrações da norma IEC 61499;
Dubinin, Vyatkin e Pfeiffer (2005): expõe brevemente a linguagem UML-
FB, mostra um exemplo de aplicação e indica a existência de
ferramentas conversoras UML-FB, disponíveis para download;
Zhang, Diedrich e Halang (2005): explica como estender e usar a UML
para fazer a modelagem de aplicações baseadas em abstrações da
norma IEC 61499; e
Panjaitan e Frey (2006): propõe o uso da UML para a modelagem de
sistemas de automação e a posterior passagem desses modelos para
diagramas de abstrações da norma IEC 61499. Por fim, os autores
apresentam sua própria ferramenta para executar tal transformação.
� Ferramentas para o suporte às atividades de engenharia de sistemas de
automação distribuídos (incluindo a transformação de diagramas da UML em
diagramas de abstrações da norma IEC 61499):
Thramboulidis (2003): expõe a ferramenta Common Object-oriented
Real-time Framework for the Unified development of distributed
Industrial-Process Measurement and Control Systems (IPMCS)
applications-Function Block Development Kit (CORFU-FBDK), que dá
31
suporte ao ciclo de vida de projeto de aplicações voltadas a sistemas de
automação distribuídos e que, para isso, segue uma arquitetura chamada
enhanced four Layer CORFU Architecture (enhanced-4LCA) e está
inserida no contexto de um processo de desenvolvimento incremental (o
CORFU development process);
Tranoris e Thramboulidis (2003a): mostra a ferramenta CORFU
Engineering Support System (ESS), que pode ser dividida em dois
subsistemas: uma ferramenta para auxílio à engenharia de software, que
nesse caso é a IBM Rational Rose, e outra chamada CORFU-FBDK, que
é composta por: biblioteca de blocos funcionais pré-definidos, editor de
blocos funcionais, editor de diagramas de blocos funcionais, editor da
camada de sistema e pelo gerenciador do recurso de transformação
(Transformation Facility Manager - TFM).
Tranoris e Thramboulidis (2003b): exibe outros aspectos da ferramenta
CORFU ESS, cuja função é fazer interface com a ferramenta IBM
Rational Rose, transformar seus diagramas em modelos baseados em
abstrações da norma IEC 61499 (através da aplicação de um conjunto de
regras de transformação) e fornecer meios para a continuidade do
desenvolvimento de projetos em um ambiente que emprega somente os
conceitos de sistemas de automação vistos na norma IEC 61499;
Dubinin, Vyatkin e Pfeiffer (2005): cita os conversores UML-FB e FB-
UML, que passam as descrições de sistemas em UML para diagramas
de abstrações da norma IEC 61499 e vice-versa (segundo o que é
descrito na linguagem UML-FB);
Software Engineering Group (2005): mostra o funcionamento da
ferramenta Archimedes ESS, a qual fornece suporte ao desenvolvimento
de modelos baseados nas abstrações da norma IEC 61499 e sua
subseqüente transformação para sistemas executáveis;
Čengić, Ljungkrantz e Åkesson (2006): mostra a ferramenta FUnction
Block Execution Runtime (Fuber), a qual pode ser utilizada para
descrever e executar sistemas baseados em abstrações da norma IEC
61499. Seu principal diferencial em relação às outras ferramentas é que
o comportamento de uma aplicação pode ser modificado durante a sua
execução, já que os seus algoritmos não são previamente compilados, e
32
sim interpretados;
Chouinard e Brennan (2006): descreve algumas das funcionalidades da
ferramenta comercial ISaGRAF, que permite o desenvolvimento de
sistemas baseados em abstrações da norma IEC 61499, assim como a
simulação do sistema e a distribuição dos blocos funcionais entre os
dispositivos, por exemplo;
Dai, Shih e Vyatkin (2006): mostra o estado do projeto Open, Object-
Oriented kNowledge Economy for Intelligent Distributed Automation
(OOONEIDA) Workbench, cujo objetivo é a criação de uma ferramenta
(chamada FBench), de código aberto, para dar suporte ao
desenvolvimento de aplicações compatíveis com o padrão IEC 61499
para sistemas de automação distribuídos;
Holobloc, Inc. (2006b): oferece diversos tutoriais sobre a norma IEC
61499 e abundante material sobre a ferramenta Function Block
Development Kit (FBDK), usada no suporte a projetos de sistemas de
automação distribuídos que utilizam os blocos funcionais da IEC 61499
como abstrações principais;
The University of Auckland, Research Centre for Embedded Intelligence
– CEMBI (2007): apresenta a ferramenta FBench, cujo objetivo é auxiliar
no processo de engenharia de sistemas e componentes baseados no
padrão IEC 61499. Ela permite a exibição, a edição e a interconexão de
blocos funcionais de forma gráfica, e também realiza a transformação
dos mesmos para a linguagem Java (o que viabiliza a simulação da
aplicação como um todo); e
Zoitl e Strasser (2007): explica a função das ferramentas Framework for
Distributed Industrial Automation and Control-Integrated Development
Environment (4DIAC-IDE) – ambiente de engenharia em que a descrição
de hardware de um sistema de automação é feita em Field Device
Configuration Markup Language (FDCML) e a descrição de software é
feita em blocos funcionais da norma IEC 61499 – e 4DIAC-Run-time
Environment (4DIAC-RTE ou FORTE) – ambiente de execução em
tempo real para o software citado anteriormente.
33
1.3. OBJETIVOS
Diante desse cenário, os objetivos a serem alcançados nesta dissertação
são:
� Detalhar as principais técnicas recentemente disponibilizadas para fazer o
mapeamento entre diagramas da UML e diagramas de abstrações da norma
IEC 61499, bem como seus pré-requisitos e restrições, fornecendo, ao fim,
uma comparação entre elas e sugestões de extensão quanto à possibilidade
de expressão de requisitos relacionados a qualidade de serviço (Quality of
Service – QoS); e
� Estudar as ferramentas descritas na Justificativa (item 1.2) para entender
quais são suas funcionalidades, como elas se inter-relacionam, e qual seu
nível de cobertura quanto à norma IEC 61499 e, além de fornecer uma
comparação entre elas, propor extensões a essas ferramentas, seja para
melhorar a expressividade do mapeamento entre diagramas da UML e
diagramas de abstrações da norma IEC 61499, seja para cobrir outras
necessidades relativas a ferramentas de suporte ao desenvolvimento de
sistemas de automação distribuídos (como a sua interação e aplicação a
redes de automação específicas – por exemplo, à tecnologia LonWorks).
1.4. ORGANIZAÇÃO DO DOCUMENTO
O presente documento é organizado através dos seguintes capítulos:
� Capítulo 1 – Introdução: mostra a introdução, a justificativa e os objetivos da
dissertação;
� Capítulo 2 – Projeto de sistemas de automação distribuídos: faz o
detalhamento do que são sistemas de automação distribuídos e mostra
como as áreas de engenharia de sistemas e de software, e de engenharia
de controle e automação podem ser unificadas para cobrir todo o processo
de desenvolvimento desses sistemas;
34
� Capítulo 3 – Mapeamento de diagramas da UML em diagramas de
abstrações da norma IEC 61499: exibe as principais tendências para a
execução da transformação de diagramas da UML em diagramas de
abstrações da norma IEC 61499;
� Capítulo 4 – Ferramentas computacionais para suporte às atividades de
engenharia voltadas ao desenvolvimento de sistemas de automação
distribuídos: mostra algumas das ferramentas usadas para suporte às
atividades de engenharia dos sistemas de automação descritos através de
abstrações da norma IEC 61499, e descreve quais as suas principais
funcionalidades;
� Capítulo 5 – Proposta de extensões aos mapeamentos UML-IEC61499 e
ferramentas: sugere extensões aos mapeamentos entre abstrações da UML
e da norma IEC 61499 e às ferramentas estudadas anteriormente (com
destaque para uma nova proposta de mapeamento UML-IEC61499, a
representação de requisitos de QoS em sistemas de automação descritos
através de diagramas da UML e de diagramas da norma IEC 61499, e para
a criação de uma ferramenta que permitisse a transposição entre os
elementos da norma IEC 61499 e as abstrações da tecnologia LonWorks); e
� Capítulo 6 – Considerações finais: exibe as conclusões, contribuições,
melhorias e trabalhos futuros a serem realizados a partir desta pesquisa.
1.5. CONSIDERAÇÕES SOBRE ESTILO E FORMATAÇÃO DO TEXTO
Para facilitar a leitura, optou-se por:
� Repetir o termo completo referente a cada sigla utilizada no texto a partir do
início de cada capítulo (como Unified Modeling Language para UML); e
� Não traduzir termos ou siglas consagrados em língua estrangeira (como
gateways e métodos get, por exemplo, ou FB para bloco funcional (function
block)).
Além disso, escolheu-se não adotar plural em caso de utilização de siglas
(por exemplo, Function Blocks é abreviado por FB, e não FBs).
35
2. PROJETO DE SISTEMAS DE AUTOMAÇÃO DISTRIBUÍDOS
Apresenta-se neste capítulo a definição de sistemas de automação,
incluindo a distinção entre sistemas centralizados, hierárquicos e distribuídos, e a
viabilidade de uso da tecnologia LonWorks para a implementação desses últimos. A
partir de então, discutem-se abordagens, técnicas e ferramentas para o
desenvolvimento de projetos, primeiramente do ponto de vista da engenharia de
sistemas e de software (em que são mostrados o paradigma de orientação a objetos
e a Unified Modeling Language (UML)), e posteriormente do ponto de vista da
engenharia de controle e automação (em que são expostas a modularização de
sistemas por meio de blocos funcionais e a norma International Electrotechnical
Commission (IEC) 61499). Por fim, conclui-se que tais abordagens, técnicas e
ferramentas, embora não sejam isoladamente suficientes, podem ser usadas de
forma complementar para fornecer cobertura completa às atividades de engenharia
do ciclo de vida de projetos de sistemas de automação. Entre diversos aspectos,
mostra-se a possibilidade de aproximação entre as modelagens dadas em UML
daquelas fornecidas em termos de abstrações da norma IEC 61499, por exemplo.
Ressalva-se que, embora este capítulo tenha se tornado extenso, optou-se
por expor de forma abrangente todos os conceitos que fundamentam o restante da
dissertação (a fim de dispensar consulta constante a outras referências).
2.1. SISTEMAS DE AUTOMAÇÃO
2.1.1. Definição
Segundo Samad, McLaughlin e Lu (2007), uma planta de processamento é
uma organização estruturada de elementos físicos, controlada por critérios
específicos da área de aplicação a que está vinculada, e que possui diversos
interessados ou envolvidos que podem afetar ou ser afetados por sua operação.
Entre os interessados ou envolvidos citados anteriormente, estão desde os
36
investidores da indústria, que visam ao seu alto rendimento, até aqueles que
trabalham nelas: segundo Åström (1985), os seres humanos participam desse
contexto agindo como operadores ou gerentes da planta.
No entanto, a ação do homem em ambientes complexos (muitas vezes com
restrições críticas de temporização), como o de uma planta de processamento, pode
não ser desejável:
O controle de um sistema complexo por um operador humano não éeficiente devido às inúmeras inter-relações entre as diversas variáveis. Noteque mesmo em um sistema simples um controlador automático eliminaráquaisquer erros humanos de operação. Se for necessária alta precisão decontrole, o controle deve ser automático. (OGATA, 1982)
Dessa forma, justifica-se o interesse pelo uso de sistemas de automação no
controle de processos. Segundo Samad, McLaughlin e Lu (2007), o sistema de
automação é vital para a operação das plantas de processamento, pois ele é
responsável por controlá-la e por desempenhar outras funções avançadas, como
otimização, agendamento e planejamento de produção. O sistema de automação
assegura que os parâmetros apropriados sejam medidos, que as situações
operacionais sejam analisadas, que oportunidades mais rentáveis sejam exploradas,
que ações de controle sejam calculadas e tomadas, que situações anormais sejam
identificadas e solucionadas, que os processos sejam integrados e que o pessoal da
planta seja sempre mantido informado sobre seu estado, e que seu conhecimento e
capacidades sejam utilizados de maneira adequada.
Todas as funções descritas acima são cumpridas tipicamente por duas
partes diferentes de um sistema de automação: o subsistema de controle de
processos e o subsistema de supervisão e gerenciamento. Este último, além de
realizar as funções de otimização, comunicação e planejamento, permite a visão e a
gestão global da planta e do subsistema de controle de processos por parte dos
operadores: as informações relevantes sobre os mesmos (como equipamentos em
modo de falha, exibidas através de interfaces homem-máquina, por exemplo),
ajudam em que o sistema de automação cumpra seus objetivos.
O sistema de controle de processos, por sua vez, no qual este trabalho
concentra seu foco, possui diversos componentes, e dentre esses os principais são
(AIHKISALO, 2002; ÅSTRÖM, 1985; SANTOS, 1979):
� Sensores, que medem variáveis relevantes, ou seja, revelam o estado de
um objeto ou processo automatizado;
37
� Atuadores, que executam ações, modificando o estado dos objetos; e
� Controladores (ou unidades de processamento), que tomam decisões
baseados nas informações dadas pelos sensores, cumprindo assim tarefas
de regulação (ou seja, comparam as medidas dadas pelos sensores com os
valores desejados, executam operações matemáticas e geram sinais de
correção, enviados para os atuadores).
Os sensores e atuadores são ligados às unidades de entradas e saídas de
sinais do sistema de controle de processos, que podem estar integradas com os
dispositivos controladores ou podem ser disponibilizadas em módulos (que permitem
sua fácil substituição). As unidades de entrada são usadas para levar os sinais dos
sensores aos controladores, enquanto as unidades de saída exportam o sinal dos
controladores para os atuadores. Ambas partes fazem conversão e adequação dos
sinais por meio de transdutores, e sua escolha depende do tipo e quantidade de
sinais a serem tratados no sistema (sendo os principais tipos o analógico e o digital).
Finalmente, o sistema de comunicação interliga todos os componentes do
sistema.
A partir deste ponto, o trabalho direciona seu foco apenas ao sistema de
controle de processos, e essa deve ser a interpretação dada à expressão “sistema
de automação”. Enquanto isso, o sistema de supervisão continuará sendo citado da
mesma maneira, caso necessário.
Conforme pode ser visto em Åström (1985), a principal motivação para o uso
de controle de processos centraliza-se nas promessas de melhor qualidade dos
produtos, melhor uso de matérias-primas e energia, maiores volumes de produção,
melhores relatórios gerenciais, menores custos e menor poluição ambiental. No
entanto, todas essas vantagens são difíceis de se justificar quantitativamente, ao
contrário do que ocorre com a verificação de uma melhor regulação do sistema,
menores tempos de mudança em sua funcionalidade e melhor controle da planta e
seus subprocessos. Já em Ogata (1982), vê-se que, desde que os avanços na teoria
e na prática de controle automático propiciam meios para atingir-se desempenho
ótimo de sistemas dinâmicos e eliminação de operações manuais repetitivas
(levando a menos erros no sistema), a maioria dos engenheiros e cientistas que
atuam nesta área devem entender e conhecer bem este campo.
38
2.1.1.1. Sistemas de automação predial
Uma das áreas de aplicação dos sistemas de automação é em edifícios
inteligentes, cujos principais objetivos, segundo Clements-Croome (1997), Gustin
(2005) e Wong, Li e Wang (2005), podem ser agrupados da seguinte maneira:
● Quanto a aspectos de requisitos de usuário: oferecer ambientes produtivos,
confortáveis, saudáveis, seguros (em termos patrimoniais, individuais e de
dados, contra danos por incêndios, terremotos, desastres e danos
estruturais, entre outros), flexíveis (quanto ao uso do espaço), eficientes e
eficazes, de maneira a assegurar satisfação, bem-estar e suporte às
atividades criativas, intelectuais e espirituais de seus ocupantes; ser
aderentes à realidade cultural e social em que estão inseridos, além de
adaptáveis a mudanças nesse âmbito; ser ambientalmente sustentáveis
(pela otimização do uso de recursos – incluídos a utilização de insumos
(como energia elétrica) e a devolução de dejetos ao meio ambiente);
minimizar seus custos em investimento, operação e manutenção; e passar a
idéia de avanço tecnológico (para aumentar seu valor de mercado); e
● Quanto a aspectos tecnológicos: permitir o controle automatizado, a
monitoração, o gerenciamento, a operação local e/ou remota e a
manutenção dos diferentes sistemas do edifício, de forma integrada e
mantendo alto desempenho, confiabilidade, robustez, adaptabilidade (às
exigências do ambiente e dos ocupantes), flexibilidade e escalabilidade
(para possibilitar a incorporação de novos sistemas e/ou modificação das
funções); e ter projeto e implementação consistentes com seus requisitos
tecnológicos e de uso, de curto e longo prazo, levantados junto a todos os
interessados, para garantir que não ocorra sua obsolescência antes de se
obter o retorno do investimento.
Para alcançar todas essas metas com elevado grau de autonomia, os
edifícios inteligentes devem garantir o inter-relacionamento e a integração entre
todos os seus componentes, incluindo sua estrutura (arquitetura interior e exterior),
sistemas (construídos a partir de tecnologias das áreas mecânica, elétrica,
mecatrônica, civil e da computação ou informação), serviços, elementos de
gerenciamento e ocupantes, no sentido de que os mesmos atuem cooperativamente
como uma entidade coesa.
39
Um dos sistemas que participa dessa integração é o sistema de automação
predial, cuja função é permitir a troca de informações e a atuação conjunta de
diversos subsistemas que dão suporte à operação dos edifícios, como os de
aquecimento, ventilação e condicionamento de ar (Heating, Ventilating and Air
Conditioning – HVAC), segurança (contra incêndios e para proteção da vida),
transporte, elevadores, iluminação, drenagem e abastecimento de água, controle de
acesso, telecomunicações e processamento de dados.
2.1.2. Histórico
A evolução tecnológica dos sistemas de automação é detalhada a seguir a
partir das descrições de Åström (1985) e Samad, McLaughlin e Lu (2007):
� Passagem dos sistemas pneumáticos à utilização de padrões elétricos
(como a norma 4-20mA) na interligação de sensores e atuadores aos seus
respectivos controladores, sendo estes constituídos por componentes
elétricos discretos;
� Separação dos sistemas de automação, até então monolíticos, em diversos
dispositivos (como sensores, transdutores, reguladores e atuadores)
intercambiáveis e produzidos em larga escala, a partir de componentes
padronizados;
� Uso de computadores nos sistemas de automação, embora inicialmente
para fins de supervisão, alarme, armazenamento de dados, estabelecimento
de boas condições de operação (otimização estática), agendamento de
tarefas, planejamento de produção e geração de relatórios (anos 50);
� Uso de computadores para controle dos sistemas de automação
(constituindo o que se conhece por controle digital direto, ou Digital Direct
Control – DDC) (anos 60);
� Surgimento dos controladores lógicos programáveis (CLP), computadores
especiais para a realização de funções seqüenciais e lógicas no campo, e
posteriormente dos primeiros sistemas de automação distribuídos, em que
cada um de seus dispositivos computacionais espalhados pela planta
realizava parte do processamento atribuído ao sistema. Paralelamente, dá-
se o início do uso de redes de controle para unir as possíveis unidades de
entrada e de saída dos CLP aos mesmos (substituindo as interligações
40
elétricas tradicionais) e para conectar os módulos dos sistemas distribuídos2
(anos 70);
� Integração e constituição de sistemas abertos baseados em redes (anos 80);
� Uso de padrões da tecnologia da informação e arquiteturas centradas em
aplicação nos sistemas de automação (anos 90); e
� Previsão, a partir deste ponto, do uso intensivo de redes de comunicação
sem fio, da disponibilização de infraestrutura para aplicações avançadas, e
do surgimento de sistemas colaborativos de automação de processos
(Collaborative Process Automation Systems – CPAS), em que informações
contextuais são diretamente intercambiadas entre as aplicações de um
sistema de automação em tempo real.
Devido a essa evolução histórica, surgiu a distinção entre sistemas de
automação centralizados, hierárquicos e distribuídos, sendo essa segmentação
referente à localização tanto das aplicações lógicas quanto dos módulos físicos dos
sistemas. No entanto, ressalta-se que, entre esses, o parâmetro mais importante
para a classificação é a distribuição do processamento nos sistemas de automação.
2 De acordo com Echelon Corporation (1999), redes de controle são sistemas digitais decomunicação que permitem a um grupo de dispositivos intercambiar mensagens curtas, emtopologia ponto-a-ponto, e se caracterizam principalmente pela confiabilidade e segurança. Asredes de controle, assim, são similares a redes comuns de transmissão de dados, mas sãootimizadas para o custo, o desempenho, o tamanho e as restrições temporais próprias de seudomínio de aplicação.
Figura 1: Diferentes estruturas de sistemas: centralizada (a), hierárquico (b) e distribuído (c) –adaptado de Åström (1985).
41
2.1.2.1. Sistemas de automação centralizados e hierárquicos
Em um sistema de automação centralizado, todos os sensores e atuadores
fazem interface direta com um sistema central (MAHALIK; LEE, 2002). Os
controladores possuem microprocessadores de alto desempenho que processam a
aplicação, em que é implementada a lógica de controle para todos os pontos de
entrada e saída conectados a ele (já que sensores e atuadores não possuem por si
nenhum processamento interno ou capacidade de comunicação), e podem, algumas
vezes, trocar informações entre si (ECHELON CORPORATION, 1999). Como visto
em Aihkisalo (2002), um dos exemplos de sistemas desse tipo são aqueles
implementados com CLP, computadores de pequeno porte, com sistema operacional
de tempo real, dedicados apenas à automação de processos.
Apesar dos sistemas de automação centralizados serem adequados para
casos em que é necessária sincronização em tempo real ou grande fluxo de dados
entre dispositivos (XIE; PU; MOORE, 1998) e de terem a seu favor o fato de suas
aplicações serem mais fáceis de se conceber – já que neste caso, segundo Åström
(1985), é mais simples implementar as interações entre os laços de controle, Mahalik
e Lee (2002) afirmam que o uso de sistemas de automação centralizados também
acarreta algumas desvantagens, como o problema de falha central (em que o
sistema de automação falharia ou pararia por completo se o controlador fosse de
alguma forma danificado) e a impossibilidade de atender os sinais e mensagens
provenientes dos dispositivos de campo, dentro de certos requisitos temporais, caso
fosse mal dimensionado. Adicionalmente, os sistemas centralizados apresentam
problemas quanto ao cabeamento (já que este é extenso e, além de caro, pode
provocar perdas de informação) (AIHKISALO, 2002).
Por outro lado, os sistemas de automação hierárquicos são aqueles em que
controladores supervisórios (gateways) intercambiam informações entre si,
usualmente através de uma rede de controle, para conectar sistemas de automação
isolados (ECHELON CORPORATION, 1999).
Apesar de representar uma vantagem em termos de distribuição de
funcionalidade e pela integração de sistemas antes independentes (como os
sistemas legados), as desvantagens dos sistemas hierárquicos, segundo Echelon
Corporation (1999) e Wang et al. (2004), centralizam-se no fato dos gateways serem
soluções proprietárias, de difícil construção, configuração e manutenção, que não
42
somente diminuem o tempo de resposta dos sistemas como ainda não permitem
comunicação entre/com os dispositivos da planta (o que dificulta a implementação
dos algoritmos de controle). Portanto, nota-se que os sistemas de automação
hierárquicos ainda oferecem dificuldades quando da necessidade de expansão, já
que não são tão flexíveis quanto o ideal.
2.1.2.2. Sistemas de automação distribuídos
Finalmente, um sistema de automação distribuído consiste de dispositivos
ditos inteligentes, os quais se comunicam diretamente entre si através de um ou
mais canais de comunicação (normalmente uma rede de controle), usando um
protocolo comum (AIHKISALO, 2002; ECHELON CORPORATION, 1999;
CAUFFRIEZ et al., 2004). Neste contexto, assim como definido em Xie, Pu e Moore
(1998), o termo “dispositivo inteligente” refere-se à existência de uma unidade de
processamento no dispositivo, que lhe permite responder a eventos externos em
uma forma pré-definida, seja matemática ou lógica. Assim, em um sistema
descentralizado é possível realizar o processamento dos dados localmente em cada
laço de controle (ÅSTRÖM, 1985). Vale destacar ainda que, além da capacidade de
cumprir requisitos de tempo real, Mahalik e Lee (2002) ressaltam a importância dos
sistemas de automação distribuídos possuírem, normalmente, dispositivos com
capacidade de auto-diagnóstico e auto-manutenção.
A partir dessa descrição inicial, segue-se para a listagem dos principais
componentes de um sistema distribuído, que compreende, segundo Echelon
Corporation (1999), Mahalik e Lee (2002) e Xie, Pu e Moore (2002):
● Os dispositivos de campo, que são sensores e atuadores sem capacidade
de processamento;
● Os módulos ou nós computacionais, que são os dispositivos responsáveis
por realizar o processamento de dados e a implementação de protocolos de
comunicação, quando necessário. Eles se caracterizam por possuir um ou
mais microprocessadores, transceptores para o meio de comunicação,
dispositivos para armazenamento de dados (memórias), portas de entrada e
saída de dados (para interconectá-los aos dispositivos de campo) e módulos
para adaptação ou conversão de sinais. Os módulos ou nós contém
aplicações (software), que, conjunta e cooperativamente, cobrem todas as
43
funcionalidades necessárias ao sistema de automação. Por fim, vale
destacar que principalmente quando tais módulos estão encapsulados junto
a um dispositivo de campo, provendo a este capacidade de processamento,
os mesmos são conhecidos por dispositivos inteligentes – smart devices ou
intelligent devices;
● O meio ou canal de comunicação, que serve como base para a troca de
dados entre todos os dispositivos do sistema de automação (seja de forma
digital ou analógica). De acordo com o seu tipo (por exemplo, fibra óptica,
cabo coaxial, par trançado, etc.), o meio de comunicação oferece
características físicas distintas – que impactam na topologia da rede e na
velocidade e distância de transmissão, por exemplo, condicionando a
escolha do projetista do sistema.
Figura 2: Estrutura geral de um sistema de automação distribuído.
Figura 3: Composição interna de um nó pertencente a um sistema de automação distribuído.
44
De acordo com as características apresentadas anteriormente, as principais
vantagens dos sistemas de automação distribuído, a partir dos textos de Aihkisalo
(2002), Echelon Corporation (1999), Mahalik e Lee (2002), Samad, McLaughlin e Lu
(2007) e Xie, Pu e Moore (1998) concentram-se em: cabeamento simplificado; maior
eficiência, robustez e disponibilidade devido à diminuição dos atrasos de controle
(dada a execução local das aplicações de controle), além de facilidade de
implementação e bom desempenho (em termos de sincronização e consistência das
aplicações); maior confiabilidade (pela multiplicidade de nós de processamento
(cada qual com segmentos da aplicação de controle), que minimiza as chances de
haver um ponto central de falha que afete todo o sistema); maior escalabilidade (já
que aceitam a inserção de novos nós para a expansão gradual de suas
capacidades, o que causa menor impacto nos custos iniciais de implementação); e
maior flexibilidade para a adaptação ou alteração do sistema para uma grande
variedade de aplicações, já que a troca ou modificação dos módulos individuais de
software não afeta o seu funcionamento global. Por fim, deve-se ressaltar que os
contínuos estudos sobre de redes de controle que garantam boa qualidade de
serviço – como pode ser visto em Neumann ([2006]) – ajudam a afastar
preocupações com a possibilidade desses sistemas não atenderem restrições
estritas de temporização. Portanto, devido a todas essas vantagens dos sistemas
distribuídos sobre os sistemas centralizados ou hierárquicos, este trabalho direciona
seu foco para os primeiros.
2.1.2.2.1. A tecnologia LonWorks
Segundo Mahalik e Lee (2002), a tecnologia LonWorks (ou simplesmente
LON), desenvolvida pela empresa Echelon Corporation entre as décadas de 80 e 90,
tem como objetivo fornecer uma solução completa para o projeto, a implantação e a
manutenção de sistemas de controle e automação distribuídos. Para que isso seja
possível, estão previstos pela tecnologia LonWorks, conforme Mahalik e Lee (2003),
o microprocessador denominado Neuron Chip, transceptores para diversos meios de
comunicação (como cabo coaxial, par trançado, rede de transmissão de energia
elétrica e fibra ótica) e múltiplas taxas de transmissão, além de ferramentas de
desenvolvimento (que abrangem desde a geração das aplicações ao gerenciamento
da rede).
45
Em um sistema LonWorks, diversos nós, responsáveis pela execução das
tarefas de controle e automação, interagem através de uma rede digital e
bidirecional. Tais dispositivos são usualmente constituídos pelo processador Neuron
Chip, um transceptor para o meio de comunicação, e circuitos eletrônicos
específicos para a sua aplicação (HUR; KIM; PARK, 2005).
Segundo Hur, Kim e Park (2005), o Neuron Chip, processador de 8 bits de
muito alta escala de integração (Very Large Scale Integration – VLSI), é composto
internamente por memória somente para leitura (Read-Only Memory – ROM), três
subprocessadores, interface de comunicação e interfaces (portas) de entrada e
saída configuráveis. Ele também possui ou interage com uma memória de acesso
randômico (Random Access Memory – RAM).
A ROM contém o firmware do Neuron Chip, que inclui o seu sistema
operacional (agendador de tarefas), o protocolo de comunicação entre dispositivos
padronizado pela tecnologia LonWorks (chamado LonTalk) e uma biblioteca para
facilitar o uso das portas de entrada e saída do processador, a ser empregada pelo
usuário ao elaborar a aplicação do Neuron Chip (HUR; KIM; PARK, 2005; XIE; PU;
MOORE, 1998). O protocolo de comunicação LonTalk permite que os dispositivos do
ambiente de controle possam se comunicar uns com os outros, por meio do
intercâmbio de pacotes, em uma topologia ponto a ponto. Para isso, cada dispositivo
pode ser endereçado por um endereço físico – o Neuron ID, atribuído a cada Neuron
Chip, ou lógico – configurado através de ferramentas de gerenciamento de rede
(AIHKISALO, 2002). O protocolo LonTalk é aberto, padronizado (padrão American
National Standard Institute / Electronic Industries Alliance / Consumer Electronics
Association 709.1 – ANSI/EIA/CEA 709.1), e provê os serviços essenciais de todas
as sete camadas do modelo de referência para interconexão de sistemas abertos
especificada pela International Organization for Standardization (International
Organization for Standardization / Open Systems Interconnection – ISO/OSI).
Quanto aos processadores internos do Neuron Chip, verifica-se, segundo
Xie, Pu e Moore (1998), que os mesmos possuem diferentes funções: o processador
de acesso ao meio provê os serviços referentes às camadas um e dois do modelo
ISO/OSI (incluindo o controle do hardware de comunicação e a execução do
algoritmo de evitação de colisões), o processador de rede implementa das camadas
de três a seis do modelo ISO/OSI (ou seja, responsabiliza-se pelo processamento
das variáveis de rede intercambiadas entre as aplicações dos dispositivos, pelo
46
endereçamento dessas mensagens, pelo processamento de transações, pela
autenticação, pelo diagnóstico, pelos temporizadores de software, pelo
gerenciamento da rede e por funções de roteamento), e, por fim, o processador de
aplicações executa o código escrito pelo usuário, vinculado às tarefas de automação
e controle.
Já a aplicação de automação e controle dos dispositivos fica guardada na
memória RAM do Neuron Chip, que também grava seus dados de configuração.
Todos esses dados são descarregados por meio da própria rede de comunicação
LonWorks no dispositivo, com a ajuda de ferramentas de gerenciamento de rede e
desenvolvimento de aplicações (HUR; KIM; PARK, 2005).
Do ponto de vista lógico, em um sistema LonWorks cada dispositivo deve
executar as suas próprias funções e intercambiar dados com os demais para que o
sistema de automação cumpra seu objetivo. Como será visto em maiores detalhes
no capítulo 5, a aplicação de cada dispositivo é modularizada em blocos funcionais,
e cada bloco funcional possui variáveis de entrada e saída denominadas variáveis
de rede (network variables – NV). Essas variáveis de rede, quando do mesmo tipo e
sentidos opostos, podem ser conectadas logicamente através de um processo
chamado binding, para permitir a intercomunicação das aplicações. Adicionalmente,
cada bloco funcional pode conter propriedades de configuração (configuration
properties – CP), que são variáveis para a configuração de variáveis de rede, blocos
funcionais ou dispositivos.
Do ponto de vista de elaboração das aplicações, Mahalik e Lee (2003)
afirmam que o Neuron Chip pode ser programado utilizando a linguagem Neuron C,
derivada da linguagem ANSI C. Essa linguagem de programação é orientada a
objetos, e possui comandos de comunicação específicos para o envio de
mensagens do protocolo LonTalk (AIHKISALO, 2002). Outras ferramentas permitem
a programação para dispositivos LonWorks sem a escrita de código em Neuron C
(ou seja, de maneira gráfica), como é o exemplo da ferramenta TAC Menta
(TOURANDOVERCONTROLS, 2006).
2.1.3. Necessidades latentes dos sistemas de automação distribuídos
Nota-se neste ponto que a modularidade dos sistemas de automação
distribuídos é um de seus grandes trunfos, e se baseia na divisão da funcionalidade
47
global do sistema: as subaplicações são distribuídas entre nós de processamento, e
assim, ao invés de existir uma única aplicação monolítica, lida-se na verdade com
diversos módulos de software, descritíveis por uma interface bem definida, que
interagem e cooperam entre si para que o sistema como um todo atinja seus
objetivos. Ao mesmo tempo em que é extremamente benéfico, vê-se que o
particionamento da aplicação é uma tarefa muito complexa, já que diversos fatores
influenciam as decisões dos projetistas, entre eles os requisitos funcionais e não-
funcionais do sistema (como necessidade de manutenibilidade e qualidade de
serviço), as características dos nós (quanto a entradas e saídas físicas conectadas a
eles e capacidade de processamento, por exemplo) e a própria experiência do
pessoal responsável.
Como a escolha incorreta dessas subdivisões pode levar o sistema de
automação a não ser concebido da melhor maneira e apresentar os mesmos
inconvenientes de sistemas de automação centralizados, percebe-se a necessidade
de que tal processo seja guiado adequadamente: Além disso, é fundamental que
ferramentas adequadas forneçam suporte a esse processo. Alguns trabalhos na
área de sistemas de automação embasam estas idéias: a necessidade de
abordagens de modelagem e análise de sistemas de automação prediais, por
exemplo, é levantada por Gustin (2005); a necessidade de ferramentas de projeto
para guiar a distribuição da “inteligência” nos sistemas de automação, e o uso
provável de componentes para a geração de software (conceito de orientação a
objetos) é manifestada por Xie, Pu e Moore (1998); e a necessidade de ferramentas
e técnicas para a realização da descentralização das tarefas de controle também é
destacada por Mahalik e Lee (2002).
2.2. CICLO DE VIDA DE PROJETO DE SISTEMAS DE AUTOMAÇÃO
DISTRIBUÍDOS
Para analisar quais os métodos e as ferramentas que poderiam assistir o
processo de desenvolvimento de sistemas de automação distribuídos, podemos
tentar encontrar respostas em duas áreas: na própria área de engenharia de
48
controle e automação, e também na área de engenharia de software (e de sistemas
em geral). Cada uma dessas áreas apresenta uma maneira distinta de tratar o
problema de desenvolvimento de um sistema, possuindo ciclos de vida, métodos
para divisão do sistema (e do software) em módulos e linguagens peculiares. No
entanto, como será visto adiante, nenhuma dessas áreas consegue oferecer uma
solução completa para tratar todo o projeto de desenvolvimento de um sistema de
automação. Apesar disso, é possível encontrar fatores comuns entre as abordagens
dessas duas áreas, o que permite aproximá-las e fazer com que uma complemente
as deficiências da outra.
Apresenta-se, a partir de então, as abordagens da engenharia de software e
da engenharia de controle e automação para o projeto de sistemas de automação
distribuídos.
2.2.1. Projetos de engenharia de software
2.2.1.1. Ciclos de vida de engenharia de software e suas atividades
No desenvolvimento de sistemas, os termos método de desenvolvimento de
sistemas, ciclo de vida de projeto e ciclo de desenvolvimento de sistemas podem ser
usados alternativamente. Uma das principais funções de um método de
desenvolvimento é estabelecer as atividades a serem executadas para que o
sistema possa ser implementado (YOURDON, 1990). Alguns exemplos dos ciclos de
vida que foram propostos para o desenvolvimento de sistemas de software,
juntamente a suas características principais, são detalhados abaixo:
� Clássico, convencional ou em cascata: adota a abordagem de composição
modular (bottom-up) para o projeto de sistema, com execução linear e
seqüencial das atividades de projeto;
� Estruturado: uso da abordagem de decomposição modular (top-down) para
o projeto do sistema, com possibilidade de desenvolvimento concorrente de
atividades;
� Prototipação: construção de um modelo executável do sistema previamente
à utilização do método clássico de desenvolvimento;
� Espiral: elaboração de um modelo evolutivo do projeto (dada pela
construção de uma sucessão de protótipos e pela resolução incremental das
49
especificações de projeto), até a obtenção de um sistema com nível de
refinamento suficiente; e
� Processo Unificado: desenvolvimento iterativo e incremental do sistema,
guiado por seus casos de uso, com foco na determinação da arquitetura e
na resolução dos principais riscos de projeto nas fases iniciais do sistema.
Independentemente das diferenças de enfoque de cada um desses
métodos, algumas atividades técnicas (não-gerenciais) de desenvolvimento de
projeto podem ser consideradas comuns (adota-se aqui uma simplificação das
descrições de Yourdon (1990) para as mesmas):
� Levantamento (Eliciação) de requisitos: estudo inicial da viabilidade e das
necessidades do projeto;
� Análise: especificação estruturada do projeto, envolvendo normalmente a
modelagem do sistema, a partir dos dados obtidos durante o levantamento
de requisitos;
� Projeto: determinação da forma pela qual o projeto deve ser implementado,
com a obtenção (em nível lógico) da hierarquia e das interfaces dos módulos
de software a representarem o sistema, além da previsão de sua distribuição
em processadores;
� Implementação: codificação e integração progressiva do software;
� Testes: verificação e validação do sistema (ou seja, constatação de que as
necessidades dos interessados, obtidas durante a atividade de levantamento
de requisitos, estão correta e completamente atendidas pelo software); e
� Instalação: colocação do software no ambiente de execução previsto no
projeto do sistema.
Apesar de não ser citada por Yourdon (1990), a atividade de manutenção
pode ser incluída à lista acima: nesta, controla-se o estado do sistema instalado e se
oferece suporte à sua utilização (não somente no sentido de auxílio ao uso, como
para correção de falhas). Algumas vezes, essa fase é propícia para o levantamento
de novas necessidades dos usuários e outros interessados tendo em vista o início
de um novo projeto ou geração de uma nova versão do sistema.
50
2.2.1.2. Separação de sistemas em módulos: orientação a objetos
De acordo com o disposto na descrição da atividade de análise, uma de
suas tarefas é executar a divisão lógica do sistema em módulos e a determinação da
hierarquia entre eles. Atualmente, uma das formas mais comuns de se realizar essa
tarefa é adotando técnicas de orientação a objetos. Yourdon e Argila (1999) citam
que essa abordagem sugere a estruturação dos programas de computador de
acordo com o problema a ser resolvido, e destacam que, embora o termo
“orientação a objetos” tenha sido empregado de muitas maneiras distintas, ele
sempre sugere uma associação entre abstrações de elementos do mundo real e
trechos correspondentes de software denominados objetos (entidades
independentes, assíncronas e concorrentes que armazenam dados, encapsulam
serviços e trocam mensagens entre si a fim de garantir a execução das funções
pretendidas para o sistema como um todo). Complementarmente, Nerson (1992)
observa que, na análise orientada a objetos, busca-se identificar os tipos de objetos
que podem ser mapeados nos elementos do domínio de aplicação as ser
representado, o que facilita o levantamento dos principais relacionamentos entre os
diferentes tipos de objetos. A vantagem mais relevante do uso das técnicas de
orientação a objetos é a possibilidade de reuso, não somente da codificação do
software, mas também dos demais componentes do ciclo de vida de um projeto –
como os requisitos levantados e arquiteturas projetadas (YOURDON; ARGILA,
1999). No artigo de Armstrong (2006), são identificados oito conceitos fundamentais
da orientação a objetos:
� Objeto: item individual e identificável, real ou abstrato, que contém dados
sobre si e descrições de suas possibilidades de manipulação desses dados;
� Classe: descrição da organização e das ações apresentadas por um ou mais
objetos similares;
� Abstração: ato de criar classes para simplificar aspectos da realidade
usando distinções inerentes ao problema;
� Herança: mecanismo que permite que os dados e o comportamento de uma
classe sejam incluídos ou usados como base de uma nova classe;
� Método: mecanismo que permite acessar, registrar ou manipular as
informações de um objeto;
� Passagem de mensagem: processo pelo qual um objeto envia dados a outro
51
objeto ou solicita a esse objeto a execução de um método;
� Polimorfismo: habilidade em que diferentes classes respondem a uma
mesma mensagem e implementam seu método apropriadamente; e
� Encapsulamento: técnica para projetar classes e objetos que restrinjam
acesso a seus dados e comportamento por meio da definição de um
conjunto estrito de mensagens que estejam habilitados a receber.
Para facilitar o entendimento do tema, Armstrong (2006) propõe também
uma taxonomia para a orientação a objetos, em que os citados conceitos são
separados em dois grupos e relacionados entre si:
� Os termos objeto, classe, abstração, herança e encapsulamento, centrados
no relacionamento entre classes e objetos e os mecanismos que dão
suporte à estrutura classe/objeto, são agrupados do conjunto Estrutura (já
que uma classe é uma abstração de um objeto; uma classe ou um objeto
encapsulam dados e comportamento; e a herança permite que os dados e
comportamentos encapsulados de uma classe sejam baseados em uma
outra classe existente); e
� Os termos método, passagem de mensagem e polimorfismo, dirigidos à
descrição das ações dos objetos no sistema, são agrupados no conjunto
Comportamento, já que a passagem de mensagem é um processo em que
um objeto envia informações para outro objeto ou invoca um de seus
métodos; e o polimorfismo permite que diferentes objetos respondam a uma
mesma mensagem e implementem o método apropriado para aquele objeto.
2.2.1.3. Modelagem dos conceitos de orientação a objetos: UML
Uma das linguagens que permitem a representação de sistemas concebidos
segundo técnicas de orientação a objetos é a UML. A UML é uma linguagem visual
e, embora usualmente seja empregada para modelar sistemas de software, pode ser
utilizada para visualizar, especificar, construir e documentar artefatos de sistemas
dos mais diversos domínios (BOOCH; RUMBAUGH; JACOBSON, 1998). Ainda que
sua criação deva-se, inicialmente, aos pesquisadores Booch, Jacobson e Rumbaugh
– os quais unificaram seus métodos de modelagem, chamados, respectivamente,
Booch, Object-Oriented Software Engineering (OOSE) e Object Modeling Technique
(OMT), a UML foi adotada como padrão em 1997 pelo Object Management Group
52
(OMG) e é atualmente mantida por esse órgão. Segundo Bordbar, Derrick e Waters
(2002), ela se tornou o padrão de facto na representação de sistemas concebidos
segundo as técnicas de orientação a objetos.
A modelagem em UML é independente de um processo de desenvolvimento
em particular (embora encaixe-se mais adequadamente em um processo centrado
em arquitetura, guiado por casos de uso e iterativo e incremental, como é o caso do
Processo Unificado). A UML também prevê mecanismos para estender sua
capacidade de expressão, o que a torna bastante flexível: ela tanto pode ser
personalizada para domínios de aplicação definidos quanto pode ser associada a
outras linguagens. Por fim, deve-se ressaltar que há uma grande quantidade de
ferramentas de mercado que dão suporte à geração de modelos da UML (tais como
o IBM Rational Rose e o Microsoft Visio).
O destaque da UML nos campos da engenharia de sistemas e de software
deve-se ao fato de ser uma linguagem expressiva, muito conhecida, de aplicação
geral e fácil compreensão (mesmo entre pessoal não técnico). Conforme pode ser
visto em Booch, Rumbaugh e Jacobson (1998), através dos diagramas definidos
pela UML pode-se modelar aspectos estáticos e dinâmicos dos sistemas, e
organizar os elementos de interesse segundo as perspectivas de casos de uso, de
projeto, de processo, de implementação e de distribuição (deployment) (cinco visões
complementares).
2.2.1.3.1. Diagramas da UML
Os diagramas da UML podem ser subdivididos em duas categorias:
diagramas estruturais (utilizados para a visualização das partes estáticas de um
sistema) e diagramas comportamentais (utilizados para a visualização das partes
dinâmicas de um sistema).
Até a UML versão 1.X, estavam definidos nove diagramas básicos: quatro
diagramas estruturais, sendo eles o Diagrama de Classes, o Diagrama de Objetos, o
Diagrama de Componentes e o Diagrama de Distribuição (Deployment), e cinco
diagramas comportamentais, dentre os quais estão o Diagrama de Casos de Uso, o
Diagrama de Máquinas de Estados, o Diagrama de Atividades, e, finalmente, o
Diagrama de Seqüência e o Diagrama de Colaboração – sendo esses dois isomorfos
e denominados coletivamente como Diagramas de Interação (BOOCH;
53
RUMBAUGH; JACOBSON, 1998). A partir da publicação da UML versão 2.X, no
entanto, ficaram definidos, ao todo, treze diagramas fundamentais: seis diagramas
estruturais (já que surgem o Diagrama de Estruturas Compostas e o Diagrama de
Pacotes) e sete diagramas comportamentais (pois são adicionados dois Diagramas
de Interação – o Diagrama de Visão Geral das Interações e o Diagrama de
Temporização, enquanto que o Diagrama de Colaboração passa-se a chamar
Diagrama de Comunicação) (SPARX SYSTEMS PTY LTD., 2008).
Foge ao escopo deste trabalho apresentar um estudo aprofundado da UML,
especialmente se considerarmos a grande abrangência do tema. Dessa maneira,
prefere-se somente expor os conceitos da UML relevantes para os capítulos
subseqüentes deste trabalho, explorados através de alguns diagramas da UML. As
referências utilizadas para a elaboração das seguintes seções foram as de Booch,
Rumbaugh e Jacobson (1999) para os conceitos gerais da UML e UML1.X, e de
Sparx Systems Pty Ltd. (2008), para as abstrações da UML 2.X.
2.2.1.3.1.1. Diagramas Estruturais
2.2.1.3.1.1.1. Diagrama de Classes
O Diagrama de Classes é usado para mostrar uma visão estática de um
sistema. Os elementos primordiais nesse tipo de diagrama são as classes, sendo
que cada uma dessas descreve um conjunto de objetos que compartilham os
mesmos atributos, operações, relacionamentos e semântica.
Uma classe é um tipo de classificador da UML: em geral, um classificador é
um elemento de modelagem que pode possuir instâncias e que descreve
características estruturais (na forma de atributos) e comportamentais (na forma de
operações), comuns a todas elas. Outros classificadores são: interfaces, sinais, tipos
de dados, componentes, nós, casos de uso e subsistemas.
Por sua vez, uma instância é uma manifestação concreta de uma abstração,
para a qual um conjunto de operações podem ser aplicadas e possuidora de um
estado interno que guarda os efeitos de suas operações. As instâncias das classes,
especificamente, são chamadas de objetos.
Já um atributo representa uma propriedade de um classificador (um tipo de
dado ou estado compartilhado entre todas suas instâncias), além de apresentar
54
normalmente o intervalo de valores que as instâncias dessa propriedade podem
assumir.
Por outro lado, uma operação é a implementação de um serviço que pode
ser requisitado a qualquer instância de um certo classificador para modificar seu
comportamento – dado que, na maioria das vezes, invocar uma operação implica
modificação dos dados ou estados internos da instância. O nome da operação e
seus parâmetros (variáveis passadas na chamada do método ou retornadas por ele
– neste caso, denominadas mais especificamente de valores de retorno) são
conhecidos por assinatura da operação. Vale destacar que a UML distingue os
termos operação e método: este último representa a implementação de uma
operação, e fornece, portanto, um algoritmo executável para a mesma (geralmente
dado em uma linguagem de programação ou texto estruturado).
Finalmente, um detalhe importante associado a atributos e operações é a
sua visibilidade: a visibilidade caracteriza se o atributo ou operação pode ser
utilizada por outros classificadores da UML. Estão especificados três níveis de
visibilidade:
� Visibilidade pública (public): determina que qualquer classificador externo
visível ao presente classificador pode usar seu atributo ou operação
(símbolo usual: +);
� Visibilidade protegida (protected): especifica que qualquer descendente do
classificador pode usar seu atributo ou operação (símbolo usual : #); e
� Visibilidade privada (private): denota que somente o próprio classificador
pode usar seu atributo ou operação (símbolo usual: -).
Outros classificadores de interesse, comuns em Diagramas de Classe, são
as interfaces. Uma interface restringe-se a prescrever uma coleção de operações
usadas para especificar os serviços de uma classe ou componente. Ressalta-se, no
entanto, que as mesmas não especificam estruturas (ou seja, não incluem atributos),
nem qualquer tipo de implementação (como métodos, por exemplo). Quando uma
interface é implementada por uma classe ou componente, ela pode ser chamada de
interface exposta. Uma interface exposta fornecida por um classificador é mostrada
pela notação reduzida que se assemelha a um plugue (ou a um “pirulito” – lollipop), e
indica um relacionamento de realização entre eles. Já uma interface aceita por um
classificador (que especifica a aptidão do mesmo em se comunicar com outro
classificador que implemente essa interface) é dada pela notação reduzida parecida
55
a um soquete, e indica um relacionamento de dependência entre os mesmos.
Entre diversos elementos da UML podem ser especificadas conexões
denominadas relacionamentos. Dentre eles, podem ser citadas as dependências, as
generalizações, as associações e as realizações.
Uma dependência é um relacionamento de uso que indica que a modificação
na especificação de um elemento pode afetar o elemento que o utiliza, mas não
necessariamente o contrário. É denotada visualmente por uma seta de ponta aberta
e linha tracejada.
Uma generalização, por outra parte, é um relacionamento entre um
classificador mais geral e um classificador mais específico (os classificadores em
que há herança mais comumente são as classes, interfaces e pacotes). No caso das
classes, a generalização significa que a subclasse (ou classe filha) é um tipo
específico da superclasse (ou classe mãe), e que esta pode ser substituída pela
primeira. Quando uma classe possui exatamente uma classe mãe, diz-se que a
herança é simples; se houver mais de uma superclasse, a herança é dita múltipla.
Uma subclasse sempre herda as propriedades de sua(s) superclasse(s),
especialmente seus atributos e operações, mas freqüentemente as classes filhas
possuem atributos e operações a mais que as classes mães. Se a subclasse possuir
uma operação de mesma assinatura que a da superclasse, esta operação prevalece
à da superclasse (ocorrência chamada polimorfismo).
Uma associação é um relacionamento estrutural que especifica que
instâncias de um tipo estão conectadas a instâncias de outro tipo. Entre as classes,
as associações mais comuns conectam exatamente duas classes (associação
binária), mas pode haver associações conectando duas ou mais classes (ainda que
isso seja mais raro). Algumas características de uma associação são seu nome
(usado para descrever a natureza da relação), os papéis (que indicam qual o papel
que a classe ao final da associação representa perante a(s) outra(s) classe(s)
envolvida(s)) e a multiplicidade (que indica quantos objetos podem estar conectados
através de uma instância de uma associação). Um tipo especial de associação é a
agregação, a qual modela um relacionamento de uma classe representante de uma
parte para uma classe representante do todo.
Por fim, uma realização é um relacionamento semântico entre
classificadores, em que um deles especifica um contrato que o outro garante
satisfazer. Conforme visto anteriormente, esse tipo de relacionamento é comum, por
56
exemplo, entre classes e interfaces (significando que a classe implementa os
serviços especificados pela interface).
2.2.1.3.1.1.2. Diagrama de Estruturas Compostas
Um Diagrama de Estruturas Compostas exibe a estrutura interna de um
classificador (ou seja, a configuração e o relacionamento entre seus elementos
internos, que, juntos, realizam o seu comportamento), além dos pontos de interação
desse classificador com outros elementos do sistema. Assim, tal diagrama é
normalmente composto por classificadores, partes, portas e conectores.
Uma parte é um elemento pertencente ao classificador modelado que
representa um papel, uma superclasse abstrata ou uma classe concreta a ser
implementada por uma ou mais instâncias no momento de execução (dependendo
da multiplicidade – opcional – associada à parte).
Uma porta, por outro lado, é um elemento que representa uma parte externa
visível de uma instância de um classificador, definindo a interação entre o
classificador e suas partes ou ambiente através da especificação dos serviços que
ele requer ou provê – o que pode ser feito por meio de interfaces, nas notações
soquete (requeridas) ou plugue (fornecidas). Ao receber uma requisição, uma porta
pode entregá-la diretamente ao classificador que a contém (sendo o tratamento da
requisição descrito no comportamento desse classificador) ou pode delegá-la a uma
ou mais de suas partes internas.
Finalmente, um conector liga duas ou mais entidades, permitindo a elas
interagir no momento de execução, e é mostrado como uma linha entre algumas
combinações de partes, portas e classificadores estruturados.
Figura 4: Exemplo de Diagrama de Classes.
57
2.2.1.3.1.1.3. Diagrama de Componentes
Um componente é uma parte física e substituível de um sistema. Em muitos
aspectos, componentes assemelham-se a classes: possuem nomes, realizam um
conjunto de interfaces e podem ser aninhados, ter instâncias, participar em
interações e participar em relacionamentos de dependência, generalização e
associação. No entanto, enquanto classes são apenas lógicas, os componentes
podem ser mapeados em nós do sistema pois representam o encapsulamento físico
de componentes lógicos (ou seja, estão em outro nível de abstração).
Outra característica especial é que os atributos e operações de um
componente só podem ser acessados através de sua interface. Uma interface
realizada por um componente é chamada de interface de exportação (export
interface), e indica uma interface que o componente provê como um serviço para
outros. Já uma interface usada por um componente é chamada de interface de
importação (import interface).
Assim, a função do Diagrama de Componentes é explicitar uma visão
estática do sistema ao mostrar os seus componentes e relacionamentos.
Figura 6: Exemplo de Diagrama de Componentes.
Figura 5: Exemplo de Diagrama de Estruturas Compostas.
58
2.2.1.3.1.1.4. Diagrama de Distribuição (Deployment)
O Diagrama de Distribuição (Deployment) ilustra aspectos estáticos da visão
de distribuição de um sistema através da exibição de seus nós e relacionamentos.
Um nó é um elemento físico do sistema, representante de um recurso
computacional (possuindo, normalmente, memória e capacidade de processamento),
em que componentes são distribuídos e executados. O conjunto de objetos ou
componentes executados por um nó é chamado de unidade de distribuição
(distribution unit).
Como os componentes, os nós também se parecem a classes: possuem
nomes e podem ser aninhados, ter instâncias, participar em interações, ter atributos
e métodos, e participar em relacionamentos de dependência, generalização e
associação. Desses relacionamentos, o tipo mais comum encontrado nos Diagramas
de Distribuição é a associação, que representa conexão física entre os nós, e,
embora mais rara, a dependência é usada para vincular os nós aos componentes
que executam.
2.2.1.3.1.1.5. Diagrama de Pacotes
O Diagrama de Pacotes é usado para refletir quais são e como estão
relacionados os pacotes de um sistema.
Um pacote é um mecanismo de propósito geral utilizado para organizar
elementos (incluindo classes, interfaces, componentes, nós, colaborações, casos de
uso, diagramas e mesmo outros pacotes) em grupos, representando tanto
Figura 7: Exemplo de Diagrama de Distribuição (Deployment).
59
relacionamentos lógicos como físicos entre eles.
Entre os pacotes pode haver dois tipos principais de relacionamentos:
generalizações (usadas para especificar famílias de pacotes) ou dependências do
tipo import ou access (usadas para designar que um pacote usa (importa) elementos
dados por outros pacotes (seus elementos exportados)). Outro relacionamento é
dado pelo conector de aninhamento (nesting), que implica que o pacote de origem
está completamente contido pelo pacote de destino.
2.2.1.3.1.2. Diagramas Comportamentais
2.2.1.3.1.2.1. Diagrama de Casos de Uso
O Diagrama de Casos de Uso é utilizado para organizar e modelar as
funcionalidades esperadas de um sistema através da representação de casos de
uso, atores e seus relacionamentos.
O principal componente desse tipo de diagrama é o caso de uso, o qual
representa a descrição de um conjunto de seqüências de ações, normais e
exceções, que um sistema executa para fornecer um resultado observável a um ator.
Um caso de uso deve ser complementado pelo fluxo de eventos (texto que descreve
detalhadamente como o caso de uso ocorre, inclusive suas seqüências anormais).
Cada seqüência específica de ações que ilustra comportamento (uma instância de
um caso de uso) é chamada cenário. Um ator, por sua vez, representa um conjunto
coerente de papéis que os usuários dos casos de uso (humanos, dispositivos de
hardware ou outros sistemas, por exemplo) podem desempenhar ao interagir com
esses casos de uso.
Figura 8: Exemplo de Diagrama de Pacotes.
60
2.2.1.3.1.2.2. Diagrama de Máquinas de Estados e Diagrama de Atividades
O Diagrama de Máquinas de Estados mostra o comportamento de instâncias
– normalmente objetos de uma classe – diante da recepção de eventos, o que é
especialmente útil em sistemas reativos.
Nesse caso, uma máquina de estados designa uma seqüência de estados
pelos quais um objeto transita, exibindo os eventos que causam tais transições e as
ações tomadas pelo objeto frente à recepção desses eventos. Um estado é uma
condição ou situação durante a vida de um objeto durante o qual ele permanece por
um estado finito de tempo, seja executando atividades, seja esperando por algum
evento.
Atividades, no contexto acima, são processamentos não-atômicos (ou seja,
passíveis de interrupção por eventos) que, em última instância, podem ser
decompostos em ações (processamentos atômicos – por exemplo, a chamada a
uma operação, o envio de um sinal, a criação ou destruição de um objeto ou a
execução de um processamento puro, como o cálculo de uma expressão – que pode
agir sobre o próprio objeto da máquina de estados ou indiretamente sobre outros
objetos visíveis àquele objeto, resultando em uma mudança de estado do sistema ou
o retorno de um valor).
Observa-se que um estado é usualmente composto pelas seguintes partes
(nem todas obrigatórias): nome, ações de entrada e saída (ações executadas ao se
entrar ou sair do estado), transições internas (transições que não causam a
modificação do estado do objeto), subestados (estados internos que compõem uma
estrutura aninhada do estado original, abrangendo subestados disjuntos –
Figura 9: Exemplo de Diagrama de Casos de Uso.
61
seqüencialmente ativos – ou concorrentes – concorrentemente ativos), atividades e
eventos adiados (lista de eventos não tratados nesse estado, mas sim adiados e
postos em uma fila para posterior tratamento – ou seja, feito quando o objeto atingir
outro estado). Dois casos especiais de estados são os chamados estado inicial (que
marca o local de começo de uma máquina de estado ou subestado) e estado final
(que indica a finalização da execução da máquina de estados ou do estado
composto).
Por sua vez, uma transição é um relacionamento entre dois estados,
indicando que um objeto no primeiro estado (estado de origem) executará certas
ações e entrará no segundo estado (estado de destino) quando um determinado
evento ocorrer e certas condições forem satisfeitas – dessa forma, em tal mudança
de estado, diz-se que a transição foi disparada. Uma transição possui cinco partes
(nem todas obrigatórias): estado de origem (estado afetado pela transição), estado
de destino (estado ativo após o término da transição), gatilho (ou trigger – evento
cuja recepção pelo objeto permite o disparo da transição, desde que a condição de
guarda seja satisfeita), condição de guarda (expressão booleana avaliada na
recepção do evento de gatilho: se for verdadeira, a transição pode ocorrer; se for
falsa, a transição não é disparada, e caso nenhuma outra transição possa ser
disparada pelo mesmo evento, o evento se perde) e ação.
O Diagrama de Atividades é um caso especial de Diagrama de Estados, ou
seja, todas as características do último aplicam-se ao primeiro. No entanto, nesse
caso particular os estados representam atividades (estados de atividade – activity
states) ou ações (estados de ação – action states), e o término da execução desses
Figura 10: Exemplo de Diagrama de Máquinas de Estados (da classe Sensor).
62
estados provoca automaticamente o disparo de transições para outros estados (ou
seja, não há há evento de gatilho nas transições). Os estados de atividade podem
ser interpretados como elementos compostos, já que são formados por um conjunto
de ações (inclusive de entrada e saída) e podem conter subestados. Assim, o
desmembramento desses estados poderia gerar iterativamente novos Diagramas de
Atividades até que todos os estados do diagrama fossem estados de ação.
Além do que foi descrito sobre Diagramas de Estados, outros elementos
comuns dos Diagramas de Atividades são as transições condicionais (ou branches,
em que uma transição de entrada pode ser desviada por caminhos alternativos de
acordo com a condição de guarda das transições de saída), as divisões (ou forks,
em que um fluxo de controle é dividido entre dois ou mais fluxos de controle
concorrentes) e as junções (ou joins, que representam a sincronização de dois ou
mais fluxos de controle concorrentes).
2.2.1.3.1.2.3. Diagramas de Interação (Diagrama de Seqüência, Diagrama de
Colaboração/Comunicação e Diagrama de Visão Geral das Interações)
Um Diagrama de Interação (Diagrama de Seqüência, Diagrama de
Colaboração/Comunicação, Diagrama de Visão Geral das Interações ou Diagrama
de Temporização) mostra um grupo de instâncias (de classes, componentes, nós ou
casos de uso) e seus relacionamentos, além das mensagens que elas trocam entre
si. As instâncias que participam em uma interação tanto podem ser representantes
de elementos concretos (pertencentes ao mundo real) quanto elementos prototípicos
Figura 11: Exemplo de Diagrama de Atividades (da classe Controlador).
63
(uma instância qualquer de um classificador, expressando, nesse caso, um certo
papel de um elemento no sistema).
Por sua vez, uma mensagem é a especificação de uma comunicação entre
instâncias, com passagem de informações entre as mesmas (por parâmetros ou
valor de retorno, por exemplo), e prováveis mudança de estado e/ou disparo de uma
atividade (procedimento computacional) no sistema – já que a recepção de uma
mensagem pode ser considerada como a chegada de um evento. O tipo mais
comum de mensagem modelada é chamada função, em que um objeto invoca a
operação de um outro (ou de si próprio). O conjunto de mensagens trocadas entre
diversos objetos forma uma seqüência. Vale lembrar que nos Diagramas de
Interação representam-se normalmente fluxos diretos e seqüenciais de controle, mas
também podem ser modeladas seqüências mais complexas, envolvendo interações
e condicionais.
O Diagrama de Seqüência, especificamente, enfatiza a ordenação temporal
das mensagens trocadas entre instâncias. Alguns de seus elementos são a
representação da linha de vida (lifeline) de uma instância (que representa a
existência da mesma durante um período de tempo, possivelmente mostrando sua
criação ou destruição), e o seu foco de controle (que indica o período de tempo em
que o objeto está realizando alguma ação).
Por sua vez, o Diagrama de Colaboração/Comunicação ressalta a
organização estrutural das instâncias que participam em uma interação (enviando ou
recebendo mensagens), dada usualmente pela modelagem das ligações (links) entre
Figura 12: Exemplo de Diagrama de Seqüência.
64
as instâncias (conexões semânticas que constituem caminhos através dos quais
uma instância pode enviar mensagens para outra ou para si, geralmente
concretizadas por instâncias de uma associação). As mensagens transmitidas
através de uma ligação podem ser prefixadas por um número de seqüência único, o
que lhes confere ordenação temporal.
Por fim, o Diagrama de Visão Geral das Interações é um tipo de Diagrama
de Atividades em que os nós representam Diagramas de Interação, expressos por
meio de dois elementos especiais:
� Ocorrência de Interação (Interaction Ocurrence): referência a um diagrama
existente, cujo nome é posto no meio de um quadro de referência (elemento
que o representa); e
� Elemento de Interação (Interaction Element): representação explícita de um
Diagrama de Interação no quadro.
Deve-se enfatizar que, por ser um tipo de Diagrama de Atividades, todos os
controles desse tipo de diagrama (como condicionais (branches), divisões (forks) e
junções (merges), entre outros) aplicam-se a um Diagrama de Visão Geral de
Interações.
Figura 13: Exemplo de Diagrama de Colaboração/Comunicação.
Figura 14: Exemplo de Diagrama de Visão Geral das Interações.
65
2.2.1.3.2. Outros elementos e mecanismos gerais da UML
2.2.1.3.2.1. Nota
Uma nota, em qualquer diagrama, é um símbolo gráfico usado para
descrever restrições ou fazer comentários relativos a um elemento ou coleção de
elementos.
2.2.1.3.2.2. Mecanismos de extensão
2.2.1.3.2.2.1. Valor rotulado
Um valor rotulado (tagged value) permite a criação de novas propriedades
em um elemento pré-existente da UML ou em um estereótipo (lembrando que um
exemplo de propriedades são os atributos e operações de uma classe, por exemplo).
No entanto, lembra-se que o valor rotulado assemelha-se a um metadado – já que o
mesmo é aplicado a um elemento da UML, e não a suas instâncias.
2.2.1.3.2.2.2. Restrição
Uma restrição (constraint) é uma extensão da semântica de um elemento da
UML que permite adicionar-lhe novas regras ou modificar suas regras pré-existentes
(ou seja, uma restrição especifica condições que devem ser mantidas verdadeiras
para que o modelo construído com esse elemento esteja bem formado). Uma
restrição pode ser dada em texto simples, ou, caso necessário, em uma linguagem
de semântica mais precisa, como a Object Constraint Language (OCL). Por fim, vale
ressaltar que algumas das restrições mais comuns estão associadas a valores de
tempo e espaço.
2.2.1.3.2.2.3. Estereótipo
Um estereótipo é uma extensão do vocabulário da UML, que permite a
criação de novos elementos da UML, similares aos já existentes, mas com
propriedades, semântica e notação especiais (já que cada estereótipo pode prover
66
seu próprio conjunto de valores rotulados, restrições e ícone, respectivamente).
Pode-se idealizar um estereótipo como um metatipo, dado que ele cria o equivalente
a um novo bloco de construção no metamodelo UML.
2.2.1.3.2.2.4. Perfil (Profile)
Finalmente, um perfil é uma coleção de estereótipos, valores rotulados e
restrições que, em conjunto, podem descrever um determinado problema particular
de modelagem e facilitam a construção de modelos nesse domínio.
2.2.2. Projetos de engenharia de controle e automação
2.2.2.1. Ciclos de vida de engenharia de controle e automação e suas atividades
Quanto aos ciclos de vida de engenharia de controle e automação para
sistemas de automação distribuídos, Mahalik e Lee (2002) afirmam que,
independentemente da complexidade envolvida, tais métodos envolvem a
especificação ou identificação do problema, e a segmentação (ou descentralização),
o desenvolvimento e os testes do sistema. Em Echelon Corporation (1999) pode-se
encontrar o detalhamento de algumas subatividades que corresponderiam ao
desenvolvimento de um sistema distribuído baseado na tecnologia LonWorks:
� Projeto do sistema: consiste da seleção dos dispositivos e da rede que deve
compor o sistema. Os dispositivos devem conter os pontos de entrada e
saída necessários ao sistema (ou fazer interface com pontos legados), e
implementar as funções de controle apropriadas em suas aplicações. Por
sua vez, a rede de comunicação deve ser selecionada de acordo com as
Figura 15: Exemplo de outros elementos e mecanismos gerais da UML: nota, estereótipo, valorrotulado e restrição.
67
características próprias dos meios físicos disponíveis (como a taxa de
transmissão de dados): assim, são determinados o tipo e a quantidade de
canais, assim como seus elementos de interconexão (roteadores, por
exemplo);
� Configuração de rede: inclui a escolha do endereçamento lógico para os
dispositivos a serem instalados; a interconexão lógica das aplicações de
cada dispositivo; e a configuração do protocolo de comunicação dos
dispositivos de acordo as características e desempenho desejados (como a
forma de confirmação da recepção e a autenticação de mensagens);
� Configuração da aplicação: abrange a personalização da aplicação de cada
dispositivo para que ele execute as funcionalidades desejadas dentro de
certos parâmetros estipulados; e
� Instalação: consiste da instalação dos canais da rede de comunicação, dos
dispositivos e dos elementos de interconexão da rede; da interligação dos
possíveis pontos de entrada e saída legados aos dispositivos que os
tratarão; e do uso de ferramentas apropriadas para descarregar os dados de
configuração da rede e da aplicação de cada dispositivo (além da própria
aplicação, caso necessário). Por fim, vale lembrar que pode seguir-se a esta
uma etapa de manutenção do sistema.
Como descrito por Mahalik e Lee (2002), no entanto, a decisão sobre a
segmentação do sistema ocorre previamente ao desenvolvimento do projeto em si.
Do ponto de vista da descentralização das aplicações (necessária, inclusive, para a
decisão dos dispositivos a serem utilizados no sistema), ela pode ser realizada
através de abstrações denominadas blocos funcionais.
2.2.2.2. Separação de sistemas em módulos: blocos funcionais
De maneira geral, um bloco funcional é uma cápsula (usualmente de
software, mas, de forma mais geral, de alguma propriedade intelectual) que consiste
de variáveis de entrada e de saída, variáveis internas e descrição de comportamento
interno (DAI; SHIH; VYATKIN, 2006).
Segundo a descrição do modelo generalizado de bloco funcional dado
Heverhagen, Tracht e Hirschfeld (2003), aderente à descrição acima, as variáveis de
entrada somente podem ser escritas externamente e lidas internamente ao bloco
68
funcional. Por sua vez, as variáveis de saída podem ser lidas e escritas
internamente, e somente lidas externamente ao bloco funcional. Finalmente, os
autores definem, além dessas, variáveis especiais de entrada e saída (through
variables), que são compartilhadas entre diversos blocos funcionais: assim, se
diversos blocos funcionais estão interconectados por meio dessas variáveis, todos
os blocos funcionais acessam o valor da variável conectada à primeira entrada da
cadeia. Ressalta-se neste ponto que as variáveis de interface de um bloco funcional
(de entrada, de saída e through variables) podem ser interconectadas
exclusivamente se seus tipos de dados forem compatíveis, e que elas
constantemente têm um valor atribuído que pode ser recebido ou enviado a outro
bloco funcional (portanto, esta característica contrapõe-se ao modelo de
comunicação da orientação a objetos, em que os objetos se comunicam pelo
intercâmbio de mensagens). Quanto ao comportamento interno dos blocos
funcionais, os mesmos podem ser especificados para atender a tempo contínuo, a
tempo discreto ou a eventos, e suas instâncias possuem persistência das
informações de seu estado interno.
O uso de blocos funcionais para a divisão de aplicações de sistemas é muito
comum na área de engenharia de controle e automação, e é suportado por diversas
ferramentas (como pode ser visto em Echelon Corporation (2006), Honeywell
International Inc. (2005), TourAndoverControls (2006) e VisualControl, LLC (2003)).
No entanto, visando a uma possível aproximação entre conceitos de orientação a
objetos e de blocos funcionais, tem-se interesse especial no estudo de blocos
funcionais orientados a eventos (já que essa característica permitiria que o
comportamento dos blocos funcionais se assemelhasse ao que é visto em objetos,
em que um evento de chegada de mensagem dispara determinadas atividades).
Nesse contexto, justifica-se o interesse no estudo da norma IEC 61499, descrita a
seguir.
2.2.2.3. Modelagem dos conceitos de blocos funcionais: norma International
Electrotechnical Commission 61499 (IEC 61499)
Uma das normas relacionadas ao uso de blocos funcionais orientados a
eventos no projeto de sistemas distribuídos de controle e medição para processos
industriais (Industrial-Process Measurement and Control Systems – IPMCS) é a IEC
69
61499. Para isso, ela está organizada em quatro partes (INTERNATIONAL
ELECTROTECHNICAL COMMISSION, 2005a):
� Parte 1 – Arquitetura (Architecture): contém requisitos gerais (incluindo
escopo, referências normativas, definições e modelos de referência) e
regras para a declaração de tipos de blocos funcionais, para o
comportamento das instâncias desses tipos e para o uso dos blocos
funcionas na configuração, no atendimento aos requisitos de comunicação e
no gerenciamento de aplicações, recursos e dispositivos dos IPMCS
distribuídos;
� Parte 2 – Requisitos das Ferramentas de Software (Software Tool
Requirements): define os requisitos gerais de ferramentas de software que
auxiliem o desenvolvimento das atividades de engenharia de IPMCS
distribuídos (incluindo a especificação de tipos de blocos funcionais,
recursos e dispositivos; a especificação, análise, validação, configuração,
implementação, operação e manutenção desses sistemas; e a troca de
informações entre dadas ferramentas);
� Parte 3 – Tutorial (Tutorial Information): esclarece dúvidas freqüentes sobre
a norma (em todas as suas partes) e fornece exemplos de uso de seus
conceitos no contexto de problemas comuns de engenharia de controle e
automação; e
� Parte 4 – Regras para Perfis de Aderência à Norma (Rules for Compliance
Profiles) – especifica as características das partes 1 e 2 da norma IEC
61499 a serem implementadas para permitir a interoperabilidade entre os
dispositivos, a portabilidade do software e a configurabilidade dos
dispositivos através das ferramentas de software, mesmo quando
produzidos por diferentes fabricantes.
Considerando as restrições de escopo desta dissertação, a seguir serão
detalhadas somente as partes 1 e 2 da norma.
2.2.2.3.1. Parte 1 – Arquitetura (Architecture)
A parte 1 da norma IEC 61499 define uma arquitetura genérica – dada em
termos de modelos de referência, sintaxes textuais e representações gráficas – e
apresenta recomendações para o uso de blocos funcionais no projeto de sistemas
70
distribuídos de controle e medição para processos industriais (IPMCS).
2.2.2.3.1.1. Modelos de referência (abstrações) da norma IEC 61499
Conforme descrito em International Electrotechnical Commission (2005a), os
modelos de referência da norma IEC 61499 (que podem ser entendidos como suas
abstrações ou conceitos primordiais) são3:
� Sistema (IPMCS): é dado por uma coleção de dispositivos interconectados e
em comunicação através de uma rede (que consiste de segmentos – trechos
de rede – e ligações – conexões dos dispositivos à rede). Qualquer função
desempenhada pelo IPMCS é modelada por uma aplicação, que deve estar
contida em um ou mais dispositivos;
� Dispositivo: deve conter ao menos uma interface (seja de processo, seja de
comunicação), e pode conter zero ou mais recursos. Uma interface de
processo realiza um mapeamento entre uma planta física (da qual se obtém
uma medida analógica, por exemplo) e os recursos, sendo as informações
obtidas do processo dadas a esses recursos como eventos ou dados. Já
uma interface de comunicação faz um mapeamento entre os recursos e as
informações intercambiadas através de uma rede. Seus serviços podem
incluir: fornecer as informações trocadas através da rede aos recursos, na
forma de eventos ou dados; ou prover suporte a atividades de programação,
configuração e diagnóstico dos dispositivos (entre outras);
� Recurso: é considerado uma unidade funcional em que as aplicações do
sistema são postas. Um recurso sempre fica contido em um dispositivo e
possui controle independente (assim, entre outras operações, um recurso
pode ser criado, configurado, parametrizado, iniciado ou apagado, sem
afetar outros recursos do dispositivo). As suas funções são aceitar dados
e/ou eventos das interfaces de comunicação e de processo, tratá-los por
meio das aplicações e fornecer a tais interfaces dados e/ou eventos
correspondentemente. Além disso, uma outra função é controlar a execução
e a transferência de dados entre blocos funcionais da aplicação, de acordo
com as interconexões entre blocos funcionais, a ordem de ocorrência de
3 Algumas figuras referentes aos modelos de referência da norma IEC 61499 podem ser vistas noANEXO A.
71
eventos e outras informações de temporização (como períodos e prioridades
de execução);
� Aplicação: consiste de uma rede de blocos funcionais (ou diagrama de
blocos funcionais) cujos nós são blocos funcionais ou subaplicações (e seus
parâmetros), e cujos arcos são conexões de dados ou de eventos entre eles
– sendo que as subaplicações, como as aplicações, também são redes de
blocos funcionais. Uma aplicação pode ser distribuída entre diversos
recursos de um mesmo ou de diferentes dispositivos, e um recurso usa as
relações causais especificadas pela aplicação para determinar as ações
apropriadas a serem dadas em resposta aos eventos que recebe de suas
interfaces (como o agendamento e a execução de algoritmos dos blocos
funcionais; a modificação de valores de variáveis; a geração de outros
eventos; e novas interações com as interfaces de processamento e de
comunicação);
� Bloco funcional: é uma unidade funcional de software que possui, como
características mais importantes, uma interface externa (composta por
entradas de eventos, que afetam a execução de um ou mais algoritmos
internos; saídas de eventos, que provocam eventos em uma conexão de
acordo com algum de seus algoritmos ou outra capacidade funcional do
recurso em que o bloco funcional está instalado; entradas de dados,
mapeáveis em variáveis de entrada; e saídas de dados, mapeáveis em
variáveis de saída); dados internos (mapeáveis em variáveis internas); e
especificações funcionais (dadas pela combinação dos dados e/ou do
estado interno, persistentes e inacessíveis exteriormente, com um conjunto
de capacidades funcionais do recurso associado e/ou algoritmos internos,
normalmente inacessíveis pelo exterior da interface). Pode fazer parte da
definição de interface externa do bloco funcional a associação de eventos e
dados por meio do qualificador WITH: por meio desse artifício, uma entrada
de evento e um conjunto de entradas de dados podem ser ligados entre si
para especificar quais variáveis devem ser amostradas na ocorrência de um
determinado evento; e podem ser unidos uma saída de evento e um
conjunto de saídas de dados para indicar que evento aponta a modificação
de certas variáveis (enfatizando-se que todas essas associações são feitas
para garantir a consistência de dados das aplicações);
72
� Distribuição: refere-se à colocação dos blocos funcionais de uma aplicação
ou subaplicação em um ou mais recursos, de um ou mais dispositivos. Vale
lembrar que, embora distribuídos, os blocos funcionais – elementos
atômicos de uma aplicação – mantêm entre si suas relações originais;
� Gerenciamento: pode ser entendido como a monitoração e o controle do
estado dos recursos e dispositivos de um sistema, que pode ser realizado de
maneira compartilhada ou distribuída, por aplicações específicas para essa
função; e
� Estado operacional: refere-se a um estado de uma unidade funcional
(dispositivo, recurso ou aplicação) que controla as ações que a mesma pode
realizar, de acordo com a etapa do ciclo de vida em que esteja (projeto,
comissionamento, operação ou manutenção), e também ajuda a manter a
sua integridade em relação às demais unidades funcionais. Assim, alguns
exemplos de estados operacionais são “operacional”, “configurável”,
“carregado” e “parado”, por exemplo.
Embora não esteja explícito anteriormente, as abstrações dispositivo,
recurso, subaplicação e bloco funcional possuem tipos e instâncias (com uma
relação muito semelhante a classes e objetos, no paradigma de orientação a
objetos). Assim, um tipo de bloco funcional, por exemplo, estabelece um modelo
para as suas correspondentes instâncias.
A partir deste ponto, serão detalhados alguns elementos da norma IEC
61499, como os tipos de blocos funcionais, os tipos de interfaces adaptadoras e o
que é a configuração de unidades funcionais e sistemas, a fim de dar subsídios ao
entendimento do restante da dissertação.
Figura 16: Composição de um IPMCS da norma IEC 61499 (em UML).
73
2.2.2.3.1.2. Tipos de blocos funcionais
A especificação de um tipo de bloco funcional define as características de
todas as suas instâncias, incluindo o nome desse tipo e a sua interface externa
(dada pelo número, nomes, tipos e ordem dos eventos de entrada e de saída; o
número, nomes, tipos e ordem dos dados de entrada, de saída e internos; e as
eventuais associações WITH entre entradas e saídas de eventos e de dados).
A descrição do funcionamento de um bloco, no entanto, pode ser dada por
maneiras gerais (como através do uso de linguagem natural), ou depende da
espécie do bloco funcional: na norma, são descritos os blocos funcionais básicos, os
blocos funcionais compostos e os blocos funcionais de interface de serviços (Service
Interface Function Blocks - SIFB), vistos a seguir.
Figura 17: Especificação estrutural de um tipo de bloco funcional da norma IEC 61499 (em UML).
Figura 18: Subclassificação dos tipos de blocos funcionais (em UML).
74
2.2.2.3.1.2.1. Blocos funcionais básicos
Os blocos funcionais básicos são os elementos atômicos de uma aplicação.
O comportamento desses blocos é definido através de seus algoritmos – que
especificam uma seqüência finita de operações, responsável por lidar com os
valores de variáveis de entrada, de saída e internas e transformá-las em novos
valores das variáveis de saída e internas – e de seu Diagrama de Controle de
Execução (Execution Control Chart – ECC) – que relaciona a ocorrência de eventos
nas entradas correspondentes do bloco funcional à invocação e execução dos
algoritmos.
O ECC possui ações, estados e transições. Uma ação é composta por um
algoritmo e, opcionalmente, por um evento que indica o término da execução desse
algoritmo. Um estado, por sua vez, pode ter zero ou mais ações vinculados a ele,
com exceção do estado inicial do ECC (único, e sempre denominado START), que
não deve possuir ação alguma. Por fim, uma transição é uma ligação que denota
uma migração entre um estado de origem e um estado de destino, disparada pelo
cumprimento de uma condição booleana (expressão construída em torno dos
valores de uma ou mais variáveis de entrada de evento ou de dado, variáveis de
saída ou variáveis internas pertencentes a um bloco funcional). Caso a transição
deva ocorrer de qualquer maneira, independentemente do valor das variáveis do
bloco funcional, a condição booleana é denotada por “1”. Dessa maneira, pode-se
ver que o ECC leva o bloco funcional a ter o seguinte comportamento: os algoritmos
do estado corrente (estado ativo) são executados, e, conseqüentemente, são
Figura 19: Bloco funcional básico da norma IEC 61499 – traduzido de Christensen (2002)).
75
modificadas algumas variáveis do bloco funcional; a partir dessas alterações, pode
ser disparada uma transição, que causa a desativação do estado corrente e ativação
de um novo estado (para o qual essa seqüência se repete).
2.2.2.3.1.2.2. Blocos funcionais compostos
Os blocos funcionais compostos têm como objetivo encapsular uma rede de
blocos funcionais. Assim, o comportamento desses blocos é dado por sua rede de
blocos funcionais (interna), e pela forma como essa rede se interconecta com suas
entradas e saídas, de eventos e de dados (ou seja, sua interface). Dessa forma,
blocos funcionais compostos assemelham-se a subaplicações, embora estas
diferenciem-se dos primeiros principalmente por seus blocos funcionais poderem
estar distribuídos em diversos recursos, por poderem conter outras subaplicações, e
por não poderem ter, em sua interface, eventos ligados a dados por qualificadores
WITH.
Figura 20: Diagrama de controle de execução de um bloco funcional básico da norma IEC 61499 –adaptado de Christensen (2002).
Figura 21: Bloco funcional composto da norma IEC 61499 – traduzido de Christensen (2002).
76
2.2.2.3.1.2.3. Blocos funcionais de interface de serviços
Os blocos funcionais de interface de serviços (service interface function
blocks) fornecem um ou mais serviços para uma aplicação, baseados no
mapeamento de primitivas de serviço às suas entradas e saídas de dados e de
eventos (as quais, muitas vezes, possuem semântica específica). O comportamento
desse tipo de bloco é definido pelas seqüências de primitivas dos serviços (que
fornecem ou requisitam da outra parte envolvida na interação), as quais podem ser
dadas por uma notação gráfica especial: os Diagramas de Seqüência de Tempos da
norma ISO/IEC 10731.
É possível encontrar duas subclassificações desses blocos funcionais:
� Blocos funcionais de comunicação: provêem interfaces entre as aplicações e
as funções de mapeamento de comunicação de seus recursos; e
� Blocos funcionais de gerenciamento: implementam funções que permitem:
Em um recurso, criar, inicializar, iniciar, parar, apagar, questionar a
existência, requisitar os atributos ou prover notificação de mudanças de
disponibilidade ou de estado:■ Dos tipos de dados;■ Dos tipos de blocos funcionais (e instâncias); ou■ Das conexões entre instâncias dos blocos funcionais.
Em um dispositivo, criar, inicializar, iniciar, parar, apagar, questionar a
existência, requisitar os atributos ou prover notificação de mudanças de
disponibilidade ou do estado dos recursos.
Figura 22: Bloco funcional de interface de serviços da norma IEC 61499 (aspecto externo idêntico aosdos demais blocos) e especificação da seqüência de primitivas de um serviço – adaptado deChristensen (2002).
77
2.2.2.3.1.3. Tipos de interfaces adaptadoras
Os tipos de interfaces adaptadoras podem ser usados para fornecer um
modelo de representação compacta de uma interface de um bloco funcional
(conjunto de entradas e saídas de eventos e de dados) e dos caminhos usados por
ela para fornecer ou receber um serviço. Ressalva-se que:
� Quando um bloco funcional provê um serviço para outro bloco funcional, ele
é denominado bloco funcional provedor (provider). Ao utilizar uma instância
de um determinado tipo de adaptador para expressar a interface usada para
esse serviço, tal instância é chamada adaptador plugue (plug);
� Quando um bloco funcional aceita um serviço de outro bloco funcional, ele é
denominado bloco funcional aceitador (acceptor). Ao utilizar uma instância
de um determinado tipo de adaptador para expressar a interface usada para
esse serviço, tal instância é chamada adaptador soquete (socket);
� Um adaptador soquete e um adaptador plugue só podem ser
interconectados se forem do mesmo tipo; e
� O padrão da interação entre um bloco funcional provedor e outro aceitador
pode ser representado por seqüências de primitivas de serviço (ou seja, por
Diagramas de Seqüência de Tempos da norma ISO/IEC 10731).
2.2.2.3.1.4. Configuração de unidades funcionais e sistemas
A configuração de um IPMCS, atividade prévia à sua operação, conta, de
forma geral, com as seguintes etapas:
� Configuração das aplicações, com a determinação dos nomes, tipos e
conexões (de dados, de eventos e de adaptadores) de cada bloco funcional;
� Configuração dos dispositivos, com a escolha de valores específicos para
seus parâmetros, e a determinação de seus recursos, blocos funcionais e
conexões (de dados, de eventos e de adaptadores);
� Configuração dos recursos, com a escolha dos tipos de dados suportados, e
tipos e instâncias de blocos funcionais (e suas respectivas conexões de
dados, de eventos e de adaptadores); e
� Configuração da rede, com a atribuição de valores específicos para os
parâmetros dos segmentos de rede, e a determinação dos dispositivos ou
78
recursos unidos a cada segmento por meio de ligações (assim como o valor
dos parâmetros destas).
2.2.2.3.1.5. Anexos
Por fim, os anexos da parte 1 da norma IEC 61499 apresentam as seguintes
informações:
� Anexo A (normativo): mostra os blocos funcionais de eventos (Event
Function Block), que podem ser usados para a geração e o processamento
de eventos;
� Anexo B (normativo): expressa a descrição da sintaxe textual através da
qual podem ser descritos todos os elementos da norma (como blocos
funcionais, por exemplo) de maneira mais formal;
� Anexo C (informativo): fornece modelos de orientação a objetos para guiar a
criação de ferramentas computacionais para suporte ao ciclo de vida
(projeto, implementação, comissionamento e operação) dos IPMCS;
� Anexo D (informativo): mostra a relação entre a norma IEC 61499 e a norma
IEC 61131-3 (que também trata de blocos funcionais, mas não orientados a
eventos);
� Anexo E (informativo): especifica aspectos relacionados à transferência de
informações entre processos de aplicação (recursos), segundo a norma ISO/
IEC 7498-1, feita pelos blocos funcionais de comunicação;
� Anexo F (normativo): especificações em sintaxe textual de todas as figuras
apresentadas nessa parte da norma; e
� Anexo G (informativo): mostra a função dos atributos, que, associados a
tipos de dados, variáveis, aplicações, e a tipos e instâncias de blocos
funcionais, dispositivos e recursos (assim como a seus elementos
componentes), possuem valores que podem ser acessados e/ou
modificados em algum momento do ciclo de vida desses elementos. São
postos em atributos dados como versão, permissão de escrita e descrição
de algoritmos de blocos funcionais, por exemplo.
79
2.2.2.3.2. Parte 2 – Requisitos das Ferramentas de Software (Software Tool
Requirements)
A norma IEC 61499, na seção principal de sua parte 2, estabelece que uma
ferramenta de software para o desenvolvimento das atividades de engenharia de
IPMCS distribuídos deve ser capaz de:
� Permitir o intercâmbio dos elementos de sua biblioteca (que contém
declarações de tipos de blocos funcionais, recursos, dispositivos,
subaplicações, adaptadores, e dados, além das configurações de sistemas)
com outras ferramentas de software;
� Mostrar as declarações dos elementos de sua biblioteca de uma forma
conveniente às tarefas de engenharia (seja por texto ou graficamente,
seguindo a norma IEC 61499-Parte 1, seja adotando um formato próprio);
� Permitir a alteração das declarações dos elementos de sua biblioteca
(incluindo a adição, a exclusão ou a alteração de seu conteúdo – como, por
exemplo, variáveis e algoritmos de tipos de blocos funcionais), textual,
graficamente ou de ambas formas;
� Viabilizar a validação (ou seja, a verificação sintática ou semântica, ou
simulação e teste de operação, por exemplo) de um elemento da biblioteca;
� Permitir a implementação das declarações (como a produção de código
executável, por exemplo, e a ligação das instâncias dos blocos funcionais a
recursos e dispositivos); e
� Fornecer meios para a operação, teste e manutenção do IPMCS, caso isso
seja necessário para dar suporte a alguma etapa de engenharia desse
sistema.
2.2.2.3.2.1. Anexos
Por sua vez, os anexos da parte 2 da norma IEC 61499 exibem os seguintes
assuntos:
� Anexo A (normativo): mostra as definições de tipos de documento
(Document Type Definitions – DTD), dados na sintaxe definida pela
especificação da eXtensible Markup Language (XML), para a troca de
elementos entre bibliotecas de distintas ferramentas de software (o que
80
permite, por exemplo, a portabilidade de descrições de tipos de blocos
funcionais);
� Anexo B (informativo): fornece um modelo gráfico simples para a
representação das abstrações da norma IEC 61499, independentemente da
ferramenta utilizada; e
� Anexo C (informativo): exemplos referentes à parte 2 da norma IEC 61499.
2.3. COMENTÁRIOS SOBRE OS PROJETOS DE SISTEMAS DE
AUTOMAÇÃO DISTRIBUÍDOS
Tendo como objetivo o entendimento das contribuições das áreas de
engenharia de sistemas e de software e de engenharia de controle e automação
para a obtenção de ciclos de vida, métodos para modularização, linguagens e
ferramentas adequados para o desenvolvimento de sistemas de automação
distribuídos, é possível sintetizar as informações vistas nas seções anteriores da
seguinte maneira:
� Quanto à engenharia de software e sistemas:
Os métodos de desenvolvimento de sistemas dessa área são muito bem
documentados pela literatura e são aplicáveis a distintos tipos de projeto
(não somente de software), muitos deles contando inclusive com
processos de gerenciamento além dos fluxos de atividades técnicos. As
principais etapas desses métodos compreendem o levantamento
(eliciação) de requisitos, a análise, o projeto, a implementação, os testes,
a instalação e a manutenção dos sistemas;
Uma das formas de modularização mais comuns nessa área ocorre
quando se adotam técnicas de orientação a objetos, em que o sistema
ou software é representado por abstrações chamadas objetos, que
estabelecem normalmente um paralelo entre si e um objeto do mundo
real (como dispositivos, processadores ou mesmo pessoas, por
exemplo). Essa característica e o fato de que os mecanismos de
orientação a objetos permitem a representação de relações
81
semanticamente complexas entre elementos facilita a sua aplicação a
qualquer domínio;
Das linguagens utilizadas para expressar conceitos de orientação a
objetos uma das mais populares é a UML: através de seus modelos
gráficos é possível representar de forma muito rica aspectos de
diferentes níveis de abstração sobre um determinado sistema (desde
idéias puras a elementos de implementação). Destacam-se também a
sua facilidade de compreensão e flexibilidade (principalmente pela
possibilidade de expansão da linguagem); e
Finalmente, as ferramentas fornecidas pela área têm funcionalidades
centradas na representação de sistemas (que podem ser de propósito
geral, como aquelas que permitem a modelagem através da UML) e na
implementação específica de software (como as que são aplicadas para
codificação em linguagens de computação – por exemplo, Java e C).
� Quanto à engenharia de controle e automação:
Os ciclos de vida de projetos de automação em geral são direcionados
às atividades de construção do sistema em si (contando com as fases de
projeto (já de baixo nível de abstração), de configuração da rede de
comunicação, da configuração de aplicações, da instalação – de
dispositivos e de software – e da manutenção do sistema). Durante a
fase de projeto, ou eventualmente um pouco antes dela, executa-se o
entendimento do problema e sua modelagem, mas tais atividades não
constituem normalmente uma etapa formal do método de
desenvolvimento;
O uso de blocos funcionais para a segmentação das aplicações dos
sistemas de automação é bastante difundido. Em geral, essas
abstrações representam apenas módulos de encapsulamento de
funções, mas especificamente os blocos funcionais orientados a eventos
assemelham-se a elementos reativos (no sentido de que executam
funções internas e divulgam dados de acordo com a recepção de
determinados eventos);
A norma IEC 61499 contribui com a área ao padronizar blocos funcionais
orientados a eventos para expressar aplicações de sistemas de
automação distribuídos, além de oferecer outras abstrações (como
82
dispositivos e recursos) para permitir também a representação da
estruturas físicas referentes a esses sistemas. Adicionalmente, incentiva
a criação de ferramentas computacionais para suporte às etapas de
engenharia de desenvolvimento de sistemas que utilizem suas
abstrações (normatizando-as e definindo características que levem à
interoperabilidade entre elas); e
As diversas ferramentas de engenharia de controle e automação
direcionam-se preferencialmente à modelagem matemática de sistemas,
verificação e validação de modelos e implementação de redes de
controle específicas (incluindo testes, configuração de rede e
dispositivos, e supervisão de campo, entre outras funções).
Assim, do ponto de vista de levantamento de requisitos e de análise
conceitual (incluída aqui a atividade de modelagem), a engenharia de sistemas e
software parece ter contribuições importantes a oferecer aos projetos de sistemas de
automação distribuídos. Por sua vez, a de engenharia de controle e automação
aporta, nesse contexto, ciclos de vida e ferramentas bem estabelecidos quanto ao
projeto de baixo nível e implementação dos sistemas. Dessa maneira, mesmo com
suas diferenças, parece interessante unir as técnicas dessas duas áreas, a fim de
que uma cubra as deficiências da outra no desenvolvimento de projetos. Isso pode
ser feito se considerarmos os seguintes aspectos:
� Possibilidade de unificação dos ciclos de vida: pode-se entender o
desenvolvimento de software e de hardware como subprojetos dentro do
projeto de um sistema de automação distribuído. Este poderia ser
constituído das etapas de levantamento de requisitos, análise, projeto,
implementação, testes, instalação e manutenção (como no ciclo de
engenharia de software), mas com atividades específicas de software e
hardware (como configuração de rede, por exemplo) distribuídas entre essas
macro-atividades, que recebem ênfases diferentes de acordo com o
momento do projeto geral (como ocorre com as atividades dentro das fases
no Processo Unificado de desenvolvimento de sistemas, por exemplo); e
� Similaridade entre conceitos de orientação a objetos e de descrição de
sistemas em termos de blocos funcionais orientados a eventos: uma vez que
tanto objetos como blocos funcionais orientados a eventos representam, ao
mesmo tempo, estrutura (interface externa) e comportamento (encapsulado
83
pela interface), e que ambos respondem a estímulos externos (sejam eles
chamados de mensagens ou eventos, que alteram seu estado interno e,
opcionalmente, a condição de variáveis), tais abstrações parecem ser
compatíveis entre si.
A partir desse ponto, então, torna-se coerente e desejável estabelecer uma
correlação entre a UML e as abstrações da norma IEC 61499: com a UML ter-se-ia a
possibilidade de expressar uma visão geral dos requisitos e da análise do sistema de
automação distribuído (tanto sob a perspectiva da aplicação quanto do ambiente de
implementação teórico), enquanto que as abstrações da norma IEC 61499 poderiam
mostrar, além do projeto de baixo nível da aplicação (com a divisão do software em
blocos funcionais), uma visão mais concreta do sistema de hardware subjacente. Os
modelos de ambas linguagens conseguiriam, dessa maneira, mostrar visões
distintas e complementares de todo o sistema, usadas nas diversas atividades do
ciclo de vida do projeto de um sistema de automação.
Complementarmente, o estabelecimento de um mapeamento entre essas
linguagens tornaria possível a automatização da transformação desses modelos,
que poderia ser realizada por alguma ferramenta computacional. Dessa maneira, os
engenheiros de software e sistemas e o engenheiros de controle e automação
poderiam trabalhar cooperativamente, compartilhando as tarefas de especificação de
um sistema e, ainda assim, utilizar para isso suas próprias linguagens e ferramentas
(ou seja, sem a necessidade de estudar profundamente uma outra área de
conhecimento) (PANJAITAN; FREY, 2006a).
Dado o interesse nessa linha de pesquisa, analisam-se no capítulo seguinte
algumas das principais técnicas de mapeamento entre UML e abstrações da norma
IEC 61499.
84
3. MAPEAMENTO DE DIAGRAMAS DA UML EM DIAGRAMAS DE
ABSTRAÇÕES DA NORMA IEC 61499
Este capítulo apresenta alguns dos principais trabalhos sobre o mapeamento
de diagramas da Unified Modeling Language (UML) em diagramas de abstrações da
norma International Electrotechnical Commission (IEC) 61499 (chamado, a partir
deste ponto, de mapeamento UML-IEC61499). O interesse neste tópico justifica-se
no fato de que o desenvolvimento de tal técnica leva à obtenção de regras para a
transformação automática das descrições de sistemas de automação em UML para
as descrições em termos de abstrações da norma IEC 61499, o que pode ser
utilizado para a implementação de ferramentas computacionais de auxílio a projetos.
A partir deste ponto, fica subentendido que os termos relacionados a
diagramas de blocos funcionais e outros conceitos correlatos referem-se somente
àqueles tratados pela norma IEC 61499 (tornando opcional o uso deste
complemento no texto).
3.1. TENDÊNCIAS NO MAPEAMENTO UML-IEC61499
As técnicas de mapeamento UML-IEC61499 a serem tratadas neste
capítulo, por ordem de relevância, compreendem os seguintes trabalhos4:
� Mapeamento de Thramboulidis: Thramboulidis (2001) e Tranoris e
Thramboulidis (2002, 2003b);
� Mapeamento de Dubinin e Vyatkin: Dubinin e Vyatkin (2004) e Dubinin,
Vyatkin e Pfeiffer (2005);
� Mapeamento de Panjaitan e Frey: Panjaitan e Frey (2005, 2006a, 2006b);
� Mapeamento de Zhang, Diedrich e Halang: Zhang, Diedrich e Halang (2005);
e
4 Deve-se esclarecer que o nome do subtópico foi escolhido de acordo com o(s) nome(s) do(s)pesquisador(es) que aparece(m) como autor(es) em todos os trabalhos correlatos, e que o critériousado para a sua ordem de apresentação é a aplicabilidade do mapeamento considerando osobjetivos iniciais da dissertação e a existência de ferramentas para automatizá-lo.
85
� Mapeamento de Heverhagen, Tracht e Hirschfeld: Heverhagen, Tracht e
Hirschfeld (2003).
A seguir, passa-se à descrição de cada uma dessas técnicas.
3.1.1. Mapeamento de Thramboulidis
Para realizar o mapeamento UML-IEC61499, Thramboulidis (2001) e
Tranoris e Thramboulidis (2002, 2003b) sugeriram extensões à UML especialmente
através do mecanismo de estereótipos. Como será visto adiante, a base dessa
transposição é a captura de dados das classes e de informações adicionais dos
Diagramas de Interação para obter blocos funcionais e interconexões que
descrevam completamente o sistema de automação determinado. Iterativamente, o
projetista deve lidar com a passagem dos diagramas da UML para os diagramas de
blocos funcionais, até que todos os diagramas de blocos funcionais gerados a partir
dos Diagramas de Interação sejam unificados e todas as redundâncias de blocos
funcionais sejam eliminadas.
A ferramenta computacional que automatiza as regras de transformação
UML-IEC61499 de Thramboulidis é o Common Object-oriented Real-time
Framework for the Unified development of distributed Industrial-Process
Measurement and Control Systems (IPMCS) applications (CORFU) Engineering
Support System (ESS), que dá suporte ao processo de desenvolvimento CORFU e
cuja subaplicação chamada Transformation Facility Manager (TFM) executa o
mapeamento referido.
3.1.1.1. Diagramas da UML usados no mapeamento de Thramboulidis
Os Diagramas de Classes, Pacotes, Estados e Interação são usados como
fontes de dados para uma série de regras de transformação simples e
automatizáveis que levam à obtenção dos diagramas de blocos funcionais do
sistema. Os Diagramas de Casos de Uso, embora importantes para o estudo do
sistema a ser desenvolvido, não oferecem dados para tal mapeamento. A seguir,
são detalhadas as funções de cada tipo de diagrama.
86
3.1.1.1.1. Diagrama de Classes
O Diagrama de Classes representa os tipos de blocos funcionais que
compõem a aplicação do sistema de automação distribuído, além de seus
relacionamentos. Isto é feito respectivamente por classes descritas com estereótipos
adequados e por relacionamentos de agregação e dependência.
3.1.1.1.1.1. Estereótipos das classes
As classes podem assumir os seguintes papéis no sistema de automação
especificado, de acordo com os seus estereótipos:
� Bloco Funcional (Function Block – FB);
� Bloco Funcional de Interface de Serviço (Service Interface Function Block –
SIFB);
� Terminador do Processo Industrial (Industrial Process Terminator – IPT); e
� Objeto do Mundo Real (Real-World Object – RWO).
A seguir, são explicadas as características de cada um desses estereótipos.
3.1.1.1.1.1.1. Estereótipo FB
O estereótipo FB determina que uma classe representa um tipo de bloco
funcional.
Os atributos privados ou protegidos representam as variáveis internas do
bloco funcional, enquanto os atributos públicos, ou obtidos por meio de operações
get() e registrados através de métodos set(), indicam a existência de dados de
entrada e de saída do bloco funcional, e se relacionam às dependências de dados
entre blocos funcionais (detalhados adiante no texto, e que determinam a troca de
dados entre os mesmos).
Os métodos públicos representam eventos de entrada dos blocos funcionais,
e os possíveis parâmetros passados em tais métodos correspondem aos dados de
entrada vinculados a esses eventos (e, nesse caso, eventos e dados são ligados
pelo qualificador WITH quando da transformação da UML para os diagramas de
blocos funcionais). Se houver um valor de retorno para um método, este deve ser
considerado como um dado de saída do bloco funcional. Os métodos públicos das
87
classes de estereótipo FB estão ligados aos relacionamentos de dependência de
controle entre as classes (a serem vistas adiante, e que designam a transmissão de
eventos de um bloco funcional a outro), enquanto os métodos privados destinam-se
a maximizar as possibilidades de reuso de código dos blocos funcionais.
Por fim, vale lembrar que cada classe de estereótipo FB pode estar
vinculada a um Diagrama de Máquinas de Estados se representar um bloco
funcional básico (já que esses diagramas designam os Diagramas de Controle de
Execução ou Execution Control Chart – ECC).
3.1.1.1.1.1.2. Estereótipo SIFB
Quando o sistema de automação precisa interagir com uma entidade
externa, utiliza-se uma classe de estereótipo SIFB para especificar o elemento
responsável pela interface entre as partes citadas (já que o SIFB é responsável por
prover um ou mais serviços para o sistema de automação, como o mapeamento de
serviços primitivos, entre eles os de comunicação, para facilitar a troca de eventos e
dados entre o sistema de automação e a entidade externa).
3.1.1.1.1.1.3. Estereótipo IPT
As classes de estereótipo IPT representam as entidades do processo
industrial que são monitoradas e controladas pela aplicação, já que os IPT fazem a
interface entre o sistema de controle (entidades lógicas) e os elementos da planta
(dados, por exemplo, por um objeto do mundo real, ou classe de estereótipo RWO).
Assim, pode-se entender o IPT como a representação lógica dos elementos físicos
previamente citados.
Os IPT, dependendo de servirem como interface para elementos fontes ou
sorvedouros de dados, são discriminados como IPT de entrada (input-IPT), IPT de
saída (output-IPT) ou IPT de entrada e saída (input/output-IPT). Os dados ou
eventos (de entrada ou de saída) da aplicação, ligados à planta, são chamados de
parâmetros do processo industrial (ou Industrial Process Parameters – IPP), sendo
os dados de entrada vinculados a métodos set(), e os de saída a métodos get().
88
3.1.1.1.1.1.4. Estereótipo RWO
O estereótipo RWO representa os objetos relevantes do mundo real (ou
seja, os dispositivos de entrada e saída, físicos, que fazem interface com o sistema
de controle, fornecendo sinais de entradas e recebendo sinais de saída do mesmo).
3.1.1.1.1.2. Relacionamentos
Os relacionamentos usados nos Diagramas de Classes restringem-se a
relacionamentos de associação (agregação) ou a relacionamentos de dependência,
conforme descrito a seguir.
3.1.1.1.1.2.1. Associação (Agregação)
Os tipos de blocos funcionais compostos (composite FB) e das
subaplicações (sub-applications) devem ter relacionamentos de agregação com as
classes que representam os tipos de blocos funcionais pertencentes a eles. Vale
ressaltar que a única diferença entre bloco funcional composto e subaplicação é que
Figura 23: Diagrama de Classes de um sistema de automação genérico para demonstração do usodos estereótipos do mapeamento de Thramboulidis (estereótipos FB, IPT, SIFB e RWO).
89
no último os blocos funcionais componentes podem ser colocados em recursos
diferentes do sistema.
3.1.1.1.1.2.2. Dependência
Os relacionamentos de dependência entre classes podem receber um dos
estereótipos listados abaixo:
� Dependência de dados (DataDependency – DD): o estereótipo DD é
colocado em relacionamentos de dependência entre as classes de blocos
funcionais e blocos funcionais ou IPT para designar uma associação do tipo
produtor-consumidor de dados entre as partes. É a partir desse estereótipo
que são definidos os métodos set() e get() a serem postos nas classes:
enquanto o elemento produtor no diagrama envia uma mensagem do tipo
set(nome_do_atributo, valor_do_atributo), o elemento consumidor envia uma
mensagem do tipo get(nome_do_atributo) para o produtor; e
� Dependência de controle (ControlDependency – CD): o estereótipo CD é
posto em relacionamentos de dependência entre as classes de blocos
funcionais e blocos funcionais ou IPT para designar a existência de
propagação de eventos entre elas. A partir desses relacionamentos
determina-se um método no bloco funcional receptor, chamado método de
resposta (response method), que define o comportamento do bloco funcional
frente à recepção do evento. Esse comportamento pode incluir: a execução
de processos computacionais; a modificação de valores de atributos e
disparo de transições no ECC; a habilitação ou desabilitação de métodos
contínuos; o disparo de métodos de uma só execução (one-shot); e a
habilitação ou desabilitação de relacionamentos de estereótipo DD ou CD.
A Figura 24 mostra os relacionamentos descritos anteriormente em relação
ao exemplo de um sistema de automação de um condicionador de ar (fan coil): o fan
coil deve receber a temperatura de dois sensores, posicionados em suas regiões de
retorno e insuflamento de ar, e decidir qual a velocidade em que o seu ventilador
deve funcionar (para resfriar o ar, forçando a sua passagem através de uma
serpentina de água gelada, por exemplo), ou se o ventilador deve ser desligado.
Esse exemplo deve ser usado neste capítulo, quando necessário, para ilustrar os
mapeamentos UML-IEC61499 pesquisados.
90
3.1.1.1.2. Diagrama de Pacotes
Apesar de ser uma das alternativas viáveis, o uso de pacotes para a
representação de blocos funcionais compostos e de subaplicações não é
recomendado, já que os mesmos não podem participar como elementos nos
Diagramas de Interação da UML (dificultando a representação do interfaceamento
dessas entidades com as demais). Ainda assim, se for esta a opção feita, o
Diagrama de Classes do pacote define os blocos funcionais que compõem o bloco
funcional composto ou subaplicação, além de seus relacionamentos.
3.1.1.1.3. Diagrama de Máquinas de Estados
O Diagrama de Máquinas de Estados ligado a uma classe representa o
diagrama de controle de execução (Execution Control Chart – ECC) do bloco
funcional básico descrito por ela.
Figura 24: Diagramas de Classes do sistema de automação de um condicionador de ar (fan coil) parademonstração do uso dos relacionamentos de agregação (a) e dependência (b), elaborado segundo omapeamento de Thramboulidis.
91
3.1.1.1.4. Diagrama de Interação
Os Diagramas de Interação (Diagramas de Seqüência e de Colaboração)
explicitam as conexões de dados ou eventos entre blocos funcionais, esclarecendo a
função de cada relação de dependência descrita no Diagrama de Classes.
Em primeiro lugar, para cada Diagrama de Interação obtém-se um diagrama
de blocos funcionais (que deve ser unificado aos demais ao final do processo de
transformação). Cada objeto desses diagramas deve gerar uma instância de bloco
funcional, de acordo com a classe a que o objeto pertence. Caso um objeto interaja
com um elemento externo ao sistema, deve-se adicionar um bloco funcional de
interface de serviços (SIFB) ao diagrama de blocos funcionais.
Logo, cada mensagem entre os objetos gera parte da interface de eventos
dos blocos funcionais: neste caso, o nome da mensagem é posto como o nome do
Figura 25: Parte dos estereótipos ligados a blocos funcionais (modelo em UML) – traduzido deThramboulidis (2001).
92
evento de saída do bloco funcional chamador, e também deve ser o nome do evento
de entrada do bloco funcional chamado. Assim, formam-se as interconexões entre
os eventos dessas duas instâncias de blocos funcionais (que possuem o mesmo
nome do evento de entrada/saída). Se as interações entre blocos funcionais
envolverem mensagens com parâmetros, tais parâmetros devem ser mapeados
como entradas e saídas de dados dos blocos funcionais que estão interagindo. Além
disso, tais parâmetros devem ser vinculados a seus eventos pelo qualificador WITH.
Em relação às mensagens trocadas entre blocos funcionais e IPT, os
parâmetros passados entre eles revelam quais são os IPP em questão. O nome da
mensagem vai ser mapeado como um IPP do tipo “evento” e os parâmetros
possíveis da mensagem vão ser mapeados como IPP do tipo “dado”. Se a direção
da mensagem for de um bloco funcional para um IPT, temos um IPP de atuador
(saída de dados). Caso contrário, temos um IPP de sensor (entrada de dados no
sistema).
Por fim, se uma mensagem possui mais de um receptor, uma instância do
bloco funcional divisor de eventos (Function Block Event Splitter) deve ser inserida
no diagrama de blocos funcionais, enquanto que quando houver necessidade que
dois ou mais eventos se encontrem (coincidam) para que o processo continue, uma
instância do bloco funcional de reunião de eventos (Function Block Event
Rendezvous) deve ser acrescentada ao diagrama.
Figura 26: Diagrama de Colaboração do sistema de automação de um condicionador de ar (fan coil),elaborado segundo o mapeamento de Thramboulidis e com os ícones dos estereótipos do CORFUESS.
93
3.1.1.1.5. Diagrama de Casos de Uso
Finalmente, os Diagramas de Casos de Uso, apesar de servirem para o
estudo das funções a serem desempenhadas pelo sistema de automação, não são
passíveis de mapeamento para elementos dos diagramas de blocos funcionais,
conforme relatado anteriormente.
Figura 27: Diagrama de Seqüência do sistema de automação de um condicionador de ar (fan coil),elaborado segundo o mapeamento de Thramboulidis e com os ícones dos estereótipos do CORFUESS.
Figura 28: Diagrama de blocos funcionais obtido a partir do diagrama de seqüência descrito na Figura27 (gerado com a ferramenta CORFU ESS).
94
3.1.2. Mapeamento de Dubinin e Vyatkin
A descrição de abstrações da norma IEC 61499 através da UML foi proposta
por Dubinin e Vyatkin (2004) e Dubinin, Vyatkin e Pfeiffer (2005) em sua linguagem
chamada UML-FB, a qual estende a UML através do mecanismo de estereótipos. A
linguagem UML-FB deve ser utilizada estritamente para a modelagem, o projeto e a
manutenção de sistemas de automação (devido a suas regras de aplicação e
semântica específicas).
A transformação dos diagramas da linguagem UML-FB para os diagramas
de abstrações da IEC 61499 permite a obtenção de uma especificação executável
de um sistema de controle, e é feita pelas ferramentas computacionais denominadas
conversores UML-FB e FB-UML – esta última para a conversão inversa, ou seja,
para a obtenção de diagramas da UML a partir de elementos da IEC 61499
(DUBININ; VYATKIN; PFEIFFER, 2005).
3.1.2.1. Diagramas da linguagem UML-FB
A UML-FB utiliza os Diagramas de Classes, de Seqüência, de Cooperação e
de Máquinas de Estados apresentados na UML. A seguir, detalha-se a aplicação de
cada um destes na descrição dos sistemas de automação.
3.1.2.1.1. Diagrama de Classes
Os Diagramas de Classes são usados para representar: os blocos
funcionais, subaplicações, adaptadores, recursos e dispositivos do sistema; as
interfaces dos blocos funcionais, incluindo suas entradas e saídas, tanto de dados
quanto de eventos; as configurações do sistema, dos dispositivos e dos recursos; os
dados constantes que representam parâmetros de entrada dos blocos funcionais,
subaplicações, recursos e dispositivos; e, por fim, os relacionamentos e a hierarquia
de todos esses componentes do sistema. A seguir, detalha-se como tais
informações são dadas em UML-FB.
95
3.1.2.1.1.1. Estereótipos das classes
Em primeiro lugar, deve-se esclarecer que as classes da UML correspondem
aos tipos de blocos funcionais da IEC 61499, enquanto os objetos da UML
correspondem às instâncias dos blocos funcionais. Assim, para a criação de
estereótipos para as classes, utilizou-se a própria classificação da norma IEC 61499,
em que o bloco funcional (FB) é a raiz de uma árvore de estereótipos. A partir dele,
derivam-se o bloco funcional básico (basic FB – BFB), o bloco funcional composto
(composite FB – CFB) e o bloco funcional de interface de serviços (service interface
FB – SIFB). Dubinin e Vyatkin sugerem, ainda, uma subclassificação dos SIFB de
acordo com sua aplicação: blocos funcionais de interface de serviços de processo
(process SIFB – PSIFB), que fazem conexão com o objeto controlado (planta);
blocos funcionais de interface de serviços com os equipamentos periféricos, como
temporizadores ou timers (timer SIFB – TSIFB); e blocos funcionais de interface de
serviços de comunicação (communication SIFB – CSIFB), para o encapsulamento
de funções de comunicação.
Além desses, as classes podem ainda possuir os seguintes estereótipos:
SUB (subaplicações), ADAPTER (adaptadores), CONSTANT (constantes),
SERVICE (serviços de um SIFB), SYSTEM (sistema), DEVICE (dispositivo),
DEVICE_TYPE (tipo de dispositivo), RESOURCE (recurso), RESOURCE_TYPE
(tipo de recurso), APPLICATION (aplicação) e o estereótipo Interface (pré-definido
na UML).
3.1.2.1.1.2. Estereótipos de métodos e atributos
Os métodos das classes da UML-FB podem receber os estereótipos INPUT
(se estiverem se referindo à entrada de um evento), OUTPUT (se forem associados
à saída de um evento desse bloco funcional) ou INTERNAL (caso sejam internos).
Os atributos, por sua vez, designam entradas e saídas de dados, e, além de
receberem esses estereótipos, podem ter também os estereótipos SOCKET ou
PLUG (se estiverem associados à existência de adaptadores – soquetes e plugues,
respectivamente) e são declarados como sendo de um tipo específico (booleano ou
inteiro, por exemplo).
96
3.1.2.1.1.3. Relacionamentos
O diagrama de classes da UML-FB identifica tanto os tipos de blocos
funcionais, dispositivos e recursos (representados como classes) quanto suas
instâncias (dadas por objetos). Para definir a hierarquia de classes e objetos,
utilizam-se relacionamentos de generalização, associação e dependência.
3.1.2.1.1.3.1. Associação
Os relacionamentos de associação são utilizados para determinar as
conexões entre entradas e saídas de eventos, de dados e de adaptadores existentes
entre os tipos de blocos funcionais interligados, estabelecendo assim uma
correspondência de todos-para-todos (multiplicidade n-m) entre as instâncias desses
blocos funcionais. Os relacionamentos de associação podem ser dos seguintes
tipos: EVENT (para eventos), DATA (para dados), EVENT_WITH_DATA (para
eventos relacionados a dados) ou ADAPTER (para adaptadores).
Por outro lado, os relacionamentos de agregação da UML-FB têm como
propósito identificar quais são os blocos funcionais compostos utilizados no sistema,
ou seja, tais relacionamentos determinam quais instâncias específicas de blocos
funcionais são encapsuladas por um tipo de bloco funcional, subaplicação ou
recurso. O nome do papel da parte contida, especificado por essa conexão, fornece
o nome da instância do bloco funcional. Tal nome não pode ser repetido em outra
conexão de agregação entre as mesmas classes.
3.1.2.1.1.3.2. Generalização
Os relacionamentos de generalização são utilizados para descrever que um
tipo de bloco funcional herda de um outro suas entradas e saídas de eventos, dados
e adaptadores, ou até mesmo interfaces completas.
Quando uma relação de generalização é rotulada com o estereótipo STR,
isso significa que a classe filha designa, na verdade, uma instância de um tipo de
dispositivo ou de recurso (herdando, mais precisamente, sua configuração – ou seja,
sua composição interna).
97
3.1.2.1.1.3.3. Dependência
Os relacionamentos de dependência determinam ligações semânticas entre
objetos (como cliente-servidor, por exemplo), mas não são transformados em
nenhuma estrutura específica dos diagramas de abstrações da IEC 61499 (ou seja,
não há geração de código a partir deles).
3.1.2.1.2. Diagrama de Interação
Os Diagramas de Interação (Diagramas de Seqüência e de Colaboração)
são utilizados para mostrar o comportamento dinâmico do sistema, ou seja, os
eventos e dados intercambiados entre blocos funcionais, recursos e dispositivos,
estabelecendo assim conexões ponto-a-ponto entre tais componentes do sistema.
Nos Diagramas de Colaboração, o formato das mensagens é definido por
meio da linguagem Backus-Naur Form (BNF) como segue: <Nome da saída do bloco
Figura 29: Diagramas de Classes do sistema de automação de um condicionador de ar (fan coil) parademonstração do uso de relacionamentos de agregação e generalização, além de estereótipos ecomposições das classes, elaborado segundo o mapeamento de Dubinin e Vyatkin.
98
funcional>-<Nome da entrada do bloco funcional> <Nome da conexão>. Já nos
Diagramas de Seqüência, os métodos da UML representam eventos, e, caso os
mesmos possuam parâmetros, tais eventos ficam vinculados a dados por meio do
qualificador WITH da norma IEC 61499. Os Diagramas de Seqüência podem ser
usados para a geração dos Diagramas de Seqüência de Tempos que seguem a
International Organization for Standardization (ISO) TR 8509, os quais podem ser
aplicados no paradigma de blocos funcionais da IEC 61499 para descrever o
comportamento dos SIFB.
3.1.2.1.3. Diagrama de Máquinas de Estado
Os Diagramas de Máquinas de Estado da UML-FB são usados para
designar o comportamento de cada um dos tipos de bloco funcional básicos, já que
devem ser mapeados diretamente em seus Diagramas de Controle de Execução
(ECC). Para isso, os diagramas de estado da UML-FB mantêm-se muito simples,
sem incluir estados históricos ou compostos, e nem transições complexas (com
ações ou sinais, por exemplo).
Figura 30: Diagrama de Colaboração do sistema de automação de um condicionador de ar (fan coil),elaborado segundo o mapeamento de Dubinin e Vyatkin.
99
3.1.2.1.4. Considerações sobre conexões entre blocos funcionais
Os relacionamentos estabelecidos entre classes e objetos nos diversos
diagramas da UML-FB determinam a hierarquia do sistema (que pode ser expressa
através de diagramas de blocos funcionais aninhados) e as conexões entre as
instâncias dos blocos funcionais. Essas conexões podem ser classificadas como
locais ou de trânsito. As primeiras descrevem ligações diretas entre blocos
funcionais de um mesmo nível hierárquico (ou seja, entre objetos irmãos) ou entre
níveis diferentes, porém diretamente relacionados. Já as conexões de trânsito são
aquelas que ocorrem entre blocos funcionais de níveis de hierarquia não
relacionados entre si. Para implementar uma conexão de trânsito (que não é prevista
pela IEC 61499) devem ser efetuadas diversas conexões locais e a redefinição das
interfaces dos blocos funcionais através dos quais essa conexão é feita. Vale
lembrar que a nomenclatura das entradas e saídas geradas é feita de acordo com o
nome da conexão ou com os nomes dos papéis da conexão.
3.1.3. Mapeamento de Panjaitan e Frey
Panjaitan e Frey (2005, 2006a, 2006b) propuseram um mapeamento de
diagramas da UML em abstrações da norma IEC 61499, baseado em extensões à
UML a partir do uso de estereótipos.
Figura 31: Exemplo de hierarquia de objetos (a) e a sua estrutura implícita de blocos funcionaisaninhados (b) – retirado de Dubinin, Vyatkin e Pfeiffer (2005). Note-se que as conexões dadas poruma linha tracejada são conexões locais, e a conexão dada por uma linha contínua – em (a) – é umaconexão de trânsito (transformada, em (b), em quatro conexões locais).
100
Nesse mapeamento, apesar de todos os diagramas da UML servirem para a
descrição de um sistema de automação, alguns deles são usados como dados de
entrada para a transformação automática em abstrações da norma IEC 61499 por
meio de uma ferramenta computacional (PANJAITAN; FREY, 2006a), enquanto
outros servem apenas como simples artefatos de descrição (como os casos de uso,
por exemplo).
3.1.3.1. Diagramas da UML usados no mapeamento de Panjaitan e Frey
Os Diagramas de Classes, de Componentes, de Estruturas Compostas, de
Pacotes, de Distribuição (Deployment), de Atividades, de Máquinas de Estados, de
Casos de Uso e de Interação da UML podem ser usados em tal mapeamento.
3.1.3.1.1. Diagrama de Classes
Os Diagramas de Classes são usados para definir os blocos funcionais,
incluindo suas entradas e saídas de dados e eventos. Isso é feito através de
estereótipos, como FBType (para as classes que designam tipos de blocos
funcionais); input e output (para os atributos que representam entradas e saídas de
dados); e event_input e event_output (para os métodos que representam entradas e
saídas de eventos). Uma outra alternativa para indicar a configuração externa dos
blocos funcionais é criar interfaces apropriadas para esses blocos funcionais, cujos
métodos sejam designados pelo estereótipo signal. Se houver parâmetros nesses
métodos (caso em que um evento de um bloco funcional estaria vinculado a um
dado pelo qualificador WITH da norma IEC 61499), seu tipo deve ser determinado.
Para que haja possibilidade de conexão entre dois blocos funcionais, suas interfaces
devem ser compatíveis (complementares, quanto ao formato e tipo). Por fim, vale
lembrar que as instâncias dos blocos funcionais são obtidas com a instanciação de
suas classes correspondentes.
Por outro lado, os relacionamentos possíveis entre blocos funcionais são os
de agregação e dependência. A agregação é utilizada para especificar quais tipos de
blocos funcionais são compostos internamente por outros blocos funcionais. Já a
dependência é usada para indicar o relacionamento entre dois blocos funcionais,
seja entre seus eventos (com o estereótipo EventConnections), seja entre seus
101
dados (com o estereótipo DataConnections). Essa interconexão leva à criação de
redes de blocos funcionais.
3.1.3.1.2. Diagrama de Componentes
Ao invés de serem denotados por classes, os blocos funcionais também
podem ser designados diretamente por componentes (quando são elementos físicos,
intercambiáveis, que podem ser diretamente mapeados em nós). Neste caso, eles
também podem implementar interfaces e estabelecer relações de dependência entre
si, conforme descrito no item anterior. Usualmente, as interfaces fornecidas
(implementadas) por um componente são colocadas na notação plugue, e as
interfaces aceitas (usadas) são colocadas na notação soquete. A conexão entre os
componentes permite a criação de redes de blocos funcionais.
3.1.3.1.3. Diagramas de Estruturas Compostas
Apesar de não serem descritos explicitamente nas referências de Panjaitan
e Frey, e sim mostrados em forma gráfica, relacionados a Diagramas de
Componentes, os Diagramas de Estruturas Compostas podem ser usados para
mostrar a composição interna de classes e componentes que representem blocos
funcionais compostos, principalmente para a geração de redes de blocos funcionais,
conforme pode ser visto na Figura 33.
Figura 32: Diagrama de Componentes e sua transformação na interface externa de um blocofuncional segundo o mapeamento de Panjaitan e Frey – retirado de Panjaitan e Frey (2006a).
102
3.1.3.1.4. Diagrama de Pacotes
Os Diagramas de Pacotes constituem uma das opções para mostrar quais
blocos funcionais básicos e blocos funcionais de interface de serviços (classes ou
componentes com estereótipos basic function block e service interface block) estão
inseridos em blocos funcionais compostos (pacotes com estereótipo composite
block) ou em recursos (pacotes com estereótipos resource), e também quais
recursos estão inseridos em dispositivos (pacotes com estereótipos device),
segundo o modelo da IEC 61499 desejado.
3.1.3.1.5. Diagrama de Distribuição (Deployment)
Os Diagramas de Distribuição (Deployment) da UML mostram, em uma
visão de alto nível, as relações entre objetos, componentes e nós do sistema. No
mapeamento UML-IEC61499, os blocos funcionais, descritos como classes ou
componentes, podem ser vinculados a recursos (denotados como componentes, por
exemplo), e estes, por sua vez, podem ser postos em seus correspondentes
dispositivos (normalmente dados por nós). A interconexão dos dispositivos pode ser
Figura 33: Diagrama de Estruturas Compostas e sua transformação na interface externa de um blocofuncional composto e na rede de blocos funcionais interna a ele, segundo o mapeamento dePanjaitan e Frey – retirado de Panjaitan e Frey (2006a).
103
feita pela ligação entre suas interfaces, as quais são realizadas de fato através de
blocos funcionais de interface de serviço (SIFB).
3.1.3.1.6. Diagrama de Atividades
Os Diagramas de Atividades são utilizados para descrever, de forma gráfica,
os algoritmos executados em um único bloco funcional ou mostrar o inter-
relacionamento entre as tarefas executadas por vários deles (independentemente de
serem tarefas seqüenciais ou concorrentes). Como os Diagramas de Atividades são
baseados na semântica da rede de Petri, eles podem ser futuramente usados para a
modelagem e a verificação formal dos sistemas.
3.1.3.1.7. Diagrama de Máquinas de Estados
O comportamento de um bloco funcional básico, dado pelo diagrama de
controle de execução (ECC) na norma IEC 61499, pode ser descrito em UML
através do Diagrama de Máquinas de Estados. Para manter consistência com o
ECC, os estados são indicados pelo estereótipo EC State, sendo sempre o estado
inicial chamado START. As transições entre estados (EC Transition) representam os
eventos, suas variáveis associadas, e as condições que provocam a passagem de
um estado a outro (caso não haja nenhum destes, denota-se o fato com o símbolo
“1”, como na norma IEC 61499). Por fim, a ação executada em cada estado (dada
pelo estereótipo EC Action) serve para designar o algoritmo que deve ser executado
Figura 34: Diagrama de Distribuição elaborado segundo o mapeamento de Panjaitan e Frey.
104
nesse estado e quais os eventos e dados de saída que devem ser atualizados
quando do término da execução desse mesmo algoritmo.
3.1.3.1.8. Diagrama de Casos de Uso
Os Diagramas de Casos de Uso, embora usados para descrever as
principais funcionalidades oferecidas por um sistema (sem detalhes de
implementação), assim como os cenários em que o mesmo está inserido, não
encontram correspondência entre os modelos previstos pela norma IEC 61499.
Portanto, apesar de serem usados para fornecer uma visão geral do sistema, tais
diagramas não são usados no processo de transformação da UML para blocos
funcionais.
3.1.3.1.9. Diagrama de Interação
Os Diagramas de Interação mostram o comportamento dinâmico entre
objetos, representantes de blocos funcionais, por exemplo): enquanto os Diagramas
de Seqüência são mais voltados para as descrições de temporização, os Diagramas
de Colaboração/Comunicação têm maior vínculo com os papéis ou tarefas
desempenhados por cada um dos objetos. Vale ressaltar que o nível de
aprofundamento pode variar durante o processo de projeto: Panjaitan e Frey, nos
artigos analisados, mostram o uso dos diagramas de seqüência, por exemplo, tanto
Figura 35: Diagrama de Máquinas de Estados segundo o mapeamento de Panjaitan e Frey – retiradode Panjaitan e Frey (2006a).
105
para a simples captura de requisitos como para mostrar a ordem de ocorrência de
eventos.
3.1.3.2. Processo de transformação da UML para blocos funcionais
Por fim, uma vez que as descrições em UML tenham sido feitas com
estereótipos dos tipos Data (dado), FBType (tipo de blocos funcionais), Adapter
(adaptador), Subapplication (subaplicação), Resource (recurso), Device (dispositivo)
e System (sistema), e que os mesmos sejam rastreáveis, pode-se passar tais
modelos para descrições em eXtensible Markup Language (XML), segundo o que é
disposto na Parte 2 da norma IEC 61499. Segundo Panjaitan e Frey (2006b), um
exemplo de regra de tradução é dado a seguir. Essa conversão de modelos UML
para modelos IEC 61499 pode ser implementada em uma ferramenta, tendo em
vista um mapeamento automático UML-IEC61499.
Figura 36: Diagrama de Seqüência segundo o mapeamento de Panjaitan e Frey – adaptado dePanjaitan e Frey (2006a).
106
3.1.4. Mapeamento de Zhang, Diedrich e Halang
O paradigma FBUML proposto por Zhang, Diedrich e Halang (2005) prevê a
extensão dos metamodelos da UML – ou seja, modelos em UML que definem essa
mesma linguagem – através da definição de novos estereótipos, restrições e valores
rotulados, agrupados em um perfil, os quais descrevem os principais conceitos
relacionados à norma IEC 61499. Dessa maneira, a UML pode ser usada, junto aos
diagramas de blocos funcionais e de configuração de dispositivos, para o projeto de
um sistema de automação distribuído, sendo esses últimos responsáveis pela
especificação arquitetural abstrata do sistema. A seguir, é detalhada a função de
cada um dos diagramas da UML nesse mapeamento UML-IEC61499.
3.1.4.1. Diagramas da UML usados no mapeamento de Zhang, Diedrich e Halang
Os diagramas da UML usados nesse mapeamento são os Diagramas de
Classes, de Estruturas Compostas, de Máquinas de Estado, de Atividades e de
Interação.
[1] Capturar estrutura dos diagramas da UML[2] Eliminar os dados irrelevantes[3] Selecionar SYSTEM para captar a estrutura do sistema: [3.1] Escrever informações relacionadas à versão do XML [3.2] Escrever o nome do sistema, i := 0 [3.3] Ler Dispositivo(i) (Device(i)) SE Dispositivo = último ENTÃO ir para [4] SENÃO INICIAR [3.3.1] Escrever o nome do Dispositivo(i), j := 0 [3.3.2] Ler Recurso(i) (Resource(i)) SE Recurso = último ENTÃO ir para [3.3] SENÃO INICIAR [3.3.2.1] Escrever o nome do Recurso(i,j) [3.3.2.2] Compor a rede de blocos funcionais (RedeBF): Acrescentar FB (nome, parâmetros, etc.) Acrescentar conexões entre eventos Acrescentar conexões entre dados SE RedeBF != fim ENTÃO voltar para [3.3.2.2] SENÃO SE Recurso != último ENTÃO (j := j + 1), voltar para [3.3.2] SENÃO (i := i + 1), voltar para [3.3][4] FIM (i := 0, j := 0)
107
3.1.4.1.1. Diagrama de Classes
Os Diagramas de Classes representam os diferentes tipos de blocos
funcionais e suas interfaces. Os blocos funcionais são representados por classes,
que podem possuir os seguintes estereótipos: BasicFB (para blocos funcionais
básicos), CompositeFB (para blocos funcionais compostos) e SIFB (para blocos
funcionais de interface de serviços). A partir daí, as interfaces dos tipos de blocos
funcionais são determinadas pelos elementos de sua classe representante: os
eventos de entrada são métodos públicos de estereótipo EventInput; os eventos de
saída são métodos privados de estereótipo EventOutput; os dados de entrada são
atributos privados de estereótipo InputVariable; os dados de saída são atributos
públicos de estereótipo OutputVariable; e as variáveis internas são atributos privados
estereotipados como InternalVariable.
Para estabelecer uma associação entre eventos e dados, como ocorre na
norma IEC 61499 ao se utilizar o qualificador WITH, emprega-se entre o evento e o
dado um relacionamento de dependência de estereótipo AssociateWith. Já para
estabelecer a relação entre um evento de entrada e seus dados e eventos de saída
deve ser posto entre eles um relacionamento de dependência de estereótipo
obsOutput (partindo do evento de entrada para as saídas), tanto no caso de blocos
funcionais básicos como compostos.
Por fim, para a representação de redes de blocos funcionais (ou seja, de
blocos funcionais compostos ou de subaplicações), são usadas classes com os
estereótipos CompositeFB (para blocos funcionais compostos) ou Application e
SubApplication (para aplicações e subaplicações), cujas interfaces externas são
especificadas da mesma maneira descrita anteriormente. Tais classes são
associadas às suas instâncias de blocos funcionais internas através de
relacionamentos de agregação.
3.1.4.1.2. Diagrama de Estruturas Compostas
Uma alternativa para expressar os elementos internos de blocos funcionais
compostos, aplicações ou subaplicações é fazer o Diagrama de Estrutura Composta
da classe que representa o bloco funcional.
As conexões de eventos e dados entre os blocos funcionais (representados
108
pelas partes da classe composta) podem ser especificadas como instâncias da
metaclasse InformationFlow (fluxo de informação), sendo seus estereótipos,
respectivamente, EventConnection ou DataConnection. Os estereótipos citados são
definidos pela extensão das metaclasses InformationItem (item de informação) e
Connector (conector). Como um InformationFlow pode transferir alguns
InformationItem, eventos e dados (instâncias de InformationItem) são passados por
uma mesma conexão de eventos e dados. Colaborações podem ser usadas para
descrever mais detalhes das conexões entre as instâncias contidas em uma classe,
e as conexões entre a classe composta e seus componentes pode ser especificada
com o uso de instâncias de portas e conectores.
3.1.4.1.3. Diagrama de Máquinas de Estados
O Diagrama de Máquinas de Estados da UML é utilizado para a
representação do diagrama de controle de execução de um bloco funcional, e, nesse
caso, seu estereótipo denomina-se ECC. Os estados do ECC são marcados pelo
estereótipo ECState, enquanto suas transições são de estereótipo ECTransition.
Estas, por sua vez, podem ter apenas um evento como gatilho (não havendo guarda
ou atividade na transição), ou podem ser disparadas por um evento e uma
expressão booleana simultaneamente (caso em que a transição tem o evento por
gatilho e a expressão por guarda). Por fim, vale lembrar que, para manter
compatibilidade com a norma IEC 61499, o estereótipo ECC possui como restrições
Figura 37: Relação entre os estereótipos DataConnection e EventConnection com as metaclassesConnector e InformationItem da UML (a), e exemplo de Diagrama de Estrutura Composta segundo omapeamento de Zhang, Diedrich e Halang – retirado de Zhang, Diedrich e Halang (2005).
109
os fatos de que nem seus estados nem suas transições podem ser compostos, além
de que seu estado inicial deve ser sempre denominado START.
3.1.4.1.4. Diagrama de Atividades
O(s) algoritmo(s) ligado(s) à(s) atividade(s) executada(s) na entrada a um
estado do ECC pode(m) ser representado(s) na UML por um método privado. Assim,
para cada um deles atribui-se o estereótipo Algorithm, que estende a metaclasse
Operation e que possui visibilidade privada fixa. Por fim, como ocorre para qualquer
método da UML, seu comportamento pode ser especificado através de um Diagrama
de Atividades.
3.1.4.1.5. Diagrama de Interação
Os Diagramas de Interação da UML previstos para uso no mapeamento de
Zhang, Diedrich e Halang são o Diagrama de Seqüência e o Diagrama de
Colaboração/Comunicação.
Os Diagramas de Seqüência são responsáveis por indicar a interação entre
as instâncias dos componentes de uma rede de blocos funcionais e suas conexões
de eventos e dados, dando destaque à visão sobre os tempos de execução de tais
interações. Os Diagramas de Colaboração/Comunicação, por sua vez, são
empregados para mostrar a cooperação entre essas instâncias do ponto de vista
estrutural. A conexão entre eventos (de entrada e saída) é descrita por uma
mensagem (de estereótipo EventConnection), dirigida do objeto remetente ao objeto
destinatário. Nesse contexto, os dados associados ao evento são passados como
parâmetros das mensagens. Para não haver conflito na nomenclatura de tais
mensagens, a seguinte regra é sugerida: “objeto_receptor evento_do_remetente
evento_do_destinatário”. Para os parâmetros, a regra aplicada deve ser:
“objeto.variável” (sendo esse objeto o dono da variável declarada). Deve-se
esclarecer que as mensagens das instâncias para a classe agregadora da rede de
blocos funcionais são operações da classe (ou bloco funcional composto) que
representam eventos de saída da mesma, enquanto aquelas que partem da classe
para as instâncias identificam seus eventos de entrada.
110
3.1.5. Mapeamento de Heverhagen, Tracht e Hirschfeld
A abordagem utilizada por Heverhagen, Tracht e Hirschfeld (2003) para o
mapeamento entre diagramas da UML e diagramas de blocos funcionais é bastante
diferente das anteriores. Neste caso, o objetivo é utilizar as extensões da UML – ou
seja, estereótipos, restrições e valores rotulados, agrupados em um perfil (profile)
denominado Adaptadores para Blocos Funcionais (ou Function Block Adapters –
FBA) – para permitir a descrição das interfaces externas de blocos funcionais (tanto
da norma IEC 61499 como de outros padrões) e de um adaptador entre esses
últimos e objetos da UML (também chamado FBA).
Figura 38: Diagrama mostrando a relação entre a classe SEQ_MVC (que representa um tipo de blocofuncional composto) e seus objetos internos ctrl:SEQ e v:SEQV (que cumprem o papel de instânciasde blocos funcionais) (a), e exemplo de Diagrama de Colaboração/Comunicação (entre uma instânciaanônima da classe SEQ_MVC e os dois objetos citados anteriormente) segundo o mapeamento deZhang, Diedrich e Halang – retirado de Zhang, Diedrich e Halang (2005).
Figura 39: Conexão entre objeto, FBA e bloco funcional – adaptado de Heverhagen, Tracht eHirschfeld (2003)
111
Vale destacar, neste ponto, que o comportamento interno dos blocos
funcionais não é mapeado em UML, mas mantido em sua linguagem original
(orientada a blocos funcionais, como Matlab/Simulink e outras definidas pela norma
IEC 61131-3).
Essa técnica tem como principal vantagem a integração entre componentes
de software orientados a eventos (objetos) e componentes de software orientados a
execução em tempo contínuo (blocos funcionais), obtendo-se, ao fim, a descrição de
um sistema completamente orientado a eventos (em UML).
O perfil da UML denominado FBA conta com sete estereótipos:
� FunctionBlock – aplicado a Classes: uma classe de estereótipo
FunctionBlock descreve um bloco funcional. Tal classe deve conter somente
portas de estereótipo FBPort para comunicação;
� FBPort, FBInPort e FBOutPort – aplicados a Portas: designam portas, que
representam os elementos para definição da estrutura externa dos blocos
funcionais (entradas e saídas de eventos e de dados). FBInPort provê uma
interface de estereótipo FBInterface, FBOutPort requer uma interface de
estereótipo FBInterface e ambas herdam suas características de FBPort.
Segundo os autores, as portas da UML são as melhores contrapartes para
os componentes da interface externa de um bloco funcional, já que tais
conceitos estão ligados à idéia de prover meios para exportação e
importação de dados, além de ajudar a deixar encapsulado o
comportamento interno de seus respectivos módulos;
� FBInterface – aplicado a Interfaces: é uma interface especial que possui
apenas uma operação (ValueChanged), cujo parâmetro possui o valor de
uma das variáveis de interface de um bloco funcional. O tipo do parâmetro
deve pertencer ao conjunto permitido pela linguagem orientada a blocos
funcionais a que o bloco funcional pertence, e esse tipo deve ser
remodelado em UML como tipo de dado, tipo primitivo ou enumeração
(datatype, primitivetype ou enumeration);
� FunctionBlockAdapter – aplicado a Classes: as classes de estereótipo FBA
têm a função de interconectar classes da UML a blocos funcionais
(representados por classes de estereótipo FunctionBlock). Para isso, os FBA
possuem portas comuns (através das quais se comunicam com as classes
da UML) e portas de estereótipo FBPort: por meio destas últimas, as
112
interfaces das classes que designam blocos funcionais ligam-se às
interfaces dos FBA. Para ser possível o mapeamento entre os protocolos da
UML e dos blocos funcionais (ou seja, para que ambos consigam
intercambiar variáveis e eventos), é definido um conjunto de traduções
chamadas FBATranslations, que descrevem o funcionamento interno do
FBA. Essas traduções são vinculadas a seus FBA através de um valor
rotulado chamado translations (de estereótipo FBATranslation); e
� FBATranslation – aplicado a Classe: uma classe de estereótipo
FBATranslation descreve o mapeamento entre os protocolos da UML e dos
blocos funcionais. O estereótipo FBATranslation possui alguns valores
rotulados:
fba (tipo: FunctionBlockAdapter): indica a classe (FBA) a que essa
tradução pertence (sendo esta uma e apenas uma);
isOrthogonal (tipo: booleano): se estiver marcada como verdadeira,
mostra que essa tradução é executada concorrentemente às demais de
seu FBA;
trigger (tipo: evento): designa um evento de sinal de uma porta ou
mudança em uma variável de interface que dispara a execução de uma
tradução;
signals (tipo: sinal): abrange a listagem de todos os sinais da porta que
devem ser acessados, recebidos ou enviados (inclusive o sinal de trigger,
se for o caso);
translationBody (tipo: string) e exceptionBody (tipo: string): dados na
linguagem FBA, representam os programas de tradução entre os
protocolos da UML e dos blocos funcionais. O software executado
normalmente corresponde àquele contido no valor rotulado
translationBody, enquanto que o exceptionBody só é executado em caso
de erro no primeiro. Os programas citados anteriormente podem ser
dados em Diagramas de Máquinas de Estados, já que a linguagem FBA
é definida como um subconjunto da semântica desses diagramas; e
fbProtocol (tipo: ProtocolStatechart): fornece um diagrama de estados
que descreve todas as seqüências válidas de mudanças nas variáveis de
interface acessadas pela tradução.
113
Por fim, destaca-se que o mapeamento de Heverhagen, Tracht e Hirschfeld
aplica-se de forma mais fácil a blocos funcionais da norma IEC 61499, já que os
blocos funcionais definidos por ela são orientados a eventos por natureza.
3.2. COMPARAÇÃO ENTRE MAPEAMENTOS UML-IEC61499 E
COMENTÁRIOS
Os mapeamentos UML-IEC61499 vistos anteriormente podem ser divididos
em dois tipos: os quatro primeiros – o de Thramboulidis, o de Dubinin e Vyatkin, o de
Panjaitan e Frey e o de Zhang, Diedrich e Halang – referem-se à passagem de
modelos da UML para modelos da norma IEC 61499, conforme seria necessário
para que as fases de levantamento de requisitos e análise de desenvolvimento de
um sistema fossem realizadas em UML, e para que a tradução desses modelos
(conforme descrevem os autores) levassem ao tratamento das demais fases de
engenharia de um sistema diretamente em abstrações da norma IEC 61499. O
mapeamento de Heverhagen, Tracht e Hirschfeld, no entanto, apesar de ser um tipo
de mapeamento entre UML e qualquer tipo de bloco funcional (inclusive os da IEC
61499) – merecendo, por isso, ser citado neste trabalho – tem um outro propósito:
compatibilizar módulos de software da orientação a objetos, dados em UML, com
módulos de software orientados a linguagens de blocos funcionais. Sendo assim,
centra-se agora o foco nos primeiros trabalhos, que serão analisados a seguir.
Conforme demonstrado pela Tabela 1, os principais diagramas da UML
utilizados nos mapeamentos UML-IEC61499 citados previamente são o Diagrama de
Classes, o Diagrama de Máquinas de Estado e os Diagramas de Seqüência e de
Colaboração/Comunicação. Esse subconjunto de diagramas é muito representativo,
não somente pelo fato de ser adotado por todos os autores estudados, mas também
por expressar alguns dos pontos de vista mais importantes de um sistema de
automação distribuído (em especial, de sua aplicação): estrutura – dado pelo
Diagrama de Classes, que essencialmente mostra a composição de uma rede de
blocos funcionais e o inter-relacionamento estático entre os blocos; comportamento
de um módulo – dado pelo Diagrama de Máquinas de Estado, que descreve o
114
diagrama de controle de execução (ECC) de um bloco funcional básico; e
comportamento geral do sistema – exposto através dos Diagramas de Seqüência e
de Colaboração/Comunicação – usados para demonstrar a dinâmica do intercâmbio
de eventos e dados entre blocos funcionais.
Por sua vez, a partir da Tabela 2 e da Tabela 3, que relacionam as
abstrações da norma IEC 61499 a elementos e relacionamentos da UML, percebe-
se a utilização intensiva de estereótipos para executar a extensão da linguagem
UML (de forma a que ela cubra os conceitos da norma IEC 61499). Este fato, no
entanto, parece ser um entrave se considerarmos que a utilização da UML seria
prevista para engenheiros de sistemas e software que, embora pudessem ter
conhecimentos gerais sobre sistemas de automação, não necessariamente estariam
envolvidos com pesquisas sobre a norma IEC 61499: portanto, a extensão da UML
para cobrir o vocabulário dessa norma poderia ser questionado.
Por outro lado, outras fortes tendências que podem ser observadas por meio
dessas tabelas é a representação de tipos de blocos funcionais da IEC 61499 por
meio de classes; instâncias de blocos funcionais através de objetos; conexões de
eventos (associados a dados através do qualificador WITH) através de métodos ou
mensagens (e seus parâmetros); entradas e saídas de dados por meio de atributos;
e relacionamento entre blocos funcionais compostos e suas instâncias de blocos
funcionais (componentes) através de relacionamentos de agregação.
De certa maneira, pode-se dizer que essas tendências estabelecem um
conjunto mínimo de representações suficientes para exprimir a maioria dos conceitos
sobre aplicações de sistemas de automação. Outros modelos da norma IEC 61499
(como os de dispositivos e recursos) foram representados apenas por alguns
autores, e podem ser questionados, novamente, no sentido da necessidade de que
os especificadores de requisitos e análise geral do sistema tenham de chegar a esse
nível de abstração, se se pretende que equipes de engenharia de sistemas e
software e de engenharia de controle e automação trabalhem cooperativamente: é
possível que, na verdade, essa tarefa de refinamento do sistema caiba melhor a
estes últimos que aos primeiros, já que eles detêm uma visão mais apurada sobre a
implementação provável do sistema.
No capítulo seguinte, serão analisadas ferramentas de suporte ao
desenvolvimento de projetos de sistemas de automação distribuídos, com foco
naquelas que realizam conversões UML-IEC61499.
115
Tabela 1: Identificação dos diagramas da UML utilizados para expressar os conceitos da norma IEC61499 segundo os mapeamentos de Thramboulidis, de Dubinin e Vyatkin, de Panjaitan e Frey e deZhang, Diedrich e Halang.
116
Tabela 2: Identificação dos principais elementos da UML utilizados para expressar os conceitos danorma IEC 61499 segundo os mapeamentos de Thramboulidis, de Dubinin e Vyatkin, de Panjaitan eFrey e de Zhang, Diedrich e Halang.
117
Tabela 3: Identificação dos principais relacionamentos da UML utilizados para expressar os conceitosda norma IEC 61499 segundo os mapeamentos de Thramboulidis, de Dubinin e Vyatkin, de Panjaitane Frey e de Zhang, Diedrich e Halang.
118
4. FERRAMENTAS COMPUTACIONAIS PARA SUPORTE ÀS
ATIVIDADES DE ENGENHARIA VOLTADAS AO DESENVOLVIMENTO
DE SISTEMAS DE AUTOMAÇÃO DISTRIBUÍDOS
Mostram-se neste capítulo algumas das principais ferramentas
computacionais para suporte às atividades de engenharia voltadas ao
desenvolvimento de sistemas de automação distribuídos e que utilizam as
abstrações da norma International Electrotechnical Commission (IEC) 61499 como
modelos para o projeto de tais sistemas. A ênfase, no entanto, foi dada àquelas que
implementam métodos de mapeamento UML-IEC61499, já que estas permitem a
cobertura das fases de levantamento de requisitos e análise do projeto por meio de
modelos da Unified Modeling Language (UML).
4.1. APRESENTAÇÃO GERAL DAS FERRAMENTAS
As ferramentas a serem apresentadas neste capítulo, por ordem de
aprofundamento em sua análise, são citadas a seguir:
� CORFU ESS: Common Object-oriented Real-time Framework for the Unified
development of distributed Industrial-Process Measurement and Control
Systems (IPMCS) applications (CORFU) Engineering Support System (ESS)
– versão 1.0.0 – Software Engineering Group, Electrical & Computer
Engineering, University of Patras;
� Conversores UML-FB: Converter from UML to IEC 61499 function blocks –
versão 1.0.1 e Converter from IEC 61499 function blocks to UML – versão
1.5 – University of Penza;
� FBench: IEC 61499 FBench – versão 0.5 (build 20070610) – Intelligent
Mechatronics and Automation Group, Department of Electrical and
Computer Engineering, The University of Auckland;
� FBDK: Function Block Development Kit (FBDK) – versão 20061017 –
Holobloc, Inc.;
119
� 4DIAC-IDE: Framework for Distributed Industrial Automation and Control-
Integrated Development Environment (4DIAC-IDE) – versão 0.0.2 (build
2007-09-27) – 4DIAC Consortium;
� ISaGRAF: ISaGRAF – versão 5.0 – ICS Triplex;
� Fuber: FUnction Block Execution Runtime (Fuber); e
� Archimedes ESS: Archimedes ESS – versão 0.8 – Software Engineering
Group, Electrical & Computer Engineering, University of Patras.
4.1.1. CORFU ESS
O CORFU ESS (SOFTWARE ENGINEERING GROUP, 2006), ferramenta
criada para automatizar o processo de desenvolvimento segundo o ciclo de vida de
desenvolvimento CORFU para sistemas distribuídos de controle e monitoração de
processos industriais (Industrial-Process Measurement and Control Systems –
IPMCS), está construído segundo a arquitetura chamada enhanced four Layer
CORFU Architecture (enhanced-4LCA), e leva em consideração as recomendações
da norma IEC 61499 quanto às ferramentas computacionais para auxílio a projetos
de engenharia.
Segundo Thramboulidis (2003), a arquitetura enhanced-4LCA possui quarto
camadas (ordenadas, a seguir, do nível mais baixo ao mais alto):
� Camada de processo industrial: abrange as representações de software dos
componentes do mundo real (artefatos de implementação), que fazem parte
dos diagramas de projeto das plantas de automação;
� Camada de sistema: fornece uma visão de engenharia do sistema de
automação distribuído, ao mostrar as abstrações de software dos recursos
computacionais que permitem a implementação da camada superior da
arquitetura (camada de aplicação) – elementos físicos tais como dispositivos
de campo e redes de comunicação, por exemplo, que fazem interface entre
as aplicações e os dispositivos do mundo real;
� Camada de aplicação: conta com as representações necessárias à análise,
projeto e implementação dos sistemas (como aqueles dados nos Diagramas
de Casos de Uso, de Interação, de Contexto e de Classes (da UML), e nos
diagramas de blocos funcionais (da norma IEC 61499)); e
� Camada de interface homem-máquina: reúne todas as abstrações para o
120
desenvolvimento e operação de interfaces homem-máquina.
Por sua vez, conforme descrito por Tranoris e Thramboulidis (2002, 2003a),
o ciclo de vida de desenvolvimento CORFU é iterativo e incremental, e procura
expandir o processo de desenvolvimento definido pela norma IEC 61499,
acrescentando a este algumas técnicas de desenvolvimento baseadas em
componentes, orientação a objetos e modelagem em UML. As principais atividades
desse ciclo de vida são:
� Captura de requisitos: definição dos casos de uso do sistema (segundo a
definição de Ivar Jacobson), descritos através do Diagrama de Casos de
Uso da UML;
� Captura do comportamento do sistema: levantamento do comportamento
dinâmico do sistema por meio dos Diagramas de Colaboração e Seqüência
da UML;
� Captura da visão estática do sistema: definição da estrutura do sistema, com
o uso do Diagrama de Classes da UML;
� Projeto dos diagramas de blocos funcionais: obtenção dos diagramas de
blocos funcionais da norma IEC 61499 a partir dos diagramas UML, usados
na avaliação e refinamento do sistema, verificação de modelos e distribuição
de blocos funcionais em dispositivos físicos.
Até o momento, o CORFU ESS implementa diversos editores das
abstrações da camada de aplicação e um editor da camada de sistema da
arquitetura enhanced-4LCA. Para isso, o CORFU ESS pode ser dividido, do ponto
de vista estrutural, em dois subsistemas (TRANORIS; THRAMBOULIDIS, 2003b):
� Uma ferramenta arbitrária para auxílio à engenharia de software (papel
cumprido até o momento pelo IBM Rational Rose), que cobre a captura de
requisitos, de comportamento e de visão estática do sistema descritos pelo
processo CORFU, segundo os conceitos da UML (abstrações pertencentes
à camada de aplicação da arquitetura enhanced-LCA); e
� A ferramenta CORFU-FBDK, usada durante a atividade de projeto de
diagramas de blocos funcionais do processo CORFU. O CORFU-FBDK
pode ser subdividido em três editores e uma ferramenta auxiliar:
Editor de Tipos de Blocos Funcionais (Function Block Type Editor): usado
para criar novos tipo ou modificar tipos de blocos funcionais pré-
existentes na biblioteca do CORFU (vinculado às abstrações da camada
121
de aplicação da arquitetura enhanced-4LCA);
Editor de Diagramas de Blocos Funcionais (Function Block Diagram
Editor): usado para a construção ou refinamento dos diagramas de
blocos funcionais (e também vinculado às abstrações da camada de
aplicação da arquitetura enhanced-4LCA)
Gerenciador do Recurso de Transformação (Transformation Facility
Manager (TFM)): automatiza a transposição dos diagramas UML para os
diagramas de rede de blocos funcionais, segundo as normas UML-
IEC61499 dispostas pelo mapeamento de Thamboulidis, conforme visto
no Capítulo 3); e
Editor da Camada de Sistema (System Layer Editor): utilizado para a
distribuição da aplicação de controle nos elementos de software que
representam os recursos computacionais do sistema (sendo um editor,
portanto, de abstrações referentes à camada de sistema da arquitetura
enhanced-4LCA).
A seguir, cada uma dessas partes será analisada separadamente.
4.1.1.1. Subferramentas do CORFU ESS
4.1.1.1.1. Editor de Tipos de Blocos Funcionais (Function Block Type Editor)
Segundo Tranoris (2003), o editor de tipos de blocos funcionais é utilizado
principalmente para modificar tipos de blocos funcionais já existentes e para a
criação de novos tipos de blocos funcionais (tanto básicos quanto compostos, a
partir dos modelos básicos ou de outros blocos funcionais pré-existentes).
Ao se editar ou criar um tipo de bloco funcional básico, as principais
informações exibidas são:
� Descrição geral do bloco funcional: expõe propriedades como o nome e a
versão do bloco; mostra e permite a modificação das entradas e saídas de
dados e eventos do bloco funcional (inclusive a determinação de tipos, a
vinculação de dados e eventos pelo qualificador WITH e a criação de
soquetes, plugues e variáveis internas); e exibe a representação gráfica do
bloco funcional;
� Especificação do bloco funcional em eXtensible Markup Language (XML):
122
mostra a estrutura do bloco funcional em XML, segundo a norma IEC 61499;
� Especificação do diagrama de controle de execução do bloco funcional
(Execution Control Chart – ECC): permite o projeto do ECC de um bloco
funcional, contando com:
Criação de estados e indicação do estado inicial (chamado sempre
START, de acordo com a norma IEC 61499) por uma linha de contorno
dupla;
Atribuição de um algoritmo e de um evento de saída (para indicação do
término do processamento do algoritmo) a um estado, caso desejado; e
Interligação dos estados através de transições simples ou complexas –
ou seja, com ou sem evento de gatilho (responsável pelo disparo da
transição), condição de guarda (expressão booleana que, se verdadeira,
habilita uma transição que tenha recebido seu evento) e ação
(processamento atômico causado pela transição);
� Estrutura navegável, em árvore, das informações contidas no XML do bloco
funcional;
� Detalhamento dos algoritmos citados no ECC: inclui o nome, a descrição e o
funcionamento de cada algoritmo (que pode ser dado em texto estruturado,
diagramas escada (ladder diagrams) ou em qualquer outra linguagem de
alto nível, e pode manipular as variáveis internas e as variáveis de interface
do bloco funcional); e
� Especificação das seqüências de serviço de um bloco funcional, caso ele
seja um bloco funcional de interface de serviço (Service Interface Function
Block – SIFB): exibe as transações entre as duas entidades participantes
dessas seqüências, com o nome dos eventos e os parâmetros
intercambiados entre elas.
No caso da edição ou criação de um bloco funcional composto, as
informações disponíveis são praticamente as mesmas descritas para um bloco
funcional básico, exceto a edição do ECC (que não se aplica, e é substituída pela
determinação de um diagrama de blocos funcionais interno ao bloco funcional
composto).
123
4.1.1.1.2. Editor de Diagramas de Blocos Funcionais (Function Block Diagram
Editor)
Conforme descrito em Tranoris (2003), o editor de diagramas de blocos
funcionais permite a criação ou a edição de um diagrama de blocos funcionais da
norma IEC 61499.
As principais funcionalidades oferecidas por essa ferramenta são:
� Adicionar instâncias de blocos funcionais (básicos ou compostos) a um
diagrama, a partir dos tipos disponíveis na biblioteca de blocos funcionais do
CORFU ESS (que também pode incluir tipos especificados pelo usuário,
além dos pré-existentes);
� Inserir blocos funcionais de eventos (Event Function Blocks) a um diagrama,
os quais podem ser exibidos através da notação tradicional ou de forma
simplificada;
� Editar características dos blocos funcionais pertencentes a um diagrama
(como seus nomes, tipos, descrições e os valores iniciais das variáveis de
dados de entrada), recarregar a definição do bloco funcional ou chamar o
editor de blocos funcionais;
� Adicionar um Industrial Process Parameter (IPP) pré-existente ao diagrama
Figura 40: Editor de Tipos de Blocos Funcionais (Function Block Type Editor) da ferramenta CORFUESS – neste caso, exibindo a interface externa e o diagrama de controle de execução (ECC) de umbloco funcional.
124
de blocos funcionais – ou seja, uma variável de entrada ou de saída de um
Industrial Process Terminator (IPT) dado no diagrama de camada de
sistema, o qual representa uma entidade existente na planta;
� Mostrar ou permitir a interconexão entre as instâncias de blocos funcionais e
entre IPP da rede de blocos funcionais;
� Exibir de maneira gráfica os tipos de dados das variáveis de interface de um
bloco funcional (recurso ativado opcionalmente para facilitar a interligação
dos blocos);
� Mostrar a relação de determinadas conexões do diagrama visualizado com
outros diagramas de blocos funcionais (referências cruzadas);
� Modificar as propriedades de visualização do gráfico (como o zoom),
adicionar notas e comandar a impressão do diagrama de blocos funcionais;
� Unificar um diagrama de blocos funcionais a outros diagramas (merge); e
� Testar (executar) o diagrama de blocos funcionais, que abrange:
Selecionar os eventos a disparar a execução, os valores iniciais dos
dados e as variáveis de entrada e saída a serem monitoradas; e
Observar as conexões ativas do diagrama de blocos funcionais (que
indicam visualmente o momento da transmissão de eventos e dados
entre blocos funcionais), a seqüência temporal de eventos e a ordem
cronológica da chamada aos blocos funcionais do diagrama de acordo
com a execução da rede (que pode ser feita por passos ou
continuamente);
Figura 41: Rede de blocos funcionais descrita no Editor de Diagramas de Blocos Funcionais(Function Block Diagram Editor) da ferramenta CORFU ESS.
125
4.1.1.1.3. Editor da Camada de Sistema (System Layer Editor)
O editor da camada de sistema permite realizar, segundo Tranoris (2003),
um primeiro desenho da estrutura física para a qual o sistema de automação é
projetado, incluindo os dispositivos da planta e a sua interconexão por meio de
redes. A cada dispositivo podem ser designados IPT (as abstrações para
representar os elementos físicos do sistema, que agem como fonte ou receptores de
dados e interagem com o mundo real), aos quais, por sua vez, podem ser atribuídos
os blocos funcionais da aplicação (configurando o processo de distribuição dos
módulos).
Em um diagrama da camada de sistema, podem ser postos:
� Redes compatíveis com a norma IEC 61499 – às quais são dados um nome,
um tipo (como LonWorks, por exemplo) e uma descrição, e para as quais se
determina os dispositivos ligados a elas (e se é possível colocar nessas
redes dispositivos não aderentes à IEC 61499);
� Redes não compatíveis com a norma IEC 61499, contando com os mesmos
dados básicos descritos acima (exceto a especificação de possibilidade de
suporte a dispositivos não aderentes à IEC 61499, já que isso é implícito);
� Dispositivos aderentes à norma IEC 61499, aos quais se pode especificar o
nome, a descrição e as propriedades do dispositivo (como nome e descrição
do fabricante, quais entradas e saídas estão disponíveis – inclusive citando
seus tipos e descrições e quais os blocos funcionais da aplicação atribuídos
Figura 42: Execução da rede de blocos funcionais através do Editor de Diagramas de BlocosFuncionais (Function Block Diagram Editor) da ferramenta CORFU ESS.
126
a esses dispositivos). Também é possível estabelecer comunicação via
TCP/IP com o dispositivo, caso o mesmo seja compatível com redes
Ethernet, e desenhar o diagrama de blocos funcionais de interface de
processo (Process Interface Function Block Diagram), cuja função é
determinar como as entradas e saídas de um dispositivo (IPP) poderiam ser
transformadas em nível lógico, com o uso de blocos funcionais para
tratamento dos sinais, de forma que as aplicações ficassem independentes
do encapsulamento físico do dispositivo (por exemplo, transformação de
uma variável dada pelo valor booleano atribuído a quatro portas de entrada
(zero para ausência de tensão, e um para presença de tensão) em um valor
em representação decimal (ou seja, passagem de “0000” a “1111” das
portas para 0 a 15, dado por uma única variável de tipo inteiro, por exemplo);
� Dispositivos aderentes ao padrão Object-Linking and Embedding (OLE) for
Process Control (OPC), para os quais são especificados nome, descrição,
tipo (OPC Data Access 1.0, 2.0 ou 3.0), dados do fornecedor, diagrama de
blocos funcionais de interface de processo, qual o servidor OPC, como
mapear IPP em itens OPC e e quais blocos funcionais da aplicação foram
carregados nesse dispositivo;
� Dispositivos genéricos, para os quais se determina o nome, a descrição, as
propriedades do dispositivo, os dados do fabricante e as entradas e saídas
disponíveis (inclusive com tipos e descrições de uso);
� IPT, sejam pré-definidos ou personalizados, para os quais se pode escolher
um ícone que os represente, um tipo (como esteira ou interface homem-
máquina, dentre uma lista fixa de opções) e os IPP correspondentes (cada
qual com nome, tipo, descrição, especificação se se trata de um IPP de
evento ou de dado, e se ele é de entrada (sensor) ou saída (atuador)); e
� Outros elementos de sistema (como computador, “nuvem” de rede e
unidades de intercomunicação), meramente ilustrativos.
Após o projeto do sistema físico, atribuição dos IPT e distribuição dos blocos
funcionais entre os dispositivos, a ferramenta de gestão do carregamento da
aplicação (Download Application Manager) ajudaria a estabelecer conexão com os
mesmos e carregar seus blocos funcionais. Como ainda está em fase experimental,
os comandos são enviados em XML, e se um dispositivo puder interpretá-los, a
comunicação pode ser estabelecida (TRANORIS, 2003).
127
4.1.1.1.4. Gerenciador do Recurso de Transformação (Transformation Facility
Manager)
Tranoris (2003) apresenta o gerenciador do recurso de transformação como
a ferramenta responsável pela passagem das abstrações em UML para as
abstrações da norma IEC 61499: assim, ela estabelece comunicação entre o
software IBM Rational Rose, retira informações dos Diagramas de Classes,
Diagramas de Casos de Uso e Diagramas de Interação e aplica as regras de
transformação UML-FB propostas por Thramboulidis, vistas no capítulo 3, para a
criação de tipos de blocos funcionais e suas interconexões.
Figura 43: Sistema de dispositivos e IPT projetado por meio do Editor da Camada de Sistema(System Layer Editor) da ferramenta CORFU ESS.
Figura 44: Gerenciador do Recurso de Transformação (Transformation Facility Manager) daferramenta CORFU ESS.
128
4.1.1.2. Análise do CORFU ESS
O CORFU ESS apresenta as seguintes características positivas:
� É uma ferramenta acadêmica, e, para uso nesse âmbito, é gratuita;
� Cobre o ciclo de vida de desenvolvimento de sistemas do levantamento de
requisitos à implementação (embora esta última fase seja parcialmente
resolvida);
� Consegue realizar a passagem de diagramas UML para diagramas de
blocos funcionais de maneira relativamente fácil;
� Utiliza o IBM Rational Rose, ferramenta amplamente conhecida e aceita
para modelagem de sistemas em UML;
� Possui editores de blocos funcionais e de diagramas em geral que contam
com uma interface simples e acessível, facilitando o entendimento dos
conceitos da norma IEC 61499 e da abordagem de Thramboulidis em
relação a ela;
� Salva todos seus arquivos (de blocos funcionais, diagramas e de sistema)
em formato XML (o que permite sua importação para outras ferramentas); e
� Possui manual reduzido, mas com exemplos significativos, e conta com
ampla quantidade de artigos para sua divulgação e explicação (o que torna
seu uso fácil e atraente);
Por outro lado, o uso do CORFU ESS oferece ainda alguns entraves, que
devem ser superados nas novas versões:
� Ao utilizar o IBM Rational Rose como software de modelagem, impede que
usuários que não possuam acesso a essa ferramenta criem diagramas UML
a serem transformados pelo CORFU ESS;
� Os modelos UML guardam muita relação com os conceitos de blocos
funcionais da norma IEC 61499, inclusive por usar estereótipos dessa área
(ou seja, o usuário deve conhecer esse padrão e entender como a
transformação é feita para que ele possa gerar diagramas passíveis de
transformação – o que dificulta o uso da ferramenta por pessoas envolvidas
somente com a área de engenharia de sistemas e software);
� Algumas funcionalidades ainda estão desabilitadas (em construção), como a
descrição do funcionamento interno de um bloco funcional por meio de
diagramas escada e o uso de adaptadores na interface do bloco funcional,
129
ou ainda são feitas por protótipos muito simples, como a ferramenta de
carga da aplicação (que somente gera os comandos em XML, de forma
genérica, sem aplicação em uma rede comercial de ampla aceitação); e
� Apresenta erros intermitentes de programação, gerais, que forçam o usuário
a encontrar, por tentativa e erro, formas de contorná-los.
4.1.2. Conversores UML-FB
4.1.2.1. Conversor da UML para blocos funcionais IEC 61499 (Converter from UML
to IEC 61499 function blocks)
O conversor da UML para blocos funcionais IEC 61499 (ALSHIN; DUBININ,
2004) é um software muito simples, em que modelos de um sistema de automação
distribuídos, especificados em UML por meio da ferramenta IBM Rational Rose, são
transformados em diversos arquivos que representam tipos e instâncias de blocos
funcionais, recursos, dispositivos e sistemas da norma IEC 61499 (DUBININ;
VYATKIN; PFEIFFER, 2005). Vale ressaltar que esses arquivos são descritos em
formato XML, de acordo com o que é especificado nessa norma.
Os diagramas da UML utilizados são os Diagramas de Classe, Diagramas
de Seqüência, Diagramas de Cooperação e Diagramas de Estados, dados segundo
as convenções estabelecidas por Dubinin e Vyatkin em sua linguagem UML-FB.
As restrições da ferramenta são listadas a seguir (CONVERTER..., 2004):
� As ligações de transição não são implementadas. Somente as conexões
entre módulos do mesmo nível hierárquico ou entre níveis diretamente
relacionados (relação entre bloco funcional composto e uma instância de
bloco funcional componente) são identificadas para a realização da
transformação;
� Não são gerados nomes hierárquicos para os blocos funcionais (ou seja, os
nomes completos desses blocos, compostos pelo aninhamento dos nomes
de todas as instâncias de blocos funcionais superiores);
� Somente as conexões entre instâncias de blocos funcionais definidas nos
Diagramas de Interação são aceitos para a geração dos arquivos de saída
do software; e
130
� A alocação de blocos funcionais pode ser realizada somente em tipos de
recursos e dispositivos, mas não em suas instâncias.
4.1.2.2. Conversor dos blocos funcionais IEC 61499 para UML (Converter from IEC
61499 function blocks to UML)
O conversor dos blocos funcionais IEC 61499 para UML (RASKIN; DUBININ,
2004) é um software complementar ao anteriormente descrito, já que ele executa a
transformação de representações em arquivos XML correspondentes a blocos
Figura 45: Representação do efeito dos conversores UML-FB.
131
funcionais, recursos, dispositivos e sistemas da norma IEC 61499, que devem estar
concentrados em uma única pasta, para modelos UML da ferramenta IBM Rational
Rose (DUBININ; VYATKIN; PFEIFFER, 2005).
Os diagramas da UML utilizados são os Diagramas de Classe, Diagramas
de Seqüência, Diagramas de Cooperação e Diagramas de Estados, dados segundo
as convenções estabelecidas por Dubinin e Vyatkin (2004) em sua linguagem UML-
FB.
4.1.2.3. Análise dos Conversores UML-FB
Os conversores UML-FB apresentam as seguintes características positivas:
� São ferramentas acadêmicas e gratuitas;
� Cobrem o ciclo de vida de desenvolvimento de sistemas da análise ao
projeto;
� Conseguem realizar a passagem de diagramas UML para arquivos em XML
representantes das abstrações da norma IEC 61499 (e vice-versa) de forma
muito fácil;
� Utiliza o IBM Rational Rose, ferramenta amplamente conhecida e aceita
para modelagem de sistemas em UML; e
� Os arquivos XML gerados para as abstrações relativas a blocos funcionais
são compatíveis com a norma IEC 61499 (o que permite sua importação em
outras ferramentas).
Por outro lado, o uso dos conversores UML-FB oferecem algumas
dificuldades:
� Ao utilizar o IBM Rational Rose como software de modelagem, impede que
usuários que não possuam acesso a essa ferramenta criem diagramas UML
a serem transformados pelos conversores UML-FB;
� Os modelos UML guardam muita relação com os conceitos de blocos
funcionais da norma IEC 61499, de forma ainda mais acentuada do que
ocorre na ferramenta CORFU. Isso é muito claro ao se perceber que na
linguagem UML-FB, em uma classe, um evento é sempre dado por um
método, uma variável de dados é sempre correspondente a um atributo e
que ambos sempre precisam de estereótipos <<INPUT>> e <<OUTPUT>>.
Assim, a possibilidade da UML isolar os engenheiros de sistemas e de
132
software do ambiente puro da automação torna-se inviável;
� A documentação dessas ferramentas é praticamente inexistente. Não foi
encontrado um manual que ajude o usuário a modelar os diagramas UML da
forma devida, o que torna muito difícil que a sua transformação para os
arquivos XML seja correta. De maneira geral, a não ser quando da utilização
e observação do modelo pronto, não se consegue obter conexões entre os
blocos funcionais, mas apenas a especificação de sua interface. Caso
semelhante ocorre para a conversão de arquivos referentes às abstrações
da norma IEC 61499 para diagramas UML, em que não há manual e o seu
comportamento é observável somente através do exemplo de testes; e
� Pela data do último projeto dos conversores (2005), eles parecem estar
descontinuados.
4.1.3. FBench
A ferramenta OOONEIDA FBench (INTELLIGENT MECHATRONICS AND
AUTOMATION GROUP, 2007) é um editor de blocos funcionais, adaptadores,
recursos, dispositivos e sistemas especificados pela norma IEC 61499 e permite,
adicionalmente, a compilação e a execução desses modelos.
Dessa maneira, pode-se, através da interface gráfica do FBench:
� Criar, visualizar ou editar um tipo pré-existente de:
Bloco funcional: além das informações de sua interface (entradas e
saídas de eventos e dados, incluindo seu tipo), exibidos de maneira
gráfica, pode-se também modificar seus atributos gerais, como nome,
comentários, vinculação a uma determinada norma (como IEC 61499),
elementos de controle de versão e informações para compilação
(formatados textualmente). Os blocos funcionais devem seguir algum dos
modelos abaixo, com características adicionais particulares:■ Básico: o diagrama de controle de execução (Execution Control Chart
– ECC) pode ser editado graficamente, por meio da alteração ou
criação de novos estados (cujos parâmetros são seu nome,
comentário, determinação se é ou não estado inicial, e vinculação a
algoritmos e eventos de saída) ou novas transições (que necessitam
de especificação de condição de transição (com evento ou condição
133
booleana de guarda) e seus estados de origem e destino, e podem
conter um comentário). Por sua vez, os algoritmos devem ser dados
textualmente, nos formatos das linguagens C ou Java, em texto
estruturado ou em linguagem livre;■ Composto: admite edição de sua rede interna de blocos funcionais (à
qual podem ser alterados ou adicionados blocos funcionais e
conexões entre estes);■ Proxy: comporta modificação das seqüências de interação;■ Interface de Serviço (Service Interface Function Block): aceita
modificação das seqüências de primitivas de interação e de sua
interface;■ Simples: permite a modificação de sua interface e do algoritmo
vinculado à chegada de um evento;
Adaptadores: ademais de permitir a alteração de sua interface, a
ferramenta estabelece uma forma pela qual as seqüências de
comunicação entre soquetes e plugues podem ser especificadas;
Recursos: permite a edição de sua rede de blocos funcionais;
Dispositivos: permite a designação de seus recursos associados;
Sistemas: comporta a representação de um sistema completo (com
dispositivos, recursos e blocos funcionais).
� Visualizar a representação em XML de qualquer abstração da norma IEC
61499, alterá-la e inclusive ativar a função Parse XML para transformar o
texto XML em representação gráfica do modelo (caminho inverso ao
normalmente visto);
� Compilar os blocos funcionais para a linguagem Java; e
� Executar os sistemas que tenham seus componentes previamente
compilados.
Um artigo que faz referência a esta ferramenta de forma bem completa é o
de Dai, Shih e Vyatkin (2006), o qual pode ser utilizado para uma visão global de seu
funcionamento e das metas futuras a respeito deste projeto
134
4.1.3.1. Análise do FBench
Apesar de ser uma ferramenta interessante para iniciar os estudos sobre a
norma IEC 61499, infelizmente o FBench apresenta algumas falhas de programação
que o tornam, por vezes, complicado de usar. Um exemplo simples é, por exemplo,
que, ao se apagar o diagrama de controle de execução de um bloco funcional
através da interface gráfica, a única forma de adicionar outro diagrama desse tipo é
alterando o texto XML referente ao bloco e ativando a função Parse XML.
No entanto, tais falhas de programação devem ser superadas nas próximas
versões, o que é uma perspectiva muito alentadora, dado que a ferramenta
realmente permite expressar, por meio das abstrações da norma IEC 61499, todo o
projeto lógico de um sistema de automação. Adicionalmente, com a sua
possibilidade de compilação e execução dos modelos, pode-se testar o sistema
antes de uma provável implementação em campo.
4.1.4. FBDK
A ferramenta FBDK (HOLOBLOC, INC., 2006), embora seja implementada
por outra instituição, tem funcionalidades e aspecto muito semelhantes em relação à
ferramenta FBench. Um dos motivos pelos quais isso pode ter ocorrido é que esta
Figura 46: Interface da ferramenta FBench (exibindo a execução de um sistema).
135
ferramenta parece ter sido a predecessora das demais, já que um de seus principais
contribuidores é o pesquisador James H. Christensen (envolvido desde o início na
normatização IEC 61499). Assim, a ferramenta FBDK e seu ambiente de execução
Function Block Run-Time (FBRT) – também baseado na linguagem Java – podem
ter servido como inspiração ou base para outros trabalhos.
Assim como a ferramenta FBench, no entanto, o FBDK ainda apresenta
algumas inconsistências do ponto de vista de falhas de programação. No entanto,
mesmo com essas restrições, é possível construir a representação de sistemas
completos e executá-los.
Por fim, destaca-se que uma boa alternativa para estudar essa ferramenta,
assim como muitos outros aspectos da norma IEC 61499 (inclusive por meio de
tutoriais e transparências), é consultar a página da empresa Holobloc, Inc.
(HOLOBLOC, INC., 2006b).
4.1.5. 4DIAC-IDE
A ferramenta 4DIAC-IDE (ECEDAC CONSORTIUM, 2007), baseada na
interface gráfica do ambiente de desenvolvimento Eclipse, permite a realização de
projetos de sistemas compatíveis com a norma IEC 61499 (usando, para isso, as
Figura 47: Interface da ferramenta FBDK (exibindo um bloco funcional de interface de serviços).
136
suas abstrações, e permitindo, além disso, a definição do ambiente de hardware do
sistema) (ZOITL; STRASSER, 2007).
As principais funções dessa ferramenta são (4DIAC CONSORTIUM, 2007):
� Fornecer e gerenciar os blocos funcionais de uma biblioteca de tipos;
� Importar tipos de dados e aplicações da ferramenta FBDK;
� Exibir e permitir a edição de características e parâmetros da interface
externa e do comportamento de tipos de blocos funcionais (inclusive o
diagrama de controle de execução, interno a um bloco funcional básico, e a
rede de blocos funcionais, interna a um bloco funcional composto);
� Criar sistemas (com aplicações, dispositivos, recursos e distribuição das
aplicações nos recursos);
� Criar aplicações, compostas por blocos funcionais e/ou subaplicações, por
meio da interconexão de entradas e saídas de eventos e de dados;
� Criar subaplicações, compostas por redes de blocos funcionais, cujos blocos
podem ser distribuídos em recursos;
� Configurar o hardware dos dispositivos do sistema a partir de modelos
fornecidos (os quais podem inclusive mostrar a interconexão com
segmentos de rede, tais como Ethernet – usado, por enquanto, somente
para documentação);
� Configurar aspectos como a porta e o endereço IP de um dispositivo para
que a ferramenta consiga gerenciar o dispositivo (como, por exemplo,
ordenar a criação de blocos funcionais quando ocorre a carga de uma
aplicação);
� Visualizar e configurar aspectos dos dispositivos como os recursos, a
interface de processos e a interface de comunicação que eles contêm;
� Fazer o mapeamento de blocos funcionais em recursos dos dispositivos;
� Carregar uma aplicação em dispositivos de campo, segundo o projeto
realizado anteriormente. (vale lembrar que para instanciar ou executar as
redes de blocos funcionais é necessário ter um ambiente de execução
compatível com a IEC 61499). Algumas opções estão disponíveis:
Carregar a configuração completa do sistema (ou seja, todas as redes de
blocos funcionais, independentemente do dispositivo ou recurso em que
estejam);
Carregar a configuração de um dispositivo (somente os blocos funcionais
137
dos recursos desse dispositivo);
Carregar a configuração de um recurso (somente os blocos funcionais de
um recurso).
A ferramenta 4DIAC-IDE é compatível com dois ambientes de execução de
blocos funcionais: o 4DIAC-RTE (FORTE) – implementado para PC e processador
embarcado (ARM7), e o FBRT. Somente os dispositivos que suportem esses
ambientes poderão ser carregados com as aplicações.
Essa ferramenta faz parte de um grande projeto (com um planejamento
ambicioso), de um consórcio de empresas. Isso já faz com que, de certa forma, ela
saia adiante das demais, já que implica um esforço conjunto de pesquisa e indústria.
Tal ferramenta tenta cobrir desde o projeto com blocos funcionais até a
implementação, e, embora seus recursos ainda sejam restritos (especialmente a
carga de aplicações e a quantidade de ambientes de execução que suporta), parece
ser apenas uma questão de tempo até que mais funcionalidades sejam adicionadas.
Figura 48: Distribuição de uma aplicação em dois dispositivos através da ferramenta 4DIAC-IDE.
138
4.1.6. ISaGRAF
A ferramenta ISaGRAF 5.0 (produzida pela empresa ICS Triplex) é a
primeira ferramenta comercial para auxílio ao desenvolvimento de projetos de
sistemas de automação distribuídos que utiliza as abstrações da norma IEC 61499
como meios principais para a geração de modelos, e, a partir daí, para a
implementação e testes dos sistemas.
Segundo Chouinard e Brennan (2006), o usuário pode, através da
ferramenta ISaGRAF, separar a tarefa de projeto segundo a organização hierárquica
dos conceitos fundamentais da norma IEC 61499, trabalhando em diferentes níveis,
ou seja, desde os modelos de blocos funcionais até o modelo geral de sistema
(cujas abstrações são dispositivos, recursos e blocos funcionais). Ao invés de
construir aplicações de controle tradicionais, as interações entre os dispositivos vão
ser reguladas automaticamente e sincronizadas pelos diagramas de blocos
funcionais da IEC 61499 (já que as aplicações constituídas por redes de blocos
funcionais são distribuídas entre recursos, e estes entre dispositivos distintos,
conforme descrito pela norma). Para ajudar na verificação de uma aplicação de
controle, a mesma também pode ser simulada na presente ferramenta.
Dada a necessidade de adaptação do pessoal já acostumado com a
definição de sistemas de blocos funcionais descritos segundo as linguagens
previstas pela norma IEC 61131-3, a ferramenta ISaGRAF permite a especificação
do comportamento (algoritmos) dos blocos funcionais básicos através das
linguagens definidas nessa norma, como em texto estruturado (Structured Text – ST)
ou diagramas em escada (Ladder Diagrams – LD). Com esse mesmo intuito,
adicionalmente, a ferramenta permite o uso opcional de diagramas de funções
seqüenciais (Sequential Function Chart – SFC) para a especificação dos diagramas
de controle de execução de um bloco funcional.
Uma vez que a aplicação completa tenha sido desenvolvida na ferramenta, a
mesma pode ser gerada em linguagem C ou em código independente de plataforma-
alvo (chamado Target Independent Code – TIC). No primeiro caso, o código-fonte
deve ser compilado e ligado (linked) às bibliotecas necessárias para ser executado
em um dispositivo. Já através do uso do TIC, o software pode ser executado (e até
corrigido em tempo real) em qualquer ambiente que implemente a máquina virtual
necessária para interpretação desse código-fonte. Assim, o código da aplicação
139
pode ser carregado em elementos com hardware diferente (processadores
embarcados, Motorola, Intel e ARM, por exemplo) e em distintos sistemas
operacionais (Microsoft Windows XP, Microsoft Windows CE, Microsoft Windows
2000, Linux, VxWorks e QNX, entre outros). O TIC também pode ser usado para
construir dispositivos de automação como pequenos controladores, desde que os
mesmos consigam interpretar essa linguagem.
Finalmente, um ambiente de execução e testes previsto pela ferramenta
ISaGRAF é o seu kit de desenvolvimento: ele inclui controladores, interconectados
via Ethernet, que internamente possuem um ambiente de execução ISaGRAF e um
driver de entradas e saídas. Através de um repetidor sem fio (hub wireless), os
mesmos podem ser acessados por qualquer computador que tenha o ambiente de
desenvolvimento ISaGRAF.
Um dos pontos mais relevantes a serem destacados sobre a ferramenta
ISaGRAF é que a mesma configura uma das primeiras apostas comerciais da
indústria na norma IEC 61499 (o que pode sugerir uma tentativa séria de inserção
dessa norma no mercado). Mais importante do que isso, no entanto, é o fato de que
essa ferramenta tenta cobrir as etapas de desenvolvimento de sistemas de
Figura 49: Distribuição de uma aplicação da norma IEC 61499 na ferramenta ISaGRAF – adaptadode Chouinard e Brennan (2006).
140
automação distribuídos que vão do projeto aos testes, fornecendo uma possibilidade
de implementação dos sistemas por meio da compilação de código, seja em TIC,
seja em linguagem C. Assim, tem-se a possibilidade de construir um sistema real e
executar testes sobre ele – como o que pode ser visto através do kit de
desenvolvimento da ferramenta, por exemplo, projetando as expectativas do uso da
IEC 61499 em ambientes de campo.
4.1.7. Fuber
Čengić, Ljungkrantz e Åkesson (2006) mostraram interesse na verificação
formal das aplicações da IEC 61499. Para isso, está sendo desenvolvido um
ambiente de execução da IEC 61499, chamado Fuber, que tem um modelo bem
definido, e, portanto, analisável.
O Fuber é desenvolvido em Java, possui código aberto, e consegue
executar diversas aplicações compatíveis com a norma IEC 61499. Na verdade, o
Fuber se diferencia dos demais ambientes de execução pois não compila os
algoritmos, e sim os interpreta, o que torna possível atualizar o comportamento da
aplicação durante a execução. Assim, o Fuber modifica os tipos de blocos
funcionais, instâncias e suas conexões enquanto a aplicação está sendo executada,
o que torna fácil a reconfiguração do software – uma característica que pode ser útil
tanto para testes quanto para aplicações que precisem de grande disponibilidade.
As principal vantagem do Fuber está justamente no fato dele prover uma
ferramenta para realizar a execução das redes de blocos funcionais básicos da
norma IEC 61499. Apesar disso, a ferramenta precisa superar diversas limitações:
� Os algoritmos dos blocos funcionais devem ser obrigatoriamente
implementados em Java;
� Os tipos de blocos funcionais compostos não são avaliados;
� Não há suporte à distribuição de aplicação entre diversos recursos;
� Não há interface gráfica para essa ferramenta (a mesma é controlada por
uma interface de linha de comandos);
� Não há como garantir que a execução tenha vínculo temporal estrito, nem
são considerados aspectos de tempo real (restrições) do ambiente de
execução; e
� Não é possível disparar as atualizações de blocos funcionais e conexões a
141
partir de uma interface externa do Fuber.
Outro aspecto a ressaltar é que seria interessante se houvesse uma versão
executável da ferramenta Fuber, já que isso é mais prático para quem deseja
analisar a ferramenta (e não modificá-la ou codificá-la através de seu código-fonte,
de acordo a como é disponibilizada atualmente).
Finalmente, tal ferramenta não aparenta cobrir outras partes de projeto que
não os testes de redes de blocos funcionais já constituídas em outras ferramentas.
4.1.8. Archimedes ESS
A ferramenta Archimedes ESS, segundo Software Engineering Group
(2005), é uma plataforma compatível com a norma IEC 61499 para o
desenvolvimento de IPMCS baseados em blocos funcionais. A partir de modelos
construídos em base às abstrações dessa norma, a ferramenta permite sua
transformação para sistemas executáveis em ambientes específicos. Atualmente, os
ambientes de execução suportados pela ferramenta CORFU são:
� RTSJ-Archimedes eXecution Environment (AXE): ambiente que se utiliza da
tecnologia Real-Time Java;
� RTAI-AXE: ambiente baseado em uma variante do sistema operacional
Linux para tempo real;
� CCM-AXE: ambiente que explora a especificação de modelos de
componentes do Common Object Request Broker Architecture (CORBA).
As características mais relevantes dessa ferramenta são o fato dela possuir
ambientes de execução de tempo real (que poderiam ser utilizados para automação,
dependendo das restrições temporais a que estes estejam sujeitos) e,
adicionalmente, permitir interface com a ferramenta CORFU ESS. Dessa maneira,
seriam cobertas desde a fase de levantamento de requisitos até a fase de
implementação de sistemas de automação.
142
4.2. COMPARAÇÃO ENTRE AS FERRAMENTAS
As ferramentas apresentadas neste capítulo conseguem cobrir, em conjunto,
diversas fases do ciclo de vida de projeto de sistemas de automação distribuídos. O
fato da norma IEC 61499 estabelecer regras para o intercâmbio de informações
entre ferramentas de software, inclusive, permite que muitas delas possam trabalhar
cooperativamente (mesmo não fazendo parte de um único pacote, fornecido por um
só fabricante). Do ponto de vista dos usuários das ferramentas, fica claro que isso é
uma grande vantagem, já que pode haver liberdade de escolha entre elas no
momento da aquisição, e se pode substituição umas pelas outras sem perda do
material anteriormente gerado. Neste ponto, uma das poucas ressalvas que se deve
fazer é o atrelamento das ferramentas CORFU ESS e Conversores UML-FB (as
duas únicas que implementam a passagem de UML para modelos da norma IEC
61499) à ferramenta comercial IBM Rational Rose: apesar da sua utilização ser
eficiente, percebe-se que, dessa forma, restringe-se o número de pessoas a terem
acesso a realizar a transformação UML-IEC61499 (o que deveria ser revisto, haja
vista que tanto o CORFU ESS quanto os conversores UML-FB são gratuitos).
Tabela 4: Cobertura das ferramentas estudadas quanto às fases de desenvolvimento do projeto desistemas de automação.
143
Deve-se notar, no entanto, que apesar de haver diversas iniciativas indo em
direção à implementação de sistemas de automação através do auxílio dessas
ferramentas, esses ambientes de execução são muito específicos, e não parecem
abranger tecnologias de automação para sistemas distribuídos bastante populares,
como LonWorks, por exemplo. Neste sentido, vê-se possibilidade de contribuição
acadêmica, a ser esclarecida no capítulo seguinte.
144
5. PROPOSTA DE EXTENSÕES AOS MAPEAMENTOS UML-IEC61499
E FERRAMENTAS
Neste capítulo serão apresentadas propostas de extensões aos
mapeamentos UML-IEC61499 (discutidos no capítulo 3) e às ferramentas
computacionais para suporte às atividades de engenharia voltadas ao
desenvolvimento de sistemas de automação distribuídos baseadas em modelagens
dadas através de abstrações da norma International Electrotechnical Commission
61499 (vistas no capítulo 4). Dentre os principais assuntos discutidos, estão a
sugestão de um mapeamento UML-IEC61499 simplificado, a representação de
parâmetros temporais em modelagens de sistemas de automação e a discussão da
viabilidade de implementação de sistemas representados pela norma IEC 61499 por
meio da tecnologia LonWorks.
5.1. EXTENSÕES AOS MAPEAMENTOS UML-IEC61499
Tendo em consideração os mapeamentos UML-IEC61499 estudados no
capítulo 3, vê-se duas principais possibilidades de contribuição nesse âmbito:
� Sugestão de um mapeamento UML-IEC61499 simplificado; e
� Indicação de mecanismos para representação de parâmetros temporais nos
modelos de sistemas de automação (dados tanto em UML quanto em
abstrações da norma IEC 61499).
5.1.1. Mapeamento UML-IEC61499 simplificado
Posto que a utilização de vocabulário associada à norma IEC 61499 em
modelos da Unified Modeling Language (UML) tende a dificultar a geração de
modelos de sistemas de automação distribuído por parte de engenheiros de
sistemas e software que não conheçam em detalhes essa padronização, propõe-se
um novo mapeamento UML-IEC61499, simplificado no sentido de dispensar o uso
145
de estereótipos vinculados ao vocabulário específico da norma IEC 61499 e por usar
um pequeno número de diagramas da UML para realizar de fato a transformação
UML-IEC61499.
Nesta proposta de mapeamento UML-IEC61499 simplificado, supõe-se que
os usuários da UML irão utilizar essa linguagem para descrever sistemas de
automação distribuídos. Dessa maneira, fica subentendido que, mesmo que não
conheçam especificamente a norma IEC 61499, tenham conceitos gerais de
automação, como a composição de um sistema por sensores, atuadores,
controladores, gateways (elementos de interface para comunicação entre sistemas)
e interfaces homem-máquina (utilizados para viabilizar a interação entre operadores
e o sistema de automação).
Para que seja possível realizar a conversão UML-IEC61499, torna-se
necessário impor algumas condições às descrições de sistemas feitas em UML:
� A fim de permitir a representação dos componentes de um sistema de
automação, alguns elementos da UML poderão ter os seguintes
estereótipos:
Sensor, Atuador, Sensor-Atuador, Gateway e IHM: utilizados para indicar
que uma classe representa uma abstração lógica de um sensor, de um
atuador, de um dispositivo sensor e atuador (ao mesmo tempo), de um
gateway ou de uma interface homem-máquina, respectivamente; e
Controlador: empregado para indicar que um nó da UML representa um
controlador de um sistema de automação;
� Todos os atributos de uma classe devem ser obrigatoriamente acessados
através de métodos, mesmo que sua visibilidade seja pública;
� As máquinas de estados detalhadas nos seus respectivos diagramas devem
ser compostas por estados simples (ou seja, sem subestados), e sempre
deve haver indicação de seu estado inicial; e
� Cada objeto representado através da UML deve receber um número de
identificação único, com a finalidade de ajudar na geração da nomenclatura
de elementos dos modelos baseados em abstrações da norma IEC 61499.
146
5.1.1.1. Diagramas da UML usados no mapeamento UML-IEC61499 simplificado
Apesar de que todos os diagramas da UML podem ser usados para
representar o sistema de automação da forma mais completa possível, num primeiro
momento apenas os dados referentes aos diagramas de Classes, de Seqüência, de
Colaboração/Comunicação (Diagramas de Interação), de Máquinas de Estados e de
Atividades serão usados para a extração de informações sobre o software, enquanto
o Diagrama de Distribuição (Deployment) fornecerá dados sobre o hardware do
sistema de automação. A seguir, detalham-se as funções dos elementos de cada
diagrama para a conversão UML-IEC61499.
5.1.1.1.1. Diagrama de Classes
No Diagrama de Classes, usado para mostrar a visão estática da aplicação
de um sistema de automação, as classes podem ser convertidas em tipos de blocos
funcionais pertencentes à norma IEC 61499. Cada método público ou protegido de
uma classe designa o nome de entradas e saídas de eventos, enquanto que seus
parâmetros (inclusive o valor de retorno) especificam as entradas e saídas de dados
(conforme detalhado na seção referente a Diagramas de Interação). Aos métodos
privados, em geral, cabe a função de expressar atividades internas aos objetos, e
devem ser traduzidos para a norma IEC 61499 como algoritmos. Por sua vez, os
atributos de uma classe devem representar apenas as variáveis internas, de entrada
e de saída do bloco funcional, mas não devem gerar ligações entre entradas e
saídas de dados de blocos funcionais (o que deve ser feito exclusivamente pelos
parâmetros dos métodos). Como todo e qualquer atributo deve ser acessado através
de métodos correspondentes, além de serem mantidas boas práticas de orientação
a objetos, implementa-se a distinção entre uma variável de dados (atributo) e uma
entrada ou saída de dados (parâmetro ou valor de retorno de um método) – apesar
de terem uma relação semântica clara, determinada pela IEC 61499.
De acordo com os tipos de estereótipos que podem serem aplicados às
classes – Sensor, Atuador, Sensor-Atuador, IHM e Gateway – discriminam-se os
blocos funcionais de interface de serviços (service interface function block – SIFB)
da norma IEC 61499, já que os mesmos são responsáveis por permitir a interação
entre a aplicação e o processo controlado ou a rede de comunicação.
147
Uma interface, por sua vez, cumpre o papel de um adaptador da norma IEC
61499 (já que ambas abstrações conseguem reduzir a representação da interface de
uma classe ou bloco funcional, e ajudam no reuso de definições). Quando uma
classe indicar um relacionamento de realização em relação a uma interface (seja na
notação reduzida (plugue), seja na notação expandida), denota-se que o tipo de
adaptador representado pela interface está incluído no tipo de bloco funcional
determinado pela classe, cumprindo a função de adaptador plugue. Por sua vez,
quando houver um relacionamento de dependência entre uma classe e uma
interface (seja na notação reduzida (soquete), seja na notação expandida), também
é inferido que o tipo de adaptador representado pela interface está incluído no tipo
de bloco funcional determinado pela classe, mas desta vez cumprindo a função de
adaptador soquete.
Quanto aos relacionamentos estabelecidos entre classes, têm significado
especial os relacionamentos de agregação (que indicam a existência de blocos
funcionais compostos) e os relacionamentos de generalização, que podem ser
usados entre classes de um diagrama para que um tipo de bloco funcional herde as
características de outro (para fins de reutilização de especificações) – assim, torna-
se mais fácil compor novos tipos de blocos funcionais a partir de blocos funcionais
pré-existentes.
Figura 50: Exemplo de Diagrama de Classes segundo o mapeamento UML-IEC61499 simplificado.
148
5.1.1.1.2. Diagrama de Interação
Para designar as conexões de eventos e dados entre instâncias de blocos
funcionais, podem ser usados alternativamente o Diagrama de Seqüência ou o
Diagrama de Colaboração/Comunicação, de acordo com o tipo de visão que se
queira ter dessas interações: para o ponto de vista da relação temporal entre as
interações, recomenda-se o uso do primeiro; e para o entendimento da estrutura
usada para as interações, aconselha-se o uso do segundo.
Tanto no Diagrama de Seqüência quanto no Diagrama de Colaboração, os
objetos designam instâncias de um tipo de bloco funcional (já que este é
representado por uma classe, conforme dito anteriormente). Por sua vez, as
mensagens intercambiadas entre os objetos estipularão as conexões entre eventos
e dados de instâncias de blocos funcionais, conforme disposto abaixo:
� Uma chamada de método configura uma conexão entre uma saída de
evento do bloco funcional (objeto) chamador e uma entrada de evento do
bloco funcional (objeto) chamado. O nome da entrada e da saída de evento
deve corresponder ao nome do método invocado (adicionado do número
identificador os objetos chamador e chamado);
� Se houver algum parâmetro no método chamado, este deve gerar uma
ligação entre uma saída de dado do bloco funcional (objeto) chamador e
uma entrada de dado do bloco funcional (objeto) chamado. Neste caso, a
entrada ou saída de dado deve ser conectada a sua respectiva entrada ou
saída de evento (referente à chamada do método) pelo qualificador WITH. O
nome da entrada e da saída de dado deve corresponder ao nome do
parâmetro passado na mensagem (adicionado do número identificador os
objetos chamador e chamado);
� Caso o método possua um parâmetro de valor de retorno, deve-se adicionar
uma ligação entre uma saída de evento do bloco funcional (objeto) chamado
e uma entrada de evento do bloco funcional (objeto) chamador
(correspondente à indicação de retorno do método), e, adicionalmente, uma
saída de dado do bloco funcional (objeto) chamado e uma entrada de dado
do bloco funcional (objeto) chamador (correspondente ao valor de retorno).
Neste caso, a entrada ou saída de dado deve ser conectada a sua
respectiva entrada ou saída de evento (referente à chamada do método)
149
pelo qualificador WITH. O nome das entradas e saídas de eventos e de
dados deve ser composto de acordo com as regras descritas anteriormente,
inclusive mantendo-se a numeração original do objeto chamador e do objeto
chamado nessa ordem (assim, pode-se identificar uma ligação de eventos e
dados correspondentes a um retorno de valor). Como normalmente não há
um nome para um parâmetro de retorno, pode-se atribuir a qualquer retorno
um nome padrão (como “retorno”, por exemplo, acrescido de um número
seqüencial).
Uma chamada a um método próprio da classe será interpretado como
algoritmo interno, e não vai gerar saídas de dados e eventos externas (já que o
objeto tem controle sobre seu próprio estado e variáveis)
Neste ponto, para uma boa representação das abstrações da norma IEC
61499 quando da execução da conversão UML-IEC61499, deve-se observar quais
métodos das classes corresponderiam a implementações de operações indicadas
por interfaces. Dessa maneira, é possível agrupar as entradas e saídas de dados e
eventos correspondentes em adaptadores adequados, cujos nomes devem
corresponder ao nome da interface que representa esse tipo de adaptador
(conforme descrito na parte referente a Diagramas de Classes). Vale destacar que,
mesmo que uma relação de dependência não tenha sido explicitada entre a interface
e a classe representante do tipo de bloco funcional aceitador, o seu adaptador
Figura 51: Exemplo de conversão de método com parâmetros e valor de retorno para uma rede deblocos funcionais (a) e detalhe da interface externa de um dos blocos funcionais (b), segundo omapeamento UML-IEC61499 simplificado.
150
soquete deve ser criado, a fim de que uma ligação entre adaptadores desses blocos
funcionais possa ser estabelecida.
O relacionamento entre as instâncias contidas em um bloco funcional
composto, e a ligação das mesmos à interface externa de seu bloco contenedor
também deve ser dada por Diagramas de Seqüência ou de
Colaboração/Comunicação, que devem ser estruturados da mesma forma como
descrito anteriormente. Portanto, as mensagens trocadas entre o objeto
representante do bloco funcional composto com os objetos que designam os blocos
funcionais contidos estabelece a conexão entre os seus elementos de interface.
Por fim, como um bloco funcional de interface de serviços possui entradas e
saídas de dados e eventos específicas (ditadas pela norma IEC 61499), deve-se
ressaltar que no caso de haver troca de mensagens com um objeto que represente
uma instância desse tipo de bloco funcional, as seguintes restrições na
nomenclatura dos eventos e métodos devem ser tomadas em consideração
(destaca-se que todas as regras vistas anteriormente permanecem mantidas caso
não se explicite o contrário):
� A invocação de métodos de um objeto representante de um bloco funcional
de interface de serviços por parte de um objeto representante de um bloco
funcional qualquer da aplicação deve gerar no bloco funcional de interface
de serviços uma entrada de evento obrigatoriamente denominada REQ (ao
qual a saída de eventos do bloco funcional da aplicação deve ser
conectado). Por fim, se houver valor de retorno para esse método, deve-se
gerar uma saída de eventos obrigatoriamente chamada CNF no bloco
funcional de interface de serviços, conectada à entrada de eventos do bloco
funcional da aplicação; e
� A invocação de métodos de um objeto representante de um bloco funcional
qualquer da aplicação por parte de um objeto representante de um bloco
funcional de interface de serviços deve gerar no bloco funcional de interface
de serviços uma saída de evento obrigatoriamente denominada IND (ao qual
a entrada de eventos do bloco funcional da aplicação deve ser conectado).
Por fim, se houver valor de retorno para esse método, deve-se gerar uma
entrada de eventos obrigatoriamente chamada RSP no bloco funcional de
interface de serviços, conectada à saída de eventos do bloco funcional da
aplicação; e
151
� No caso em que se queira inicializar as funções de um objeto referente a um
bloco funcional de interface de serviços, um nome específico de método de
inicialização deve ser estipulado (como init(), por exemplo). Assim, quando
houver necessidade de fazer uma chamada a esse método do objeto, tal
chamada poderá ser traduzida para as abstrações da norma IEC 61499
através da criação de uma conexão de eventos entre os blocos funcionais
relacionados aos objetos em comunicação, ligada à entrada de eventos do
bloco funcional de interface de serviços que deve obrigatoriamente ser
chamada INIT. Caso haja parâmetros para este método, estes devem ser
transformados em dados estruturados, passados por meio da entrada de
dados denominada mandatoriamente PARAMS. Por fim, se houver valor de
retorno para esse método, a saída de eventos relacionada deve ser
chamada INIT0.
Caso um objeto representante de um bloco funcional de interface de
serviços tenha mais de um método a oferecer aos objetos da aplicação (interação
REQ-CNF), uma alternativa possível para distinguir uma chamada a um desses
métodos em especial é atribuir a cada um deles um número de identificação.
Quando for detectado que um objeto está invocando um desses métodos, a
transformação UML-IEC61499 gerará uma entrada de dados no bloco funcional de
interface de serviços, que servirá para receber o número identificador do método, de
acordo com seu nome.
Figura 52: Exemplos de blocos funcionais de interface de serviços, para interações iniciadas pelaaplicação (a) e para interações iniciadas pelo recurso (b) – retirado de International ElectrotechnicalCommission (2005a).
152
5.1.1.1.3. Diagrama de Máquinas de Estados
O Diagrama de Máquinas de Estados deve ser utilizado para designar o
comportamento interno dos objetos que representam blocos funcionais básicos de
uma aplicação da norma IEC 61499.
Os estados (simples), transições, eventos, condições de guarda e ações de
uma máquina de estados encontram correspondentes diretos no diagrama de
controle de execução (Execution Control Chart – ECC) de um bloco funcional básico.
No entanto, deve-se destacar, quanto a tal conversão UML-IEC61499:
� Conforme as condições dadas às modelagens em UML, todos os estados
desse tipo de diagrama devem ser simples para que o mapeamento seja
possível (já que não há estados compostos no diagrama de controle de
execução da norma IEC 61499);
� Sempre deve haver um estado inicial em uma máquina de estados da UML,
a ser transformado no estado chamado START do diagrama de controle de
execução da norma IEC 61499;
� As atividades indicadas para execução dentro de um estado da UML
(normalmente dadas em termos de métodos privados do objeto) devem ser
transformadas em algoritmos associados a uma ação de um estado da
norma IEC 61499;
� Caso o evento de saída de um estado da UML implique a chamada a um
método de um objeto externo, deve-se vincular à ação referente ao estado
da IEC 61499 uma indicação de evento de saída (cujo nome é determinado
pelo nome do método, como visto anteriormente);
� Se o gatilho de uma transição entre estados da UML for justamente a
chamada a um método do objeto em questão, deve-se colocar como gatilho
da transição do diagrama de controle de execução (ECC) o evento de
entrada do bloco funcional associado, cujo nome é determinado pelo nome
do método, conforme visto anteriormente; e
� Da mesma maneira, se na ação associada a uma transição entre estados da
UML houver uma chamada a um método de um objeto externo ao que está
sendo considerado, a mesma deve ser substituída, na ação da transição
entre estados do diagrama de controle de execução, por uma referência a
um evento de saída do bloco funcional.
153
5.1.1.1.4. Diagrama de Atividades
Os Diagramas de Atividades podem ser utilizados para especificar em
maiores detalhes os algoritmos referentes às atividades citadas nos estados dos
Diagramas de Estados da UML.
No entanto, apesar de relativamente simples dada a estrutura geral dos
diagramas da UML, a conversão destes para a especificação de algoritmos prevista
pela norma IEC 61499 depende de que as ações descritas no diagrama já estejam
em uma linguagem padronizada pela norma (como texto estruturado, por exemplo).
Caso contrário, os algoritmos obtidos após a tradução servirão como documentação
do comportamento esperado, mas não como código compilável para aplicações da
norma IEC 61499.
5.1.1.1.5. Diagrama de Distribuição (Deployment)
O Diagrama de Distribuição deve ser utilizado para expressar uma visão
geral do sistema de automação, em que se dá ênfase a quais devem ser os
principais dispositivos físicos usados nesse projeto (inclusive controladores) - ainda
que isso sirva apenas como uma primeira sugestão, a ser refinada pela equipe de
engenharia de controle e automação responsável pelo projeto de baixo nível e
implementação do sistema.
Os nós da UML devem ser convertidos para dispositivos da norma IEC
61499. Por sua vez, os relacionamentos de associação entre eles designarão os
links e segmentos da rede de comunicação a compor o sistema de automação
distribuído. Finalmente, se for necessário que a equipe de engenharia de software
indique em que nós certos objetos devem ser processados, tais nós deverão ter o
estereótipo Controlador e deverão ser mapeados em dispositivos da norma IEC
61499 em que haja um só recurso (já que esta abstração da IEC 61499 não poderá
ser designada explicitamente pela UML). Posteriormente, os blocos funcionais
referentes aos objetos citados (vinculados aos nós por relacionamentos de
dependência) deverão ser atribuídos à configuração desse recurso, segundo a
norma IEC 61499.
154
5.1.1.2. Comentários
O método de mapeamento UML-IEC61499 simplificado tem como influência
principal o mapeamento UML-IEC61499 sugerido por Thramboulidis, já que este
mantém o foco da representação de sistemas por parte dos engenheiros de
sistemas e software justamente na sua maior especialidade: a aplicação. Apesar
disso, a principal desvantagem que se tentou contornar em relação a esse
mapeamento foi o uso excessivo de estereótipos vinculados estritamente à IEC
61499, dando maior liberdade aos usuários da UML ao projetar um sistema de
automação segundo conceitos mais facilmente acessíveis do que aqueles da norma
IEC 61499 (que exigem conhecimento específico dessa padronização). Por outro
lado, ressalta-se que, apesar do sistema de automação distribuído poder ser
projetado por meio de diversos diagramas, apenas um pequeno subconjunto de
elementos da UML deve ser usado para a conversão entre abstrações dessa
linguagem para aquelas próprias da norma IEC 61499.
A partir dessa conversão, adicionalmente, o projeto deve ser verificado,
refinado e complementado por especialistas da área de engenharia de controle e
automação, que conheçam a norma IEC 61499 e se utilizem de ferramentas
compatíveis com a mesma, para que esse desenvolvimento possa chegar à etapa
de implementação e testes. Por exemplo, os blocos funcionais gerados podem ser
agrupados em subaplicações (já que estas não têm representação prevista em UML)
e devem ser redistribuídos entre recursos e dispositivos (dado que a descrição física
e de distribuição da aplicação necessariamente deve ser revisada).
5.1.2. Mecanismos para representação de parâmetros temporais em modelos
de sistemas de automação
Segundo Bordbar, Derrick e Waters (2002), métodos tradicionais de
engenharia de sistemas não focalizam o desenvolvimento de sistemas distribuídos,
particularmente com respeito a questões de desempenho e suas restrições
associadas de qualidade de serviço (Quality of Service – QoS). Quando aplicado no
âmbito computacional, QoS está relacionado a características de desempenho de
elementos de um sistema (quanto a atrasos e erros em suas funções, por exemplo)
que afetam o serviço desse sistema como um todo – contrapondo-se, dessa forma, à
155
descrição de aspectos meramente funcionais. Alguns atributos de QoS de interesse
no contexto de aplicações multimídia, por exemplo, são atraso e variação de atraso
na transmissão de pacotes de dados – dimensões relacionadas à temporização, e
vazão de uma rede de comunicação – dimensão relacionada a volume.
Um sistema de automação distribuído, é, em grande parte dos casos, um
sistema de tempo real: conforme a definição de Booch, Rumbaugh e Jacobson
(1998), nesse tipo de sistema certos comportamentos devem ser executados em
momentos precisos (absoluto ou relativo), dentro de períodos predizíveis (e, na
maior parte das vezes, restritos).
Muito embora o grau de exigência de especificação dos requisitos temporais
possa variar, dependendo da aplicação do sistema considerado (segundo Booch,
Rumbaugh e Jacobson (1998), podem existir desde sistemas de tempo real estritos
(hard real time), que requerem a execução de comportamentos de forma completa e
repetível dentro de nanossegundos ou milissegundos, até outros sistemas que
comportam a execução de comportamentos em períodos da ordem de segundos ou
até maiores), é necessário, para que um sistema distribuído alcance o desempenho
desejado, que sentenças sobre os parâmetros de QoS associados a tempo sejam
enunciadas.
Apesar da importância do tema, percebe-se que nenhum dos mapeamentos
UML-IEC61499 prevê a expressão de tais requisitos, nem primeiramente na UML,
nem posteriormente sua tradução para atributos das abstrações da norma IEC
61499.
Assim, sugere-se neste trabalho a utilização de restrições (contraints),
mecanismos de extensão da semântica de um elemento da UML, para a enunciação
de requisitos de temporização dos modelos de sistemas de automação distribuídos
feitos nessa linguagem (segundo a forma descrita na seção referente ao
mapeamento UML-IEC61499 simplificado). Com tais restrições disponíveis, os
requisitos de temporização poderão ser transferidos para as representações do
sistema de automação dados em abstrações da norma IEC 61499, dada a execução
da conversão UML-IEC61499.
156
5.1.2.1. Parâmetros temporais relevantes para o projeto de sistemas de automação
distribuídos dados segundo a norma IEC 61499
Uma lista reduzida mas significativa de parâmetros temporais relevantes
para o projeto de sistemas de automação modelados segundo a norma IEC 61499
inclui:
� Marcos de tempo e períodos de duração da comunicação entre blocos
funcionais; e
� Estimativa da duração da execução dos algoritmos de um bloco funcional
básico.
Apesar de tal relação ficar muito aquém do necessário para exaurir o tema
da expressão de requisitos de QoS em sistemas de automação distribuídos, a
mesma serve como base para início dos trabalhos relacionados a essa área,
devendo ser expandida em trabalhos posteriores.
5.1.2.1.1. Especificação de marcos de tempo e períodos de duração da
comunicação entre blocos funcionais
Uma das opções para a especificação de marcos de tempo e períodos de
duração da comunicação entre blocos funcionais em UML é a colocação de
restrições e observações de tempo e de duração nos Diagramas de Seqüência.
As restrições e observações de tempo e de duração são recursos
específicos da UML 2.X para estabelecer parâmetros de temporização:
� Uma observação de tempo (TimeObservation) estipula uma referência para
a marcação do tempo;
� Uma restrição de tempo (TimeConstraint) é uma condição sobre o limite de
tempo em que determinado comportamento do sistema deva se manifestar;
� Uma observação de duração (DurationObservation) estipula uma referência
para a mensuração de um período de tempo; e
� Uma restrição de duração (DurationConstraint) é uma condição sobre o
período de tempo em que determinado comportamento do sistema deva
ocorrer.
Qualquer restrição da UML pode ser dada em um texto feito em linguagem
natural ou em alguma linguagem passível de interpretação computacional (machine
157
readable language) – por exemplo, uma sentença em linguagem de programação
Java ou mesmo linguagens especiais para a descrição de restrições em diagramas
UML (como a Object Constraint Language (OCL), em que, segundo Bordbar, Derrick
e Waters (2002), os blocos básicos de construção das expressões são os objetos e
suas propriedades).
Em um Diagrama de Seqüência a ser mapeado em um modelo de
abstrações da IEC 61499, observações e restrições de tempo e de duração
poderiam ser colocados nos diagramas para condicionar a temporização da troca de
mensagens entre objetos representantes de blocos funcionais: portanto, tais
restrições, no momento de uma conversão UML-IEC61499, deveriam ser aplicadas
às conexões de eventos e dados das instâncias de blocos funcionais envolvidas na
comunicação, e, do ponto de vista prático, colocadas como texto em um atributo
associado a essas conexões. Vale lembrar que a declaração de atributos específicos
de aplicação está prevista no Anexo G da Parte 1 da norma IEC 61499.
Figura 53: Diagrama de Seqüência (da UML 2.X) com ênfase nas observações de tempo e duração, enas restrições de tempo e duração – traduzido de Object Management Group (2007).
158
Outro tipo de diagrama da UML 2.X que poderia ser utilizado seria o
Diagrama de Temporização.
Alguns exemplos de restrições temporais para a transmissão de eventos e
blocos funcionais incluiriam, por exemplo, a duração máxima de tempo entre a
emissão de um evento e sua recepção por parte de um bloco funcional, a duração
de tempo (atraso) entre a chegada do evento a um bloco funcional e a amostragem
de seus dados correspondentes e o limite de tempo entre a recepção de um evento
e a resposta a esse evento por parte de um bloco funcional.
A notação específica a ser utilizada para expressar essas idéias dependeria
da linguagem escolhida para as restrições. O uso de um formato adequado para as
expressões e de uma linguagem como a Real-Time Logic (RTL), por exemplo –
lógica formal para expressão de comportamento de sistemas – ajudaria inclusive em
que os modelos gerados pudessem ser verificados por meio de ferramentas de
interpretação e simulação baseadas nas expressões das restrições.
Figura 54: Diagrama de Temporização (da UML 2.X) com ênfase nas observações de tempo eduração, e nas restrições de tempo e duração – traduzido de Object Management Group (2007).
159
5.1.2.1.2. Especificação de estimativa da duração da execução dos algoritmos de
um bloco funcional básico
De maneira semelhante, mecanismos de extensão gerais da UML (como
restrições e valore rotulados) podem ser usadas para especificar dados de
temporização quanto à duração de um método privado de uma classe, que seria
interpretado como um algoritmo de um bloco funcional básico no caso de uma
conversão UML-IEC 61499.
Segundo Booch, Rumbaugh e Jacobson (1998), por exemplo, o valor
rotulado semantics, que permite a inserção de uma descrição sobre a semântica de
um elemento, poderia ser vinculado a uma operação qualquer. Colocando-se uma
expressão de tempo nesse valor, seria possível modelar a complexidade temporal
da operação (tipicamente, o período máximo, mínimo e/ou médio de tempo em que a
operação deveria ter sido finalizada). Tal artifício poderia ser usado, assim, para
estimar e comparar os tempos de execução projetados e obtidos com a
implementação de uma operação, e também para obter a complexidade temporal de
uma transação computacional completa.
Vale destacar que um atributo já previsto pela norma IEC 61499 chama-se
ExecutionTime, e é justamente relacionado ao tempo de execução, no pior caso, de
um algoritmo de um certo tipo de bloco funcional em um determinado tipo de recurso
(INTERNATIONAL ELECTROTECHNICAL COMMISSION, 2005a).
5.1.2.1.3. Comentários
No campo de requisitos de temporização aplicados a sistemas de
automação distribuídos, apesar da contribuição apresentada acima para
mapeamentos UML-IEC61499, ainda há muito espaço para a realização de
trabalhos.
Em primeiro lugar, seria necessário estipular um conjunto de medidas de
interesse prático sobre os requisitos de QoS (em especial os de temporização). A
seguir, seria interessante estipular o formato e a linguagem de cada expressão
desses requisitos, de preferência prevendo a criação ou a utilização de ferramentas
computacionais para avaliá-las e, com isso, simular o comportamento dinâmico do
sistema. Em caso de uso da UML como meio para o projeto de sistemas, uma outra
160
área de estudos correlata seria a avaliação de perfis (profiles) UML para a expressão
específica de sistemas de tempo real. Como esse é um tema bastante vasto,
suspende-se por aqui a sua discussão, sugerida como uma possível continuação
deste trabalho.
5.2. EXTENSÕES DAS FERRAMENTAS COMPUTACIONAIS PARA
SUPORTE ÀS ATIVIDADES DE ENGENHARIA VOLTADAS AO
DESENVOLVIMENTO DE SISTEMAS DE AUTOMAÇÃO DISTRIBUÍDOS
Tendo em vista as ferramentas computacionais analisadas no capítulo 4,
entende-se que uma possível contribuição neste âmbito possa ser a sugestão da
construção de uma ferramenta que permita a implementação de um sistema de
automação distribuído baseado na tecnologia LonWorks a partir dos modelos de
sistema dados pelas abstrações da norma IEC 61499. Dessa maneira, considerando
também a aplicação de conversões UML-IEC61499 quando necessário, conseguir-
se-ia cobrir todo o ciclo de desenvolvimento de um sistema de automação, desde o
levantamento de requisitos até a implementação, testes e manutenção de um
sistema, concretizado por meio de uma tecnologia muito bem aceita e difundida no
mercado de automação.
Para mostrar a viabilidade da construção dessa ferramenta, analisa-se nesta
seção, primeiramente, a compatibilidade entre as abstrações da norma IEC 61499 e
das abstrações previstas pela tecnologia LonWorks. Uma vez constatada a
capacidade de aproximar esses diferentes modelos lógicos, parte-se para a
indicação de possíveis formas de construção de uma nova ferramenta
computacional para suporte às atividades de engenharia voltadas ao
desenvolvimento de sistemas de automação distribuídos.
161
5.2.1. Compatibilidade entre as abstrações da norma IEC 61499 e das
abstrações previstas pela tecnologia LonWorks para o projeto de sistemas de
automação distribuídos
Nesta parte, apresentam-se inicialmente os conceitos sobre os modelos
lógicos de sistemas de automação distribuídos aceitos no âmbito de sistemas
LonWorks. A seguir, comparam-se essas abstrações às da norma IEC 61499.
Para evitar a repetição desnecessária de referências, destaca-se que todas
as informações sobre a tecnologia LonWorks expostas no presente item foram
baseadas em Echelon Corporation (1999, 2005).
5.2.1.1. Elementos lógicos dos sistemas LonWorks (com ênfase na representação
de aplicações de sistemas distribuídos)
5.2.1.1.1. Instâncias dos elementos das aplicações LonWorks
5.2.1.1.1.1. Bloco funcional
As aplicações de um dispositivo LonWorks são subdivididas em blocos
funcionais (Functional Blocks – fblock).
Um bloco funcional recebe dados de entrada (operacionais e de
configuração, provenientes da rede, do hardware do dispositivo ou de outros blocos
funcionais), executa o processamento de tais dados, e, como conseqüência, pode
gerar dados de saída (enviados, da mesma maneira, para a rede, o hardware ou
outros blocos funcionais).
As entradas e saídas de um bloco funcional são feitas por meio de variáveis
de rede (Network Variables – NV), as quais são os dados operacionais do bloco
funcional, ou por propriedades de configuração (Configuration Properties – CP),
sendo estas os dados para configuração de variáveis de rede, de blocos funcionais
ou do dispositivo como um todo. Segundo Echelon Corporation (2005), o bloco
funcional é um conceito orientado a objetos, para o qual as variáveis de rede e as
propriedades de configuração representam o papel de membros.
Um bloco funcional deve ser implementado sempre quando for necessário
que uma determinada função executada por um dispositivo seja acessada por outros
162
dispositivos ou deva ser configurada externamente. Dessa forma, o bloco funcional
cumpre a tarefa de oferecer uma interface externa para permitir que o dispositivo
possa interagir com outros elementos do sistema LonWorks.
5.2.1.1.1.2. Variável de rede
Uma variável de rede (NV) permite ao bloco funcional ao qual está
associada (sendo este um e apenas um bloco) intercambiar dados com os demais
blocos funcionais de uma aplicação LonWorks. Cada variável de rede possui, como
atributos principais, uma direção (variável de entrada, caso seja usada para receber
dados, ou variável de saída, caso seja usada para enviar dados) e segue um
determinado modelo ou tipo (que define as unidades, as escalas e a estrutura dos
dados contidos na variável).
Variáveis de rede de mesmo tipo e direções opostas podem ser conectadas
para permitir que seus blocos funcionais intercambiem dados: tal operação é
denominada binding (termo do inglês que poderia ser traduzido como “interligar”), e
pode ocorrer tanto no projeto da rede de dispositivos LonWorks (fase de engenharia
do sistema) quanto no momento de sua instalação (fase de implementação), através
de ferramentas computacionais de gerenciamento da rede LonWorks.
Uma única variável de rede de saída pode ser logicamente conectada a
apenas uma ou a múltiplas variáveis de rede de entrada (nesse último caso, trata-se
de uma conexão fan-out). Por sua vez, uma única variável de entrada pode receber
apenas uma ou múltiplas variáveis de rede de saída (o que é denominado conexão
Figura 55: Representação teórica de um bloco funcional LonWorks.
163
fan-in). Assim, através do binding, quando há modificações no valor de uma variável
de saída, a(s) variável(is) de entrada conectada(s) a ela recebe(m) a atualização do
dado em questão.
Para exemplificar este ponto, um binding se dá quando um dispositivo que
possui um bloco funcional representando uma chave (switch), com uma variável de
rede de saída chamada switch on/off, é ligado a outro dispositivo que possui um
bloco funcional relacionado a uma lâmpada (lamp), com uma variável de rede de
entrada chamada lamp on/off: ao se criar uma conexão entre essas duas variáveis
de rede, tem-se o mesmo efeito funcional de conectar um cabo (físico) entre a chave
e a lâmpada.
5.2.1.1.1.3. Propriedade de configuração
Uma propriedade de configuração (CP) é um item de dados que caracteriza
o comportamento de um dispositivo em um sistema, já que ele descreve um valor de
configuração para uma ou mais variáveis de rede, para um ou mais blocos
funcionais ou mesmo para o próprio dispositivo como um todo. Ela é a
implementação de um determinado modelo ou tipo de propriedade de configuração
(que define as unidades, as escalas e a estrutura dos seus dados).
Um propriedade de configuração que pode ser tomada como um exemplo
chama-se cpMaxSendTime. Sua função é especificar o tempo máximo de envio de
uma variável através da rede LonWorks após uma alteração em seu valor.
5.2.1.1.2. Tipos ou modelos para os elementos das aplicações LonWorks
5.2.1.1.2.1. Perfil funcional
Um perfil funcional ou modelo de perfil funcionais (Functional Profile – FP ou
Functional Profile Template - FTP) define um tipo de bloco funcional, sendo ele
especificado para viabilizar a realização de uma única tarefa em um dispositivo.
Os perfis funcionais descrevem quais são os seus membros obrigatórios e
opcionais (ou seja, quais variáveis de rede e propriedades de configuração são
mandatórias ou não), e contém, ainda, descrições adicionais sobre o significado
semântico de cada um de seus dados internos.
164
Cada bloco funcional da aplicação é a implementação de um perfil funcional
determinado. Vale ressaltar que, ao instanciar um perfil funcional, o bloco funcional
deve implementar todos os membros obrigatórios definidos pelo perfil funcional, e
pode implementar algum, todos ou nenhum dos membros opcionais. Um bloco
funcional pode também conter novos membros, que não estão pré-definidos no perfil
funcional, sendo estes denominados membros específicos de implementação
(implementation-specific members).
5.2.1.1.2.2. Tipo de variável de rede
Um tipo ou modelo de variável de rede (Network Variable Type – NVT)
especifica as informações sobre a estrutura e formato dos dados que devem estar
contidos em uma variável de rede.
Se a variável for um valor escalar (ou seja, como um valor inteiro, ou uma
enumeração, por exemplo), apresentam-se, como informações principais, seu tipo,
tamanho (em bytes), intervalo de valores puros (raw values – sendo esses valores
especificados em inteiros, correspondentes aos bytes da variável), valores puros
inválidos, fatores de escala (a serem aplicados aos valores puros, para gerar o valor
final – ou processado – da variável), intervalo de valores (processados) válidos,
unidade e resolução. Caso a variável seja composta por uma estrutura de dados, as
Figura 56: Representação de um perfil funcional LonWorks.
165
características citadas anteriormente são especificadas para cada um de seus
elementos. De maneira geral, pode-se afirmar também que um tipo de variável de
rede pode herdar suas características de um outro modelo de variável de rede.
5.2.1.1.2.3. Tipo de propriedade de configuração
Similarmente ao caso anterior, um tipo ou modelo de propriedade de
configuração (Configuration Property Type – CPT) especifica as informações sobre a
estrutura e formato dos dados que devem estar contidos em uma propriedade de
configuração.
Se a propriedade de configuração for um valor escalar, apresentam-se,
como informações principais, seu tipo, tamanho (em bytes), intervalo de valores
puros (raw values – sendo esses valores especificados em inteiros, correspondentes
aos bytes da propriedade de configuração), valores puros inválidos, fatores de
escala (a serem aplicados aos valores puros, para gerar o valor final – ou
processado – da variável), intervalo de valores (processados) válidos, unidade,
resolução e valor padrão (default value). Caso a propriedade de configuração seja
composta por uma estrutura de dados, as características citadas anteriormente são
especificadas para cada um de seus elementos. De maneira geral, pode-se afirmar
também que um tipo de propriedade de configuração pode herdar suas
características de um outro modelo de propriedade de configuração ou de um
modelo de variável de rede.
5.2.1.1.3. Relacionamento entre os sistemas LonWorks e suas aplicações
Em geral, um dispositivo LonWorks contém uma aplicação, que consiste de
um ou mais blocos funcionais, os quais podem ser configurados e usados de forma
isolada, sendo cada um dos mesmos baseado da definição de um perfil funcional.
Os blocos funcionais podem ser, então, conectados entre si, independentemente do
dispositivo em que estejam alocados.
166
5.2.1.2. Comparação dos modelos lógicos dos sistemas LonWorks aos dos sistemas
de automação projetados segundo a norma IEC 61499
Ao serem comparadas as abordagens da norma IEC 61499 e da tecnologia
LonWorks quanto às suas aplicações, podemos notar diversas semelhanças:
� Em primeiro lugar, pode-se destacar que ambos modelos lógicos
consideram, como ambiente de aplicação, um sistema de automação
distribuído, em que dispositivos com capacidade própria de processamento
executam funções específicas e modulares. Logo, a interligação lógica entre
tais dispositivos (ou seja, entre suas aplicações) determinam a sua
comunicação e colaboração, e permitem a execução da funcionalidade
global do sistema;
� Tanto na tecnologia LonWorks quanto na norma IEC 61499 encontram-se
referências ligando seus conceitos, principalmente o uso de blocos
funcionais, aos paradigmas de orientação a objetos – o que pode ser visto,
por exemplo, em Echelon Corporation (1999, p. 31), em que uma instância
Figura 57: Relacionamento entre modelos lógicos LonWorks.
167
de um perfil funcional é chamado de objeto (ao invés da denominação bloco
funcional), e International Electrotechnical Commission (2005c, p. 8), em que
se fala diretamente da aderência dos modelos da IEC 61499 a conceitos de
orientação a objetos;
� As aplicações dos dispositivos são segmentadas em blocos funcionais, os
quais são elementos lógicos que fornecem uma interface externa (ou seja,
variáveis de entrada e saída, visíveis, que permitem a interação com outros
blocos funcionais) e que encapsulam o seu funcionamento interno. Cada
bloco funcional é uma instância de um modelo (ou tipo) de bloco funcional, o
que estabelece uma relação similar à de classes e objetos, conforme
esperado; e
� Por fim, a obtenção da aplicação completa do sistema é dada pela
interligação entre variáveis de entrada de um bloco funcional e variáveis de
saída de outro bloco funcional, independentemente do dispositivo a que
estes pertençam. Adicionalmente, a conexão entre elas é permitida apenas
para variáveis de tipos compatíveis e direções opostas.
Apesar dessas semelhanças, não existe um mapeamento direto entre os
conceitos da norma IEC 61499 e da tecnologia LonWorks. As diferenças mais
significativas estão descritas a seguir:
● Pode-se afirmar que a tecnologia LonWorks não faz distinção entre
dispositivos físicos e lógicos: segundo seu modelo, um dispositivo é
basicamente composto por apenas um processador Neuron Chip, vinculado
a algum hardware adicional (memórias, circuitos de adaptação de sinais,
etc.). Já a norma IEC 61499 propõe a existência de recursos, que podem ser
interpretados como dispositivos lógicos, já que cada um cuida da execução
de um conjunto de blocos funcionais, embora estejam encapsulados dentro
de dispositivos (físicos);
● Da mesma maneira, nos termos da tecnologia LonWorks uma aplicação está
fortemente associada à idéia de dispositivo. Isso significa que uma aplicação
colocada em um nó, em princípio, é utilizada apenas para implementar
funções visando a tornar o dispositivo em si “inteligente”, e o conjunto de
dispositivos inteligentes compõem a funcionalidade do sistema de
automação. Já a norma IEC 61499 tem uma abordagem um pouco mais
ampla em relação a isso: o sistema de automação é composto por diversos
168
dispositivos, físicos e lógicos (recursos), que servem como base para a
distribuição livre de blocos funcionais, os quais juntos compõem sub-
aplicações e aplicações. Assim, justifica-se que na tecnologia LonWorks não
existam os blocos funcionais compostos e as sub-aplicações: na norma IEC
61499, estes são elementos lógicos para a agregação de blocos funcionais
em um mesmo dispositivo (os primeiros) ou até em dispositivos diferentes
(os segundos), o que não se faz necessário se os blocos funcionais, logica e
fisicamente, forem supostos agregados simplesmente pelo dispositivo que
os contém;
● Por outro lado, nos modelos da tecnologia LonWorks não existe diferença
entre dados e eventos, como ocorre na norma IEC 61499 para designar os
elementos para intercâmbio de informações entre blocos funcionais. Mesmo
se for de interesse notificar apenas um evento em um bloco funcional
LonWorks, isso deve ser feito através da transmissão de um dado,
provavelmente de tipo booleano;
● Na tecnologia LonWorks, também não existem adaptadores (soquetes e
plugues), embora eles possam ter alguma semelhança com as variáveis de
rede no sentido de agrupar um conjunto de dados para sintetizar a interface
de interação entre dois blocos funcionais (no modelo produtor-consumidor
ou cliente-servidor). O modelo LonWorks para as variáveis de rede, no
entanto, supera o que foi proposto até o momento para os dados de entrada
e saída dos blocos funcionais na norma IEC 61499: enquanto nesta os
dados são escalares ou no máximo vetores (arrays) de tipos simples (como
strings, inteiros, booleanos e bytes), as variáveis de rede abrangem desde
escalares a estruturas complexas (contendo outros escalares, estruturas ou
variáveis de rede), as quais podem herdar características de outras variáveis
de rede e possuem um significado semântico específico;
● A norma IEC 61499, além de discriminar as variáveis de entrada e saída de
um bloco funcional em dados e eventos, estabelece o diagrama de controle
de execução (ECC) como recurso para determinar os estados internos de
um bloco funcional, as condições para a ocorrência de transições entre
esses estados e os algoritmos a serem executados (inclusive com o
detalhamento das variáveis afetadas). Na tecnologia LonWorks, não existe
um formalismo adequado para a descrição do funcionamento interno dos
169
blocos funcionais: no melhor dos casos, há recomendações gerais e
explicações sobre a semântica de sua interface, mas, em última instância, o
funcionamento do bloco funcional depende de seu implementador (e, muitas
vezes, a própria codificação serviria como meio de sua documentação);
● Da mesma forma, não existe na tecnologia LonWorks elementos lógicos
específicos que tratem da interação dos blocos funcionais com outros
sistemas ou elementos físicos (o que é feito, na norma IEC 61499, pelos
blocos funcionais de interface de serviço (Service Interface Function Blocks
– SIFB)). Dessa forma, a construção de gateways de comunicação com
outros sistemas não pode ser expressada por meio de seqüências de
primitivas de serviço, assim como a interação com dispositivos físicos (muito
embora na implementação através da linguagem Neuron C, por exemplo, o
uso de entradas e saídas físicos é feito por meio de funções e variáveis
pertencentes a uma biblioteca específica);
● Finalmente, vale destacar que não há um elemento na norma IEC 61499
com características semelhantes às propriedades de configuração
encontradas nos modelos da tecnologia LonWorks. Apesar de haver formas
de expressar essas informações segundo a norma IEC 61499 (por meio de
adaptadores, eventos e dados, por exemplo), a diferenciação de dados
operacionais e dados utilizados apenas para configuração de dispositivos,
blocos funcionais e variáveis de entrada e saída parecem ser interessantes
do ponto de vista da idealização e organização das aplicações.
Tendo em consideração os tópicos acima, percebe-se que, de maneira
geral, a abordagem da norma IEC 61499 quanto aos de sistemas de automação
distribuídos é muito mais abrangente que os conceitos da tecnologia LonWorks:
nesse sentido, pode-se inclusive sugerir que esta última seja considerada uma
especialização da primeira, contando com as seguintes restrições:
� Os dispositivos LonWorks possuem um e apenas um recurso para cada
processador Neuron Chip que contenham;
� Não existem agregações de blocos funcionais, mas apenas redes de blocos
funcionais; e
� Cada variável de rede LonWorks pode ser representada por uma estrutura
de dados e um evento da norma IEC 61499 associados por um qualificador
WITH (já que o firmware do Neuron Chip, responsável por gerenciar a
170
transmissão de mensagens entre os nós, notifica a camada de aplicação
sempre quando há alteração em qualquer variável de rede ou propriedade
de configuração).
5.2.1.3. Comentários
Sendo assim, apesar das diferenças entre os modelos lógicos da tecnologia
LonWorks e da norma IEC 61499, percebe-se que esta última pode expressar todos
os recursos da primeira e ainda enriquecer a semântica dos sistemas de automação
idealizados.
Além disso, devido a seus modelos lógicos serem explicitamente orientados
a eventos, a norma IEC 61499 permitiu que ocorresse a sua interação com os
modelos de orientação a objetos, especialmente aqueles descritos em UML, como
disposto nos capítulos anteriores. Isso faz com que as abstrações da norma IEC
61499 tenham um uso ainda mais desejável do que as da tecnologia LonWorks.
Vale destacar, no entanto, que além do uso da tecnologia LonWorks ser uma
alternativa tecnicamente viável para a implementação dos sistemas descritos através
da norma IEC 61499 (já que esta também não restringe nenhuma tecnologia de
implementação), ela pode contribuir com a norma IEC 61499 através de recursos
próprios de uma tecnologia consagrada, principalmente na área de automação
predial e nos mercados europeu e chinês, como por meio da definição de blocos
funcionais, variáveis de rede e as propriedades de configuração publicadas pelo
órgão de padronização da tecnologia LonWorks, denominado LonMark.
Assim, como será detalhado adiante, sugere-se neste trabalho o uso das
abstrações da norma IEC 61499 para definir a modelagem dos sistemas de
automação distribuídos e a tecnologia LonWorks como um dos meios de
implementação desses sistemas. Adicionalmente, indica-se a exploração dos
modelos LonWorks de blocos funcionais, variáveis de rede e propriedades de
configuração padronizados para aumentar a quantidade e melhorar a expressividade
dos tipos de blocos funcionais, adaptadores, dados e eventos da norma IEC 61499.
Dessa maneira, pode-se aliar uma capacidade de modelagem mais representativa e
o uso de uma tecnologia bem aceita, com reaproveitamento de informações e
sistemas legados.
171
5.2.2. Implementação de ferramenta computacional para suporte ao
desenvolvimento de sistemas de automação distribuídos LonWorks
Vê-se, até o momento, que os sistemas de execução dos modelos da norma
IEC 61499 baseiam-se em ambientes Java, Linux ou sistemas de automação de
menor porte (CHOUINARD; BRENNAN, 2006; SOFTWARE ENGINEERING
GROUP, 2006). A partir do que foi discutido no item anterior, uma das possíveis
expansões das ferramentas para suporte ao desenvolvimento de sistemas de
automação distribuídos seria que as mesmas permitissem a interação, do ponto de
vista de implementação, com os sistemas LonWorks.
Assim, a idéia primordial seria ampliar as ferramentas para que as mesmas
permitissem o desenvolvimento completo dos sistemas de automação, com a
realização do levantamento de requisitos e análise do sistema através das
abstrações da UML, o projeto do sistema por meio das abstrações da norma IEC
61499, e a implementação, os testes e a manutenção do sistema feitos através do
uso de recursos da tecnologia LonWorks.
5.2.2.1. Visão geral da ferramenta
A ferramenta idealizada nesta seção deve ser composta por:
� Uma sub-aplicação para permitir o projeto de sistemas por meio de modelos
da UML (como, por exemplo, o IBM Rational Rose);
� Uma sub-aplicação para a conversão de tais modelos em outros, dados
segundo a norma IEC 61499 (ou seja, uma ferramenta que implemente
algum dos mapeamentos UML-IEC61499, como o Transformation Facility
Manager (TFM), discutido no capítulo 4);
� Uma sub-aplicação para permitir o projeto de sistemas por meio de modelos
da IEC 61499 (a fim de refinar as representações obtidas através da
conversão UML-IEC61499); e
� Uma sub-aplicação para, a partir das representações dadas em abstrações
da IEC 61499, permitir funções de monitoração e controle, e de
gerenciamento da rede (incluídas, aqui, atividades como configuração dos
dispositivos, configuração de rede, execução de testes, verificação e
alteração do estado dos dispositivos, observação e alteração das
172
aplicações, entre outros).
Para que esta última ferramenta seja viável, um dos requisitos é que as
abstrações da norma IEC 61499 possam ser transformadas em elementos de
implementação LonWorks (ou seja, em configuração e código de máquina dos
dispositivos, por exemplo).
5.2.2.1.1. Transformação das abstrações da norma IEC 61499 em elementos de
implementação LonWorks
Em termos gerais, a transformação entre abstrações da IEC 61499 para os
elementos de implementação da tecnologia LonWorks pode ser feita da seguinte
maneira:
� Como restrição da modelagem, é preciso que um dispositivo da norma IEC
61499 contenha apenas um recurso para representar um dispositivo
LonWorks;
� As sub-aplicações e os blocos funcionais compostos da norma IEC 61499
devem ser desmembrados até que a aplicação completa do sistema seja
vista apenas em termos de instâncias de blocos funcionais básicos. Essas
instâncias serão mapeadas na tecnologia LonWorks como blocos funcionais
(objetos). Dado que a configuração de um sistema da norma IEC 61499
determina em qual recurso cada um desses blocos deve estar alocado, e
levando em consideração a restrição vista anteriormente, obtém-se os
relacionamentos entre um dispositivo LonWorks e seus blocos funcionais;
� Os tipos de blocos funcionais básicos da norma IEC 61499 determinarão a
composição dos perfis funcionais LonWorks:
Cada entrada de evento ou de dado deve ser transformada em uma
variável de rede de entrada. O tipo da variável de rede corresponderá ao
tipo de dado transferido ou, no caso de um evento, pode ser de um tipo
qualquer, como booleano, por exemplo (neste caso, na verdade, o tipo
de dado é irrelevante, já que qualquer alteração em uma variável de rede
gera um evento tratável pela camada de aplicação);
Da mesma forma, uma saída de evento ou de dado deve ser
transformada em uma variável de rede de saída. O tipo da variável de
rede corresponderá ao tipo de dado transferido ou, no caso de um
173
evento, pode ser de um tipo qualquer;
Um qualificador WITH entre uma entrada de eventos e uma entrada de
dados pode ser simulada no nível de aplicação LonWorks pela
amostragem do valor da variável de rede correspondente à entrada de
dados quando a variável de rede referente ao evento indicar alteração
em seu valor;
Um qualificador WITH entre uma saída de eventos e uma saída de dados
pode ser simulada no nível de aplicação LonWorks pela atualização do
valor da variável de rede correspondente à saída de dados quando a
variável de rede referente ao evento tiver o seu valor atualizado;
O diagrama de controle de execução (ECC) deve ser transformado no
software de um bloco funcional. Os estados e as transições podem ser
transformados em uma implementação computacional de uma máquina
de estados (dada em linguagem de máquina, por exemplo). Por sua vez,
os algoritmos serão conjuntos de operações a serem realizadas pelo
microprocessador. Por fim, os eventos de entrada e saída que forem
manipulados pelo ECC podem ser traduzidos, respectivamente, como
verificação ou alteração de um valor de uma variável de rede.
� Os blocos funcionais de interface de serviços, a princípio, poderão ser
transformados em blocos funcionais LonWorks da mesma maneira que os
blocos funcionais básicos da norma IEC 61499 quanto à sua interface. No
entanto, seu comportamento, aparentemente, não pode ser traduzido sem
se conhecer a aplicação do bloco funcional. Por exemplo, se for conhecido
que esse diagrama é usado em certo bloco funcional para mostrar a
interação da aplicação com as entradas e saídas de um Neuron Chip, isso
pode ser transformado em um software que utilize a biblioteca de entradas e
saídas do Neuron Chip para manipular suas entradas e saídas;
� Finalmente, um tipo de adaptador pode designar, da mesma forma que
ocorre com a estrutura de um bloco funcional, quais são as variáveis de rede
a serem geradas em um nó LonWorks.
174
5.2.2.1.2. Aspectos de implementação
Uma opção para a implementação das idéias acima é através do uso de
ferramentas de desenvolvimento LonWorks (fornecidos pela empresa Echelon
Corporation).
Através do software NodeBuilder (ECHELON CORPORATION, 2006), seria
possível compilar uma aplicação (referente a um dispositivo LonWorks), dada em
linguagem Neuron C, para se obter um código executável em um Neuron Chip (vale
ressaltar que a linguagem de máquina do Neuron Chip não é aberta, portanto não
haveria, a princípio, possibilidade de compilação direta para esse processador a
partir da descrição de um sistema em modelos da norma IEC 61499). Dessa
maneira, os blocos funcionais da norma IEC 61499 (considerando sua estrutura e
comportamento), dados em arquivos XML (conforme a norma), poderiam ser
convertidos para a linguagem Neuron C, e então compilados (para gerar os blocos
funcionais e variáveis de rede da aplicação de um dispositivo LonWorks).
Por meio do kit de desenvolvimento LNS (ECHELON CORPORATION,
2004), seria possível desenvolver ferramentas que interagem com o Sistema
Operacional de Rede LNS (LNS Network Operating System). Este, por sua vez, é o
software responsável por realizar os serviços de rede associados a um sistema
LonWorks (incluindo a configuração, a instalação e a manutenção de rede –
chamados coletivamente por gerenciamento de rede, e a monitoração e controle do
sistema – abrangendo dispositivos e canais de comunicação). Todas as funções do
LNS podem ser invocadas por meio de um controle ActiveX chamado LNS Object
Server, o qual fornece uma visão da hierarquia de objetos do LNS. Tal hierarquia
apresenta os componentes de rede (como dispositivos de aplicação, variáveis de
rede, blocos funcionais LonMark, propriedades de configuração, roteadores e
canais) como objetos padrão do Windows – cujos métodos permitem a execução de
operações no componente associado; cujas propriedades viabilizam a verificação de
estado e configuração do componente; e cujos eventos indicam mudanças no
componente. Dessa maneira, qualquer ambiente de desenvolvimento que possa
utilizar esse controle ActiveX (como, por exemplo, o Microsoft Visual Studio .NET
2003) pode viabilizar o desenvolvimento de uma ferramenta para interagir com o
LNS, e, assim, gerenciar uma rede LonWorks. Dessa maneira, mostra-se uma das
formas pelas quais seria possível fazer uma ferramenta para configurar os
175
dispositivos da rede LonWorks, carregar suas aplicações (já compiladas pelo
software NodeBuilder, por exemplo) e executar o processo de ligação (binding) das
variáveis de rede. Além disso, haveria a possibilidade de visualizar o estado
operacional do sistema LonWorks. Portanto, por meio dessa solução, é provável que
se pudesse construir uma ferramenta computacional que, integrada à ferramenta
NodeBuilder, permitisse a instalação, testes e manutenção da rede LonWorks a
partir de um modelo do sistema de automação dado por meio de abstrações da
norma IEC 61499. Um exemplo de uma ferramenta que realiza todas essas funções,
mas com a exibição do sistema, dada de forma gráfica, por meio de blocos
funcionais e dispositivos LonWorks chama-se LonMaker, e também é fornecida pela
empresa Echelon Corporation: a mesma pode servir como inspiração sobre o ponto
a ser atingido pela ferramenta a ser construída (no sentido de implementação, testes
e manutenção de uma rede LonWorks, mas não quanto à representação de
elementos relativos ao levantamento de requisitos, análise e projeto do sistema).
Finalmente, uma interface de programação (application program interface -
API) disponibilizada pelo órgão de padronização LonMark, permite a exploração de
arquivos públicos, chamados Resource Files, que reúnem tipos padronizados de
perfis funcionais, variáveis de rede e propriedades de configuração (standard FTP
(SFTP), standard NVT (SNVT) e standard CPT (SCPT)). A utilização dessa interface
por uma ferramenta computacional poderia ser analisada para a criação de tipos de
blocos funcionais e adaptadores da norma IEC 61499 específicos para a
representação daquelas abstrações LonWorks. Além de enriquecer a biblioteca de
tipos de blocos funcionais de uma ferramenta da IEC 61499, a geração de código
para os sistemas LonWorks seria muito mais eficiente (já que a semântica dos
dados, inclusive a vinculação entre eles, estaria especificada).
5.2.2.2. Comentários
O fato de se poder implementar um sistema de automação dado por
abstrações da norma IEC 61499 em tecnologia LonWorks, dentro das condições
analisadas nesta dissertação, levariam a que fosse possível constituir uma
ferramenta computacional para auxílio a todas as etapas de engenharia do ciclo de
desenvolvimento de um sistema de automação. Segundo o que foi estudado, essa
perspectiva pode ser tornada uma realidade. No entanto, outros trabalhos devem
176
complementar esta dissertação no sentido de construir de fato essa ferramenta (o
que, certamente, além de oferecer uma solução valiosa para as equipes de
engenharia, acrescentaria contribuições acadêmicas importantes sobre as
vantagens e desvantagens tanto da norma IEC 61499 quanto dos modelos lógicos
da tecnologia LonWorks).
177
6. CONSIDERAÇÕES FINAIS
6.1. CONCLUSÕES
Percebe-se, através do que foi exposto nos capítulos anteriores, que as
pesquisas na área de projetos de automação modelados segundo a norma
International Electrotechnical Commission (IEC) 61499 ainda estão em seu início, já
que a norma, publicada recentemente (em 2005), não foi muito difundida até o
momento, especialmente fora do âmbito acadêmico.
É interessante notar a preocupação de diversos pesquisadores (como
Thramboulidis, por exemplo) em complementar as sugestões dessa norma no
sentido de cobrir etapas de projeto de sistemas de automação que não estão
previstas por ela, como o levantamento de requisitos e a análise do sistema. Para
isso, a Unified Modeling Language (UML) tem sido usada de maneira extensiva,
dado que a maioria dos engenheiros de sistemas e software estão acostumados a
especificar sistemas dessa maneira. A expressividade e possibilidade de expansão
da UML para outros domínios (que não os de software) também são atributos que
facilitam a sua adoção para a modelagem de sistemas em diversas outras áreas.
Além de abordagens teóricas sobre a aproximação dos modelos da UML em
relação àqueles oferecidos pela norma IEC 61499, encontram-se também alguns
primeiros trabalhos de implementação de ferramentas para suporte às atividades de
engenharia de sistemas de automação. Muito embora a existência dessas
ferramentas tenha sido sugerida explicitamente pela norma IEC 61499, certas
iniciativas (como a do Common Object-oriented Real-time Framework for the Unified
development of distributed Industrial-Process Measurement and Control Systems
(IPMCS) applications (CORFU) Engineering Support System (ESS)) empenham-se
em tratar a conversão de modelos da UML para os modelos da IEC 61499 – a ser
realizada previamente à continuação do projeto exclusivamente em elementos de
modelagem da IEC 61499. Nota-se, também, que muitas delas estão iniciando a
implementação prática dos sistemas de automação, por meio do desenvolvimento de
ambientes de execução compatíveis com a norma. Neste ponto, no entanto,
178
percebe-se que se têm usado ambientes Java, Linux ou tecnologias de automação
para sistemas de pequeno porte como meio de implementação e testes, e não
sistemas comerciais já difundidos (o que certamente seria interessante pela
possibilidade de reaproveitamento de ferramentas e suporte a sistemas legados).
Dessa maneira, tentou-se contribuir com tais pesquisas no sentido de
apresentar sugestões para melhorar tanto os mapeamentos UML-IEC61499
estudados quanto para viabilizar a implementação prática de sistemas de automação
LonWorks. No entanto, nota-se que ainda há diversas iniciativas a serem exploradas
dentro dessa área para que se chegue a métodos e ferramentas suficientemente
estáveis e abrangentes a ponto de serem adotados pela indústria (mesmo porque a
própria norma IEC 61499 ainda está em fase de divulgação).
6.2. CONTRIBUIÇÕES
As principais contribuições dadas nesta dissertação são listadas a seguir:
� Proposta de um novo mapeamento entre abstrações da UML e da norma
IEC 61499 (em contraposição àqueles vistos no capítulo 3, que lhe serviram
de base), tendo como principal objetivo a desvinculação da linguagem usada
nos modelos UML dos conceitos e do próprio vocabulário específico da
norma IEC 61499 – de forma a tornar a modelagem de um sistema de
automação mais simples, nas fases de levantamento de requisitos e análise
do sistema, para aqueles que não conheçam a padronização citada e
utilizem a UML;
� Indicação sobre possíveis formas de uso de mecanismos de extensão da
UML (principalmente restrições – constraints), além de diagramas da UML
2.X, para a expressão de parâmetros temporais – relacionados ao conceito
de qualidade de serviço (Quality of Service – QoS) – para o projeto de
sistemas de automação distribuídos dados segundo a norma IEC 61499; e
� Sugestões para a construção de uma ferramenta computacional para
suporte ao desenvolvimento de sistemas de automação distribuídos que
permitisse a passagem de modelos de sistemas dados através de
abstrações da norma IEC 61499 para elementos de implementação da
179
tecnologia LonWorks, resultado posterior à análise da compatibilidade entre
as abstrações da norma IEC 61499 e das abstrações previstas pela
tecnologia LonWorks para o projeto de sistemas de automação distribuídos.
Como contribuições secundárias, podem-se citar:
� Elaboração de tutorial sobre conceitos fundamentais da UML, abrangendo
os seus principais diagramas (inclusive aqueles introduzidos a partir da
versão 2.X da norma);
� Elaboração de tutorial sobre a norma IEC 61499, relacionada ao uso de
blocos funcionais orientados a eventos no projeto de sistemas distribuídos
de controle e medição para processos industriais;
� Apresentação de discussão sobre a compatibilidade entre ciclos de vida de
desenvolvimento de projetos, métodos de modularização e linguagens
específicas para a modelagem de sistemas, segundo os pontos de vista da
engenharia de sistemas e software, e da engenharia de controle e
automação;
� Revisão de literatura sobre algumas das principais propostas de
mapeamento entre a UML e os modelos de representação de sistemas de
automação dados pela IEC 61499, e elaboração de tabelas para viabilizar a
comparação sistemática das mesmas; e
� Revisão de literatura sobre algumas das principais ferramentas de suporte
às atividades de engenharia do ciclo de vida de projetos de sistemas de
automação distribuídos (dentro do contexto de utilização de modelos da
UML e da norma IEC 61499 para a sua representação), além da vinculação
das ferramentas às fases de desenvolvimento cobertas por cada uma
(também apresentado em formato tabular, para facilitar sua comparação).
6.3. MELHORIAS
Posto que muitos dos assuntos que foram tratados nesta dissertação ainda
estão aquém de serem soluções definitivas em termos de métodos e ferramentas
para o projeto de sistemas de automação distribuídos, há muito espaço para
melhorias. Algumas delas estão sugeridas a seguir:
180
� Busca e análise de novas referências sobre tipos de mapeamento UML-
IEC61499 que não tenham sido abordadas ou que possam ter surgido após
a publicação desta dissertação (de forma a ampliar e atualizar o
conhecimento nesta área);
� Estudo mais aprofundado das ferramentas de auxílio a projetos de sistemas
de automação apresentadas no capítulo 4, especialmente após o
encerramento deste texto – já que novas versões das ferramentas serão
lançadas e provavelmente haverá interesse em verificar suas
funcionalidades. Neste ponto, seria especialmente relevante estudar em
detalhes aquelas que não foram abordadas de forma aprofundada nesta
dissertação, como por exemplo a ferramenta Archimedes ESS, mostrando
seus pontos fortes e deficiências;
� Análise do mapeamento UML-IEC61499 proposto nesta dissertação e
aprimoramento do mesmo, seja pela adição de novos diagramas UML a
gerarem modelos compatíveis com as abstrações da norma IEC 61499
(como por exemplo, o Diagrama de Componentes, que parece ser uma boa
opção para expressar componentes de software que implementam as
classes representantes de blocos funcionais), seja pela sugestão das formas
pelas quais pudessem ser realizadas transformações inversas dos modelos
(de representações da norma IEC 61499 para a UML, que teriam grande
utilidade para o reaproveitamento de modelos de sistemas já
implementados);
� Aprofundamento da proposta de utilização de restrições em modelos da
UML para designar restrições temporais de sistemas de automação: neste
ponto, sugere-se a determinação de um conjunto de parâmetros de
interesse para sistemas de automação (incluindo sua forma de expressão
nos modelos do sistema) e de uma linguagem formal adequada para permitir
a geração de testes de desempenho (de forma a complementar as
funcionalidades de uma possível ferramenta de suporte ao desenvolvimento
de sistemas de automação), bem como a verificação do possível uso de
perfis (profiles) UML voltados a sistemas de tempo real para melhorar a
expressividade dos modelos da UML sobre aspectos de tempo; e
� Execução de análise crítica da proposta de mapeamento entre as
abstrações da IEC 61499 e da tecnologia LonWorks, aprofundamento da
181
mesma e proposição de uma conversão inversa completa de elementos
lógicos e de implementação da tecnologia LonWorks para abstrações da
norma IEC 61499 (o que não foi abordado neste texto por restrições de
tempo, mas que seria de grande interesse para a engenharia reversa de
redes LonWorks já instaladas).
6.4. TRABALHOS FUTUROS
Como trabalhos futuros, além das melhorias citadas acima, poderiam ser
realizadas as seguintes investigações:
� Exploração do assunto sobre blocos funcionais de gerenciamento da norma
IEC 61499, que permitem, em um recurso, criar, inicializar, iniciar, parar,
excluir e indagar sobre os atributos e a existência de tipos de dados, de tipos
e instâncias de blocos funcionais, e de conexões entre instâncias de blocos
funcionais (além de notificar mudanças na disponibilidade e estado desses
elementos), e, em um dispositivo, executar as mesmas funções
relativamente a um recurso. Os blocos funcionais de gerenciamento
parecem ser aplicáveis no caso de ferramentas de gestão de uma rede de
automação, e parecem ter paralelo com blocos funcionais LonMark
denominados NodeObject: essa relação poderia ser explicitada;
� Implementação de uma ferramenta de conversão UML-IEC61499
(independentemente do tipo de mapeamento escolhido) com o uso de
ferramentas abertas e gratuitas para a modelagem de sistemas UML (haja
vista que em todos os casos estudados a ferramenta utilizada foi o IBM
Rational Rose, que é um software comercial e não está disponível a todas
as pessoas da comunidade);
� Criação de uma ferramenta para executar o mapeamento UML-IEC61499
simplificado, proposto nessa dissertação, especialmente para verificar a
possibilidade técnica de sua implementação e para fornecer uma ferramenta
útil para a modelagem de sistemas de automação (o que também permitiria
uma abordagem prática do assunto, além de conseqüentes aprimoramentos
teóricos sobre o tema);
182
� Idealização e implementação de uma ferramenta para simulação sobre o
comportamento dinâmico, no tempo, de sistemas de automação – baseado
na expressão de seus requisitos temporais tanto na UML quanto nas
abstrações da norma IEC 61499;
� Estudos sobre outros requisitos de QoS que sejam de interesse para
sistemas de automação distribuído (assim como de outros tipos requisitos
não-funcionais), e geração de propostas para sua expressão nos modelos
dos sistemas;
� Implementação de uma ferramenta completa para executar algum
mapeamento entre modelos da UML e da IEC 61499, e a passagem de
modelos da IEC 61499 para sistemas LonWorks, de forma a fornecer
suporte a todas as etapas do ciclo de vida de desenvolvimento de projetos
de automação. Esta proposta é bastante ousada, já que, a princípio, trata-se
de um projeto de grande porte (considerando a necessidade de implementar
não somente funções de modelagem, mas também de gestão de rede e
controle e monitoração). No entanto, a mesma pode ser subdividida em
projetos menores (ao estilo “dividir para conquistar”), abrindo diversas
frentes de trabalho; e
� Adoção de abordagens totalmente diferentes às deste trabalho para a
modelagem de sistemas de automação: por exemplo, modelagem exclusiva
dos sistemas de automação em UML ou em IEC 61499 (passando-se à
implementação do sistema diretamente a partir desses modelos). Esta última
sugestão seria muito interessante para a comparação global das vantagens
e desvantagens de se adotar modelagens puras (em uma única linguagem)
ou híbridas (como as exploradas neste texto) para o projeto de sistemas de
automação.
6.5. ENCERRAMENTO
(A partir deste ponto, a autora permite-se expressar uma visão particular
sobre os resultados obtidos neste trabalho).
Pessoalmente, meu objetivo ao iniciar esta dissertação era dar uma
183
contribuição à área de projetos de sistemas de automação, em que percebia uma
grande lacuna (do ponto de vista de uma engenheira de software) quanto ao
momento em que era necessário levantar requisitos e realizar a análise de um
sistema (e, dentro dessa, a modularização das aplicações). Diversas vezes utilizei-
me de ferramentas para modelar o sistema em UML, e depois adaptava os modelos,
de forma não-automatizada, para blocos funcionais da linguagem de implementação
que estivesse utilizando.
Ao iniciar a pesquisa sobre esse tema, percebi que diversos autores tinham
as mesmas insatisfações que eu, e que haviam começado a publicar trabalhos
nessa área vinculando a UML a representações dos sistemas de automação em
abstrações da norma IEC 61499. Mais do que isso, começavam a publicar as
primeiras ferramentas para conversão automática dos modelos de sistemas (UML-
IEC61499), e outras para o suporte específico ao projeto de aplicações e sistemas
completos de automação com blocos funcionais daquela norma.
Tendo sugerido modificações a essas abordagens e maneiras de unir as
ferramentas existentes aos sistemas LonWorks (com os quais trabalhava
especialmente na área de automação predial), senti uma grande satisfação ao
perceber que, embora o caminho ainda seja bastante longo para chegarmos ao
ponto ideal para cobrir completamente o desenvolvimento de sistemas de
automação (ou seja, por meio de ferramentas abrangentes de auxílio ao projeto),
temos a perspectiva de tornar essa visão uma realidade através do desenvolvimento
de diversos outros trabalhos. Assim, isso me motiva a permanecer dentro dessa
área de pesquisa, a fim de realizar parte das contribuições necessárias para
alcançarmos essa meta.
184
REFERÊNCIAS
4DIAC CONSORTIUM. HowTo for 4DIAC-IDE Version 0.0. [S. l.]: 4DIACConsortium, 2007. 28 p. Disponível em: <http://www.fordiac.org/fileadmin/user_upload/4DIAC-IDE_HowTo_V0.0.pdf>. Acesso em: 12 nov. 2007.
AIHKISALO, T. Remote maintenance and development of home automationapplications. Espoo: Technical Research Centre of Finland (VTT), 2002. 85 p.(Série VTT Tiedotteita – Meddelanden – Research Notes, 2129). Disponível em:<http://www.vtt.fi/inf/pdf/tiedotteet/2002/T2129.pdf>. Acesso em: 5 abr. 2007.
ALSHIN, D.; DUBININ, V. UML to FB converter. v. 1.0. 2004. Disponível em:<http://alice.stup.ac.ru/~dvn/fb61499/uml_fb/converters/vlasov/UMLtoFB_Vlasov_Jan_9_2005.zip>. Acesso em: 21 ago. 2007.
ARMSTRONG, D. J. The Quarks of Object-Oriented Development.Communications of the ACM, [S. l.], v. 49, p. 123-128, fev. 2006. Número 2.Disponível em: <http://delivery.acm.org/10.1145/1120000/1113040/p123-armstrong.pdf?key1=1113040&key2=3766990811&coll=GUIDE&dl=GUIDE&CFID=20457838&CFTOKEN=16438283>. Acesso em: 5 abr. 2007.
ÅSTRÖM, K. J. Process control – Past, present, and future. IEEE Control SystemsMagazine, [S. l.], v. 5, p. 3-10, ago. 1985.
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. The Unified Modeling LanguageUser Guide. Massachusetts: Addison-Wesley, 1998. 512 p.
BORDBAR, B.; DERRICK, J.; WATERS, G. Using UML to specify QoS constraints inODP. Computer Networks, [S. l.], v. 40, p. 279-304, 2002. Disponível em:<http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6VRG-45X0D60-2-2R&_cdi=6234&_user=5674931&_orig=search&_coverDate=10%2F07%2F2002&_sk=999599997&view=c&wchp=dGLbVtb-zSkzS&md5=23cdf75c82b5af0181843fa5109f9837&ie=/sdarticle.pdf>. Acesso em: 5 abr. 2007.
CAUFFRIEZ, L. et al. Design of intelligent distributed control systems: adependability point of view. Reliability Engineering and System Safety, [S. l.], v.84, p. 19-32, 2004. Disponível em: <http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6V4T-49RCGDN-1-18&_cdi=5767&_user=5674931&_orig=search&_coverDate=04%2F30%2F2004&_sk=999159998&view=c&wchp=dGLbVlb-zSkWA& md5=f7cebe9b67e48b8b96234aaed095aa01&ie=/sdarticle.pdf>. Acessoem: 10 abr. 2007.
185
ČENGIĆ, G.; LJUNGKRANTZ, O.; ÅKESSON, K. Formal Modeling of Function BlockApplications Running in IEC 61499 Execution Runtime. In: 2006 IEEEINTERNATIONAL CONFERENCE ON EMERGING TECHNOLOGIES ANDFACTORY AUTOMATION (ETFA '06), 2006, Prague. Proceedings... [S. l.]: IEEE,2006. p. 1269-1276. Disponível em: <http://ieeexplore.ieee.org/iel5/4178170/4178171/04178302.pdf?tp=&isnumber=&arnumber=4178302>. Acesso em: 14 dez. 2007.
CHOUINARD, J.; BRENNAN, R. W. Software for Next Generation Automation andControl. In: 2006 IEEE INTERNATIONAL CONFERENCE ON INDUSTRIALINFORMATICS, 4., 2006, [S. l.]. [S. l.]: IEEE, 2006. Disponível em: <http://ieeexplore.ieee.org/iel5/4053335/4053336/04053506.pdf?tp=&isnumber=&arnumber=4053506>. Acesso em: 12 nov. 2007.
CHRISTENSEN, J. H. The IEC 61499 Standard: Concepts and R&D Resources.[S. l.: s. n.], 2002. 78 p. Documento do PowerPoint. Disponível em:<http://www.holobloc.com/papers/tut_61499.zip>. Acesso em: 23 jul. 2007.
CLEMENTS-CROOME, T. D. J. What do we mean by intelligent buildings?Automation in Construction, [S. l.], v. 6, p. 395-400, 1997. Disponível em:<http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6V20-3SNMSDH-3-1&_cdi=5688&_user=5674931&_orig=search&_coverDate=09%2F30%2F1997&_sk=999939994&view=c&wchp=dGLbVlb-zSkWA&md5=5638565d317e972325b9a966d4a5930e&ie=/sdarticle.pdf>. Acesso em: 10 abr. 2007.
CONVERTER from UML to IEC 61499 function blocks -- forward engineering. 2004.Apresenta informações sobre a ferramenta. Disponível em:<http://alice.stup.ac.ru/~dvn/fb61499/uml_fb/converters/alshin/download.htm>.Acesso em: 21 ago. 2007.
DAI, W.; SHIH, A. C. K.; VYATKIN, V. Development of Distributed IndustrialAutomation Systems and Debugging Functionality Based on the Open SourceOOONEIDA Workbench. In: AUSTRALASIAN CONFERENCE ON ROBOTICS ANDINDUSTRIAL AUTOMATION (ACRA 2006), 2006, Auckland. [S. l.: s.n.], 2006. p. 1-7.Disponível em: <http://www.araa.asn.au/acra/acra2006/papers/paper_5_ 55.pdf>.Acesso em: 21 jun. 2007.
DUBININ, V.; VYATKIN, V. UML-FB – A language for modeling and implementationof industrial-process measurement and control systems on the basis of IEC 61499standard. In: INTERNATIONAL CONFERENCE OF SCIENCE AND TECHNOLOGY“NEW INFORMATION TECHNOLOGIES AND SYSTEMS” (NITS’2004), 6., 2004,Penza. Proceedings... [S. l.: s. n.], 2004. p. 77-83. Disponível em: <http://alice.stup.ac.ru/~dvn/fb61499/docs/paper/my/Nits2004/dubinin_vyatkin_nits2004.pdf>. Acessoem: 21 ago. 2007.
186
DUBININ, V.; VYATKIN, V.; PFEIFFER, T. Engineering of Validatable AutomationSystems Based on an Extension of UML Combined With Function Blocks of IEC61499. In: 2005 IEEE INTERNATIONAL CONFERENCE ON ROBOTICS ANDAUTOMATION, 2005, Barcelona. Proceedings... [S. l.]: IEEE, 2005. p. 3996-4001.Disponível em: <http://ieeexplore.ieee.org/iel5/10495/33250/01570732.pdf>. Acessoem: 21 ago. 2007.
ECEDAC CONSORTIUM. 4DIAC-IDE. Version 0.0.2. 2007. Disponível em:<http://www.fordiac.org/fileadmin/user_upload/4DIAC-IDE-0.0.2.zip>. Acesso em: 12nov. 2007.
ECHELON CORPORATION. Introduction to the LonWorks system, v. 1.0. [S. l.]:Echelon Corporation, 1999. 73 p. Disponível em: <http://www.echelon.com/support/documentation/manuals/078-0183-01A.pdf>. Acesso em: 20 mai. 2005.
ECHELON CORPORATION. LNS® Application Developer's Kit/Turbo EditionModel 34309. [S. l.]: Echelon Corporation, 2004. 4 p. Disponível em:<http://www.echelon.com/support/documentation/datashts/34309.pdf>. Acesso em:20 mai 2005.
ECHELON CORPORATION. LonMark Application-Layer InteroperabilityGuidelines, v. 3.4. [S. l]: Echelon Corporation, 2005. 130 p. Disponível em:<http://www.lonmark.com/technical_resources/guidelines/docs/LmApp34.pdf>.Acesso em: 20 mai. 2005.
ECHELON CORPORATION. Echelon's NodeBuilder Development Tool. [S. l.]:Echelon Corporation, 2006. Descrição técnica-comercial da ferramentaNodeBuilder® 3.1. Disponível em: <http://www.echelon.com/products/development/nodebuilder/default.htm>. Acesso em: 16 mar. 2007.
GUSTIN, G. D. B. Modelagem e análise de sistemas distribuídos e abertos paraautomação predial. 2005. 196 p. Tese (Doutorado) – Escola Politécnica daUniversidade de São Paulo, São Paulo, 2005.
HEVERHAGEN, T.; TRACHT, R.; HIRSCHFELD, R. A Profile for Integrating FunctionBlocks into the Unified Modeling Language. In: INTERNATIONAL WORKSHOP ONSPECIFICATION AND VALIDATION OF UML MODELS FOR REAL TIME ANDEMBEDDED SYSTEMS (SVERTS'03), 2003, San Francisco. Proceedings... [S. l.: s.n.], 2003. Disponível em: <http://www-verimag.imag.fr/EVENTS/2003/SVERTS/PAPERS-WEB/08-Heverhagen-FunctionBlockAdapters.pdf>. Acesso em: 21 ago.2007.
187
HOLOBLOC, INC. FBDK. Version 20061017. 2006. Disponível em: <http://www.holobloc.com/fbdk.zip>. Acesso em: 21 jun. 2007.
HOLOBLOC, INC. HOLOBLOC, Inc.: Resources for the New Generation ofAutomation and Control. [S. l.]: Holobloc, Inc., 2006. Página da Internet sobre aempresa Holobloc, sobre o projeto FBDK e sobre o padrão IEC 61499. Disponívelem: <http://www.holobloc.com>. Acesso em: 21 jun. 2007.
HONEYWELL INTERNATIONAL INC. Control_Builder_PIN.pdf: Descrição técnica-comercial da ferramenta Experion® Control Builder. Phoenix, 2005. Disponível em:<http://hpsweb.honeywell.com/HPSWEBII/DownloadDocument.axd?DocumentUrl=/NR/rdonlyres/0A391DEE-0210-4913-81A4-DC336268C5F6/24268/Control_Builder_PIN.pdf>. Acesso em: 27 abr. 2007.
HUR, S. -H.; KIM, D.; PARK, G. -T. Building automation system via LonWorks andLinux based personal computer. Automation in Construction, [S. l.], [2005]. Noprelo. Disponível em: <http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6V20-4HGM778-1-11&_cdi=5688&_user=10&_orig=search&_coverDate=07%2F31%2F2006&_sk=999849995&view=c&wchp=dGLzVlz-zSkzV&md5=40579c6d974a46ec00646d058495880b&ie=/sdarticle.pdf>. Acesso em: 15 mai. 2006.
INTELLIGENT MECHATRONICS AND AUTOMATION GROUP. IEC 61499 FBench.Version v0.5. 2007. Disponível em: <http://sourceforge.net/project/showfiles.php?group_id=1986 68&package_id=235424&release_id=546550>. Acesso em: 21 jun.2007.
INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 61499-1: Functionblocks – Part 1: Architecture. Geneva, 2005. 111 p.
INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 61499-2: Functionblocks – Part 2: Software tool requirements. Geneva, 2005. 41 p.
INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 61499-3: Functionblocks for industrial-process measurement and control systems – Part 3: Tutorialinformation. Geneva, 2005. 48 p.
MAHALIK, N. G. P. C.; LEE, S. K. A study on production line automation withLonWorksTM control networks. Computer Standards & Interfaces, [S. l.], v. 24, p.21-27, 2002. Disponível em: <http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6TYV-44KVXKV-1-9&_cdi=5628&_user=5674931&_orig=search&_coverDate=03%2F31%2F2002&_sk=999759998&view=c&wchp=dGLbVtz-zSkzS&md5=2721fa88f8c35f76ccd998c1164c46e9&ie=/sdarticle.pdf>. Acesso em: 10 abr. 2007.
188
MAHALIK, N. G. P. C.; LEE, S. K. Design and development of system level softwaretool for DCS simulation. Advances in Engineering Software, [S. l.], v. 34, p.451-465, 2003.
NERSON, J.-M. Applying Object-Oriented Analysis and Design. Communications ofthe ACM, [S. l.], v. 35, p. 63-74, set. 1992. Número 9. Disponível em:<http://delivery.acm.org/10.1145/140000/130997/p63-nerson.pdf?key1=130997&key2=0286990811&coll=GUIDE&dl=GUIDE,ACM&CFID=20458071&CFTOKEN=63249700>. Acesso em: 5 abr. 2007.
NEUMANN, P. Communication in industrial automation — What is going on?.Control Engineering Practice, [S. l.], v. 15, p. 1332-1347, nov. 2007. Disponívelem: <http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6V2H-4MJBTHB-1-1&_cdi=5703&_user=10&_orig=search&_coverDate=11%2F30%2F2007&_sk=999849988&view=c&wchp=dGLbVlz-zSkzS&md5=cc15ae606bb482b77a8b1f9befdeae9c&ie=/sdarticle.pdf>. Acesso em: 28 mar. 2007.
OBJECT MANAGEMENT GROUP. Unified Modeling Language: Infrastructure. [S.l.], fev. 2007. 732 p. Disponível em: <http://www.omg.org/cgi-bin/apps/doc?formal/07-02-06.pdf>. Acesso em: 5 abr. 2007.
OGATA, K. Introdução a Sistemas de Controle. Tradução de André Fábio Kohn;José Carlos Teixeira de Barros Moraes. In: ______. Engenharia de ControleModerno. Rio de Janeiro: Prentice/Hall do Brasil, 1982, p. 1-16.
PANJAITAN, S.; FREY, G. Functional Design for IEC 61499 Distributed ControlSystems using UML Activity Diagrams. In: 2005 INTERNATIONAL CONFERENCEON INSTRUMENTATION, COMMUNICATIONS AND INFORMATIONTECHNOLOGY (ICICI), 2005, Bandung. Proceedings... [S. l.: s. n.], 2005. p. 64-70.Disponível em: <http://www.eit.uni-kl.de/frey/papers/PDF/Acc01.pdf>. Acesso em: 21ago. 2007.
PANJAITAN, S.; FREY, G. Combination of UML Modeling and the IEC 61499Function Block Concept for the Development of Distributed Automation Systems. In:2006 IEEE INTERNATIONAL CONFERENCE ON EMERGING TECHNOLOGIESAND FACTORY AUTOMATION (ETFA '06), 2006, Prague. Proceedings... [S. l.]:IEEE, 2006. p. 766-773, 2006. Disponível em: <http://ieeexplore.ieee.org/iel5/4178170/4178171/04178238.pdf?tp=&isnumber=&arnumber=4178238>. Acesso em:21 jun. 2007.
PANJAITAN, S.; FREY, G. Designing Generic/Reusable Functionality BasedControllers for Distributed Control using UML. In: 2006 IEEE INTERNATIONALCONFERENCE ON ROBOTICS AND AUTOMATION, 2006, Orlando.
189
Proceedings... [S. l.]: IEEE, 2006. p. 321-326. Disponível em: <http://ieeexplore.ieee.org/iel5/10932/34383/01641731.pdf?tp=&isnumber=&arnumber=1641731>.Acesso em: 20 ago. 2007.
RASKIN, S.; DUBININ, V. IEC61499 converter. v. 2.0. 2004. Disponível em:<http://alice.stup.ac.ru/~dvn/fb61499/uml_fb/converters/raskin/FBtoUMLconverter_v15_July_12_2004.zip>. Acesso em: 21 ago. 2007.
SAMAD, T.; MCLAUGHLIN, P.; LU, J. System architecture for process automation:Review and trends. Journal of Process Control, [S. l.], v. 17, p. 191-201, 2007.Disponível em: <http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6V4N-4MVDVG1-1-1&_cdi=5763&_user=5674931&_orig=search&_coverDate=03%2F31%2F2007&_sk=999829996&view=c&wchp=dGLbVzb-zSkzk&md5=97831b0cfbc422cc789ae4db43e97924&ie=/sdarticle.pdf>. Acesso em: 29 mar. 2007.
SANTOS, J. J. H. Generalidades sobre automação. In: ______. Automaçãoindustrial. Rio de Janeiro: Livros Técnicos e Científicos, 1979. p. 1-23.
SOFTWARE ENGINEERING GROUP. Archimedes ESS 0.8 User's Guide. Patras:Software Engineering Group, Electrical & Computer Engineering, University ofPatras, 27 jan. 2005. 17 p. Disponível em: <http://seg.ee.upatras.gr/mim/ArchimedesESSUsersGuide1_2.pdf>. Acesso em: 14 ago. 2007.
SOFTWARE ENGINEERING GROUP. CORFU ESS. Version 1.0.0. 2006. Disponívelem: <http://seg.ee.upatras.gr/corfu/dev/files/corfu_ess_distribution_1.0.0.exe>.Acesso em: 21 jun. 2007.
SPARX SYSTEMS PTY LTD. UML 2.1 Tutorial. 2008. Disponível em:<http://www.sparxsystems.com.au/resources/uml2_tutorial/index.html>. Acesso em:10 jan. 2008.
THE UNIVERSITY OF AUCKLAND, RESEARCH CENTRE FOR EMBEDDEDINTELLIGENCE – CEMBI. FBench Project: Home. [S. l.]: The University ofAuckland, Research Centre for Embedded Intelligence – CEMBI, 2007. Página daInternet sobre o projeto FBench. Disponível em: <http://www.ece.auckland.ac.nz/%7Evyatkin/fbench/index.html>. Acesso em: 21 jun. 2007.
THRAMBOULIDIS, K. Using UML for the Development of Distributed IndustrialProcess Measurement and Control Systems. In: 2001 IEEE INTERNATIONALCONFERENCE ON CONTROL APPLICATIONS, 2001, México City. Proceedings...[S. l.]: IEEE, 2001. p. 1129-1134. Disponível em: <http://ieeexplore.ieee.org/iel5/7676/20975/00974023.pdf?tp=&isnumber=&arnumber=974023>. Acesso em: 30ago. 2007.
190
THRAMBOULIDIS, K. C. Towards an Engineering Tool for Implementing ReusableDistributed Control Systems. In: EUROPEAN SOFTWARE ENGINEERINGCONFERENCE / ACM SIGSOFT INTERNATIONAL SYMPOSIUM ONFOUNDATIONS OF SOFTWARE ENGINEERING, 2003, Helsinki. Proceedings...[S. l.]: ACM, 2003. p. 351-354. Disponível em: <http://portal.acm.org/ft_gateway.cfm?id=940119&type=pdf&coll=GUIDE&dl=GUIDE&CFID=25603290&CFTOKEN=82547824>. Acesso em: 18 abr. 2007.
TOURANDOVERCONTROLS. Menta_forHVAC.pdf: Descrição técnica-comercial daferramenta TAC MentaTM. [S. l.], 2006. Disponível em: <http://www.tac.com/data/internal/data/05/01/1169217918962/Menta_forHVAC.pdf>. Acesso em: 21 jul. 2007.
TRANORIS, C. (Ed.). CORFU FBDK: Quick Start Guide, v. 0.8. Patras: SoftwareEngineering Group, 2003. 27 p. Disponível em: <http://seg.ee.upatras.gr/corfu/dev/CORFU_FBDK_Quick_Guide.pdf>. Acesso em: 21 jun. 2007.
TRANORIS, C.; THRAMBOULIDIS, K. From requirements to function blockdiagrams: a new approach for the design of industrial control applications. In:MEDITERRANEAN CONFERENCE ON CONTROL AND AUTOMATION, 10., 2002,Lisbon. Proceedings... [S. l.: s. n.], 2002. Disponível em: <http://med.ee.nd.edu/MED10-2002/pdf/392.pdf>. Acesso em: 21 ago. 2007.
TRANORIS, C.; THRAMBOULIDIS, K. An IEC-compliant Engineering Tool forDistributed Control Applications. In: MEDITERRANEAN CONFERENCE ONCONTROL AND AUTOMATION (MED '03), 11., 2003, Rhodes. [S. l.: s. n.], 2003. p.1-6. Disponível em: <http://seg.ee.upatras.gr/thrambo/dev/Papers/MED-03paper.pdf>. Acesso em: 21 jun. 2007.
TRANORIS, C.; THRAMBOULIDIS, K. Integrating UML and the Function BlockConcept for the Development of Distributed Control Applications. In: 2003 IEEEINTERNATIONAL CONFERENCE ON EMERGING TECHNOLOGIES ANDFACTORY AUTOMATION, 2003, [S. l.]. Proceedings... [S. l.]: IEEE, 2003. p. 87-94.Disponível em: <http://ieeexplore.ieee.org/iel5/8826/27958/01248674.pdf?tp=&isnumber=&arnumber=1248674>. Acesso em: 21 jun. 2007.
VISUALCONTROL, LLC. VisualControl%20brochure%2002-20-03_r01.pdf:Descrição técnica-comercial da suíte de ferramentas VisualControlTM. FairviewHeights, 2003. Disponível em: <http://www.smartcontrols.us/smartControls/scvc/VisualControl%20brochure%2002-20-03_r01.pdf>. Acesso em: 3 mai. 2007.
VYATKIN, V. ViVe – the Visual Verifier. [S. l.: s. n.], 2007. 3 p. Disponível em:<http://www.ece.auckland.ac.nz/~vyatkin/tools/VisualVerifier.pdf>. Acesso em: 12nov. 2007.
191
WANG, S. et al. Investigation on intelligent building standard communicationprotocols and application of IT technologies. Automation in Construction, [S. l.], v.13, p. 607-619, 2004. Disponível em: <http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6V20-4CJCYBD-1-1&_cdi=5688&_user=5674931&_orig=search&_coverDate=09%2F30%2F2004&_sk=999869994&view=c&wchp=dGLbVzW-zSkzS&md5=e965bc994e953773fd8074608343baf1&ie=/sdarticle.pdf>. Acesso em:10 abr. 2007.
WONG, J. K. W.; LI, H.; WANG, S. W. Intelligent building research: a review.Automation in Construction, [S. l.], v. 14, p. 143-159, 2005. Disponível em: <http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6V20-4D5JYDY-1-1&_cdi=5688&_user=5674931&_orig=search&_coverDate=01%2F31%2F2005&_sk=999859998&view=c&wchp=dGLzVzz-zSkzV&md5=0b64b1dc7bdca745cdd5804aa7b13877&ie=/sdarticle.pdf>. Acesso em: 10 abr. 2007.
XIE, C.; PU, J.-S.; MOORE, P. R. A case study on the development of intelligentactuator components for distributed control systems using LONWORK neuron chips.Mechatronics, [S. l.], v. 8, p. 103-119, 1998. Disponível em: <http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6V43-3TB05XD-2-1&_cdi=5747&_user=5674931&_orig=search&_coverDate=03%2F31%2F1998&_sk=999919997&view=c&wchp=dGLbVlz-zSkWA&md5=13218e3227000db3db760276573636df&ie=/sdarticle.pdf>. Acesso em: 10 abr. 2007.
YOURDON, E. Análise estruturada moderna. Tradução Dalton Conde de Alencar.13 ed. Rio de Janeiro: Campus, 1990. 836 p. (Série Yourdon Press).
YOURDON, E; ARGILA, C. Introdução. In: ______. Análise e projeto orientados aobjetos: estudos de casos. Tradução Angelita Carvalho Gomes; Alvaro Antunes.São Paulo: MAKRON Books, 1999. p. 1-18.
ZHANG, W.; DIEDRICH, C.; HALANG, W. A. Specification of Function BlockApplications with UML. In: 2005 IEEE INTERNATIONAL CONFERENCE ONROBOTICS AND AUTOMATION, 2005, Barcelona. Proceedings... [S. l.]: IEEE,2005. p. 4002-4007. Disponível em: <http://ieeexplore.ieee.org/iel5/10495/33250/01570733.pdf?arnumber=1570733>. Acesso em: 21 ago. 2007.
ZOITL, A.; STRASSER, T. Modelling Distributed Control Systems within 4DIACbased on IEC 61499. [S. l.]: 4DIAC Consortium, 2007. 68 p. Tutorial em formato detransparências. Disponível em: <http://www.fordiac.org/fileadmin/user_upload/4DIAC_Tutorial.pdf>. Acesso em: 12 nov. 2007.
192
ANEXO A – Figuras complementares referentes aos modelos de
referência da norma IEC 61499
As figuras a seguir foram retiradas de Christensen (2002) e traduzidas para
a língua portuguesa. Essas mesmas ilustrações estão presentes na Parte 1 da
norma IEC 61499 (INTERNATIONAL ELECTROTECHNICAL COMMISSION,
2005a), e são utilizadas nesta dissertação para tornar mais claros os conceitos
relacionados aos modelos de referência da norma IEC 61499.
Figura 58: Arquitetura de um dispositivo.
Figura 59: Arquitetura de um recurso.
193
Figura 60: Arquitetura de um sistema distribuído segundo a norma IEC 61499.