CNC-C: Um Controlador Aderente Às Normas ISO 14649 E IEC 61499

UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC
CENTRO DE CIÊNCIAS TECNOLÓGICAS – CCT

DEPARTAMENTO DE ENGENHARIA ELÉTRICA – DEE
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA – PPGEEL
EDUARDO HARBS
CNC-C2: UM CONTROLADOR ADERENTE ÀS NORMAS

ISO 14649 E IEC 61499
Joinville
2012
UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC
CENTRO DE CIÊNCIAS TECNOLÓGICAS – CCT
DEPARTAMENTO DE ENGENHARIA ELÉTRICA – DEE
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA – PPGEEL
EDUARDO HARBS
CNC-C2: UM CONTROLADOR ADERENTE ÀS NORMAS

ISO 14649 E IEC 61499
Dissertação submetida à Universidade do Estado

de Santa Catarina como parte dos requisitos para a
obtenção do grau de Mestre em Engenharia Elétrica
Orientador: PhD. Roberto Silvio Ubertino Rosso

Jr.
Coorientador: PhD. Marcelo da Silva Hounsell
Joinville
2012
EDUARDO HARBS
CNC-C2 : UM CONTROLADOR ADERENTE ÀS NORMAS ISO 14649

E IEC 61499
Esta Dissertação foi julgada adequada para a obtenção do título de Mestre em Engenharia Elétrica
e aprovada em sua forma final pelo Curso de Mestrado Profissional em Engenharia Elétrica do
CCT/UDESC.
Banca Examinadora:
Orientador/
Presidente:
PhD., Roberto Silvio Ubertino Rosso Jr.

UDESC
Coorientador/
Suplente:
PhD., Marcelo da Silva Hounsell

UDESC
Membro:
Dr., André Bittencourt Leal

UDESC
Membro:
PhD., João Carlos Espíndola Ferreira

UFSC
Membro:
PhD., Neri Volpato

UTFPR
Joinville, 9 de Outubro de 2012
Este trabalho está dedicado à Deus,
Quem sempre tem sido fiel para co-
migo, aos meus pais Lodemar e Ma-
ria pelo amor e dedicação incondi-
cional, à minha esposa Tatiane pelo
amor, apoio e compreensão dedica-
dos neste período.
AGRADECIMENTOS
Ao meu orientador, professor Roberto Silvio Ubertino Rosso Jr., pela sua colaboração,
incentivo e conversas esclarecedoras no desenvolvimento deste trabalho. Ao professor Marcelo
da Silva Hounsell, coorientador, pelo apoio e questionamentos.
Aos meus pais Lodemar Harbs e Maria Harbs pelo grande amor e incentivo dados.
À minha esposa Tatiane pelo incentivo, amor e compreensão nos momentos de dificuldade
ao longo dessa caminhada.
À minha irmã Sandra e meu cunhado Daniel pelo incentivo.
Aos professores e amigos André Bittencourt Leal e Fernando Lafratta.
Ao Sr. Dietmar Erich Bernhard Lilie pela doação da estrutura mecânica da máquina junto ao
Prof. Fernando Lafratta.
Ao aluno do curso de ciência da computação, ex-bolsista do grupo, Allan Yoshio Hasegawa,

pelo trabalho desenvolvido na construção do front-end do compilador.
Ao bolsista Guilherme Jarentchuk pelo apoio e trabalho desenvolvido na construção do

editor de modelos IEC 61499 e algorítmos de geração de trajetórias.
Ao bolsista Gabriel Negri pelo apoio e trabalho desenvolvido na construção das ferramentas
de visualização e execução aderentes a IEC 61499.
Aos colegas de laboratório Yuri K. Lopes, Lucas H. Negri, Rodrigo Trentini, Renan Sebem
e Thiago Oliveira.
Uma máquina pode fazer o trabalho
de 50 pessoas comuns. Nenhuma
máquina pode fazer o trabalho de
uma pessoa extraordinária.
– Elbert Hubbard
RESUMO
HARBS, Eduardo. CNC-C2 : Um Controlador Aderente às Normas ISO 14649 e IEC 61499.
2012. 156 f. Dissertação (Mestrado Profissional em Engenharia Elétrica – Área: Automação
de Sistemas) – Universidade do Estado de Santa Catarina, Programa de Pós-Graduação em
Engenharia Elétrica, Joinville, 2012.
A indústria tem enfrentado dificuldades quanto à flexibilidade das máquinas CNC, devido
à norma utilizada atualmente para a programação CNC, a ISO 6983 ou código G/M. Com
objetivo de substituição desta norma, desenvolveu-se a ISO 14649 ou STEP-NC, que é um
novo modelo de transferência de dados unificado entre sistemas CAD/CAM e CNC. Para
atender os novos requisitos de automação e controle de sistemas, desenvolveu-se a norma
IEC 61499, visando o uso de objetos de software, os function blocks (FBs). Neste trabalho
integraram-se as normas STEP-NC e IEC 61499 para a construção de uma nova geração de
CNCs, onde STEP-NC fornece o modelo de dados completo, porém sem funcionalidade, e os
FBs fornecem as funcionalidades ao modelo de dados para o controle da máquina-ferramenta.
Para tal, foi desenvolvido um controlador para uma máquina CNC protótipo aderente às normas
STEP-NC e IEC 61499. Este protótipo é constituído de uma fresadora 2,5D, acionada por
um conjunto de três servoacionamentos com CLPs integrados. Um conjunto de software foi
desenvolvido para compilação do arquivo STEP-NC e geração automática de modelos IEC
61499, visualização, edição e execução de FBs e rede de FBs além de uma biblioteca de
modelos IEC 61499. Teste do software e do protótipo foi realizado com a usinagem de uma peça
exemplo, alcançando o objetivo proposto e provendo as características individuais das normas
no controlador, como: interoperabilidade, portabilidade, uso de features, configurabilidade,
distribuição e adaptabilidade.
Palavras-chave: STEP-NC, Function Block, Controlador Numérico Computadorizado, intero-

perabilidade, integração.
ABSTRACT
HARBS, Eduardo. CNC-C2 : Um Controlador Aderente às Normas ISO 14649 e IEC 61499.
2012. 156 f. Dissertação (Mestrado Profissional em Engenharia Elétrica – Área: Automação
de Sistemas) – Universidade do Estado de Santa Catarina, Programa de Pós-Graduação em
Engenharia Elétrica, Joinville, 2012.
The industry has found difficulties towards CNC machines flexibility, due to the CNC program-
ming current standard, the ISO 6983 or G/M code. The ISO 14649 or STEP-NC was developed
to replace the current standard. It is a new unified data transfer model between CAD/CAM and
CNC systems. To satisfy the new automation and control systems requirements, the IEC 61499
standard was developed, aiming the use of software objects, called function blocks (FBs). In this
work, the standards STEP-NC and IEC 61499 were integrated to build a new generation of CNC,
where STEP-NC supplies the complete data model without functionality, and the FBs provide
the functionalities to the data model for the machine tool command. In this context, a controller
for a CNC machine prototype, compliant to STEP-NC and IEC 61499 standards was developed.
The prototype consists of a 2,5D milling machine, driven by a group of three servomotors drivers
with integrated PLCs. A set of software was developed for compiling STEP-NC files and the
automatic generation of IEC 61499 models, viewing, editing and executing FBs and FB networks,
and further a library with IEC 61499 models. Test on software and prototype was performed
machining an example workpiece, achieving the proposed goal and providing the individual
characteristics of the standards in the controller, such as: interoperability, portability, use of
features, configurability, distribution and adaptability.
Keywords: STEP-NC, Function Block, Computer Numerical Control, interoperability, integra-

tion.
LISTA DE FIGURAS
2.1 Exemplo de linha de programa em ISO 6983 . . . . . . . . . . . . . . . . . . . 34
2.2 Diferença de fluxo de informação com o uso do código G/M e com o uso de
STEP-NC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.3 Descrição geral do modelo de dados . . . . . . . . . . . . . . . . . . . . . . . 38
2.4 Relação entre ISO 10303 e ISO 14649 . . . . . . . . . . . . . . . . . . . . . . 39
2.5 Estrutura de um arquivo físico STEP-NC . . . . . . . . . . . . . . . . . . . . . 41
2.6 Estrutura hierárquica de um arquivo STEP-NC . . . . . . . . . . . . . . . . . 42
3.1 Características gerais do modelo de FB . . . . . . . . . . . . . . . . . . . . . . 48
3.2 Bloco de Função Básico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.3 Bloco de Função Composto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.4 Bloco de função de serviço de interface PUBLISH . . . . . . . . . . . . . . . 53
3.5 Bloco de função de serviço de interface SUBSCRIBE . . . . . . . . . . . . . . 53
3.6 Inicialização da interação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.7 Transferência de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.8 Modelo de Aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.9 Modelo de Recurso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.10 Modelo de Dispositivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.11 Funcionalidade do Dispositivo de Classe 0 . . . . . . . . . . . . . . . . . . . . 58
3.14 Modelo de Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.1 Arquitetura típica de um CNC e seus periféricos . . . . . . . . . . . . . . . . . 62
4.2 Nova arquitetura de um CNC e seus periféricos . . . . . . . . . . . . . . . . . 62

5.1 Controlador CNC proposto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.2 Arquitetura aberta desenvolvida . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.3 Arquitetura proposta e fluxo de dados da STEPNCMillUoA . . . . . . . . . . . 85
5.4 Controlador baseado em PC . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.1 Estrutura do CNC-C2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.2 Representação de um modelo EXPRESS e um modelo UML usado para mapear

Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.3 Arquitetura do compilador desenvolvido . . . . . . . . . . . . . . . . . . . . . 96
6.4 Objetos usados para trocar mensagens entre componentes do compilador e o

usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
6.5 Exceptions do compilador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
6.6 Componente da análise sintática . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.7 Árvore sintática gerada pelo JavaCC + JJTree . . . . . . . . . . . . . . . . . . 99
6.8 Componente da análise semântica . . . . . . . . . . . . . . . . . . . . . . . . 100
6.9 Diagrama de classes mostrando as classes principais . . . . . . . . . . . . . . . 100
6.10 Diagrama de sequência: interação com o usuário . . . . . . . . . . . . . . . . . 101
6.11 Diagrama de sequência: método Compile . . . . . . . . . . . . . . . . . . . . 101
6.12 Diagrama de sequência: método runSyntacticAnalysis . . . . . . . . . . . . . . 102
6.13 Diagrama de sequência: new EntityTO . . . . . . . . . . . . . . . . . . . . . . 103
6.14 Diagrama de sequência: método runSemanticAnalysis . . . . . . . . . . . . . . 104
6.15 Trecho de código desenvolvido para a aplicação da back-end . . . . . . . . . . 105
6.16 Exemplo de um arquivo system genérico da linguagem de marcação XML gerado

a partir do back-end do compilador . . . . . . . . . . . . . . . . . . . . . . . . 106
6.17 Exemplo de funcionamento do resource STEP-NC_DATA desenvolvido . . . . 107
6.18 Interface gráfica para utilização do compilador desenvolvido, integrado com o

ambiente de visualização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
6.19 Ambiente de visualização de FBs e rede de FBs desenvolvido neste trabalho . . 109
6.20 Interface gráfica do editor desenvolvido neste trabalho (aba selecionada FB Básico)112
6.21 Caixa de texto para visualização da estrutura XML gerada pelo editor desenvolvido113
6.22 Proposta de utilização da rede CAN para comunicação entre os equipamentos

constituintes da rede. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
6.23 Proposta de utilização da rede RS485 para comunicação entre os equipamentos

constituintes da rede. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
6.24 Proposta de utilização do gerenciador de comunicação para transeferência de

dados entre os equipamentos constituintes da rede . . . . . . . . . . . . . . . . 117
6.25 Diagrama geral da configuração da rede CAN construída . . . . . . . . . . . . 118
6.26 Máquina e protótipo de controlador construído . . . . . . . . . . . . . . . . . . 118
6.27 Estrutura de dados gerais construída para comunicação CAN . . . . . . . . . . 119
6.28 Estrutura de dados específicos por eixo construída para comunicação CAN . . . 119
6.29 Fluxograma base da programação Ladder desenvolvida . . . . . . . . . . . . . 120
7.1 Projeto da peça utilizada nos testes . . . . . . . . . . . . . . . . . . . . . . . . 121
7.2 Ocorrência de um Exception durante a compilação do arquivo exemplo . . . . . 122
7.3 Entidade CUTTING_COMPONENT definida pelo modelo de dados STEP-NC . 123
7.4 Visualização gráfica da trajetório de usinagem . . . . . . . . . . . . . . . . . . 125
7.5 Peça exemplo usinada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Lista de Abreviaturas
AIM Application Interpreted Model
AP Application Protocol
ARM Application Reference Model
CAD Computer Aided Design - Desenho Auxiliado por Computador
CAE Computer Aided Engineering - Engenharia Auxiliada por Computador
CAM Computer Aided Manufacturing - Manufatura Auxiliada por Computador
CAPP Computer Aided Process Planning - Planejamento do Processo Auxiliado por

Computador
CAx Computer Aided technologies
CIM Computer Integrated Manufacturing - Manufatura Integrada por Computador
CL Cutter Location
CLP Controlador Lógico Programável
CNC Computer Numerical Control - Controlador Numérico Computadorizado
dIPMCS distributed Industrial-Process Measurement and Control Systems - Processos

industriais, de medição e de controle distribuídos
DPP Distributed Process Planning
ECC Execution Control Chart - Gráfico de Controle de Execução
EDM Electrical Discharge Machining
FB Function Block - Bloco de Função
FBRT Function Block Run Time
FIFO First In, First Out
FMC Flexible Manufacturing Cells - Célula Flexível de Manufatura

FMS Flexible Manufacturing Systems - Sistemas Flexíveis de Manufatura
IA Inteligência Artificial
IEC International Electrotechnical Commission
IGES Initial Graphics Exchange Standard
ISO International Organization for Standardization
MIT Massachusetts Institute of Technology
MVC Model-View-Control
NC Numerical Control - Controlador Numérico
PDOs Process Data Objects
SCADA Supervisory Control and Data Acquisition - Sistemas de Supervisão e Aquisição

de Dados
SDAI STEP Data Access Interface
SET Standard d’Exchange et de Transfer
STEP STandard for the Exchange of Product model data (ISO 10303)
STEP-NC STandard for the Exchange of Product model data for Numerical Control (ISO
14649)
TO Transaction Objects
UML Unified Modeling Language
VDA Verdand des Automobilindustrie
XML eXtensible Markup Language

SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.1 OBJETIVOS DO TRABALHO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.1.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.1.2 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.2 DELIMITAÇÃO DO TRABALHO . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.3 ESTRUTURA DA DISSERTAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2 TRANSFERÊNCIA DE DADOS NA MANUFATURA . . . . . . . . . . . . . . . . 28
2.1 MODELO DA INDÚSTRIA DE MANUFATURA . . . . . . . . . . . . . . . . . . 28
2.2 TROCA DE DADOS NOS SISTEMAS DE MANUFATURA . . . . . . . . . . . . 28
2.2.1 Troca de dados entre CAD e CAM . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3 ISO 10303 OU STEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3.1 Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3.2 Estrutura STEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.4 TROCA DE DADOS ENTRE CAM E CNC . . . . . . . . . . . . . . . . . . . . . 32
2.4.1 O Código G/M (ISO 6983) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.5 ISO 14649 OU STEP-NC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.5.1 Estrutura da Norma STEP-NC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.5.2 Arquivo Físico STEP-NC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3 AUTOMAÇÃO DA MANUFATURA . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.1 EVOLUÇÃO DAS TÉCNICAS DE CONTROLE . . . . . . . . . . . . . . . . . . . 43
3.2 PROGRAMAÇÃO DE CLP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3 COMPARATIVO ENTRE AS NORMAS IEC 61131 E IEC 61499 . . . . . . . . . 45
3.4 IEC 61499 - MODELOS E CONCEITOS . . . . . . . . . . . . . . . . . . . . . . . 46
3.4.1 Modelo de Blocos de Funções . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.4.2 Tipos de Blocos de Funções . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.4.2.1 Bloco de Função Tipo Básico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.4.2.2 Bloco de Função Tipo Composto . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.4.2.3 FB Tipo Serviço de Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.4.3 Modelo de Aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.4.4 Modelo de Recurso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.4.5 Modelo do Dispositivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.4.6 Modelo do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.5 FORMATO DO ARQUIVO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4 TECNOLOGIAS CORRELATAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.1 ARQUITETURA DE UMA MÁQUINA CNC . . . . . . . . . . . . . . . . . . . . 61
4.2 COMPILADOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.3 SERVOACIONAMENTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.3.1 Servomotor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.3.2 Servoconversor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.4 PROGRAMAS DE COMPUTADOR EXISTENTES ADERENTES A NORMA IEC

61499 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.4.1 Ferramenta nxtStudio - IEC61499 e SCADA . . . . . . . . . . . . . . . . . . . . 67
4.4.2 Sistema UML e FBs - CORFU FBDK . . . . . . . . . . . . . . . . . . . . . . . . 68
4.4.3 Ferramenta aderente a IEC 61499 junto com IEC 61131 - ISaGRAF . . . . . . . . 69
4.4.4 Ambiente de Execução Fuber . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.4.5 Estrutura 4DIAC-RTE e 4DIAC-IDE . . . . . . . . . . . . . . . . . . . . . . . . 70
4.4.6 FBDK e FBRT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.4.7 FBench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5 TRABALHOS RELACIONADAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.1 TRABALHOS RELACIONADOS AO USO DO MODELO DE DADOS STEP-NC 74
5.1.1 Sistema aderente a STEP-NC para torneamento . . . . . . . . . . . . . . . . . . . 74
5.1.2 STEP-NC para a geração atual de CNC . . . . . . . . . . . . . . . . . . . . . . . 75
5.1.3 Simulador de Fresadora baseado em STEP-NC . . . . . . . . . . . . . . . . . . . 76
5.1.4 Controlador CNC Aderente a STEP-NC . . . . . . . . . . . . . . . . . . . . . . . 76
5.1.5 Aplicando STEP-NC diretamente na máquina CNC . . . . . . . . . . . . . . . . . 78
5.2 TRABALHOS RELACIONADOS AO USO DA NORMA IEC 61499 . . . . . . . . 80
5.2.1 Plano de Processo em Blocos de Funções . . . . . . . . . . . . . . . . . . . . . . 80
5.2.2 Monitoramento e usinagem remota utilizando FBs . . . . . . . . . . . . . . . . . 81
5.3 TRABALHOS RELACIONADOS AO USO INTEGRADO DAS NORMAS STEP-

NC E IEC 61499 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.3.1 STEP-NC e FBs para uma manufatura interoperável . . . . . . . . . . . . . . . . 82
5.3.2 Aumetando a interoperabilidade da usinagem CNC com STEP-NC . . . . . . . . 82
5.3.3 CNC baseado em STEP-NC e FBs IEC 61499 . . . . . . . . . . . . . . . . . . . 83
5.3.4 Sistema CNC baseado em STEP-NC e arquitetura de FBs . . . . . . . . . . . . . 84
5.3.5 Uso de features e FBs na usinagem CNC . . . . . . . . . . . . . . . . . . . . . . 86
5.3.6 Integração das normas ISO 14649 e IEC 61499 para a construção de um CNC
interoperável . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.4 DISCUSSÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6 CNC-C2 : UM CNC INTEROPERÁVEL . . . . . . . . . . . . . . . . . . . . . . . 91
6.1 SOLUÇÃO PARA INTEGRAÇÃO DAS NORMAS . . . . . . . . . . . . . . . . . 91
6.2 ESTRUTURA DA MÁQUINA-FERRAMENTA E CNC-C2 . . . . . . . . . . . . . 92
6.2.1 Item 1 - Arquivo STEP-NC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.2.2 Item 2 - Compilador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.2.2.1 Front-end do compilador desenvolvido . . . . . . . . . . . . . . . . . . . . . . . 94
6.2.2.2 Back-end do compilador desenvolvido . . . . . . . . . . . . . . . . . . . . . . . 100

6.2.3 Item 3 - Arquivo XML IEC 61499 . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.2.4 Item 4 - Visualização e Ambiente de Execução da Rede de FBs . . . . . . . . . . 108
6.2.5 Item 5 - GASR FB Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.2.6 Item 6 - Biblioteca de FBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
6.2.7 Item 7 - Rede de Comunicação PC-CNC . . . . . . . . . . . . . . . . . . . . . . 114
6.2.8 Item 8 - Máquina . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
7 TESTES E DISCUSSÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
7.1 ARQUIVO DE ENTRADA STEP-NC, COMPILADOR E ARQUIVOS XML GE-

RADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
7.2 EDITOR DE FBS E BIBLIOTECA DE BLOCOS DE FUNÇÃO . . . . . . . . . . . 123
7.3 VISUALIZADOR E AMBIENTE DE EXECUÇÃO . . . . . . . . . . . . . . . . . 124
7.4 REDE DE COMUNICAÇÃO, CLP E MÁQUINA-FERRAMENTA . . . . . . . . . 124
7.5 PEÇA USINADA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
7.6 DISCUSSÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
8 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
8.1 TRABALHOS FUTUROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
APÊNDICE A - GASR FB EDITOR: GUIA DO USUÁRIO . . . . . . . . . . . . 141
APÊNDICE B - ARQUIVO STEP-NC CONSTRUÍDO PARA TESTE . . . . . . . 147
APÊNDICE C - ARQUIVO XML SYSTEM GERADO . . . . . . . . . . . . . . . 153
APÊNDICE D - TRECHO DO ARQUIVO RELATÓRIO DO AMBIENTE DE

EXECUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
19
1 Introdução
Uma série de mudanças revolucionárias na configuração de sistemas de manufatura ocorreram
desde o sistema de produção artesanal até os sistemas utilizados atualmente. No início do
século XX surgiu a mais conhecida e tradicional configuração de um sistema de manufatura, o
sistema de produção em massa (transfer line), o qual permite uma alta eficiência (quantidade)
e um baixo custo de produção (XU; NEWMAN, 2006). Na década de 1950 foi desenvolvida
a primeira máquina NC (Controle Numérico) no Massachussets Institute of Technology, onde
possibilitava a reprogramação para usinagem de diferentes peças. Durante os anos de 1980,
percebeu-se um consumidor mais sofisticado e um aumento na concorrência internacional, o
que fez com que os fabricantes tivessem que mudar o seu foco. Consumidores mais exigentes
começaram a buscar produtos com mais variedades, baixo preço e alta qualidade. Isto resultou na
mudança dos conceitos dos fabricantes, onde buscaram não somente uma produção eficiente, mas
acrescentaram flexibilidade à produção e capacidade de resposta aos anseios dos consumidores.
Estas características são essenciais para a indústria atual, que necessita possuí-las para se manter
competitiva no mercado globalizado (CHOUINARD; BRENNAN, 2006; WANG; JIN; FENG,
2006).
Na busca por um sistema flexível de produção, o CNC (Computer Numerical Control - Con-
trolador Numérico Computadorizado) tornou-se o elemento central dos sistemas de manufatura,
tais como linhas de transferência flexível, FMC (Flexible Manufacturing Cells - Célula Flexível
de Manufatura), FMS (Flexible Manufacturing Systems - Sistemas Flexíveis de Manufatura) e
também de maneira isolada. O CNC proporcionou à indústria mais agilidade na produção de
pequenos lotes de diferentes tipos de peças por possibilitar a reprogramação para usinagem.
Desde a década de 1970 o CNC teve uma evolução significativa, tonando-se mais automático e
confiável, adicionando novos processos e proporcionando a capacidade de produção multi-eixos,
multi-ferramentas e multi-processos (ROSSO Jr.; ALLEN; NEWMAN, 2002; CALABRESE;
CELENTANO, 2007). A caracterítica conceitual do CNC de ser flexível e a evolução estrutural
das máquinas-ferramentas, têm revelado à indústria uma deficiência na questão da programação
CNC. A norma atual para programas NC (Numerical Control - Controlador Numérico) utiliza
comandos que não mudaram de maneira significativa desde a década de 1950 quando a primeira
máquina NC foi desenvolvida no MIT (Massachusetts Institute of Technology). Assim como
1 Introdução 20
as primeiras máquinas NC, as atuais máquinas CNC continuam a usar o mesmo padrão de
programação, normalizado pela ISO 6983:1982, conhecidos como códigos G/M que se baseiam
na descrição dos movimentos da ferramenta. Pelo uso desta linguagem estagnada e antiga, o
controlador do CNC atual é considerado rígido e proprietário, contendo extensões especiais de
cada fabricante de máquina CNC (FINKE Jr., 2011).
A norma ISO 6983 limita a portabilidade do programa por três razões. Primeiramente, a
linguagem foca na programação do caminho do centro da ferramenta em relação aos eixos
da máquina, ao invés do processo de usinagem com relação a peça. Segundo, o padrão define
a sintaxe das instruções do programa, mas na maioria dos casos resulta em uma semântica
ambígua. Terceiro, fabricantes das máquinas CNC complementam a linguagem com exten-
sões não abrangidas no escopo da ISO 6983. Estes programas, quando processados em um
sistema CAM (Computer Aided Manufacturing - Manufatura Auxiliada por Computador) por
um pós-processador específico, tornam-se dependentes da máquina (XU; WANG; RONG, 2006).
Consequentemente, uma máquina CNC pode somente aceitar seu código G/M proprietário, o
qual dificulta e/ou impede a flexibilidade e a interoperabilidade das informações de usinagem
(MINHAT; XU; VYATKIN, 2009).
A fim de preparar as empresas de manufatura para enfrentar as demandas de clientes cada

vez mais exigentes e imprevisíveis, os sistemas de manufatura com CNC interoperáveis podem
ser a chave para alcançar o sucesso. Este tipo de sistema pode ser caracterizado como sendo
capaz de (XU; WANG; RONG, 2006): 1) possibilitar o fluxo de informação bidirecional em todas
as camadas do ciclo de vida do produto; 2) ter usinagem baseada em features1 ; 3) a máquina
CNC ser autônoma; 4) ser tolerante a falhas; 5) ser distribuído; 6) ser modular; 7) ser expansível;
8) ser portável; e 9) adaptável.
De maneira a alterar o cenário atual, devido aos problemas existentes, pesquisas dentro da
área de manufatura integrada, CIM (Computer Integrated Manufacturing - Manufatura Integrada
por Computador), tem buscado soluções com o intuito de proporcionar às empresas de fabricação
um sistema com as características acima. Pesquisas estas em nível de sistema bem como em
nível de componente, por exemplo, controle e máquina.
Em substituição ao código G/M e com o intuito de prencher a lacuna de informação existente

entre o setor de projeto, sistemas computacionais como CAD (Computer Aided Design - Desenho
Auxiliado por Computador), CAPP (Computer Aided Process Planning - Planejamento do
1
Exemplos de features: furo redondo, cavidade, hanhura, etc.
1 Introdução 21
Processo Auxiliado por Computador), CAM e a área de execução, CNC, o comitê técnico TC184
da ISO (International Organization for Standardization) trabalhou na direção de um padrão
unificado para fornecer um modelo para troca de dados entre os mesmos. Baseado no modelo da
ISO 10303 (1994a), conhecida como STEP (STandard for the Exchange of Product model data
(ISO 10303)), desenvolveu-se a ISO 14649 (2003a), ou STEP-NC (STandard for the Exchange
of Product model data for Numerical Control (ISO 14649)). Neste trabalho serão utilizados os
termos STEP-NC e ISO 14649 como sinônimos. Este modelo busca solucionar o defeito da
ISO 6983 não especificando o caminho do centro da ferramenta, mas especificando o processo
de usinagem. Utiliza o conceito de orientação a objetos Workingsteps, que correspondem as
features de usinagem de alto nível e parâmetros de processo associados (ISO, 2003a). Uma das
principais contribuições da tecnologia do uso de features é que estas trazem significado aos
modelos geométricos (ROSSO Jr.; NEWMAN, 2003). O uso deste conceito é útil pela forma
de comunicação, onde são utilizados termos da manufatura, como por exemplo: furos, ilhas e
cavidades e não somente geometrias primitivas como pontos, linhas e curvas. Outra característica
importante do uso do modelo de dados STEP-NC é a possibilidade de fluxo bidirecional das
informações entre o setor de projeto e o chão de fábrica, característica essa desejada em um
sistema interoperável, eliminando assim um dos problemas enfrentados com o uso do código
G/M. Com isso, alterações feitas nos modelos em chão de fábrica podem retornar ao setor de
projeto mantendo assim a integridade das informações do produto ao longo do seu ciclo de vida
(NEWMAN et al., 2008).
O formalismo STEP-NC aumenta a eficiência dos equipamentos de manufatura pela pos-

sibilidade de desenvolvimento de abordagens de programação inteligente e tornam os CNCs e
os softwares mais interoperáveis através da troca de dados de alto nível, sem perdas em toda
a cadeia de produção (RAUCH et al., 2009). A característica da STEP-NC de ser orientada a
objetos, ajuda a deslocar a geração do caminho da ferrramenta para o nível de chão de fábrica,
transferindo para o controlador CNC o poder de tomada de decisões e a responsabilidade pelo
cálculo do caminho da ferramenta, abrindo espaço para métodos avançados de programação,
novas abordagens de simulação e implementação de otimização para obter um melhor controle
do processo de fabricação (WANG; CAI; FENG, 2009).
Cada vez mais, o CNC deve ser flexível, exigindo o controle de sistemas distribuídos, onde
existam vários dispositivos com poder de processamento incorporados em rede para diferentes
áreas de atuação da máquina-ferramenta. Tendo que ser facilmente integrado em sistemas
de automação, interoperar com CLP (Controlador Lógico Programável), outros CNC, robôs,
1 Introdução 22
dispositivos de controle integrado, etc (VYATKIN, 2007). Mesmo tendo uma evolução na
tecnologia de controle de sistemas, como a robótica avançada e os CNC, a complexidade dos
sistemas mostrou a existência de algumas barreiras impostas pelas técnicas de controle atuais
quando se busca a flexibilidade em sistemas cada vez mais distribuídos. O resultado é, muitas
vezes, um conjunto de “ilhas de automação”, faltando uma integração que é necessária para um
comportamento estável e eficiente. Como resultado, novas abordagens de controle de software e
hardware são necessárias para realizar um sistema que seja flexível, capaz de reconfiguração e
sensível à falhas (CHOUINARD; BRENNAN, 2006).
Para satisfazer os novos requisitos de automação e controle de sistemas, de maneira a

proporcionar flexibilidade, adaptabilidade e reconfigurabilidade, foi criada a norma IEC 61499
(GRABMAIR et al., 2007). Desenvolvida pela IEC (International Electrotechnical Commission),
esta norma visa o uso de objetos de software, os FB (Function Block - Bloco de Função),
em dIPMCS (distributed Industrial-Process Measurement and Control Systems - Processos
industriais, de medição e de controle distribuídos) (MINHAT; XU; VYATKIN, 2009). Em
particular, a IEC 61499 é baseada nos FBs da norma IEC 61131 (2003), linguagem padronizada
para CLP, ampliando-a para atender mais adequadamente às exigências de controle distribuído
em um formato que é independente da implementação (CHOUINARD; BRENNAN, 2006). Esta
nova estrutura para o desenvolvimento de sistemas de controle distribuídos, permite também que
novas potencialidades sejam exploradas, tais como a confiabilidade, introduzindo a tolerância a
falhas na arquitetura da aplicação, portabilidade e interoperabilidade (YUSOF; TAN; KASIM,
2009).
O FB é considerado um bloco de software onde são executadas funções básicas de controle

de um sistema distribuído. Cada FB pode ser composto por uma diversidade de outros FBs ou
alternativamente, por diversos algoritmos e por uma máquina de estados ECC (Execution Control
Chart - Gráfico de Controle de Execução). O ECC define os estados internos e as transições
entre estados que devem ser ativadas pela chegada de um evento, podendo também depender do
valor de uma variável. O ECC define ainda os algoritmos, ou fragmentos de código, que devem
ser executados quando o estado é ativado e qual o evento que o algoritmo deve gerar uma vez
terminada a sua execução (SANTOS; SOUSA, 2008).
Com a necessidade da utilização de novas tecnologias de engenharia destinadas a ajudar e

reduzir os esforços de projeto e permitir a reconfiguração mais fácil e rápida de equipamentos,
pode ser utilizada a emergente norma IEC 61499. O objetivo principal desta norma não é o de
1 Introdução 23
servir como uma metodologia de programação, mas sim como um modelo de arquitetura para
sistemas distribuídos (VYATKIN, 2007). O fator motivador para o desenvolvimento desta norma
é a inadequação das atuais técnicas para desenvolvimento de software para sistemas distribuídos
complexos, que garantam flexibilidade e reconfigurabilidade ao sistema (SANTOS; SOUSA,
2008).
A integração das normas ISO 14649 e IEC 61499 pode ser a chave para alcançar um CNC in-
teroperável, e é o grande desafio, possuindo as características citadas de cada norma. A integração
das normas deve ocorrer de forma automática, onde os dados STEP-NC devem ser representados
em redes de FBs em um formato aderente à norma IEC 61499. Essas redes construídas a partir do
modelo de dados STEP-NC, fornecem funcionalidades a esses dados, podendo então comandar
uma máquina ferramenta, eliminando o uso do código G/M, o qual tem dificultado as indústrias
de aproveitarem as vantagens de agilidade nos processos, não utilizando completamente de
avançados recursos computacionais no planejamento, gerenciamento e controle da manufatura.
Tanto a STEP-NC quanto a IEC 61499 são alvo de projetos acadêmicos e da indústria, porém
existem diferentes abordagens não consolidadas utilizando a integração das normas. Há alguns
anos, a pesquisa sobre interoperabilidade na manufatura está em andamento, tanto em nível
de sistema (controle), como em nível de componentes (máquina) (XU; WANG; RONG, 2006).
Vários trabalhos relacionados descrevem tipos de arquiteturas e estruturas visando prover uma
máquina ferramenta CNC cada vez mais flexível e interoperável. Pesquisas apresentam protótipos
que utilizam o padrão STEP-NC como modelo de dados da peça, porém fazem a tradução para
código G/M, podendo assim utilizar de máquinas comerciais existentes (YUSOF; CASE, 2010).
Outras abordagens que utilizam a ISO 14649, porém sem a tradução para linguagem proprietária,
é apresentada por Zhu, Wang e Fu (2006) na construção de uma ferramenta de simulação de
usinagem e apresentada por Calabrese e Celentano (2007) e Pacheco et al. (2011) no acionamento
direto de uma máquina protótipo CNC. Uma estrutura mais recente agrega ao modelo de dados
STEP-NC uma arquitetura na construção do controlador da máquina, que é o uso da IEC 61499
(XU; WANG; RONG, 2006; WANG; XU; TEDFORD, 2007). Esta nova arquitetura, a IEC 61499,
permite seu uso na área de planejamento de processo adaptativo Wang et al. (2009) e da usinagem,
como apresentado em Wang, Holm e Adamson (2010). Outros trabalhos trazem uma verificação
formal do comportamento do sistema aderente a IEC 61499 (GERBER; IVANOVA-VASILEVA;
HANISCH, 2008; IVANOVA-VASILEVA; GERBER; HANISCH, 2008; GERBER; HANISCH,
2010). O uso em conjunto das normas ISO 14649 e IEC 61499 tem perspectivas promissoras no
desenvolvimento da nova geração de CNC, onde a aplicação de controle da máquina é construída
1 Introdução 24
a partir dos dados STEP-NC (MINHAT; XU; VYATKIN, 2009; FINKE Jr. et al., 2011).
Assim, nota-se a necessidade de uma implementação conjunta das normas ISO 14649 e IEC
61499 que demonstre aos fabricantes das máquinas ferramentas os benefícios e a confiabilidade
de seu uso. A junção das duas normas pode ser vista como natural, onde a STEP-NC fornece um
modelo de dados completo, porém sem funcionalidades de comando e controle de máquina, e os
FBs fornecem as funcionaldades ao modelo de dados (XU; WANG; RONG, 2006). Eliminar a
distância entre os projetos desenvolvidos e principalmente fabricantes é um dos pontos fundamen-
tais para disseminar novas tecnologias, onde para tal, é necessário possuir softwares e protótipos
confiáveis e transparentes capazes de demonstrar suas funcionalidades. Este trabalho se baseia na
proposta de uma nova estrutura, comparadas coms as estruturas encontradas na literatura, para a
implementação das normas, no desenvolvimento de softwares capazes de atender as normas foco
deste trabalho e necessidades desta pesquisa. É importante ressaltar que este trabalho tem foco
no desenvolvimento do controlador CNC, visando a atenção dos fabricantes de controladores
CNC e não sob ponto de vista dos usuários das máquinas ferramenta.
Uma hipótese para a implementação da integração das normas no controle e acionamento

do CNC é a criação de uma rede de FBs a partir dos dados provenientes do arquivo STEP-NC
de forma automática e integrada, onde esta rede de blocos de função será executada em um
microcomputador comum. Para a representação dos objetos workingsteps, que são um sub tipo
de executable STEP-NC, em um modelo da IEC 61499, foi proposta a criação de modelos
de recursos resources IEC 61499. O modelo de recurso é constituído de uma rede de FBs e
possui controle independente de suas operações, ficando responsável pelo cálculo do caminho da
ferramenta e uso dos parâmetros associados para cada executable STEP-NC.
Para a construção dos FBs e suas redes são necessários softwares para auxiliar o trabalho. Os
softwares encontradas nas literaturas, aderentes à norma IEC 61499, possuem limitações/falhas
que dificultam o uso. Uma hipótese é a construção de ferramentas para execução, visualização,
criação e edição de FBs e rede de FBs. Outro problema encontrado na questão da integração das
normas está na forma de representação dos dados STEP-NC em FBs. Uma hipótese é reunir,
em FBs de serviço de comunicação dentro de um resource, todos os dados referente de um
executable, como dados da feature e dados do processo associado. Esse bloco de serviço de
comunicação, possuindo todos os dados, invocará a instância do resource do tipo de executable,
constituinte da bibliteca de FBs, e executará os cálculos do caminho da ferramenta e uso dos
parâmetros. Como saída, a hipótese é a criação de equações de movimentos (linear, circular, entre
1.1 Objetivos do Trabalho 25
outros) que poderão ser enviados para o controlador de baixo nível e/ou simuladores gráficos.
Neste trabalho será usada a expressão “controlador de baixo nível” para representar o CLP ou
microcontrolador responsável por controlar o acionamento dos drivers de potência dos motores.
Vale destacar também a busca pela característica de interoperabilidade, onde neste trabalho é
buscada a interoperabilidade de informação entre o setor de projeto e o chão de fábrica e a porta-
bilidade do código STEP-NC entre os controladores CNC, características garantidas pela norma
ISO 14649 com o uso do modelo de dados STEP-NC. É buscada também a interoperabilidade
no nível de controle do CNC, onde a aderência a estrutura de controle à norma IEC 61499 traz
essa característica ao controlador.
1.1 Objetivos do Trabalho
1.1.1 Objetivo Geral
Desenvolver um controlador CNC que utilize diretamente o arquivo STEP-NC, sem o uso de
código G/M, tendo como arquitetura para comando de máquina o uso de Blocos de Função
aderentes à IEC 61499 e que o controlador possua as características de: portabilidade, interopera-
bilidade, configurabilidade, uso de features, autonomia, distribuição e adaptabilidade.
1.1.2 Objetivos Específicos
Para tal são definidos os seguintes objetivos específicos:
• Desenvolver um compilador para ler o arquivo STEP-NC de entrada e gerar como saída
arquivos no formato XML contendo instâncias FBs e de modelos IEC 61499;
• Construir uma biblioteca de tipos de blocos de funções e modelos IEC 61499, que deve
possuir um modelo de recurso para cada executável da norma ISO 14649;
• Desenvolver uma ferramenta de software para visualização gráfica, edição e execução da

rede de FBs aderente à estrutura de arquivo definida pela IEC 61499;
• Realizar a comunicação entre o microcomputador e os CLPs dos servoacionadores através

de uma rede de comunicação industrial, para realizar a troca de dados entre dos dispositivos
1.2 Delimitação do Trabalho 26
distribuídos constituintes da rede do CNC, os quais possuem fragmentos de códigos capazes
de processar informações;
• Comprovar através de um protótipo a viabilidade da utilização conjunta das normas

destacadas.
Essa pesquisa se classifica, segundo Silva e Menezes (2001), no tipo da pesquisa aplicada
por sua natureza, onde objetiva gerar conhecimentos para aplicação prática dirigidos à solução
de problemas específicos. Quanto à forma de abordagem do problema, o tipo quantitativo é
mais destacado, mas também a abordagem qualitativa é adotada. A classificação quanto aos
objetivos, será utilizada a pesquisa exploratória para descrição do problema de forma a torná-
lo explícito, envolvendo levantamento bibliográfico nesta fase. Contudo, na parte prática do
trabalho, esta pesquisa possui características da pesquisa explicativa, utilizando de um método
experimental (protótipo) para provar os objetivos. E por último, quanto aos procedimentos
técnicos de uma pesquisa, este trabalho se utiliza de: pesquisa bibliográfica, pois utiliza de
materiais já publicados; pesquisa experimental, onde possui o objetivo de estudo determinado e
busca nos padrões as variáveis capazes de influenciar o objetivo alvo; estudo de caso onde se
aprofunda no detalhamento das características individuais das normas.
1.2 Delimitação do Trabalho
Neste trabalho, as normas ISO 14649 ou STEP-NC e a IEC 61499 ou FBs são objetos da
pesquisa. A integração das normas, de forma automática, é buscada para a construção de um
controlador CNC interoperável. Neste trabalho o controlador utiliza como entrada de informações
o arquivo STEP-NC no formato ISO10303-21. Não é objetivo desta pesquisa a construção deste
tipo de arquivo, não provendo de editor ou gerador de arquivo STEP-NC. Visa implementação
de um controlador CNC com um número limitado de features prismáticas e processos da norma
ISO 14649, perante a grande quantidade de features descritas na norma. As operações analisadas
são para uma fresadora CNC 2,5D, cujos eixos são comandados por servoacionamentos.
1.3 Estrutura da Dissertação
Este trabalho está organizado em oito capítulos. No Capítulo 1 é apresentada a introdução

do trabalho, relatando o problema e os objetivos a serem alcançados. No Capítulo 2 tem-se a
1.3 Estrutura da Dissertação 27
descrição da norma ISO 14649 ou STEP-NC, apresentando as principais características da norma.
No Capítulo 3 é descrita a norma IEC 61499 ou FBs, sendo apresentado seus modelos e conceitos.
No Capítulo 4 tem-se uma fundamentação teórica sobre temas abordados no desenvolvimento do
trabalho e sobre ferramentas se software existentes aderente à norma IEC 61499. No Capítulo 5
uma revisão bibliográfia é feita revelando os trabalhos relacionados. No Capítulo 6 é apresentada
uma nova proposta para a implementação de um controlador CNC interoperável, com todas as
ferramentas desenvolvidas e a descrição completa da arquitetura utilizada para o controle da
máquina. No Capítulo 7 é apresentado o teste do trabalho e uma discussão dos resultados. Por
fim, no Capítulo 8 tem-se a conclusão, contribuições e trabalhos futuros.
28
2 Transferência de Dados na Manufatura

Neste capítulo será abordada uma das áreas que fundamentam esta pesquisa, referente à transfe-
rência de dados na manufatura. Inicialmente, tem-se o cenário atual e uma evolução no modelo da
manufatura. A partir desta evolução, questões como a troca de dados entre os sistemas auxiliados
por computador e entre esses sistemas e a máquina-ferramenta CNC se tornaram importantes
na indústria. É discutida e aprensentada a linguagem utilizada para a programação CNC atual,
destacando suas limitações e problemas. E com o objetivo de solucionar as questões até aqui
levantadas, são apresentados os padrões ISO 10303 e ISO 14649.
2.1 Modelo da Indústria de Manufatura
Nas últimas décadas, as prioridades econômicas de produção deixaram de ser baseadas só

em baixo custo de produtos padronizados para o uso de instalações industriais com um conceito
de produção por demanda. Esse conceito foi adotado a fim de melhor enfrentar os desafios e
aproveitar as oportunidades da globalização econômica. Em uma abordagem tradicional, a área
de projeto e fabricação são consideradas separadas, mas em um ambiente moderno e global a
separação se torna uma grande fraqueza da indústria, tornando os ciclos de produção lentos e
caros (YUSOF; TAN; KASIM, 2009). Se ocorrer alguma modificação, que exista necessidade de
redesenho do produto, o engenheiro irá passar as informações de volta para a equipe de projeto.
Hoje, com o uso de tecnologias de informática e tecnologias de comunicação nas indústrias,
os métodos anteriormente mencionados estão em grande parte sendo substituídos por sistemas
auxiliados por computador, por exemplo CAD e CAM, para implementar engenharia simultânea.
O uso de sistemas computacionais no auxílio da manufatura traz redução da interação humana
e proporciona um aumento da produção, redução de custos e melhor qualidade de produto
(YUSOF; TAN; KASIM, 2009).
2.2 Troca de Dados nos Sistemas de Manufatura
Hoje, o software e hardware disponíveis nas máquinas ferramenta CNC tornam possível
simular graficamente o movimento da ferramenta e a remoção do material, controlar a vida útil
2.2 Troca de Dados nos Sistemas de Manufatura 29
da ferramenta e realizar controle adaptativo em tempo de execução para melhoria dos processos
de usinagem. O maior desenvolvimento do CNC ocorreu com a aplicação de controladores de
software, os CLP, onde a lógica é implementada em software em vez de hardware.
Embora estes desenvolvimentos tenham ocorrido no setor de chão de fábrica, fornecedores

e usuários ainda estão buscando uma linguagem comum entre o setor de projeto, que utilizam
CAD, CAPP, CAM, e o CNC; para integrar o conhecimento gerado em cada etapa (ROSSO
Jr.; NEWMAN, 2003). Com a atual gama de padrões proprietários para sistemas auxiliados por
computador, os CAx (Computer Aided technologies), traduzir informações escritas num recurso
CAx específico para trabalhar em outro recurso CAx, requer um grande esforço. Como resultado,
a capacidade de resposta de uma empresa às mudanças do mercado e sua capacidade de lidar
com a realocação de recursos ou alterações é severamente prejudicada (WANG, 2009). Junto a
esses padrões poprietários entre os sistemas CAx, existe ainda uma dificuldade para a troca de
dados entre os sistemas CAx e o controlador CNC.
2.2.1 Troca de dados entre CAD e CAM
O papel básico de um sistema CAD é definir com precisão a geometria de um projeto de uma
peça. Essa definição, realizada no CAD, é fundamental para todas as atividades subsequentes do
ciclo do produto. Como cada sistema CAD tem seu próprio método de descrever a geometria,
matematicamente e estruturalmente, há sempre alguma perda de informação ao traduzir os dados
de um formato de dados CAD para outro, e para outros sistemas auxiliados por computador
como o CAM (WANG, 2009).
Desde o início dos sistemas CAD/CAM, o problema da portabilidade dos modelos entre
sistemas foi umas das questões chaves a dificultar a disseminação destas ferramentas. Muitas
soluções foram propostas na direção de padronização e uso de normas para a troca de dados,
tais como SET (Standard d’Exchange et de Transfer), VDA (Verdand des Automobilindustrie)
e IGES (Initial Graphics Exchange Standard), os quais obtiveram sucesso parcial pois não
supriram plenamente as necessidades da indústria (XU; WANG; RONG, 2006; ROSSO Jr.;
ALLEN; NEWMAN, 2002). Para resolver o problema de falta de um padrão internacional aceito
pela maior parte dos usúarios, a ISO desenvolveu o padrão para intercâmbio de modelos de
dados de produtos, a ISO 10303 ou STEP. Esta norma possibilita a troca de dados, através de um
sistema neutro, entre os programas utilizados no desenvolvimento de produtos de engenharia e
será melhor detalhada na seção 2.3 deste trabalho.
2.3 ISO 10303 ou STEP 30
Embora esses esforços permitiram a criação de tradutores STEP pelos fornecedores, seu uso
na cadeia de manufatura era limitado. Um grande obstáculo tem sido a falta de interligação dos
sistemas computacionais CAD/CAM com o CNC, isso devido às capacidades de programação
limitada do código G/M utilizada nos controladores CNC (ROSSO Jr., 2005).
2.3 ISO 10303 ou STEP
A integração dos sistemas CAD/CAE (Computer Aided Engineering - Engenharia Auxiliada

por Computador)/CAPP/CAM no processo de manufatura enfrentou inúmeras dificuldades
para a troca de dados entre eles. A partir dessas dificuldades encontradas e com o objetivo de
padronização dos modelos de dados dos produtos foi desenvolvida a norma ISO 10303 também
chamada de STEP (ISO, 1994a). Segundo Loffredo (2000), a norma STEP possibilita a troca
de dados, através de um sistema neutro, entre os programas utilizados no desenvolvimento de
produtos de engenharia.
2.3.1 Visão Geral
A norma ISO 10303 possui suporte ao desenvolvimento durante toda a cadeia de processo, de
maneira que as informações permaneçam íntegras e consistentes durante todo o ciclo de vida
do produto. Isso faz com que a troca de dados se torne eficiente entre os diversos setores da
empresa, fabricantes e fornecedores. A norma STEP proporciona esse padrão de armazenamento
de dados através da criação de vários AP (Application Protocol) dirigidas a diferentes domínios
de aplicações, seja ele de projeto, usinagem ou manutenção (WANG, 2009). O padrão STEP é
um padrão neutro que é adequado para as necessidades industriais, diferente de outros padrões
como SET, VDA e IGES que, como dito anteriormente, obtiveram um sucesso parcial (ROSSO
Jr.; NEWMAN, 2003).
Um dos aspectos mais importantes da norma STEP é a sua extensibilidade. Essa extensibi-
lidade é obtida através do uso de uma linguagem formal para a modelagem de dados, a qual é
aplicada utilizando a linguagem EXPRESS (ROSSO Jr., 2005). Melhorias futuras para STEP
podem introduzir outros métodos de descrição, mas EXPRESS é o instrumento fundamental
utilizado para descrever os modelos de informações e protocolos de aplicação que são a maior
parte da norma.
2.3 ISO 10303 ou STEP 31
2.3.2 Estrutura STEP
O padrão STEP está dividido em muitas partes. Estas partes abrangem temas como métodos
utilizados para descrever a norma, arquiteturas de implementação, os procedimentos de testes
de conformidade, modelos de informação de recursos e protocolos de aplicação (LOFFREDO,
2000).
A estrutura desta norma é descrita na ISO 10303 Parte 1 (ISO, 1994a), como segue (ROSSO
Jr., 2005; WANG, 2009):
1. Visão geral e princípios fundamentais (Parte 1): Este é um documento simples, dando uma
visão geral de STEP e uma exposição de seus princípios fundamentais;
2. Métodos de descrição (Partes 11 a 19): Abrangem a linguagem de modelagem de informa-

ções EXPRESS e sua forma gráfica, EXPRESS-G;
3. Métodos de implementação (Partes 21 a 29): Abrangem métodos de representação de

dados que tenha sido modelado em EXPRESS;
4. Metodologia de testes de conformidade e estrutura (Partes 31 a 39): fornecem o conceito

geral do teste de conformidade bem como métodos de ensaio real e requisitos em matéria
de laboratórios de ensaio e clientes;
5. Recursos integrados genéricos (Partes 41 a 99): fornece um meio flexível para criar a
integração entre diferentes aplicativos;
6. Recursos integrados de aplicação (Partes 101 a 199): estes são os modelos de informação
EXPRESS com um foco mais específico;
7. Protocolos de aplicação (Partes 201 a 299): Estas são as partes destinadas à aplicação na
indústria. Especificam os requisitos para dados de aplicações de um domínio específico da
engenharia. Descrevem as estruturas de dados para um modelo de produto.
Em Recursos Integrados genéricos se encontra a parte 43 que possui a representação da

estrutura das features, onde features são entidades dotadas com diversos atributos, como parâ-
metros geométricos, tolerâncias, posição, referências a outras features, entre outros (RAUCH
et al., 2009). Deve-se reconhecer que o uso de features trouxe muitas vantagens aos ambientes
de projeto e manufatura. Este uso é particularmente útil pela forma de comunicação, usando
2.4 Troca de Dados entre CAM e CNC 32
termos de manufatura como por exemplo furos, ilhas e cavidades, ao invés de efetuar operações
booleanas usando entidades geométricas tais como: cilindros, cubos entre outras. O uso da
programação baseada em features traz significado aos modelos geométricos e esta é a principal
contribuição desta tecnologia (ROSSO Jr.; NEWMAN, 2003).
2.4 Troca de Dados entre CAM e CNC
Um pacote de software CAM é usado para criar dados, tais como o caminho de ferramenta e
especificar ferramentas de corte que serão utilizados na usinagem da peça. Uma vez criado o
caminho da ferramenta em dados CL (Cutter Location), estes são pós-processados em códigos
de máquina que contêm os movimentos da máquina. O pós-processador é desenvolvido para
uma máquina específica, onde contém códigos proprietários de um único modelo máquina CNC.
Em geral o código G/M é o padrão de dados utilizado para descrever para um CNC como fazer
uma peça. Essa característica traz um problema de interoperabilidade de código entre máquinas.
Durante o processo de transição do CAM para o CNC, não é dada qualquer informação ao CNC
sobre o que ele está fazendo ou porque as instruções têm de ser executadas na ordem dada
(ROSSO Jr., 2005).
Para solucionar o problema da transferência de dados entre CAM e CNC, na metade da

década de 1990, passou a ser desenvolvida uma nova interface de dados com base na norma
ISO 10303, que é a ISO 14649 ou STEP-NC (ROSSO Jr.; NEWMAN, 2003). Essa norma visa
fornecer um modelo de dados orientado a objetos para uma nova geração de CNC inteligentes. A
sua inovação quanto ao padrão utilizado atualmente na programação NC, o código G/M, está na
habilidade de representar a geometria das peças, utilizando o conceito de features, possuindo
um modelo mais detalhado de dados que provê informações sobre geometrias, ferramentas a
utilizar, operações a desempenhar e um plano de trabalho. Ainda possibilita o fluxo bidirecional
entre sistemas CAM e CNC, fazendo com que não haja perda de informações e tornando muito
mais fácil e rápida a atualização ou modificação em produtos já pré-projetados. Essa norma será
abordada com mais detalhes na seção 2.5.
2.4.1 O Código G/M (ISO 6983)
O padrão de programação CNC permaneceu praticamente inalterado desde os anos de 1950,

quando a primeira máquina NC foi desenvolvida (ISO, 1982). As máquinas ferramentas evoluí-
ram muito, desde máquinas simples com controladores sem memória impulsionados por fitas
perfuradas até as hoje altamente sofisticadas. Na década de 1970, as máquinas CNC tiveram um
desenvolvimento significativo no sentido de serem mais automáticas e confiáveis abrangendo
posteriormente com novos processo, tais como estampagem e nibbling, corte a laser e corte a jato
de água. Com o desenvolvimento dos minicomputadores, e mais tarde, os microcomputadores,
houve uma enorme melhoria na capacidade das máquinas CNC, atualmente capazes de realizar
controle multi-eixos, multi-ferramentas e multi-processos. Estas capacidades crescentes fizeram
a tarefa de programação cada vez mais difícil e complexa. Contudo, a programação CNC não
evoluiu junto, não ampliando seu código para se adequar às novas capacidades do CNC. Essa
inadequação da norma de programação CNC gerou a criação de códigos específicos por parte
de cada fabricante CNC, acarretando em códigos proprietários e falta de interoperabilidade de
código entre as máquinas CNC.
Basicamente, a máquina CNC recebe instruções em seqüências de blocos contendo comandos

para preparar a operação da máquina, parâmetros, coordenadas e velocidade. De acordo com a
ISO 6983, o código G/M é baseado nos seguintes comandos (WANG, 2009):
• Funções preparatórias: de G00 a G99;
• Comandos mistos: M (também chamado de funções da máquina);
• Comandos de movimento de eixos: X, Y, Z, A, B, C;
• Comandos de avanço e velocidade: F (taxa de avanço) e S (velocidade do eixo árvore);
• Comandos de identificação: N (número do bloco);
• Seleção de ferramenta de corte: T.
A Figura 2.1 mostra um exemplo de umaa linha de programa em cógigo G/M (ISO 6983).
Alguns problemas enfrentados pelo uso da ISO 6983 estão resumidos a seguir (WANG,
2009):
• A linguagem concentra-se na programação de caminho do centro da ferramenta em relação

aos eixos da máquina, ao invés de descrever as tarefas de usinagem com relação à peça;
• O código G/M é um tipo de linguagem baseada em números. O padrão define a sintaxe

das instruções do programa, mas na maioria dos casos deixa a semântica ambígua;
Figura 2.1: Exemplo de linha de programa em ISO 6983
Fonte: adaptado de (ROSSO Jr., 2005)
• A fim de reforçar a capacidade da máquina CNC, os fornecedores de controladores CNC

desenvolveram seus próprios conjuntos de comandos de controle para adicionar mais
recursos. Isso ocorreu devido à falta de desenvolvimento do padrão ISO 6983, tornando os
controladores CNC pouco aderentes à norma. Extensões e variações são todas feitas de
forma independente pelos fabricantes, o que significa que os operadores têm de conhecer
os dialetos e peculiaridades das máquinas;
• O arquivo gerado contendo o código G/M tem que ser gerado por um pós-processador
para uma máquina específica, para obter o conjunto de comandos de baixo nível. Essa
transição para o baixo nível pode desprezar de dados que a princípio não são relevantes,
mas dificulta ou até mesmo impede a verificação e simulação;
• A norma suporta apenas uma forma de fluxo de informações, isto é, do projeto para a
fabricação. Assim, mudanças feitas no chão de fábrica não podem ser enviadas de volta
ao setor de projeto, acarretando em que as experiências sobre o chão de fábrica não são
preservadas;
• O código G/M define apenas três modos de movimentos (linear e circulares). O código
G/M não suporta curvas spline, o que o torna incapaz de interpretar dados de superfícies
complexas diretamente.
É evidente a necessidade de um novo modelo de dados para CNC. Atualizar o padrão do

código G/M pode não ser suficiente. O novo modelo de dados precisa suportar um ambiente
completo e integrado para a área de projeto e fabricação. Na seção 2.5 será descrita a norma que
2.5 ISO 14649 ou STEP-NC 35
tende a substituir o código G/M.
2.5 ISO 14649 ou STEP-NC
Apesar do desenvolvimento que tem melhorado a arquitetura dos softwares e das máquinas-
ferramenta CNC, os fabricantes e usuários procuravam uma infraestrutura comum para os
sistemas CAD, CAE, CAPP, CAM e CNC que integrasse e traduzisse a informação de cada um
dos estágios da cadeia. Com o propósito de prover um padrão consistente e de qualidade para
a manufatura baseada em CNC é que a ISO 14649, também conhecida como STEP-NC, foi
desenvolvida (ROSSO Jr.; NEWMAN, 2003).
Contrária à atual norma ISO 6983, a STEP-NC não é um método para programação da peça
e normalmente não descreve o movimento da ferramenta para a máquina CNC. Em vez disto,
provê um modelo de dados orientado a objeto para CNC com uma interface de dados detalhada
e estruturada que incorpora a programação baseada em features, onde uma série de informações
são representadas, como as features a serem usinadas, tipos de ferramentas usadas, as operações
a executar, e a sequência de operações a ser seguida (BENAVENTE, 2011).
A Figura 2.2 mostra a diferença do fluxo de informaçôes entre o cenário atual da manufatura
baseada em CNC usando a ISO 6983 onde o fluxo de informação é unidirecional entre os sistemas
CAD/CAM e CNC (lado esquerdo da figura) e o fluxo bidirecional com o uso da STEP-NC
(lado direito da figura). Além disso, algumas informações disponíveis nos sistemas CAD/CAM
são parcialmente perdidas quando pós-processadas para código G/M, pois o padrão não fornece
suporte para a maioria das informações (ROSSO Jr., 2005).
O lado esquerdo da Figura 2.2 revela a deficiência existente com o uso dos CNC convencio-
nais, onde o sentido do fluxo de informação é único, do setor de projeto para o chão de fábrica
e sem a possibilidade de rotorno de informações. Além disso, a informação transmitida possui
comandos específicos para uma máquina específica, não sendo possível a troca de máquina sem
alteração no código. Já o lado direito revela uma troca de informações de alto nível, possuindo
termos de manufatura na estrutura do arquivo.
Segundo Zhu, Wang e Fu (2006) e Xu e Newman (2006), alguns dos maiores benefícios do
uso da STEP-NC podem ser resumidos em:
• Tanto a descrição baseada em features como o modelo da estrutura na ISO 14649 são
Figura 2.2: Diferença de fluxo de informação com o uso do código G/M e com o uso de STEP-NC
Fonte: Adaptado de ROSSO Jr. (2005)
harmonizadas com a ISO 10303. Logo, a STEP-NC suporta o fluxo bidirecional de

informação para transferência de dados entre CAD/CAM e CNC. Como um resultado,
modificações nas informações sobre tarefas de usinagem e dados tecnológicos feitas no
chão de fábrica podem ser salvos e transferidos para os setores superiores;
• Os pós-processadores serão eliminados porque a interface não requer informações especí-

ficas da máquina;
• STEP-NC é independente do fabricante da máquina-ferramenta, pois fornece um modelo

de dados neutro;
• STEP-NC provê um modelo de dados completo e estruturado, ligando informações geomé-

tricas e tecnológicas, de modo que nenhuma informação seja perdida entre os diferentes
estágios do processo;
• Seus elementos de dados são suficientes para descrever os dados da tarefa NC;
• O modelo de dados é expansível (com classes de conformidade);
• Os tempos de usinagem podem ser reduzidos, pois otimizações inteligentes podem ser
construídas dentro do controlador STEP-NC;
• Arquivos XML podem ser usados para transportar informações, permitindo manufatura
distribuída baseada em Web.
Outro aspecto importante é que o uso de STEP-NC significa trabalhar com formalismo
NC único para qualquer software de máquina-ferramenta, já que nenhuma operação de póspro-
cessamento é necessária. O formalismo STEP-NC, consequentemente, aumenta a eficácia dos
equipamentos de manufatura através da possibilidade do desenvolvimento de abordagens de
programação inteligente, IA (Inteligência Artificial), e tornando esses equipamentos e softwa-
res mais interoperáveis através da troca de dados de alto nível em toda a cadeia de dados da
manufatura (RAUCH et al., 2009).
2.5.1 Estrutura da Norma STEP-NC
Efetivamente, STEP-NC define um padrão de dado de entrada para sistemas CNC. Como a STEP-
NC é uma extensão da STEP para tratamento de processos NC, ela segue estritamente o padrão
STEP (WANG, 2009). O modelo de dados baseado em STEP-NC contém dados geométricos,
características de usinagem, dados do processo de usinagem e dados de ferramentas. Os dados
geométricos são originados do CAD, e descritos na ISO 10303 AP2032 , incluindo todas as
informações necessárias para definir a geometria final da peça. Dados das features de usinagem
e dados do processo de usinagem são gerados pelo CAM (AP2243 , AP2144 ), onde definem os
parâmetros tecnológicos e as ferramentas a serem usadas durante processo que são normalizadas
pela ISO 14649. No modelo de dados ISO 14649 os objetos Workingsteps, um para cada feature,
associam ferramentas e parâmetros tecnológicos, e a sequência desses Workingsteps é posta em
um plano de trabalho (ISO, 2003a). A Figura 2.3 mostra uma descrição geral do modelo de
dados.
Existem dois métodos para implementar um programa de dados STEP-NC. O padrão ISO
14649 é um ARM (Application Reference Model), enquanto a ISO 10303-238 é um protocolo
de aplicação (AP) que implementa o AIM (Application Interpreted Model) em um contexto
STEP-NC, permitindo melhor integração com outros protocolos de aplicação da ISO 10303. O
modelo ARM, que é a implementação utilizando a ISO 14649, é mais simples e apropriada para
2
AP203 Protocolo de Aplicação: Configuração controlada de projetos 3D de peças mecânicas e montagens.
3
AP224 Protocolo de Aplicação: Definição de produto mecânico para planos de processo utilizando recursos de
usinagem.
4
AP214 Protocolo de Aplicação: Dados básicos para projetos mecânico automotivo.
Figura 2.3: Descrição geral do modelo de dados
Fonte: Adaptado de ISO (2003a)
aplicação ao desenvolvimento de um protótipo de controle CNC (PACHECO et al., 2011).
A norma ISO 14649 segue a estrutura STEP onde há um padrão geral para as diretrizes e mui-
tas partes que descrevem cada ramo de tecnologia ou processo, como fresamento, torneamento,
EDM (Electrical Discharge Machining), como mostrado na Figura 2.4.
A Figura 2.4 mostra as relações entre os protocolos de aplicações STEP e ISO 14649 e
também a estrutura da ISO 14649. Pode-se perceber na figura que a ponte para transformar um
modelo de produto em um programa de usinagem são as features tecnológicas descritas na ISO
10303 AP224 (ROSSO Jr., 2005).
2.5.2 Arquivo Físico STEP-NC
A norma STEP-NC é definida utilizando a linguagem formal de especificação de dados EXPRESS

que pode ser definido de duas formas, textualmente ou graficamente. Para verificação formal e
como entrada para elementos tais como SDAI (STEP Data Access Interface), a representação
textual é a mais importante e simples de implementar. A principal característica do EXPRESS é
a possibilidade de validar formalmente uma população de tipos de dados. EXPRESS é, em geral,
similar a uma linguagem de programação orientada a objetos. A linguagem EXPRESS faz uso
Figura 2.4: Relação entre ISO 10303 e ISO 14649
Fonte: Adaptado de ROSSO Jr. (2005)
de diversos tipos de dados, são eles (ISO, 2003a, 2003b):
Entity: é o tipo de dado, construtor, mais importante da EXPRESS. Ele faz uso de atributos para
definir suas propriedades. Uma entidade pode se relacionar com outras de duas formas:
hierarquicamente sendo “SUBTYPE”/ “SUPERTYPE”, ou por atributos. A entidade
“SUPERTYPE” pode ter múltiplas “SUBTYPE”, podendo ser ou não “ABSTRACT”. Os
dados presentes na entidade podem ser restringidos, fazendo uso de “WHERE RULES”,
onde são expressões que precisam cumprir as regras para o código ser aceito;
Enumeration: define pedaços de textos específicos, como por exemplo: “TRUE” ou “FALSE”
para o tipo “BOOLEAN”;
Defined: especializa tipos de dados declarados anteriormente, como por exemplo, quando se
precisa do tipo INTEGER” > 0;
Select: define uma escolha entre duas entidades ou dois tipos, por exemplo: um atributo “TOLE-
RANCE_SELECT” pode ser uma entidade “PLUS_MINUS_VALUE” ou uma entidade
“LIMITS_AND_FITS”;
Aggregation: os tipos possíveis de agregações são: “SET”, “BAG”, “LIST” e “ARRAY”.

Por exemplo: a STEP-NC usa “LIST” no atributo “coordinates” da entidade “CAR-
TESIAN_POINT”;
Simple: os tipos simples podem ser equivalentes aos tipos primitivos de linguagens como Java,
esses são: “STRING”, “BINARY”, “BOOLEAN”, “LOGICAL”, “NUMBER”, “INTE-
GER” e “REAL”;
Um arquivo físico STEP-NC pode ser implementado de várias formas, que mapeiam as
estruturas EXPRESS em formatos de implementação, dentre elas destacam-se: XML (ISO,
2007), formato textual simples (ISO, 1994b) e Java (ISO, 2000). Neste trabalho será tratado o
arquivo STEP-NC implementado de acordo com estrutura definida pela ISO10303-21, muitas
vezes chamada apenas de Parte 21. A Parte 21 é composta por duas grandes seções: a primeira
intitulada “HEADER” e uma segunda seção nomeada “DATA”. Na seção HEADER têm-se
informações e observações gerais da peça, que são dados como: nome do arquivo, autor, data
do projeto, esquema, organização, entre outros. A segunda e mais importante seção, “DATA”,
contém todas as informações sobre a geometria, características e tarefas de usinagem.
Pode-se dividir a segunda parte em três grupos: “Identificação da peça, plano de trabalho e
executáveis”, “Descrição da tecnologia” e “Descrição de geometria e topologia” (ROSSO Jr.,
2005). A Figura 2.5 mostra a estrutura de um arquivo STEP-NC, e será melhor detalhado a
seguir.
Em “Identificação da Peça” tem-se informações sobre identificação da peça, identificação

do material da peça, propriedades do material, entre outros. O plano de trabalho (Workplan) é
caracterizado por uma série de executáveis, cuja ordem é pré-estabelecida ou dependente das
condições de usinagem e se os controles condicionais são utilizados ou não (CALABRESE;
CELENTANO, 2007). Uma das vantagens de se possuir um Workplan em um arquivo STEP-NC
é o fato de todas as tarefas que serão executadas pela máquina, estão ordenadas em um só local,
o que facilita a mudança da sequência das operações sem afetar o restante dos dados do arquivo,
podendo realizar uma otimização no processo.
As tarefas executáveis (executables) são de três tipos: Workingstep, program structure e NC

function. O executável mais importante é o Workingstep que define as características de usinagem
da peça. Cada Workingstep descreve uma única operação de manufatura utilizando apenas uma
ferramenta de corte. O program structure representa um plano de trabalho ou ordens do fluxo
de execução tais como: “parallel”, “if ” e “while”. O NC function inclui o estabelecimento do
Figura 2.5: Estrutura de um arquivo físico STEP-NC
Fonte: Adaptado de ROSSO Jr., ALLEN e NEWMAN (2002)
sistema de coordenadas da peça ou plano de segurança, e comandos auxiliares como parada do

programa, parada opcional, entre outros (ROSSO Jr., 2005).
O item “Descrição da tecnologia” contém detalhes e uma descrição completa de todos os

Workingsteps a serem executados no plano de trabalho. Nessa descrição são incluídos dados com
relação às ferramentas, estratégias de usinagem, features da peça, e detalhes como profundidade
de corte, velocidade de rotação, diâmetro da ferramenta, etc (CALABRESE; CELENTANO,
2007). A “Descrição da geometria” contém informações geométricas da peça, set-ups e caracte-
rísticas de fabricação. No nível mais baixo, as operações podem também conter uma descrição
explícita e exata do caminho da ferramenta se isso for requerido por um sistema CAM ou um
controlador de NC (WANG, 2009). O diagrama da Figura 2.6 representa a hierarquia existente
em um programa STEP-NC.
Machining_Workingstep é o subtipo do Workingstep que é um subtipo de Executable. Contém

informações necessárias não somente para a máquina, mas também a ligação para informações
tecnológicas de usinagem e informações geométricas. A sequência de execução do programa
NC é determinada utilizando o plano de trabalho (Workplan), entidade que possui o conjunto
Figura 2.6: Estrutura hierárquica de um arquivo STEP-NC
Fonte: Wang (2009).
ordenado de executáveis. A entidade Manufacturing_feature cobre a maioria das features de

usinagem definidas em STEP AP 224 e possui informações geométricas. Por exemplo, uma
feature pocket, um subtipo de Manufacturing_feature, tem uma base de dados de contorno de
curva e profundidade. Assim como a entidade Machining_operation é a classe abstrata para as
operações específicas do processo. Ela especifica a ferramenta a ser usada (Machining_tool), e
um conjunto de parâmetros tecnológicos: os parâmetros de usinagem (Technology, por exemplo,
da taxa de avanço, velocidade do eixo árvore), das condições de usinagem (Machine_functions)
e Machining_strategy (por exemplo, contorno paralelo, contorno espiral).
43
3 Automação da Manufatura
Neste capítulo será tratada outra área que fundamenta esta pesquisa, a área de automação da
manufatura. É apresentada a situação atual da tecnologia de automação industrial em que se
encontram as indústrias de transformação, onde são destacadas as dificuldades enfrentadas com
a atual arquitetura. E com o intuito de apontar uma solução para esse problema, é apresentada a
norma IEC 61499.
3.1 Evolução das Técnicas de Controle
A tecnologia da automação industrial evoluiu através de quatro gerações segundo Vyatkin

(2007). A transição de uma geração para outra ocorre devido à incapacidade das tecnologias
anteriores de atender as necessidades emergentes das novas realidades tecnológicas e econômicas.
Outro fator que contribui para a migração é a disponibilidade de novas tecnologias para atender
as novas exigências. As características das quatro gerações estão listadas como segue (VYATKIN,
2007):
• Primeira Geração: nesta primeira geração, em torno do anos de 1950, os controladores eram
constituídos basicamente de contatos e bobinas conectados por cabos elétricos. Qualquer
alteração na aplicação exigia uma mudança na disposição dos circuitos elétricos;
• Segunda Geração: os circuitos elétricos são substituídos por dispositivos computacionais

como microcontroladores ou CLP. Com isso, a lógica de controle passa a ser implementada
em software e não em hardware fixo. Para facilitar a transição da geração anterior para
esta geração, uma linguagem de programação gráfica foi desenvolvida, a liguagem Ladder,
linguagens padronizadas pela IEC 61131-3;
• Terceira Geração: ocorreu um aumento na complexidade dos sistemas, aumentando o

número de entradas e saídas dos dispositivos e consequentemente de cabos interligando o
controlador com sensores, acionadores e atuadores;
• Quarta Geração: essa geração conta com a arquitetura baseada em redes distribuídas,
onde todos os dispositivos são vistos como nós independentes na rede. Para alcançar este
3.2 Programação de CLP 44
nível de flexibilidade, cada um dos dispositivos deve ser equipado com uma interface
para comunicações com a rede. Como resultado, os dispositivos são conectados todos
a uma mesma rede, onde a adição de um novo dispositivo à rede não requer a adição
de mais fiação. Isto torna a reconfigurabilidade do sistema muito mais fácil comparada
com o sistema centralizado. Com essa arquitetura a fiação não limita a localização dos
dispositivos, podendo assim os dispositivos serem distribuídos conforme a necessidade.
E ainda, que as próximas gerações serão caracterizadas pelo uso de componentes verdadeira-
mente inteligentes, capazes de criar “sociedades” e reconhecer as capacidades uns dos outros
e da “sociedade” como um todo. A facilidade de integração dos componentes é um benefício
imediato, mesmo para componentes muito simples. Outros benefícios podem surgir a partir do
comportamento autônomo dos componentes que podem reagir melhor às mudanças no ambiente
em que se encontram.
3.2 Programação de CLP
O CLP tem sido utilizado como plataforma para implementação de algoritmos de controle
em aplicações industriais (HUEMEI, 2010). Após a sua inserção no mercado, várias empresas
desenvolveram CLPs com diferentes linguagens de programação, sistemas operacionais e ambi-
entes de execução. Para reduzir a complexidade para o usuário de CPLs, a IEC elaborou a norma
IEC 61131. A parte 3 (INTERNATIONAL ELECTROTECHNICAL COMMISSION, 2003)
do padrão foi publicada inicialmente em 1992, e especifica cinco linguagens de programação
para CLP, tendo como base as linguagens já existentes, contudo abstrai as peculiaridades propri-
etárias. As cinco linguagens definidas se dividem em duas categorias. As linguagens textuais
são Instruction List (IL) e Structured Text (ST). Outra categoria são as linguagens gráficas, a
linguagem chamada (FBD) Function Block Diagram, Ladder Diagram (LD) e a Sequential
Function Chart (SFC). Com a padronização das linguagens diminuiu o esforço de treinamento
(OTTO; HELLMANN, 2009). Apesar destes avanços da IEC 61131-3, o reaproveitamento direto
de elementos de software ainda não era possível, pela adoção apenas parcial da norma ou pelas
extensões realizadas por alguns fabricantes.
Embora a norma IEC 61131 tenha provado a sua adequação para a programação de aplicações
de CLPs independentes, ela não fornece suporte conveniente para a concepção e implementação
de aplicações de automação distribuídas (FAY; ZURAWSKI, 2009). Nestas aplicações, vários
3.3 Comparativo entre as normas IEC 61131 e IEC 61499 45
controladores (e, além disso, sensores e atuadores com capacidades embutidas de controle) estão
interligados, e a comunicação entre eles deve ser garantida. Como consequência, a norma IEC
61499 foi concebida em antecipação à crescente demanda por automação distribuída. Não se
destina a substituir o padrão IEC 61131, mas propõe uma linguagem em nível de sistema para
sistemas de automação distribuídos, fazendo assim a ponte entre as linguagens de programação
para CLP apoiada pela IEC 61131 e os requisitos de projeto de sistemas distribuídos.
3.3 Comparativo entre as normas IEC 61131 e IEC 61499
A norma IEC 61499 foi desenvolvida baseada na já consolidada norma IEC 61131, para
aumentar a qualidade e confiabilidade do software e reduzir o tempo de desenvolvimento para
aplicações de controle distribuídos na automação industrial. A seguir são destacadas as diferenças
entre os modelos de blocos de função,function block (FB), das normas IEC 61131-3 e IEC 61499
(LEWIS, 2001).
Uma das deficiências existentes no conceito de FB introduzido pela norma IEC 61131 está
na ordem de execução dos FBs. A ordem de execução é determinada pela dependência de outros
blocos, normalmente da esquerda para a direita, porque os blocos da direita dependem dos
valores de saída dos blocos da esquerda. O problema enfrentado devido a essa dependência
está em sistemas com redes complexas, onde ocorrem realimentações, pois é muito difícil a
determinação da ordem de execução da rede. No intuito de contornar essa dificuldade, os sistemas
de programação oferecem formas adicionais, não abrangidas pelo escopo da norma IEC 61131,
para determinação da ordem de execução da rede de FBs. O modelo de FBs da IEC 61131
define ainda variáveis globais, pelas quais é possível transferir dados e sinais de controle entre
programas rodando em diferentes recursos. A transferência de dados entre processos utilizando
variáveis globais é uma forma ruim e muitas vezes insegura, pois a identificação de onde e
quando as variáveis foram atualizadas fica difícil. Além do mais, as formas oferecidas dentro da
configuração para manipular a inicialização de variáveis globais não são definidas na norma.
Outra característica deficiente da norma IEC 61131-3 está na existência das variáveis de
acesso. Estes são um subconjunto de variáveis dentro de uma configuração e podem ser acessadas
através da interface de comunicação de outro CLP utilizando FB de comunicação. Um modelo
de comunicação mais consistente foi necessário para que pudesse ser utilizado não somente para
comunicação entre os CLP, mas também em todo tipo de dispositivos distribuídos através de
uma rede industrial.
3.4 IEC 61499 - Modelos e Conceitos 46
Na Tabela 3.1 tem-se um comparativo entre as normas IEC 61131 e IEC 61499.
Tabela 3.1: Comparação das Características entre IEC 61131 e IEC 61499. Adaptado de Zoitl et
al. (2009)
IEC 61131 IEC 61499

Tipos de Dados São definidos Adotados da IEC 61131-3
Linguagens de Programa- IL, LD, FBD, ST, SFC Não define linguagem específica,
ção a utilização da IEC 61131-3 é re-
comendada
Meios de estruturação SFC, FBD, ST Rede de FBs
Variáveis Globais Acesso direto pelas variá- Encapsulado nos FBs de serviço
veis de interface
Abordagem de engenharia Centrada na aplicação, mas Centrada na aplicação
na prática é, na maioria das
vezes, centrada nos disposi-
tivos
Conceito de execução Principalmente cíclico Dirigido a eventos
Reconfiguração dinâmica Não fornecido Interface e conjunto de instruções,
não para os dados
Conceito de distribuição Não fornecido Distribuição arbitrária das aplica-
ções
A partir desta tabela, pode-se conhecer as principais diferenças entre as normas, onde
percebe-se que a IEC 61499 é uma extensão da IEC 61131.
3.4 IEC 61499 - Modelos e Conceitos
A IEC 61499 fornece terminologia, modelos e conceitos para permitir a implementação de

controle de sistemas distribuídos utilizando blocos de funções de forma inequívoca e formal
(LEWIS, 2001), que serão apresentados nas subseções seguintes seguindo a ordem crescente da
hierarquia dos modelos.
3.4.1 Modelo de Blocos de Funções
A base de toda a arquitetura da norma IEC 61499 consiste no modelo de bloco de função
(LEWIS, 2001). O bloco de função é uma abstração que representa um componente que pode ser
implementado usualmente em forma de software, mas também pode ser implementado na forma
de hardware (VYATKIN, 2007). As principais características de um FB são (LEWIS, 2001):
• Cada FB tem o nome do tipo e um nome de instância. Sempre devem ser mostrados quando
o bloco é visualizado graficamente;
• Cada bloco possui um conjunto de eventos de entrada, os quais podem receber eventos de
outros blocos via conexões de eventos;
• Existe um ou mais eventos de saída, os quais podem ser usados para propagar eventos para
outros blocos;
• Há um conjunto de entrada de dados que permite que os valores dos dados sejam passados
a partir de outros blocos;
• Há um conjunto de saída de dados para passar valores de dados produzidos dentro do FB

para outros blocos;
• Cada bloco pode ter um conjunto de variáveis internas que são usadas para armazenar
valores retidos entre a chamada dos algoritmos;
• O comportamento do FB é definido em termos dos algoritmos e informações de estado.

Usando o estado do bloco e suas mudanças, várias estratégias podem ser modeladas para
definir qual algoritmo será executado em resposta a um evento particular.
Para melhor entendimento, serão apresentadas as principais características do modelo FB,

como descrito através da Figura 3.1. Nota-se que a interface de um FB é definida por uma lista
de variáveis de eventos de entrada e variáveis de dados de entrada, variáveis de eventos de saída
e dados de saída. Na representação gráfica, o FB pode ser dividido em duas partes: “cabeça” e
“corpo” (VYATKIN, 2007).
A “cabeça” do FB possui o controle de execução o qual é responsável por definir quais

algoritmos serão acionados com a chegada de eventos e quando os eventos de saída serão
disparados. O controle de execução é definido pelo ECC (Execution Control Chart) cuja notação
Figura 3.1: Características gerais do modelo de FB
Fonte: Adaptado de Lewis (2001)
é uma simplificação da Sequential Function Charts definida pela IEC 1131-3 (VYATKIN;
HANISCH, 2000).
No “corpo” do bloco de função, onde são conectados os dados de entrada e saída, contém
os algoritmos e dados internos que ficam ocultos dentro do bloco. O fato dos algoritmos e
dados internos ficarem ocultos dentro do bloco faz com que o usuário do FB não necessite ter o
conhecimento de sua concepção interna para utilizá-lo (LEWIS, 2001).
3.4.2 Tipos de Blocos de Funções
Um importante conceito na IEC 61499 está na capacidade de definir o tipo de bloco de função,
que define o comportamento e interfaces das instâncias dos blocos de funções que são criados a
partir do tipo (LEWIS, 2001; IEC, 2005a). Uma instância de um bloco de função é caracterizada
pelo nome do tipo e nome da instância, um conjunto de dados de entrada/saída, um conjunto
de eventos de entrada/saída, um grafo de controle de execução, dados internos, e algoritmos
internos. Os nomes do tipo e da instância são usados unicamente para identificação do bloco de
função, os dados e eventos de entrada e saída são necessários para a interconexão de diferentes
blocos de funções para formar um sistema, enquanto o controle de execução, os dados internos,
e os algoritmos internos descrevem o comportamente do bloco de função (LUDER et al., 2005).
Neste trabalho serão estudados os três principais tipos de blocos: básico, composto e de
serviço de interface.
3.4.2.1 Bloco de Função Tipo Básico
FBs do tipo básico são estruturas de software projetadas para implementar funções básicas de
controle, como cálculos simples, tratamento de eventos, entre outros (VYATKIN, 2007). O seu
comportamento é definido em termos dos algoritmos que são invocados em resposta a eventos
de entrada. Após a execução do algoritmo, eventos de saída são disparados. O mapeamento
dos eventos para os algoritmos é expresso usando uma notação especial de transição de estado,
chamada de Execution Control Chart ou ECC (LEWIS, 2001).
Um bloco de função básico, como o da Figura 3.2, possui uma interface, uma função de
controle de execução ECC, algoritmos, e variáveis internas. As variáveis internas de um bloco de
função não podem ser acessados de fora e podem ser usados somente por algortimos internos de
um bloco de função particular. Os números de 1 a 8 é a representação para sequência de tempos
que define a execução do FB e será descrita em seguida.
Figura 3.2: Bloco de Função Básico
A interface é definida pelos eventos de entrada/saída e dados de entrada/saída. A função

de controle de execução especifica o algoritmo que deve ser invocado após a ocorrência de um
evento de entrada em um certo estado da função. Ele é especificado por meio do ECC. O bloco
de função básico possui um, e somente um ECC (VYATKIN, 2007).
Os algoritmos contidos dentro do bloco de função básico são estruturas de códigos operando
sobre entradas, saídas e dados internos. A norma recomenda que o algoritmo pode ser programado
em uma das cinco linguagens definidas pela norma IEC 61131 ou podem ser escritos em qualquer
outra linguagem suportada pelo ambiente de execução (FINKE Jr., 2011).
A norma define a execução de um FB básico como uma sequência de oito tempos (internos),
conforme representado pelos números na Figura 3.2 (DUNBININ; VYATKIN, 2008):
1 - Os valores das variáveis de entrada relevantes para o evento de entrada se tornam disponíveis;
2 - O evento de entrada ocorre e o controle de execução do FB é disparado;
3 - A função de controle de execução notifica a função de sequenciamento do recursos para

agendar um algoritmo para execução;
4 - A execução do algoritmo inicia;
5 - O algoritmo completa a computação dos valores para as variáveis de saída associadas com o
evento de saída;
6 - A função de sequenciamento do recurso é notificada que a execução do algoritmo foi

finalizada;
7 - A função de sequenciamento invoca a execução da função de controle;
8 - A função de controle de execução sinaliza um evento na saída.
É importante notar que há uma série de restrições sobre este modelo de execução. Estas
fases de tempo não podem se sobrepor e devem ocorrer na ordem prescrita para que o bloco de
função seja executado corretamente. No entanto, em algumas implementações, algumas fases
podem ser de tão curta duração que podem ser consideradas instantâneas. A IEC 61499 não
define limites para nenhuma dessas fases. No entanto, ela afirma que, em qualquer modelo de
bloco de função deve ser possível definir a duração das diferentes fases, a fim de modelar com
precisão as características de tempo da rede completa (LEWIS, 2001).
3.4.2.2 Bloco de Função Tipo Composto
A definição do tipo de um FB composto contém declarações de instâncias de blocos de função

de tipos selecionados que estão conectados por eventos e dados. A conexão de dados entre os
componente de FBs definem as transferências dos valores de dados entre as saídas e entradas,
enquanto as conexões de eventos definem a ordem de execução dos algoritmos dentro dos blocos
(LEWIS, 2001). A funcionalidade do FB do tipo composto é determinada por uma rede de
blocos interconectados, podendo possuir blocos de função dos tipos básico, composto e/ou de
serviço de interface. Um FB composto tem sua estrutura semelhante à Figura 3.3. Um bloco de
função composto se destina a ser o principal instrumento de um desenvolvedor de aplicativos
(VYATKIN, 2007).
Figura 3.3: Bloco de Função Composto
Fonte: Adaptado de Vyatkin (2007)
Um FB composto não possui variáveis internas, exceto para armazenagem dos valores dos
eventos e dados de entrada e saída. Os membros da rede de blocos de funções dentro do bloco
composto podem ser ligados uns aos outros e com a interface do bloco composto através de
conexões de dados e eventos (VYATKIN, 2007). Ao contrário dos FBs básicos, o FB composto
não possui função de controle de execução (ECC). A lógica particular de chamada dos FBs
na rede de blocos dentro do FB composto pode ser implementada usando um bloco de função
externo do tipo básico, como um supervisor, onde este bloco supervisor poderia emitir eventos
para ativar os blocos da rede (VYATKIN, 2007).
3.4.2.3 FB Tipo Serviço de Interface
O FB de serviço de interface permite a abstração de serviços específicos para uma plataforma,

tais como leitura de entradas, chaveamento de saídas ou serviços de comunicação (VLAD et
al., 2010). Sempre que qualquer forma de interação é necessária entre blocos de função dentro
de um recurso e o mundo externo ou entre recursos há a exigência de um bloco de função de
serviço de interface (LEWIS, 2001). O modelo de recurso é descrito na subseção 3.4.4.
O FB de serviço de interface serve como uma função que empacota as dependências do

hardware e permite ao desenvolvedor focar na lógica da aplicação. Sua implementação requer
conhecimento de baixo nível do hardware particular (VYATKIN, 2007).
Tal como os outros tipos de blocos de função, o comportamento de um FB de serviço de

interface é definido por uma especificação do tipo do FB. No entanto, devido ao FB de serviço de
interface estar principalmente preocupado com o meio externo, o padrão especifica uma notação
adicional, chamado de diagrama de sequência de tempo, definidos no Technical Report 8509 da
ISO (LEWIS, 2001). Estes podem ser usados para mostrar o tempo e as relações sequenciais
entre várias interações com o bloco de função. Em geral, o diagrama de sequência de tempo é
comumente usado em padrões de comunicação e fornece uma forma eficaz de vizualizar a ordem
em que as várias mensagens ou eventos ocorrem (LEWIS, 2001).
A norma IEC 61499 não define padrões para tipos específicos de blocos de função de serviço
de interface, mas estipula que esses devam ser definidos usando um padrão para as variáveis
de entrada e saída e para eventos de entrada e saída (LEWIS, 2001). Dentro dos blocos de
funções de serviço de interface, a comunicação é especialmente importante, onde a norma se
refere a dois padrões genéricos: os PUBLISH/SUBSCRIBE para comunicação unidirecional e
CLIENT/SERVER para comunicação bidirecional. Estes padrões podem ser ajustados para o
mecanismo de comunicação de uma implementação particular (VYATKIN, 2007). Deve-se notar
que o padrão não faz nenhuma tentativa de definir FBs específicos de serviço de interface, pois é
claro que cada sistema terá seus próprios requisitos particulares (LEWIS, 2001). Entretanto, a
norma padroniza os principais parâmetros de entrada e saída do FB, embora nem todos precisam
necessariamente ser utilizados na definição do tipo do FB (LEWIS, 2001). Dois exemplos de
blocos de função de serviço de interface são mostrados nas Figuras 3.4 e 3.5.
Os blocos de função PUBLISH e SUBSCRIBE são implementados em dispositivos diferentes

e eles se comunicam através de conexões de rede. Para garantir uma comunicação adequada
Figura 3.4: Bloco de função de serviço de interface PUBLISH
Fonte: Adaptado de Wei (2002)
Figura 3.5: Bloco de função de serviço de interface SUBSCRIBE
entre dois blocos de função, o valor PARAMS (endereço IP, por exemplo) deve ser o mesmo em
ambos. No exemplo apresentado, ambos os blocos de função, PUBLISH e SUBSCRIBE, são
inicializados pelo evento INIT+ conforme mostrado no diagrama temporal da Figura 3.6.
Figura 3.6: Inicialização da interação

Após o estabelecimento da comunicação, um evento de entrada REQ do PUBLISHER irá
acionar a aceitação de dados de entrada em SD_1 a SD_m. Posteriormente, os mesmos dados são
transmitidos para o SUBSCRIBER. Ao mesmo tempo, o evento de entrada também é transmitido
para a saída IND do SUBSCRIBE como evento de saída, que então aciona a saída de dados de
RD_1 a RD_m (WEI, 2002), conforme a representação gráfica é apresentada na Figura 3.7.
Figura 3.7: Transferência de dados
As duas barras verticais representadas em cada diagrama de seqüência de tempo separa os

dois diferentes domínios em que as operações ocorrem (LEWIS, 2001).
3.4.3 Modelo de Aplicação
Uma aplicação é uma rede de intâncias de FBs interconectados por eventos e dados (VYATKIN;
DUNBININ, 2006). Ela define completamente a funcionalidade desejada do sistema, mas não
especifica a estrutura do sistema em termos dos dispositivos computacionais onde os FBs serão
executados (VYATKIN; DUNBININ, 2006; VYATKIN, 2007). É por isso que uma aplicação
geralmente não inclui FBs que implementem transferência de dados através de redes, bem como
outras funções dependentes de hardware, como a leitura de sinais de entradas (VYATKIN;
DUNBININ, 2006).
Uma aplicação pode existir em um único dispositivo ou possuir funcionalidades distríbuidas

em diversos dispositivos. Em termos práticos, uma aplicação é todo o conjunto de blocos de
funções e suas interconexões para resolver um problema particular de controle. Uma aplicação
distribuída deve ser projetada como uma rede de FBs conectados. Quando a aplicação é carregada
dentro em um sistema, ela será carregada como uma série de fragmentos que serão alocados
em diferentes dispositivos (LEWIS, 2001). Na Figura 3.8 é mostrado um exemplo de aplicação
(Etapa 1 da figura), que consiste em uma rede de FBs conectados. Quando ocorre a distribuição
dessa aplicação pelos dispositivos, como mostrado na Etapa 2 da figura, conexões de eventos e
dados são rompidas. Para manter a troca de dados e eventos entre a rede, FBs de comunicação
(FBs de serviço de interface) necessitam ser inseridos onde as conexões de dados e eventos
cruzam a fronteira dos dispositivos, resultando em um sistema como mostra a Etapa 3 da figura.
Figura 3.8: Modelo de Aplicação
3.4.4 Modelo de Recurso
Recurso é uma unidade funcional contida dentro de um dispositivo que possui controle indepen-
dente de suas operações, e que provê vários serviços para as aplicações, incluindo sequenciamento
e execução de algoritmos (VYATKIN; HANISCH, 2000). Um recurso pode ser considerado
como um contêiner para uma rede de FBs o qual suporta fragmentos da aplicação distribuída
(VLAD et al., 2010). Cada recurso possui controle independente de suas operações. Isto significa
que um recurso pode ser criado, configurado, parametrizado, inicializado, apagado, etc., sem
afetar outros recursos dentro do dispositivo (VYATKIN, 2007; LEWIS, 2001).
A função de um recurso é aceitar dados e/ou eventos do ambiente, por exemplo sensores,
e/ou interface de comunicação, dados e/ou eventos do processo, e retornar dados e/ou eventos
para o ambiente e/ou interfaces de comunicação, como especificado pela aplicação que utiliza o
recurso (VYATKIN, 2007).
As principais características de um modelo de recurso são mostradas na Figura 3.9. A rede

de FBs está contida dentro do recurso, onde possui FBs de serviço de interface que podem
trocar dados e/ou eventos através da interface de comunicação com outros recursos ou através da
interface com o processo.
Figura 3.9: Modelo de Recurso
Dentro do recurso é mostrada uma rede interconectada de blocos de funções conectados por
ligações de dados e eventos. A função de sequenciamento provida pelos recursos garante que
os algoritmos encapsulados dentro dos blocos de funções sejam executados na ordem correta
(LEWIS, 2001). Os FBs de serviço de interface foram melhor explicado em subseção 3.4.2.3.
3.4.5 Modelo do Dispositivo
Um dispositivo representa uma unidade de controle, o qual pode possuir zero, um ou mais
recursos, juntos com interfaces de processos e interfaces de comunicação (VLAD et al., 2010;
LEWIS, 2001). O dispositivo é um elemento atômico de um sistema. O modelo de dispositivo é
mostrado na Figura 3.10.
Um tipo de dispositivo é especificado por sua interface de processo e sua interface de

Figura 3.10: Modelo de Dispositivo
comunicação. A interface de processo de um dispositivo provê serviços que permitam que

recursos troquem dados com entradas e saídas físicas do dispositivo (LEWIS, 2001). Informações
recebidas do processo físico são apresentadas ao recurso como dados ou eventos, ou ambos.
A interface de comunicação provê serviços de comunicação para os recursos trocarem dados

via rede externa com recursos alocados em dispositivos distribuídos. As interfaces são implemen-
tadas pelas bibliotecas de blocos de funções de serviços de interface. A norma IEC 61499 define
três classes de dispositivos ordenados pelo incremento de funcionalidades (VYATKIN, 2007):
A Classe 0 representa os dispositivos de mais simples funcionalidades programados estati-

camente, permitindo apenas reprogramação somente pela reconexão de instâncias de blocos de
funções pré-carregadas, conforme visualizado na Figura 3.11.
A Classe 1 representa dispositivos de programação simples, o qual pode criar novas instân-
cias de blocos de funções a partir de uma biblioteca de tipos de blocos de funções, conforme
visualizado na Figura 3.12.
A Classe 2 representa a completa reprogramação dos dispositivos onde a biblioteca dos tipos
de blocos de funções pode ser extendida, conforme visualizado na Figura 3.13.
Figura 3.11: Funcionalidade do Dispositivo de Classe 0
3.4.6 Modelo do Sistema
O sistema representa a estrutura mais complexa da arquitetura da IEC 61499 e é definida como
um conjunto de dispositivos onde os FBs das aplicações são alocados (VLAD et al., 2010).
Ela define ainda a relação de comunicação de dispositivos e aplicações (LEWIS, 2001). Os
dispositivos são conectados uns aos outros, tanto dentro de redes de comunicação, e também
com o processo controlado, por meio de interfaces de processo (VLAD et al., 2010).
A Figura 3.14 ilustra o conceito geral de um sistema distribuído genérico da IEC 61499, em
que os dispositivos podem comunicar-se uns com os outros sobre um ou mais links de comunica-
ção e possíveis interfaces com máquinas e processos a controlar. Isto pode ser reconhecido como
uma abstração de um tipo de dIPMCS distribuída (WEI, 2002).
Figura 3.14: Modelo de Sistema
Um sistema pode ser dito realizável se cada dispositivo contiver e suportar os tipos de FBs
que são mapeados nele, ou seja, deverá conter os tipos de FBs instanciados na biblioteca do
dispositivo. Caso contrário, o bloco não será instanciado, e o sistema não executará (VYATKIN,
2007).
O modelo do sistema revela completamente a funcionalidade desejada e inclui informa-

ções dos dispositivos e suas interconexões, tendo assim blocos de funções que implementam
3.5 Formato do Arquivo 60
transferência de dados através de redes de comunicação (VYATKIN; DUNBININ, 2006).
3.5 Formato do Arquivo
Um importante aspecto da norma IEC 61499 é a capacidade de troca de blocos de função

e modelos de aplicações entre as diferentes ferramentas e plataformas. Esta capacidade traz
inúmeros benefícios para o usuário final, onde torna-se possível reutilizar projetos de FB em
diferentes hardwares e diferentes configurações do sistema (LEWIS, 2001). A norma IEC 61499
estipula o uso da linguagem XML (eXtensible Markup Language) para representação dos FBs
(VLAD et al., 2010).
61
4 Tecnologias Correlatas
Neste capítulo serão abordados temas que serão utilizados no decorrer deste trabalho e necessitam
ser descritos para melhor compreensão por parte do leitor.
4.1 Arquitetura de uma máquina CNC
Existem atualmente três principais tipos de controladores para uma máquina CNC (CA-
PELLI, 2006), são eles:
• Multiprocessamento com ASIC (Application Specific Integrated Circuit - Circuito Inte-

grado para Aplicação Específica): existem equipamentos comercialmente disponíveis,
tais como FANUC21T, FAGO-800, MITSUBISH C3/C3-S, que permitem a integração e
garantem grande compatibilidade com este circuito integrado;
• PC front end: este é um CNC tradicional onde é incorporado um microcomputador comum

aos equipamentos comerciais como FANUC série 150/160/180/210 e Siemens 840D, onde
tais equipamentos são como uma caixa preta para os usuários;
• Cartão de controle do movimento com PC: este sistema possui uma placa de controle de
movimentação adicionada em um microcomputador. Essa placa, geralmente baseada em
circuito com DSP (Digital Signal Processor), executa as tarefas de movimentação. Com
isso o computador fica com as funções que não necessitam de processamento em tempo
real.
O primeiro tipo de controlador apresentado permite uma integração e garante grande com-
patibilidade, porém é uma arquitetura completamente proprietária, não sendo aberta e nem
reconfigurável. O segundo controlador apresentado, onde a parte fundamental é o NC, é uma
caixa preta, possuindo códigos completamente proprietários. Já o terceiro controlador, também
pode ser nomeado de controlador numérico baseado em PC (personal computer - computador
pessoal), possui maior flexibilidade do que um sistema proprietário NC, porém essa arquitetura
ainda não é totalmente aberta, possuindo cartões de controle proprietários.
4.2 Compilador 62
Ainda segundo Capelli (2006), a Figura 4.1 consiste em uma arquitetura típica de um CNC
e seus periféricos para uma fresadora de três eixos. Nesta arquitetura, todo o processamento é
realizado no CNC.
Figura 4.1: Arquitetura típica de um CNC e seus periféricos
Fonte: Adaptado de Capelli (2006)
Já na Figura 4.2 tem-se uma nova arquitetura CNC, onde um CLP foi adicionado para
realizar o controle e monitoramento dos sensores e atuadores. Com isso, o CNC fica responsável
apenas pelo tratamento do programa de usinagem e interpolação.
Figura 4.2: Nova arquitetura de um CNC e seus periféricos
Fonte: Adaptado de Capelli (2006)
A diferença principal entre as duas arquiteturas é a presença do CLP, que permite um melhor
desempenho na máquina-ferramenta a CNC pois, ao invés de ter um processamento local, tem
um processamento separado.
4.2 Compilador
Um compilador é um programa que pode ler outro programa escrito em uma linguagem -
a linguagem fonte - e gerar um programa equivalente em outra linguagem - a linguagem alvo
(AHO; SETHI; ULLMAN, 1986).
4.3 Servoacionamento 63
Um compilador utiliza um modelo típico de fases que transformam a representação da
linguagem fonte em alvo, seguindo uma ordem, conforme são detalhadas a seguir (AHO; SETHI;
ULLMAN, 1986):
Análise léxica: Identifica os caracteres contidos no arquivo de entrada e os transforma em

tokens, os quais são passados para a próxima etapa.
Análise sintática: Faz o agrupamento dos tokens em uma árvore sintática representando a
estrutura gramatical da linguagem.
Análise semântica: Analisa a árvore sintática verificando a concordância da linguagem.
Gerador de código intermediário: Gera um código fácil de construir e interpretar.
Gerador de código alvo: Recebe como entrada o código intermediário e o mapeia para a
linguagem alvo.
A front-end agrupa todas as fases de análise do código fonte de uma linguagem, enquanto
a back-end faz a síntese e geração de código conforme a aplicação desejada. A interface entre
as partes é um código intermediário gerado pela front-end, onde qualquer back-end atrelada a
qualquer conjunto hardware/software possa interpretar. Essa estrutura permite que diferentes
linguagens trabalhem com uma linguagem alvo, trocando apenas a front-end, ou que uma única
linguagem funcione com distintas linguagens alvo, trocando apenas as back-ends.
Várias ferramentas estão disponíveis para ajudar no desenvolvimento de um compilador,

incluindo geradores de parser, os quais produzem analisadores sintáticos automaticamente a
partir da descrição gramatical da linguagem de programação (AHO; SETHI; ULLMAN, 1986).
4.3 Servoacionamento
O servoacionamento é constituído por dois componentes: um servomotor e um servoconver-

sor. Nesta seção serão descritos esses dois componentes.
4.3.1 Servomotor
O servomotor é uma máquina síncrona composta por um estator bobinado e um rotor constituído
de imãs permanentes. Sua alimentação, apesar de trifásica, não pode ser efetuada através da rede
convencional, pois possui um bobinamento totalmente especial, confeccionado para proporcio-
nar uma alta dinâmica ao motor através de um fluxo eletromagnético totalmente diferente do
proporcionado pela rede. O valor deste fluxo eletromagnético é calculado pelo servoconversor
através de um modelamento matemático que leva em consideração todas as características do
servomotor. Na subseção seguinte será detalhado o servoconversor WEG (2010a).
Têm-se as especificações técnicas listadas referente ao modelo SWA (WEG, 2010a):
• Grau de proteção IP651;
• Isolamento Classe F;
• Realimentação por resolver;
• Formas construtivas B5 (sem pés, fixado pela flange);
• Protetor térmico (PTC);
• Ponta de eixo com chaveta NBR 6375;
• Ímãs de terras raras (Neodímio-Ferro-Boro);
• Rolamento com lubrificação permanente;
• Retentor para vedação do eixo;
• Temperatura máxima de operação em regime permanente: δT = 100◦ C.
Algumas características fazem do servomotor uma ótima opção para o controle de uma
máquina ferramenta. Podem-se citar alguns tópicos vantajosos com o seu uso:
• Utiliza de força contra-eletromotriz senoidal;
• Possui uma rotação suave e uniforme em todas as velocidades;
• Tem baixo nível de ruído e vibração;
• Ampla faixa de rotação com torque constante;
• Baixa manutenção (servomotores sem escovas);
• Elevada capacidade de sobrecarga;

• Baixa inércia, facilitando a frenagem;
• Resposta dinâmica rápida.
4.3.2 Servoconversor
A característica central de um servoconversor é possuir alto desempenho e alta precisão no

controle do movimento do eixo do servomotor. Isso é conseguido devido à operação em malha
fechada através da realimentação de posição dada por um sensor dentro do servomotor. O modelo
utilizado no trabalho é o SCA-06 da empresa WEG que permite o controle de velocidade, torque
e posição dos servomotores (WEG, 2010a). Sua alimentação pode ser monofásica ou trifásica, o
que facilita a operação em locais sem instalações trifásicas. A alimentação do controle e potência
são independentes, permitindo que a rede de comunicação continue comunicando mesmo com
as potências desligadas. Possui rede de comunicação que implementa o protocolo CANOpen e
um CLP incorporado ao produto padrão que utiliza a linguagem Ladder para programação. O
programa para o CLP pode ser desenvolvido utilizando o software proprietário disponibilizado
gratuitamente pela empresa fabricante do servoconversor, o WLP (WEG, 2010b). O WLP é um
software para edição do programa através da linguagem Ladder e monitoração do equipamento.
Características do servoconversor SCA-06:
• Tensão de alimentação 220-230Vca;
• Alto desempenho;
• Precisão de controle do movimento;
• Operação em malha fechada;
• Realimentação de posição por Resolver;
• Alimentação de controle e potência independentes;
• Flexibilidade e integração ao acionamento;
• IHM com display de LEDs de seis dígitos;
• Porta USB;
• CANopen padrão de fábrica;

4.4 Programas de computador existentes aderentes a norma IEC 61499 66
• Software de programação WLP gratuito;
Um fator que torna o controle com servoacionamentos preciso, é a realimentação feita através
do resolver para o servoconversor. O resolver é um transformador de alta frequência, onde o
primário está no rotor e dois secundários no estator. Ele funciona como um gerador, onde seu
rotor é acoplado ao eixo do servomotor e faz com que a interação do campo eletromagnético atue
sobre o bobinamento do estator. As amplitudes e fases das tensões induzidas nos secundários são
funções da posição do rotor. Os secundários estão defasados 90o entre si, para a geração de sinais
senoidais, estes serão condicionados e transformados em funções de realimentação do sistema
através de circuitos eletrônicos dispostos no servoconversor para verificação do posicionamento
final.
4.4 Programas de computador existentes aderentes a norma

IEC 61499
A Parte 2 da norma IEC 61499 intitulada “Software tool requirements” (IEC, 2005b), define
os requisitos que as ferramentas de software devem suportar segundo as especificações da norma.
Um requisito fundamental abordado na Parte 2, que se aplica a qualquer sistema de engenharia
compatível com a IEC 61499, é a capacidade de criar e armazenar elementos em uma biblioteca
de FBs.
A norma tem inspirado muitos pesquisadores a criarem programas de computador de apoio

aos projetistas. O conjunto usual de programas de implementação inclui um ambiente para
a edição de projetos de blocos de função e traduzi-las em forma executável, e algum tipo de
ambiente de execução, que suporte a execução de código executável (VYATKIN, 2011).
Segundo Vyatkin (2011), as principais características de ferramentas de apoio a IEC 61499

estão resumidas como segue:
• armazenar, recuperar e trocar elementos da biblioteca;
• implementar determinados elementos de uma biblioteca, por exemplo, criar uma instância
de um bloco de função em um determinado resource;
• navegar e exibir as declarações de elementos selecionados da biblioteca;

• criar e modificar as definições dos elementos da biblioteca, por exemplo, abrir um tipo de
bloco de função e modificar suas especificações internas;
• validar as definições dos elementos da biblioteca, por exemplo, ser capaz de verificar a
especificação de um bloco de função composto e assegurar que todas as ligações internas
estejam entre pontos de tipos de dados compatíveis;
• produzir formas compiláveis dos blocos de função adequados para qualquer firmware ou
carregar em dispositivos, e também de ser capaz de produzir ligações entre instâncias do
bloco de funções de uma forma que pode ser estabelecida através de uma rede.
Os exemplos mais desenvolvidos de pesquisas em ambientes de trabalho aderente a IEC

61499 são FBDK (Holobloc Inc., 2008) e 4DIAC-IDE (4DIAC, 2010). Estes foram apoiados
com um esforço de desenvolvimento consistente, até o momento, além disso o 4DIAC-IDE é um
projeto open source. Esforço de desenvolvimento substancial tem sido investido para o CORFU
(THRAMBOULIDIS, 2002) e outro é o FBench, projeto também open source (FBENCH, 2008),
mas no momento essas ferramentas não parecem ser continuamente apoiadas (VYATKIN, 2011).
Ambientes de execução incluem FBRT (Holobloc Inc., 2008), Forte (4DIAC, 2010), entre outros.
Segundo os autores estas ferramentas foram aplicadas com sucesso em muitos projetos
de automação, mas principalmente no meio acadêmico. No entanto, existe uma barreira de
utilizá-los na indústria. As ferramentas comerciais fornecem um alto nível de projeto e suporte à
depuração remota que é difícil de competir. Alcançar esse nível de maturidade, aceitável para a
indústria, requer anos de desenvolvimento e melhorias (VYATKIN, 2011).
Em seguida, são mostradas algumas das ferramentas de software aderentes à IEC 61499 já
desenvolvidas.
4.4.1 Ferramenta nxtStudio - IEC61499 e SCADA
NxtStudio (NXTCONTROL, 2010) integra a abordagem de controle distribuído com base na

IEC 61499 com sistema SCADA (Supervisory Control and Data Acquisition - Sistemas de
Supervisão e Aquisição de Dados). É um ambiente de engenharia de nível industrial, sendo
comercial, que suporta o projeto de aplicações de controle e visualização em conjunto em uma
única ferramenta. Esta abordagem tem grandes vantagens em produtividade e reutilização de
controle e componentes de visualização. Várias características do NxtStudio há muito tempo
eram esperadas por usuários IEC 61499, como por exemplo, a depuração e monitoramento de
infraestrutura on-line, permitindo depurar remotamente FBs, bem como os aplicativos totalmente
distribuídos. Outra característica é a geração automática da comunicação durante o processo
de distribuição da aplicação. Isto reduz significativamente o esforço de engenharia quando
aplicações de controle distribuídos são projetados.
4.4.2 Sistema UML e FBs - CORFU FBDK
CORFU FBDK (THRAMBOULIDIS, 2002) é um sistema de suporte à engenharia aderente à IEC

61499 que estende o modelo da norma para cobrir especificações de requisitos utilizando UML
(Unified Modeling Language). CORFU adota uma abordagem híbrida para o desenvolvimento
de dIPMCS que integra UML com o conceito de blocos de função.
Todos os arquivos salvos pela ferramenta CORFU FBDK estão no formato XML para
facilitar a leitura e intercambialidade. Porém, o CORFU FBDK não utiliza a estrutura de arquivos
proposta pela norma IEC 61499, uma vez que armazena em arquivos com extenções proprietários
informações adicionais, apenas os arquivos com extensão .fbt que descrevem os tipos de FBs são
totalmente compatíveis com a IEC 61499 (THRAMBOULIDIS; TRANORIS, 2003).
O CORFU FBDK consiste nos seguintes componentes (THRAMBOULIDIS; TRANORIS,

2003):
• Biblioteca de FB Types: A biblioteca de tipos de FBs é o repositório do FBDK CORFU

para os tipos de FBs. Um certo número de tipos pré-definidos de FBs já estão contidos
nesta biblioteca. Uma função para importar tipos de FBs definidos por outros fornecedores
que utilizam a especificação XML IEC 61499 foi desenvolvida;
• Editor FB Types: este editor é principalmente utilizado para editar FBs existentes e criar
novos FBs;
• Editor da rede de FBs: este editor é utilizado para editar redes de FBs existentes e criar
novas redes;
• Editor de camadas do sistema: pode fazer uma distribuição preliminar da aplicação, arras-
tando a instância do FB da rede de blocos de função e distribuir pelos dispositivos (device)
compatíveis e editar suas propriedades;
• Transfomação UML para rede de FBs: para automatizar o processo de transformação de
diagramas UML para diagramas de rede FB, foi concebido e implementado no FBDK
CORFU o “Transformation Facility Manager (TFM)”.
Para a execução foi desenvolvido o ambiente de execução, chamado CORFU FB Run

Time Environment (CORFU FBRTE). Segundo Vyatkin (2007), diferente de outras ferramentas
desenvolvidas utilizando a linguagem de programação JAVA, o CORFU, por não ser baseado em
JAVA, promete um maior desempenho na execução da aplicação. Um dos maiores problemas
dessa ferramenta está na adição de arquivos com extensões proprietários na construção das
aplicações com FBs, o que impede a portabilidade das aplicações.
4.4.3 Ferramenta aderente a IEC 61499 junto com IEC 61131 - ISaGRAF
ISaGRAF (ISAGRAF, 2009) é um ambiente de trabalho para CLP aderente à IEC 61131-3, que
em 2005 foi incluído o suporte à IEC 61499, tornando-se o primeiro software de automação
a ser aderente às normas industriais IEC 61131 e a IEC 61499. Esta ferramenta suporta uma
forma transparente de distribuição de código para os dispositivos de rede. O ambiente de trabalho
automaticamente insere código de comunicação onde é necessário, enquanto o usuário vê apenas
a imagem global de toda a aplicação distribuída.
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 em qualquer ambiente que implemente a máquina virtual necessária
para interpretação desse código-fonte. A filosofia por trás da TIC é proporcionar ao usuário
maior flexibilidade de hardware alvo. Mais especificamente, a tecnologia TIC permite que o
mecanismo de controle possa ser implementado em qualquer plataforma de hardware ou em
qualquer sistema operacional.
Entretanto, nem todos os conceitos da IEC 61499 foram implementados. O ambiente de

execução proposto, embora muito restritivo, fornece a primeira ferramenta comercialmente
disponível. Por ser uma ferramenta comercial, o código fonte não está aberto para ampliações
ou alterações necessárias. Medições de desempenho para este ambiente de execução não estão
disponíveis.
4.4.4 Ambiente de Execução Fuber
O ambiente de execução “Fuber” (CENGIC; LJUNGKRANTZ; AKESSON, 2006) é desenvol-

vido em linguagem Java usando uma licença de código aberto. “Fuber” é capaz de importar
muitas aplicações compatíveis com a IEC 61499 e executá-las. Diferentemente da maioria dos
outros ambientes de execução, “Fuber” não compila os algoritmos antes da execução, algoritmos
são interpretados usando o BeanShell (BEANSHELL, 2011), o que torna possível atualizar o
comportamento gráfico de um aplicativo durante a execução, um recurso que pode ser útil para
depuração.
A principal vantagem deste programa está em realizar a execução das redes de FBs básicos.
Entretanto, a ferramenta possui algumas limitações como: os algoritmos dos FBs devem ser
obrigatoriamente implementados em Java; os tipos de FBs compostos não são avaliados; não há
suporte à distribuição de aplicação entre diversos recursos; e não possui interface gráfica, sendo
controlada por uma interface de linha de comandos.
4.4.5 Estrutura 4DIAC-RTE e 4DIAC-IDE
A estrutura 4DIAC (2010) fornece dois projetos e permite o desenvolvimento de sistemas

de controle distribuídos conforme a norma IEC 61499. Esses dois projetos são: 4DIAC-RTE
(FORTE), é uma implementação pequena e portátil de um ambiente de execução, em C++,
da IEC 61499, que suporta a execução de programas de controle distribuídos em dispositivos
embarcados. Ele suporta a execução de FBs básicos, compostos e de serviço de interface e;
4DIAC-IDE, o ambiente de desenvolvimento integrado, é baseado no Eclipse (ECLIPSE, 2011)
e fornece um ambiente de engenharia extensível para aplicações de controle de modelagem
distribuída conforme a norma IEC 61499.
O 4DIAC persegue os seguintes objetivos principais (4DIAC, 2010):
• Fornecer uma base comum para desenvolvimento de aplicações industriais e pesquisa

utilizando a IEC 61499;
• Fornecer um pacote contendo um ambiente de execução para diferentes plataformas de

controle embarcado;
• Apresentar exemplos do mundo real em nível de protótipo para aumentar a aceitação da

norma IEC 61499 na indústria;
• Proporcionar um incentivo para o uso da IEC 61499 na indústria e;
• Estimular a cooperação entre institutos de pesquisa e indústria.
Essa ferramenta faz parte de um grande projeto entre empresas, o que implica um esforço
conjunto de pesquisa e indústria. Tal ferramenta tenta cobrir desde o projeto com blocos funcio-
nais até a implementação e, embora seus recursos ainda sejam limitados, é apenas uma questão
de tempo até que mais funcionalidades sejam adicionadas. Um modelo ainda não suportado
pela ferramenta é o FB composto, portanto os FBs podem ser ou do tipo básico ou do tipo
de serviço de comunicação. Outro fator que impossibilitou a utilização desta ferramenta é a
não possibilidade de edição dos recursos, possuindo apensa quatro categorias existentes na
ferramenta.
4.4.6 FBDK e FBRT
“Function block development kit” (FBDK) (Holobloc Inc., 2008) é uma ferramenta de software
amplamente usada em projetos relacionados com a IEC 61499. A ferramenta permite o desen-
volvimento gráfico de blocos de função e de sistemas baseados em blocos de função. FBDK
compila os tipos de blocos de função desenvolvidos em linguagem de programação Java. A
natureza orientada a objetos desta linguagem permite a implementação consistente de blocos de
função. Além disso, a independência de plataforma da linguagem Java leva à portabilidade do
controlador.
O uso de FBDK pode ser combinado com outras ferramentas de desenvolvimento Java,
por exemplo, ambiente de desenvolvimento integrado Eclipse (ECLIPSE, 2011), especialmente
quando o código Java é sofisticado, como por exemplo na visualização em 3D ou interface de
dispositivos periféricos que precisam ser encapsulados em blocos de função. As aplicações do
bloco de funções, projetados usando FBDK, são executados com a máquina virtual Java e o
ambiente de execução FBRT (Function Block Run Time) dos elementos da biblioteca. Entretanto,
segungo Ceschini (2008), o FBDK ainda apresenta algumas inconsistências do ponto de vista
de erros de programação (CESCHINI, 2008). Outro fator agravante é a falta de apoio contínuo,
onde sua última atualização foi realizada no ano de 2008.
4.4.7 FBench
A ferramenta OOONEIDA FBench (FBENCH, 2008) é constituída de um editor de FB, adapta-

dores, recursos, dispositivos e sistemas especificados pela norma IEC 61499, bem como de um
compilador e um ambiente de execução. O programa permite, através da sua interface gráfica:
• Criar, visualizar ou editar um tipo pré-existente de:
– Bloco de Função: pode-se modificar suas informações da interface como eventos e

dados de entrada e saída, atributos gerais como nome, comentários, vinculação a uma
determinada norma, controle de versão e informação para compilação (formatados
textualmente). Os blocos de função devem seguir um dos modelos abaixo:
∗ Básico: o diagrama de controle de execução pode ser editado graficamente,

por meio de alteração ou criação de novos estados ou novas transições e seus
estados de origem e destino. Por sua vez, os algoritmos devem ser representados
textualmente;
∗ Composto: permite a edição da rede, podendo adicionar ou remover blocos de

função e modificar ou criar ligações entre eles;
∗ Interface de Serviço: aceita modificação das sequências primitivas de interação

e de sua interface.
– Adaptadores: a ferramenta estabelece uma forma pela qual as sequências de comuni-

cação entre soquetes e plugues podem ser especificadas;
– Recursos: permite a edição da rede de blocos de função;
– Dispositivos: permite a designação de seus recursos associados;
– Sistema: comporta a representação de um sistema completo.
• Permite a visualização gráfica da representação do XML;
• Compilar os blocos de função para linguagem Java e;
• Permite a execução do sistema previamente compilado.
Apesar de ser uma ferramenta para iniciar os estudos sobre a norma IEC 61499, o FBench
apresenta alguns erros de programação que o tornam, por vezes, complicado de usar e não possui
uma interface amigável com o usuário. Suas funcionalidades e vários aspectos se assemelham
à ferramenta FDBK. E assim como o FBDK, a ferramenta FBench também não está tendo um
apoio contínuo, pois no início de 2009 foi feita a última atualização.
74
5 Trabalhos Relacionadas
Neste capítulo serão apresentados trabalhos relacionados com STEP/STEP-NC (ISO 14649)
e FB (IEC 61499). Este capítulo está dividido em três seções, onde a primeira seção trata de
pesquisas que utilizam STEP/STEP-NC como fundamento do trabalho. Na seção 5.2 serão
relatadas pesquisas que utilizam a norma IEC 61499 no desenvolvimento do trabalho. A seção
5.3 trata de trabalhos que discutem e utilizam as normas ISO 14649 e IEC 61499 e sua integração.
5.1 Trabalhos Relacionados ao Uso do Modelo de Dados

STEP-NC
5.1.1 Sistema aderente a STEP-NC para torneamento
Yusof e Case (2010) descrevem um sistema CAD/CAPP/CAM compatível a STEP para manufa-
tura de peças em centros de torneamento, descrevendo os modelos de informação que o sistema
suporta juntamente com o modelo de dados STEP-NC usado para criação dos programas NC.
O ambiente computacional proposto para o sistema compatível a STEP-NC para operações de
torneamento, SCSTO (STEP-NC Compliant System for Turning Operations), foi desenvolvido
para gerar um arquivo STEP Part 21 com base nas features de usinagem. O sistema foi construído
usando uma metodologia estruturada para o planejamento do processo e métodos orientados a
objetos para a implementação. Como entrada para o sistema SCSTO são necessários parâmetros
geométricos da peça, suas features e um plano de operação, que podem ser criados ou editados
interativamente pelo usuário. Os parâmetros geométricos podem ser importados de um CAD em
STEP AP 203. Após isso, o usuário pode gerar o programa STEP-NC da peça. Um estudo de
caso foi testado para demonstrar que a nova abordagem (STEP-NC) pode gerar um código que é
comparável com o atualmente utilizado código G, com vantagens, tais como a eliminação do
pós-processador, uso do conceito de features, entre outras. Apenas um ambiente computacional
foi desenvolvido, não chegando a construir um CNC apto a receber este arquivo STEP-NC gerado
e realizar o controle de uma máquina real.
5.1 Trabalhos Relacionados ao Uso do Modelo de Dados STEP-NC 75
5.1.2 STEP-NC para a geração atual de CNC
Em Zhang, Nassehi e Newman (2011) é apresentada uma ferramenta chamada UPCi (Universal
Process Comprehension interface) que tem como objetivo permitir a interoperabilidade no chão
de fábrica e obter uma troca de informações bidirecional entre as máquinas CNC e os recursos
computacionais. Devido ao número crescente de sistemas CAx e o uso de formatos de dados
proprietários, o problema de interoperabilidade se tornou cada vez mais importante e caro.
Segundo os autores, a maioria das pesquisas tem sido focadas na integração de informações
em sistemas de alto nível, deixando o chão de fábrica como uma ilha isolada de informações.
Os programas CNCs gerados para as máquinas não podem, em geral, ser trocados devido
às informações serem pós-processadas para máquinas específicas. Portanto, há uma maior
necessidade de considerar a interoperabilidade de informações entre CNCs diferentes e também
entre CNCs e sistemas CAx.
A fim de lidar com os problemas de interoperabilidade no chão de fábrica e captura de conhe-

cimento, a pesquisa apresentada propõe uma interface de compreensão universal do processo para
levar as vantagens da norma STEP-NC para a geração atual de sistemas de manufatura. UPCi é
usado para compreender o plano de processo dos programas de código G/M de peças e traduzi-los
em uma representação compatível genérica STEP-NC. Esta representação genérica de um plano
de processo pode ser usada para regerar programas de peça para outros controladores, retornando
para código G/M, permitindo a interoperabilidade entre máquinas CNC. Além disso, um plano
de processo genérico e abrangente em STEP-NC também pode ser usado por outros recursos
(por exemplo, CAM, PDM) como fonte rica de dados. Assim, a compreensão do processo pode
resolver o problema de interoperabilidade de informação da cadeia de produção e alimentar o
conhecimento de chão de fábrica de volta para sistemas CAx.
O projeto inovador de um mecanismo de dicionário garante a expansibilidade do programa,

podendo ser acrescentadas funções de código G/M e a respectiva representação em STEP-NC.
O plano de processo de alto nível gerado pela UPCi é encapsulado em uma estrutura de dados
aderente a STEP-NC. Atualmente, UPCi lida principalmente com vários recursos simples.
Este trabalho traz benefícios para a interoperabilidade, porém a proposta não elimina o uso
dos pós-processadores e acrescenta mais um tradutor na cadeia. Quando existe a necessidade de
tradução de informação ocorre, na maioria dos casos, perda de informação. Além da necessidade
de reconhecer novos dialetos a cada máquina CNC lançada no mercado.
5.1.3 Simulador de Fresadora baseado em STEP-NC
Zhu, Wang e Fu (2006) descreveram um sistema de simulação 3-D para fresamento baseado em
STEP-NC. A partir da análise do modelo de dados de um arquivo STEP-NC, os autores propõem
uma arquitetura para o projeto do software simulador. A ferramenta de software, chamado de
3-DMMSS, é composta de módulos que são: [Interpreting module:] responsável pela leitura
do arquivo STEP-NC e extração das informações. A saída deste módulo é uma sequência de
instâncias de estrutura de dados, das quais cada uma representa uma entidade e é representada
em um mesmo formato; [Recognizing module:] a função deste módulo é reconhecer todas as
entidades em conformidade com a ISO 14649 e conjuntos de valores dos atributos de cada
entidade. Depois de reconhecidas, as entidades são salvas em uma entidade chamada DB (Data
Base); [Modelling module:] constrói um modelo de classes C++, cujos dados são provenientes
da entidade DB, obtendo classes hierarquicamente organizadas. Cada classe C++ é o reflexo
de uma entidade definida pelo padrão STEP-NC; [Planning module:] considerado o elemento
central da ferramenta, este módulo planeja a sequência de usinagem em caso do uso de instruções
condicionais ou em outro caso, segue a sequência determinada no workplan do arquivo STEP-NC.
Outra função deste módulo é a geração do caminho da ferramenta, onde utiliza as classes C++
criadas pelo módulo anterior e gera informações sobre o caminho que a ferramenta irá percorrer
salvando no DB; [Simulation module:] é projetado para simular o processo de usinagem para o
usuário o qual pode ser utilizado para verificação do processo.
Esse sistema de simulação foi validado com a execução do exemplo 1 da norma STEP-NC
de uma peça prismática. Esta pesquisa mostrou uma arquitetura clara, onde a função e o projeto
de cada módulo foram bem detalhados e uma ferramenta que utilizou dados de alto nível STEP-
NC na geração do caminho da ferramenta. No entanto, não foi implementado em hardware,
em uma máquina CNC real, mas os autores afirmam que seria possível usar o mesmo sistema
para controlar o CNC real juntamente com a simulação. Porém, a arquitetura de construção do
controlador, onde são gerados os caminhos da ferramenta e uso dos parâmetros de processo, não
possui nenhuma padronização ou metodologia apresentada.
5.1.4 Controlador CNC Aderente a STEP-NC
No trabalho desenvolvido por Calabrese e Celentano (2007), foi apresentado um projeto e o

desenvolvimento de um sistema embarcado capaz de controlar uma máquina CNC com dois graus
de liberdade. Segundo os autores, o controlador desenvolvido pode ser classificado como um
controlador que permite o tratamento direto do arquivo STEP-NC na máquina, geração automática
e ótima do caminho da ferramenta e também permite a realização de algumas atividades de
alto nível como: verificação de viabilidade, verificação em tempo de execução da usinagem e
estado da usinagem. O controlador STEP-NC desenvolvido possui cinco módulos principais,
conforme visualizado na Figura 5.1, chamados de: “Interpreter”; “High-level Controller”;
“Tool-path Generator”; “Low-level Controller” e; “Machining Inspector”. Esses módulos foram
implementados em um microprocessador, o qual possui conexão Ethernet, por onde é transferido
o arquivo STEP-NC. A função de cada módulo é:
Interpreter: memoriza as informações STEP-NC do processo em estruturas de dados pré-

definidas pelos autores, que serão utilizadas pelos módulos seguintes;
High-level Controller: neste módulo é feita análise de cada Workingstep e avaliado se é ou

não possível de ser realizado pela máquina em questão, tratando inclusive modificações,
quando necessárias, da velocidade da ferramenta;
Tool-path Generator: é composto de diversas sub-rotinas as quais realizam a geração automática

do caminho da ferramenta para alguns tipos de feature implementadas como: pocket, slot,
round hole;
Low-Level Controller: envia sinais adequados para os drivers dos motores de passo e para a
ferramenta da máquina conforme a trajetória especificada pelo módulo anterior;
Machining Inspector: este módulo é responsável pela inspeção da execução de usinagem.
O protótipo desenvolvido foi testado usando o “exemplo 1” da ISO 14649-11. Os autores

mostraram que um microcontrolador de baixo custo é capaz de gerenciar atividades envolvidas em
um processo de usinagem utilizando STEP-NC. Os pontos fortes deste trabalho estão na utilização
direta do arquivo STEP-NC no controle da máquina, possuindo tratamento dos dados em alto
nível (geração automática e ótima do caminho da ferramenta) e realizando atividades sobre
os dados, podendo modificar parâmetros. Porém, pode-se observar questões em aberto, o que
impossibilita a reprodução do mesmo, como a não utilização ou descrição de uma metodologia
ou norma na construção do controlador de baixo nível. Com isso, não ficou clara a construção
do módulo de geração do caminho da ferramenta, onde não disponibilizam rotinas de códigos.
Outro item é que as informações do arquivo STEP-NC que são memorizadas em estrutura de
dados não estão citadas, não deixando claro a conformidade da ferramenta com a norma.
Figura 5.1: Controlador CNC proposto
Fonte: Calabrese e Celentano (2007)
5.1.5 Aplicando STEP-NC diretamente na máquina CNC
No trabalho relatado em Pacheco et al. (2011), foi construída uma arquitetura CNC aberta de
software e hardware aderente a STEP-NC. Um protótipo de uma fresadora com três eixos
comandados por motores de passo foi construída. A arquitetura é composta por quatro blocos:
“Compiler”; “Table”; “Microcontroller”; “Serial comunication, motors drives and machine
drives”. Segundo os autores a função de cada bloco pode ser descrita como segue:
Compiler: é responsável por interpretar o arquivo STEP-NC;
Table: contém e organiza as informações de usinagem como: tipo de ferramenta, dimensão e

posição dos furos;
Microcontroller: fica responsável por receber as informações do bloco Table e enviar os coman-
dos para os drives dos motores da máquina;
Serial comunication, motors drives and machine drives: possui as seguintes características,
respectivamente: troca de dados entre o computador e a placa controladora (microcontrola-
dor), acionar os motores de passo, e acionar o eixo árvore da máquina.
A Figura 5.2 mostra a arquitetura utilizada no trabalho, destacando os sentidos do fluxo de
informação.
Figura 5.2: Arquitetura aberta desenvolvida
Fonte: Pacheco et al. (2011)
Ao compilar o arquivo STEP-NC, os autores implementaram um algoritmo otimizador

que visa gerar o melhor caminho para a ferramenta. Essa otimização pode ser aceita ou não
pelo usuário. Essa otimização altera a ordem dos executáveis listados na entidade Workplan do
arquivo STEP-NC. Testes foram realizados utilizando um arquivo STEP-NC parte 21 gerado
manualmente com vários furos redondos utilizando o processo de furação, comprovando o uso
de STEP-NC no acionamento direto da máquina ferramenta CNC, livre do código G/M. Com
isso, concluiram que é viável a construção de um controlador aderente a STEP-NC, conquistando
vantagens para a manufatura.
Os pontos fortes deste trabalho estão na utilização direta do arquivo STEP-NC no aciona-
mento da máquina, sem utilização de código G/M. Juntamente com o tratamento dos dados
em alto nível com uma geração automática do caminho da ferramenta. Onde nessa geração
existe uma otimização do caminho da ferramenta, permitindo a atualização do arquivo STEP-NC
mantendo a integridade das informações ao longo da cadeia. Contudo, a estrutura de dados em
forma de tabela utilizada para transferir as informações a serem usinadas dificulta a expansão
5.2 Trabalhos Relacionados ao Uso da Norma IEC 61499 80
desta ferramenta para a implementação de novas features, onde foram utilizados e tratados um
número baixo e limitado de parâmetros provenientes do arquivo STEP-NC. No caso de novas
features que necessitem um número maior de dados para a máquina realizar o cálculo do caminho
da ferramenta, fica inviável a representação em tabela. Este trabalho também não utiliza ou
descreve nenhuma metodologia ou norma na construção do controlador de baixo nível.
5.2 Trabalhos Relacionados ao Uso da Norma IEC 61499
5.2.1 Plano de Processo em Blocos de Funções
Wang, Jin e Feng (2006) relatam a necessidade de um sistema de planejamento de processo

que incorpore flexibilidade e dinamismo ao sistema de manufatura. Planejamento de processo é
definido como a atividade de decidir quais os processos e qual a sequência de usinagem deve ser
usada para realizar as várias operações necessárias para produzir uma peça numa dada máquina.
Visando alcançar um processo de planejamento com a integração da área de projeto com as
atividades de produção, Wang, Jin e Feng (2006) propuseram um planejamento de processo
distribuído DPP (Distributed Process Planning).
Uma estrutura com duas camadas foi proposta, a qual permite a tomada de decisões para um
planejamento supervisório genérico no nível de fábrica e planejamento de operações específicas
no nível de máquina. O planejamento supervisório é feito apenas uma vez, com antecedência, ao
nível da fábrica para gerar planos de processo para uma máquina neutra, enquanto o planejamento
da operação é realizado em tempo de execução no nível de máquina para determinar operações
específicas de uma máquina escolhida. Um plano de processo de alto nível é, portanto, também
portável para diferentes máquinas, proporcionando com isso um balanceamento na linha de
produção ou para a recuperação rápida de falhas, onde um plano de operação de baixo nível pode
ser gerado após uma máquina ser finalmente escolhida.
Para obter uma ferramenta que permita um planejamento com essas características, os autores
propuseram a utilização de blocos de função (IEC 61499) para converter tarefas de planejamento
de processo em tomada de decisões orientada a objetos. Dentro do planejamento de processo
distribuído, cada recurso de usinagem pode ser representado por um FB básico. Assim, um grupo
de features de usinagem sequenciados gerados pela ferramenta pode ser encapsulado como uma
série de funções de usinagem básicas e mapeados em uma rede de blocos de função. O fluxo
5.2 Trabalhos Relacionados ao Uso da Norma IEC 61499 81
de eventos entre os blocos de função determina sua seqüência de usinagem. Normalmente, o
plano de processo de uma peça pode ser constituído por mais de um conjunto. Neste caso, cada
conjunto irá formar um FB composto.
Em Wang, Jin e Feng (2006) um protótipo do editor de FB foi desenvolvido em Java para
ajudar os planejadores do processo a realizar o projeto do FB e criação de plano genérico de
processo. O editor de FB tem quatro componentes: editor de dados e eventos, editor do algoritmo
interno, editor do ECC e editor do tipo de FB. Quinze tipos de FBs correspondente para as quinze
features típicas de usinagem, que são pré-definidas, foram desenvolvidos e armazenados em
uma biblioteca de FBs. Planejadores de processo experientes podem usar esses editores para
definir novos tipos de FBs ou modificar um plano de processo (rede de blocos de função) que
foi gerado automaticamente. A entrada para o editor de FB é uma lista de recursos de usinagem
sequenciados. As features de usinagem na lista são mapeadas uma a uma, para blocos de função
correspondentes, que são interligadas e parcialmente sequenciadas através da aplicação de cinco
regras de raciocínio definidos. Com o uso de blocos de função, os autores mostram que a máquina
torna-se autônoma nas tomadas de decisões e possui facilidade para alterações dos algoritmos
internos.
5.2.2 Monitoramento e usinagem remota utilizando FBs
Em Wang, Cai e Feng (2009) os autores apresentam uma abordagem adaptativa para planejamento
de processo, pesquisa que dá continuidade ao trabalho apresentado na subseção anterior, e
acrescenta uma ferramenta para monitoramento da execução que utiliza blocos de função. Em
Wang (2011), foi apresentada uma abordagem integrada para o desenvolvimento de um sistema
baseado em web com maior adaptabilidade, incluindo planejamento de processo distribuído,
monitoramento em tempo real e acrescentando aos trabalhos de Wang, Jin e Feng (2006),
Wang, Cai e Feng (2009) e Wang, Holm e Adamson (2010) a usinagem remota que utiliza a
arquitetura de blocos de função. O objetivo foi desenvolver uma nova metodologia e algoritmos de
processamento para melhorar a adaptabilidade na produção digital. Um exemplo de planejamento
de processos distribuídos para a usinagem remota foi escolhido como um estudo de caso para
5.3 Trabalhos relacionados ao uso integrado das normas STEP-NC e IEC 61499 82
demonstrar a eficácia desta abordagem para a fabricação remota.
5.3 Trabalhos relacionados ao uso integrado das normas

STEP-NC e IEC 61499
5.3.1 STEP-NC e FBs para uma manufatura interoperável
Xu, Wang e Rong (2006) apresentaram um trabalho que introduz os dois padrões, STEP-NC e IEC
61499. O foco dos autores está em analisar, em profundidade, os padrões do ponto de vista de suas
funcionalidades como: fluxo de informação bidirecional entre CAD/CAM, compartilhamento de
dados através da Internet, o uso do conceito de usinagem baseada em features, modularidade e
reusabilidade, CNC autônomo e inteligente e portabilidade entre recursos. Segundo os autores,
ambos os padrões, embora independentes, suportam a manufatura interoperável, onde STEP-
NC é adequada no suporte do fluxo bidirecional de informação entre CAD/CAM e CNC,
compartilhamento de dados pela Internet, uso do conceito de usinagem baseada em features,
modularidade, reusabilidade e portabilidade entre recursos. Já os FBs por outro lado, fornecem
uma arquitetura útil para o desenvolvimento de controladores CNC interoperáveis e estratégias
de controle. Os autores vêem a combinação desses dois padrões como promissora e acreditam
que pesquisas posteriores terão como foco o uso de STEP-NC como sendo o compositor do
trabalho, contendo todas as informações necessárias, enquanto que os FBs serão vistos como os
fazedores do trabalho, executando os comandos de usinagem. Entretanto, não foi implementado
nenhum trabalho prático neste artigo, apresentando apenas conceitos e possíveis maneiras de
aplicação.
5.3.2 Aumetando a interoperabilidade da usinagem CNC com STEP-NC
Em Rauch et al. (2009) são discutidos os problemas existentes na atualidade com relação
à troca e padronização de dados em todo o ciclo de vida do produto. Os autores destacam
as melhorias com o uso da norma STEP-NC, que permite o desenvolvimento de abordagens
avançadas de programação NC e a melhoria da interoperabilidade entre CAD/CAM e CNC.
Porém, eles mostram a limitação encontrada quanto a implementação da STEP-NC nas indústrias,
onde acreditam ser necessária a abordagem da STEP-NC com os equipamentos existentes, que
possuem os sistemas legados, para demonstrar seus benefícios.
São discutidas questões centrais e introduz uma associação de duas plataformas de produção,
que têm sido propostas para encontrar uma manufatura eficiente e as necessidades de interopera-
bilidade. A primeira abordagem está em nível de chão de fábrica: a plataforma SPAIM (STEP-NC
Plataform for Advanced and Intelligent Manufacturing) torna real a abordagem da programação
STEP-NC. A segunda abordagem é em nível de negócios: a plataforma IIMP (Intelligent and
Interoperable Manufacturing Plataform) que realiza a portabilidade de dados heterogêneos entre
formatos proprietários e utiliza como arquitetura os FBs da IEC 61499.
Com isso, introduziu a combinação de duas plataformas de produção complementares com o

objetivo de uma melhor supervisão e integração dos sistemas de usinagem com o padrão STEP-
NC. A plataforma SPAIM demonstra as vantagens do modelo atual de dados STEP-NC e mostra
seu desempenho com equipamentos de fabricação industrial. Embora ainda principalmente em
nível de conceito, o IIMP promete ser uma ferramenta eficiente para trabalhar com sistemas
heterogêneos e torná-los interoperáveis.
5.3.3 CNC baseado em STEP-NC e FBs IEC 61499
Minhat et al. (2009) apresentaram a implementação de uma nova arquitetura aberta CNC
baseada no modelo de dados STEP-NC e blocos de funções da IEC 61499. A arquitetura
do CNC desenvolvida é em camadas, responsáveis pelo processamento, armazenamento de
dados e execução e utiliza o padrão de projeto MVC (Model-View-Control) em sua construção.
A vantagem descrita no trabalho, em separar as funções em camadas, está na flexibilidade
de adaptação do controlador. As camadas desenvolvidas foram divididas em duas categorias,
chamadas de: “Input Model and FB Generic Data Program” e “Machine Specifc or Native
Program”. Dentro da primeira categoria se enquadram as seguintes camadas: Camada 5 é
para fornecer as definições como Security Plane, Cutting Tool, Workplan, Workpiece, Clamping
Position e assim por diante; a Camada 4, chamada de Machining features, é implementada por
uma biblioteca de blocos de funções que parametrizam características e dados de usinagem.
Nesta camada é gerado o caminho da ferramenta para cada feature; a Camada 3, chamada de
Store, armazena todos os pontos e velocidades necessárias para executar a tarefa na máquina
ferramenta. Na segunda categoria, segundo a classificação, tem-se então a Camada 2, onde os
blocos de funções fazem e recebem pedidos de pontos armazenados em memória e calculam as
velocidades para cada eixo; e a Camada 1 é responsável por ativar o controle de movimento da
máquina acionando os drivers.
O protótipo com a arquitetura CNC proposta pelos autores foi implementado e testado em
um computador que controla uma máquina fresadora vertical de três eixos. O microcomputador
é usado na execução da aplicação dos FBs baseado em Java que foram construídos utilizando a
ferramenta FBDK e foram executados utilizando o FBRT.
Na implementação de software, baseado nos dados de projeto de uma peça provenientes de

um arquivo STEP-NC, é gerada uma aplicação de FBs. Neste estágio, esta conversão de dados
do arquivo STEP-NC em estruturas de FBs é feita manualmente, não possuindo uma geração
automática e integrada da aplicação. Com a construção manual da aplicação dos FBs, erros
podem ocorrer na transferência das informações contidas no arquivo STEP-NC para a rede de
FB e não viabiliza sua aplicação prática. Nesta transferência de informações não fica claro quais
os atributos STEP-NC usados pelos FBs para a geração do caminho da ferramenta, e um dos
principais problemas é a não descrição completa de como foi realizada a representação de dados
STEP-NC em FBs.
5.3.4 Sistema CNC baseado em STEP-NC e arquitetura de FBs
Em Minhat, Xu e Vyatkin (2009) é apresentado um sistema CNC baseado em STEP-NC e FBs,

chamada de STEPNCMillUoA. Sua arquitetura, um pouco diferente da arquitetura apresentada
em Minhat et al. (2009), mostra um sistema CNC, que consiste em:
• STEP-NC data (Dados STEP-NC);
• STEP-NC to FB translator (Tradutor STEP-NC para FB);
• Prototype of embedded CNC-FB (Protótipo embarcado CNC-FB);
• STEP-NC controller (Controlador STEP-NC).
O fluxo de projeto, conforme visualizado na Figura 5.3, começa com o desenvolvimento de

um modelo de dados STEP-NC descrevendo a peça a ser usinada. O arquivo de entrada STEP-NC
(arquivo físico Parte 21) contém dados de projeto e os dados de usinagem que são correlacionados
com outras informações necessárias na programação da peça, tais como requisitos de ferramentas,
parâmetros de usinagem, a geometria, tolerâncias, estratégia e informações tecnológicas.
Figura 5.3: Arquitetura proposta e fluxo de dados da STEPNCMillUoA
Fonte: Minhat, Xu e Vyatkin (2009)
O modelo de dados STEP-NC é descrito usando a linguagem EXPRESS. Modelos de

dados em EXPRESS não definem métodos de implementação. Um conjunto de ferramentas
de software e bibliotecas de programação do ST-Developer desenvolvida pela empresa STEP
Tools são utilizadas. Estas ferramentas e bibliotecas de funções podem trabalhar diretamente
com modelos de informação EXPRESS e conjuntos de dados definidos pelo EXPRESS. O
software também fornece ferramentas de esquema EXPRESS em forma de C++. Isto é feito
através da produção de código-fonte em C++, que pode ser usado para objetos (com essas
estruturas de dados e bibliotecas) para ler, escrever, criar, pesquisar e manipular qualquer dado
STEP e STEP-NC. Então, o tradutor STEP-NC para FB interpreta os dados STEP-NC e gera um
modelo FB equivalente que pode ser manualmente modificado usando o editor da ferramenta FB
Development Kit (FBDK), ferramenta esta mantida e distribuída pela HOLOBLOC.
O protótipo é implementado usando um microcomputador como controlador CNC, chamado

de PC-CNC, uma fresadora de três eixos, com uma unidade de controle de motores que impulsi-
ona três motores de passo. O software de execução da rede de FB é executado no PC e dispara a
execução da máquina ferramenta.
O sistema protótipo foi testado com a fabricação de diversas peças, uma das quais foi o
exemplo 1 da ISO 14649-11. Testes do sistema foram realizados usando a visualização da
simulação gráfica, seguido pela usinagem na máquina fresadora. A peça resultante ficou com as
mesmas características com a simulação, em termos de dimensões das formas usinadas.
Uma das contribuições está na tradução dos dados STEP-NC para a construção da aplicação
de FB. A ferramenta utilizada para a criação de código fonte C++, a ferramenta ST-Developer,
porém é uma ferramenta comercial, não é livre, impossibilitando assim a reprodução deste
trabalho que busca uma arquitetura aberta. E outra característica não detalhada está na transcrição
da estrutura de dados em C++ para FBs, não deixando clara a metodologia utilizada, nem o
formato dos arquivos dos FBs.
5.3.5 Uso de features e FBs na usinagem CNC
O projeto desenvolvido por Minhat e Xu (2009) examina uma fresadora CNC vertical operada
usando modelo de dados ISO 14649 e utilizando a tecnologia IEC 61499 FBs no controle.
Segundo os autores, em vez de codificar a trajetória da ferramenta para uma máquina CNC
diretamente, STEP-NC apenas fornece as informações necessárias das tarefas de usinagem.
Portanto, uma máquina CNC aderente a STEP-NC deve ser capaz de gerar o caminho da
ferramenta, sendo transferido a tarefa de gração do caminho da ferramenta para o controlador
no chão de fábrica. Um controlador aderente à STEP-NC foi desenvolvido com base em um
computador pessoal. A tecnologia de blocos de função é utilizada para desenvolver um modelo
para uma fresadora CNC vertical que converte os dados de um arquivo STEP-NC em um conjunto
de FBs.
O controlador STEP-NC desenvolvido é modular e implementado usando uma estrutura de

camadas de software baseada no padrão de projeto MVC permitindo desenvolvimento rápido
para máquinas CNCs genéricas ou mais especializadas. A camada Machine Model representa
o modelo de uma máquina específica, como número de eixos usados, o tipo de sinal para
movimentar esses eixos e as dimensões físicas necessárias para representar o modelo de uma
máquina real. Os FBs são usados para representar o controle dos eixos, ou seja, FBs executam
operações de máquina em baixo nível.
A camada “View” é desenvolvida para mostrar a simulação em tempo real. Esta camada em
conjunto com a “Machine Model” servem como uma plataforma de experimentação. A camada
“Control” é projetada para manter funções generalizadas de controle que não são relacionadas
com uma máquina específica. Uma arquitetura de cinco camadas foi modelada para analisar os
dados da STEP-NC em FBs, onde as camadas mais altas são informações mais genéricas, como
Workplan, plano de segurança e as features de usinagem, e as camadas mais baixas são operações
de mais baixo nível, como movimentação de eixos e saídas analógicas.
Neste trabalho foi provado que os blocos de função são um meio viável para o desenvol-
vimento de um controlador STEP-NC. As normas STEP-NC e blocos de função se encaixam
bem no fornecimento de uma arquitetura aberta de controle de um sistema CNC. O controlador
aderente a STEP-NC desenvolvido foi testado em simulação e na máquina real, utilizando o
exemplo 1 e 2 da norma ISO 14649-11, obtendo o modelo idêntico da peça usinada. No futuro,
mais FBs podem ser desenvolvidos para representar recursos de usinagem complexos e gerar
o caminho da ferramenta correspondente. É de valia destacar a não descrição da transcrição
do modelo de dados STEP-NC para blocos de função e como foram feitas as conexões entre
os FBs. Apenas é citado de como o desenvolvimento dos blocos de função foram feitos na
plataforma Java, existe a possibilidade de desenvolver um tradutor STEP-NC para Java, havendo
uma interligação com o editor de blocos de função, porém não foi descrito como foi feito.
5.3.6 Integração das normas ISO 14649 e IEC 61499 para a construção
de um CNC interoperável
No trabalho de FINKE Jr. et al. (2011) foi apresentado um sistema que utiliza os padrões
STEP-NC e IEC 61499 para desenvolver um controlador CNC. Isto é conseguido usando a
STEP-NC como modelo de dados, e a partir dela, gerar aplicativos baseados na norma IEC
61499, encapsulando os Workingsteps em blocos de função que são definidos em uma biblioteca
do controlador CNC. O controlador CNC possui um ambiente de execução para os FBs e uma
biblioteca de FBs Workingstep com algoritmos para a máquina com suas características de
usinagem associados. O arquivo STEP-NC é convertido automaticamente em estruturas de dados
e uma rede de instâncias de FBs que são executados conforme definidos na entidade Workplan.
O controlador CNC é composto por dois principais dispositivos: um microcontrolador e um

PC. O microcontrolador é responsável por receber as informações de posição e velocidade do PC
e, comandar os drivers de motores de passo através de saídas digitais. O PC tem como função
executar o editor de arquivo STEP-NC, compilá-lo e gerar a rede de FB. Após gerada, a rede
de FBs pode ser executada no ambiente de execução gerando o caminho da ferramenta para o
microcontrolador.
O PC fornece, conforme ilustrado na Figura 5.4, um ambiente de execução, a biblioteca

de FBs, o editor de arquivos STEP-NC e o compilador. O arquivo STEP-NC pode ser editado
diretamente no controlador, de modo que mudanças no chão de fábrica podem ser reenviadas
para o departamento de projeto. Para construir uma aplicação no controlador CNC, primeiro
o arquivo STEP-NC é compilado, gerando um código Assembler. Então, numa aplicação IEC
61499 contendo blocos de comunicação, que estão vinculados com os respectivos códigos
assembler, são concatenados pelo linker gerando um arquivo executável. Finalmente, o arquivo é
carregado e executado no RTE.
Figura 5.4: Controlador baseado em PC
Fonte: FINKE Jr. et al. (2011)
A biblioteca de FBs que é utilizada durante a execução da aplicação é composta por FBs de
serviço de interface que implementam a comunicação e FBs básicos representando os Workings-
tep. Nesta fase da pesquisa, os autores construíram a estrutura dos blocos de função utilizando a
linguagem C.
O compilador foi desenvolvido em Java e segue um modelo de arquitetura em duas partes: a

front-end e a back-end. A front-end e a back-end compartilham uma interface de comunicação
padrão, permitindo assim que uma front-end sirva para diversas back-end. Nesta implementação,
a front-end se refere a todo o processo de análise do arquivo STEP-NC e a back-end é a própria
aplicação usando o compilador. Assim, o mesmo compilador pode ser usado para qualquer tipo
de CNC ou aplicação, como simuladores 3D ou CAD/CAM. O back-end desenvolvido neste
trabalho é uma lista indexada para gerar códigos Assembler representando os FBs. A ponte
5.4 Discussões 89
entre as estruturas Java e estruturas em assembler é a biblioteca Javolution (JAVOLUTION,
2012), proporcionando interoperabilidade entre classes Java e Assembler. Este arquivo Assembler
gerado representa a rede de FBs contendo informações STEP-NC.
A IEC 61499 possibilitou o desenvolvimento de um sistema de controle flexível em hardware

e software, com um modelo de programação que incorpora elementos de programação da
orientação a objetos em sua linguagem com a vantagem de ser de fácil compreensão pelos
engenheiros de sistemas.
Foram alcançadas a interoperabilidade na cadeia de manufatura, a utilização do conceito de

features na usinagem das peças, modularidade e reusabilidade dos objetos FBs desenvovidos.
A portabilidade ainda não foi alcançada pela falta de integração com softwares e a não aderên-
cia completa com a norma IEC 61499. Sem a utilização destas ferramentas não é possível o
reaproveitamento da biblioteca construída em um ambiente de execução aderente a IEC 61499.
A tomada de decisões e autonomia foram parcialmente alcançadas pela geração dinâmica das
trajetórias e a rica estrutura do STEP-NC disponível no controlador.
Foi também proposta uma arquitetura em duas camadas, na qual uma delas contém FBs
de Workingsteps responsáveis pela geração da trajetória e na segunda camada é realizado o
posicionamento e comunicação da máquina-ferramenta. Através desta arquitetura, as alterações
dos dispositivos de controle da máquina podem ser realizadas sem alteração do programa de
controle. Esta arquitetura também permite a mudança da estratégia de controle através da
reprogramação da rede de FBs de comunicação e controle.
Uma das deficiências deste trabalho está na construção das estruturas dos blocos de funções,
as quais são desenvolvidas em linguagem C, onde a norma IEC 61499 prevê que a estrutura dos
blocos devem ser desenvolvidas utilizando a linguagem XML permitindo uma maior portabili-
dade e facilidade de transferência de bibliotecas através da Internet. Outra deficiência está no
ambiente de execução que executa rede de FBs com estrutura em linguagem C, não aderindo à
norma.
5.4 Discussões
Um dos problemas enfrentados quando se trata de integração das normas STEP-NC e

IEC 61499 está em como representar os dados STEP-NC na arquitetura IEC 61499. A grande
quantidade de parâmetros contidos no arquivo STEP-NC associados a cada executável, dificulta a
5.4 Discussões 90
representação destes dados em FBs ou rede de FBs. A literatura utilizada neste trabalho apresenta
diferentes maneiras de representar STEP-NC em IEC 61499. A maior dificuldade encontrada nas
representações descritas na literatura é a falta de clareza das informações. Poucas informações
foram encontradas sobre como foi realizada essa conversão, impossibilitando a reprodução do
trabalho e a realização de uma avaliação mais profunda dos resultados.
91
6 CNC-C2: Um CNC Interoperável

A literatura abordada neste trabalho mostra limitações quanto à integração das normas ISO
14649 e IEC 61499. Uma das principais dificuldades está na forma de representação dos dados
STEP-NC em FBs. Também existe uma deficiência na aderência com a norma IEC 61499
tanto das estruturas desenvolvidas quanto das ferramentas existentes. Devido aos problemas
encontrados e buscando um CNC interoperável é proposto o desenvolvimento de programas para
execução deste trabalho.
6.1 Solução para Integração das Normas
A integração das normas STEP-NC e IEC 61499 é a proposta, de forma automática, sem a
necessidade de interferência humana, na construção da rede de controle utilizando FBs a partir
do arquivo de entrada STEP-NC. O modelo de dados STEP-NC utilizado como entrada para o
CNC será convertido em um modelo de sistema aderente à IEC 61499, o qual será responsável
pela execução da usinagem utilizando o máximo de parâmetros STEP-NC de acordo com a
estrutura da máquina protótipo. Dentro do modelo do sistema gerado, deverá conter todas as
informações dos executáveis disponibilizadas pelo arquivo STEP-NC.
Os trabalhos encontrados representam os executáveis STEP-NC em FBs do tipo básico.

Dentro destes FBs básicos estão contidos os algoritmos para o cálculo do caminho da ferramenta
e utilização dos parâmetros associados a cada tipo de executável. Neste trabalho a proposta é
representar cada executável como sendo um modelo de recurso da IEC 61499, podendo conter
uma rede de FBs interna para realizar o cálculo do caminho da ferramenta. Essa proposta se
baseia no conceito dado pela norma IEC 61499, que define que o bloco de função do tipo básico
deve exercer funções básicas dentro da rede. Visto o grande número de parâmetros associados a
cada executável STEP-NC e a possível complexidade que pode ser atribuída à utilização destes
parâmetros para o cálculo do caminho da ferramenta, a construção de um modelo de recurso para
cada executável se mostra mais natural. Desta forma haverá flexibilidade para alterações futuras
nas estratégias de controle para a usinagem devido à maior modularidade implementada. Usando
esta estrutura, novos blocos de função podem ser instanciados e/ou criados para compor a rede
de FBs do recurso, podendo implementar algoritmos complexos, uso de inteligência artificial e
6.2 Estrutura da Máquina-Ferramenta e CNC-C2 92
otimização para o cálculo do caminho da ferramenta.
Tendo em vista a necessidade de geração dinâmica do modelo de sistema IEC 61499 referente
ao arquivo de entrada STEP-NC, o controlador deverá conter uma ferramenta de software capaz
de realizar essa tradução. A proposta é desenvolver um compilador, onde o código fonte é
um arquivo STEP-NC e o código alvo são arquivos aderentes à norma IEC 61499 no formato
XML contendo as informações STEP-NC e toda a estratégia de controle da máquina-ferramenta
representada em redes de FBs.
6.2 Estrutura da Máquina-Ferramenta e CNC-C2
O controlador CNC-C2 (CNC Compliant to STEP-NC and Compliant to IEC 61499) foi
desenvolvido baseado em PC (Personal Computer) e implementa a estrutura proposta, conforme
apresentada na Figura 6.1. No PC estão os principais softwares desenvolvidos neste trabalho.
Cada item desta estrutura será relatado nesta seção.
Figura 6.1: Estrutura do CNC-C2
Fonte: produção do próprio autor
De maneira a desenvolver um protótipo CNC interoperável, é proposto um CNC que utilize

como entrada um arquivo STEP-NC e uma arquitetura de controle baseada na norma IEC 61499
para comando de máquina. Espera-se que o compilador faça a leitura do arquivo STEP-NC de
entrada e construa um modelo de sistema IEC 61499 que contenha os recursos com todas as
informações STEP-NC e uma rede de FBs com a estratégia de controle da máquina, como mostra
a Figura 6.1. A partir do modelo de sistema gerado, propõe-se que um ambiente de execução
deve permitir a execução de uma rede de FBs a partir da leitura de arquivos no formato XML,
seguindo a norma IEC 61499. Este sistema gerado é constituído de instâncias de dispositivos e
estes, instâncias de recursos. Por fim, os recursos são constituídos de instâncias de FBs básicos
e/ou compostos. Para serem instanciados, os modelos de dispositivos, recursos e tipos de FBs
devem existir e estar alocados em uma biblioteca para poder realizar a cópia do objeto. Portanto,
desenvolveu-se uma biblioteca de tipos de FBs e recursos que está no computador juntamente
com o ambiente de execução desenvolvido. Para a criação desta biblioteca desenvolveu-se um
editor gráfico que facilita a construção dos FBs e recursos. Este editor gera arquivos no formato
XML conforme a estrutura definida pela IEC 61499 a partir dos dados editados na interface
gráfica desenvolvida. A biblioteca citada contém o recurso STEP-NC_DATA, com todos os
dados STEP-NC dos executáveis, obtidos a partir do compilador desenvolvido.
Todo o cálculo do caminho da ferramenta é realizado dentro do recurso de cada executável

antes de enviar os dados para o controlador de baixo nível. A comunicação inicia após a execução
de todos os recursos referentes aos executáveis STEP-NC. Na proposta, o recurso de comunicação
utiliza um protocolo MODBUS TCP/IP para a troca de dados com o gerenciador de comunicação,
fornecido pela empresa desenvolvedora do CLP integrado ao servoacionamento. Para realizar a
comunicação, um programa realiza essa troca de dados e encapsula dentro de um FB de serviço
de interface que será instanciado dentro do recurso de comunicação.
Com as ferramentas e a estrutura apresentada obteve-se um CNC interoperável, chamado

neste trabalho de CNC-C2 , e que tem as características individuais das duas normas utilizadas.
A seguir são apresentados os itens constituintes da estrutura proposta conforme numeração
apresentada na Figura 6.1.
6.2.1 Item 1 - Arquivo STEP-NC
O modelo de dados STEP-NC utilizado como fonte de dados é implementado utilizando a

linguagem EXPRESS no formato de arquivo definido na ISO 10303-21 (ISO, 1994b). Para a
validação deste modelo, foram construídos alguns arquivos STEP-NC de peças para a realização
dos testes, porém neste trabalho será apresentado apenas um arquivo STEP-NC para a peça
exemplo. Alguns destes arquivos foram gerados com o auxílio do CAD com exportação para
STEP, onde foram adicionadas informações de processo, ferramentas e informações tecnológicas
para a geração final do arquivo STEP-NC. Também foram construídos arquivos manualmente a
partir da norma ISO 14649. A adoção do formato da parte 21 em detrimento a outros como, por
exemplo, a ISO10303-27 ou ISO10303-28, se deu devido à existência prévia do conhecimento
da parte 21 em trabalhos anteriores realizados junto ao grupo, o que levou a não utilizar outras
formas de representação do arquivo STEP-NC como o formato XML ou Java (PACHECO et al.,
2011; FINKE Jr. et al., 2011).
6.2.2 Item 2 - Compilador
O modelo de arquitetura adotado no compilador desenvolvido neste trabalho segue o modelo

apresentado por (AHO; SETHI; ULLMAN, 1986), onde o processo de compilação é dividido
em duas grandes partes, a front-end e a back-end. Essa arquitetura foi adotada pois STEP-NC é
uma linguagem que é escrita apenas uma vez e é interpretada por diferentes CNC e aplicações.
O compilador desenvolvido neste trabalho possui uma front-end associada a STEP-NC, e uma
back-end para a geração de arquivos XML contendo FBs, modelo de recursos (resources) e
um modelo de sistema (system) que constituem a rede de blocos de funções responsáveis pelo
comando da máquina-ferramenta, mas deixando em aberto a possibilidade de se criar facilmente
outras back-ends, como por exemplo aplicações gráficas 3D mostrando visualmente a peça
representada pelo arquivo STEP-NC, entre outras. Nesta seção serão detalhadas as duas partes
que compõem o compilador.
6.2.2.1 Front-end do compilador desenvolvido
A front-end faz a análise sintática do código fonte STEP-NC e em seguida a análise semântica.
Caso nenhum erro seja encontrado, o usuário receberá as instâncias em Java dos objetos definidos
no código fonte de entrada.
Para que o compilador consiga relacionar as entidades da STEP-NC com objetos Java, ele
precisa ser carregado com um esquema de classes. Esse esquema é um conjunto de classes
Java definindo modelos de dados EXPRESS quaisquer, inclusive STEP-NC. Essas classes
instanciadas serão a saída da front-end, pois elas são fáceis de serem manipuladas por qualquer
tipo de aplicação. Um exemplo básico de como um modelo EXPRESS é representado em Java
pode ser visto na Figura 6.2. No diagrama desta imagem, o pacote family é providenciado pelo
usuário, enquanto o pacote datatypes é parte da front-end. Neste exemplo, aparece apenas a
classe TYPE<?> no pacote datatypes, mas outros dados já estão implementados, como LIST<?>
e Enumeration.
Figura 6.2: Representação de um modelo EXPRESS e um modelo UML usado para mapear Java
Fonte: Hasegawa et al. (2011)
Uma visão geral da front-end pode ser vista na arquitetura apresentada na Figura 6.3. Esta
arquitetura mostra: duas classes instanciáveis pelos usuários, a StepNCCompiler e a StepNCLoa-
der, a separação da análise sintática com a análise semântica, o uso de TO (Transaction Objects)
para troca de dados entre elas, e um conjunto de exceptions.
A Figura 6.4 mostra os objetos usados para trocar informações entre os componentes do
compilador e o usuário. EntityTO é a representação interna de uma entidade da STEP-NC,
onde ela armazena o número, o nome, a linha da declaração e uma lista de atributos. Fora do
compilador ela é usada apenas para representar os tipos da seção de cabeçalho.
Durante a execução do compilador, podem ser encontrados erros. Esses erros podem ser como
um arquivo de esquema corrompido, ou erros sintáticos e/ou semânticos no código fonte. Quando
algum tipo de erro ocorrer, o compilador gera uma exceção. Na Figura 6.5 é mostrada uma
imagem onde em InternalStepNCCompilerException são listados os erros juntamente com seus
identificadores. Essa exception contém informações suficientes para informar ao usuário onde o
erro ocorreu, facilitando a depuração. As Exceptions também podem ser lançadas de dentro das
classes de um esquema, para isso se usa a SchemaStepNCCompilerException, sendo útil para
replicar os efeitos das WHERE RULES, ou seja, restrições para os dados introduzidos, como por
exemplo, o tipo POSITIVE_LENGTH_MEASURE da STEP-NC tem uma WHERE RULE que
impõe que o valor numérico de entrada seja obrigatoriamente positivo. Se for introduzido um
Figura 6.3: Arquitetura do compilador desenvolvido
valor negativo, uma SchemaStepNCCompilerException é lançada.
O componente da análise sintática é visto na Figura 6.6. A interface define o método

runSyntacticAnalysis, o qual tem como entrada o código fonte STEP-NC e como saída uma
instância do objeto StepSectionsTO. Este objeto está descrito na Figura 6.4 e consiste em um
conjunto de EntityTO para cada seção da STEP-NC. Este método implementado faz uso da
StepNCParser, que é uma classe que encapsula a biblioteca JavaCC (JAVACC, 2012) com
JJTree (JJTREE, 2012). O gerador de parser JavaCC é implementado em Java, provendo boa
compatibilidade com aplicações Java. JavaCC usa o método top-down para verificação da
gramática, e é capaz de gerar uma árvore sintática com o uso da JJTree. Ela também faz o relato
de erros sintáticos encontrados no código fonte. Um exemplo de uma árvore sintática gerada
pelo JavaCC juntamente com JJTree pode ser vista na Figura 6.7.
A componente da análise semântica pode ser vista na Figura 6.8. O construtor da classe
SemanticAnalysis depende do StepNCLoader pois nessa fase todas as EntityTO da seção de
Figura 6.4: Objetos usados para trocar mensagens entre componentes do compilador e o usuário
dados serão convertidas em instâncias das classes Java do esquema usado. Neste processo de
conversão iniciado pelo método runSemanticAnalysis, várias verificações semânticas são feitas.
Caso algum erro seja encontrado, uma exceção interna será lançada, conforme Figura 6.5. Este
método irá retornar o objeto final que será repassado ao usuário, que é uma instância da classe
CompilerResultTO, vista na Figura 6.4.
As únicas classes acessíveis ao programador são a StepNCCompiler e a StepNCLoader, como

mostrado no diagrama de classes da Figura 6.9. A StepNCLoader é responsável por carregar na
memória do compilador o esquema de classes do usuário, e também manter um buffer de acesso
a essas classes para o compilador, agilizando o tempo de processamento. A StepNCCompiler é a
classe principal, pois é ela quem irá receber a StepNCLoader e o código fonte da STEP-NC do
programador, e com o método Compile retorna o resultado.
O diagrama de sequência da Figura 6.10 mostra a interação do programador com o compila-

dor. Em três passos é possível compilar qualquer esquema EXPRESS, basta carregar o esquema
com a StepNCLoader, carregar o compilador com o loader criado e iniciar a StepNCCompiler
com o código fonte que deseja analisar. Para tratamento de erros, basta colocar operações de
try/catch do Java sobre o método Compile.
O método Compile chamado pelo usuário irá invocar os métodos runSyntacticAnalysis e o

Figura 6.5: Exceptions do compilador
método runSemanticAnalysis, nesta ordem, como mostra o diagrama de sequência na Figura

6.11. A execução do método seguinte pode ser interrompida caso algum componente encontre
um erro.
O método runSyntacticAnalysis começa invocando o método run da StepNCParser, como

mostra o diagrama de sequência na Figura 6.12. Como descrito anteriormente, a StepNCParser
encapsula o JavaCC, por isso, este método irá fazer toda a análise léxica e sintática do compilador
e retornar ao nó raiz ( Start ) da árvore sintática. Caso nenhum erro léxico ou sintático seja
encontrado, o método runSyntacticAnalysis continua seu algoritmo percorrendo todos os nós
da árvore sintática, criando a EntityTO. Por último, o método runSyntacticAnalysis retorna uma
instância do objeto StepSectionsTO composta pelas duas Collections, uma da seção do cabeçalho
e outra da seção dados.
Figura 6.6: Componente da análise sintática
Figura 6.7: Árvore sintática gerada pelo JavaCC + JJTree
O processo de converter a árvore sintática para um conjunto de EntityTO é auxiliado por

métodos especializados encontrados dentro da classe EntityTO. Esses métodos recebem como
entrada o nó da entidade e com isso retira todas as informações necessárias para popular uma
instância de EntityTO, como visto na Figura 6.13.
A última fase da compilação é marcada pelo método runSemanticAnalysis, Figura 6.14. Este
método recebe como entrada o resultado do método runSyntacticAnalysis e retorna a linguagem
alvo. Ele mantém uma lista de entidades que ainda não foram instanciadas e enquanto existirem
Figura 6.8: Componente da análise semântica
Figura 6.9: Diagrama de classes mostrando as classes principais
entidades nesta lista, ele vai escolher uma delas e fazer várias verificações nela. Caso todas as
verificações estejam de acordo, ele irá então instanciar essa entidade e retirá-la desta lista. Esse
processo pode ser entendido como uma conversão entre um objeto EntityTO para uma classe
equivalente do esquema do programador.
6.2.2.2 Back-end do compilador desenvolvido
A segunda parte do compilador, chamada back-end, está ligada diretamente com a primeira parte,
a front-end. Nesta etapa do projeto desenvolveu-se uma aplicação onde suas principais funções
Figura 6.10: Diagrama de sequência: interação com o usuário
Figura 6.11: Diagrama de sequência: método Compile
são: verificar a existência de executáveis na entidade Workplan do arquivo STEP-NC, retirar as

informações das features e dos processos relacionados e gerar arquivos no formato XML com
estrutura definida pela norma IEC 61499. Os arquivos gerados serão descritos na seção 6.2.3.
Figura 6.12: Diagrama de sequência: método runSyntacticAnalysis
O processo de encontrar os executáveis é simples. É feita uma iteração no atributo its_elements

da entidade workplan. Cada elemento do its_elements é do tipo executable, que pode se especia-
lizar no tipo machining_workingstep. Este último tipo, contém um atributo chamado its_feature,
o qual pode ser uma instância de round_hole, closed_pocket ou qualquer outro SUPERTYPE de
machining_feature descrita na norma. Ao encontrar um executável, se verifica qual sua instância,
conforme mostrado na Figura 6.15, e então são relacionados todos os atributos em um vetor de
tamanho variável, conforme quantidade de posições necessárias para cada executable.
Para a geração destes arquivos, é utilizada a biblioteca JDOM, que é um protocolo de

aplicação que facilita a criação e atualização de arquivos XML (HUNTER, 2000).
6.2.3 Item 3 - Arquivo XML IEC 61499
A rede de FBs que irá compor a aplicação alvo fará uso dos parâmetros contidos no arquivo fonte
STEP-NC para cálculo de caminho de ferramenta e troca de informações com o controlador de
baixo nível. Para cada arquivo STEP-NC de entrada, tem-se uma nova configuração da rede de
Figura 6.13: Diagrama de sequência: new EntityTO
FBs para controle da máquina. Esse dinamismo requer uma geração de estruturas aderentes a
IEC 61499 a partir do arquivo STEP-NC de entrada. Neste trabalho desenvolveu-se como saída
do compilador, três arquivos gerados no formato XML. Esses três arquivos gerados, juntamente
com a biblioteca de FBs e modelos de resources desenvolvidos neste trabalho, compõem a rede
Figura 6.14: Diagrama de sequência: método runSemanticAnalysis
de FBs para a aplicação final. Esta rede é responsável pelo uso das informações STEP-NC para
cálculo do caminho da ferramenta, uso das informações tecnológicas e troca de dados com o
controlador de baixo nível. Segue uma descrição de cada arquivo gerado.
1. Arquivo System: Compõe a aplicação alvo, contendo as instâncias de todos os resources

necessários referente aos executáveis descritos no arquivo STEP-NC. A distribuição
pelos dispositivos é feita nesta etapa, contudo, será executado apenas no PC devido à
não disponibilidade de equipamentos aderente à norma IEC 61499 atualmente. Para a
geração deste arquivo, é necessário encontrar os atributos do tipo executável que estão
listados na entidade workplan, conforme descrito anteriormente. Foi definido que cada
executável STEP-NC seja convertido em uma instância de um resource correspondente
Figura 6.15: Trecho de código desenvolvido para a aplicação da back-end
for ( I n t e g e r N : resultadoDaCompilacao . d a t a S e c t i o n E n t i t i e s . keySet ( ) ) {

O b j e c t O = r e s u l t a d o D a C o m p i l a c a o . d a t a S e c t i o n E n t i t i e s . g e t (N ) ;
i f (O i n s t a n c e o f WORKPLAN) {
WORKPLAN w o r k p l a n = (WORKPLAN) r e s u l t a d o D a C o m p i l a c a o . d a t a S e c t i o n E n t i t i e s . g e t (N ) ;
A r r a y L i s t <EXECUTABLE> l i s t _ p l a n o _ d e _ t r a b a l h o = w o r k p l a n . i t s _ e l e m e n t s . v a l u e ;
i f ( l i s t _ p l a n o _ d e _ t r a b a l h o != n u l l ) {
i f ( l i s t _ p l a n o _ d e _ t r a b a l h o . size () >0){
f o r ( i n t i = 0 ; i < l i s t _ p l a n o _ d e _ t r a b a l h o . s i z e ( ) ; i ++) {
i f ( l i s t _ p l a n o _ d e _ t r a b a l h o . g e t ( i ) i n s t a n c e o f MACHINING_WORKINGSTEP) {
MACHINING_WORKINGSTEP e x e c u t a b l e =
(MACHINING_WORKINGSTEP) w o r k p l a n . i t s _ e l e m e n t s . v a l u e . g e t ( i ) ;
i f ( e x e c u t a b l e . i t s _ f e a t u r e i n s t a n c e o f PLANAR_FACE) {
PLANAR_FACE p l a n a r _ f a c e = (PLANAR_FACE) e x e c u t a b l e . i t s _ f e a t u r e ;
...
}
...
i f ( e x e c u t a b l e . i t s _ f e a t u r e i n s t a n c e o f ROUND_HOLE) {
ROUND_HOLE r o u n d _ h o l e = (ROUND_HOLE) e x e c u t a b l e . i t s _ f e a t u r e ;
...
}
}
e l s e i f ( l i s t _ p l a n o _ d e _ t r a b a l h o . g e t ( i ) i n s t a n c e o f NC_FUNCTION ) {
...
}
...
...
dentro do modelo do system. Definiu-se também que o nome da instância do resource

será o identificador do processo dado pelo arquivo STEP-NC concatenado com o símbolo
underline juntamente com o identificador da feature. Adotou-se esse nome para facilitar a
identificação do resource com o executable descrito pelo arquivo STEP-NC. Para tal, há
a necessidade da biblioteca conter o tipo de resource instanciado. A biblioteca de FBs e
resources desenvolvida será tratada na subseção 6.2.6. O modelo system projetado deve
conter: todos os resources que correspondem aos executáveis listados no arquivo STEP-NC
alvo; um resource do tipo “STEP-NC_DATA”, que será descrito no tópico seguinte; um
resource do tipo “SETUP”, que é responsável por fazer a configuração da máquina (zero
peça) e um resource de comunicação, responsável pela troca de dados com o controlador
de baixo nível. Na Figura 6.16 tem-se o modelo da linguagem de marcação XML de um
system genérico estruturado conforme a IEC 61499.
Figura 6.16: Exemplo de um arquivo system genérico da linguagem de marcação XML gerado a
partir do back-end do compilador
< System Name="NOME_DO_SYSTEM" Comment="−−−">


< V e r s i o n I n f o D a t e = " 1 0 / 0 1 / 2 0 1 2 " O r g a n i z a t i o n ="UDESC" A u t h o r ="LAPAS" V e r s i o n = " 0 . 0 " / >
< D e v i c e Name="NOME_DO_DEVICE" Type ="DEVICE_TYPE" >
< R e s o u r c e Name="STEP−NC_DATA1" Type ="STEP−NC_DATA" / >
< R e s o u r c e Name="SETUP_FRANK" Type ="SETUP" dx = " 5 0 " dy ="50" >



</ R e s o u r c e >
< R e s o u r c e Name="NOME_DE_INSTANCIA_DO_RESOURCE" Type ="NOME_DO_TYPE_DO_RESOURCE" >

< R e s o u r c e Name="NOME_DE_INSTANCIA_DO_RESOURCE" Type ="NOME_DO_TYPE_DO_RESOURCE" >
...
...
< R e s o u r c e Name="COMMUNICATION_FRANK" Type ="COMMUNICATION" dx = " 5 0 " dy ="500" >


</ Device >
</ System >
2. Arquivo Resource STEP-NC_DATA: este resource é o elemento central do arquivo system

descrito anteriormente. Foi definido com a característica de conter a ordem dos executáveis,
conforme listado na entidade workplan, e todas as informações provenientes do arquivo
STEP-NC relacionados a cada executável. Todas as informações e a chamada dos resources
serão provenientes deste resource STEP-NC_DATA. Este arquivo é constituído de FB de
interface e um FB do tipo básico com a função de chaveamento. O bloco de chaveamento
tem a função de selecionar, na ordem dada pelo arquivo STEP-NC, os FBs de comunicação
(publisher) para envio dos dados e chamada das instâncias do resources dos executáveis.
O FB de comunicação utilizado para o envio das informações STEP-NC e chamada do
resource é o publisher com comunicação local (somente PC). Para uma maior compreensão
deste resource, pode ser observado um caso genérico apresentado na Figura 6.17.
O resource STEP-NC_DATA contém o FB de serviço de interface que inicializa a execução

da aplicação, o bloco START. Ao iniciar a execução, o bloco START envia um evento para
Figura 6.17: Exemplo de funcionamento do resource STEP-NC_DATA desenvolvido
o FB SWITCH que dispara um evento para o primeiro publisher do resource. Ao disparar

o evento para o publisher, o subscribe do resource 2 é inicializado e recebe os dados
publicados (transição T1). Com isso o resource 2 é executado e ao finalizar publica para o
subscribe do STEP-NC_DATA a finalização do resource, passando uma string contendo
o nome de instância do resource (transição T2). No STEP-NC_DATA, o FB SWITCH
verifica a string recebida com suas condições do ECC e dispara o próximo evento. Assim
como descrito, será executado até finalizar todos os resources existentes no system.
3. Arquivo FBType SWITCH: tem como função chavear em sequência os eventos para a
execução dos publishers contidos no resource STEP-NC_DATA. Essa sequência é pre-
determinada pela sequência de executáveis listados na entidade WORKPLAN do arquivo
STEP-NC. Baseado nesta sequência é gerado o arquivo XML que representa este FB. O
ECC interno deste FB contém estados com os nomes das instâncias de todos os resources
contidos no system gerado. Quando o evento INIT é chaveado, o FB chaveia o primeiro
evento, o evento SETUP. Esse evento está conectado ao bloco publisher SETUP e con-
sequentemente inicializa a execução do resource SETUP. Ao término da execução do
resource SETUP, o FB subscribe contido no resource STEP-NC_DATA recebe uma String
informando o nome da instância do resource que encerrou a execução. A string recebida é
utilizada para seleção do próximo estado no ECC do bloco SWITCH. Com isso, o próximo
resource é inicializado e esse processo ocorre até o término de todos os resources contidos
no modelo system gerado, sendo que o último resource será o COMMUNICATION que é
responsável pelo envio das informações geradas pelos outros resources para o controlador
de baixo nível. O bloco COMMUNICATION será melhor detalhado na seção 6.2.6.
6.2.4 Item 4 - Visualização e Ambiente de Execução da Rede de FBs
Uma ferramenta para visualização e execução de FBs e rede de FBs foi desenvolvida e tem como
funcionalidades de visualização:
• Visualização de FBs do tipo básico e o ECC correspondente;
• Visualização de FBs do tipo composto, podendo acessar a visualização da rede interna do

FBs (permite acesso em profundidade);
• Visualização de FBs de Serviço de Interface e o diagrama de tempo correspondente;
• Visualização do modelo de recurso (permite acesso em profundidade);
• Visualização do modelo de dispositivo (permite acesso em profundidade);
• Visualização do modelo de system (permite acesso em profundidade);
A ferramenta ainda permite a chamada e utilização do compilador (descrito na seção 6.2.2),

a partir da interface gráfica mostrada na Figura 6.18 e possibilita a execução de rede de FBs a
partir da chamada e utilização do ambiente de execução desenvolvido neste trabalho. Através da
interface gráfica do visualizador mostrada na Figura 6.19 o usuário pode carregar o arquivo XML
que deseja visualizar. Após carregar o arquivo XML, o programa executa diversar etapas até fina-
lizar com a apresentação da imagem em tela. Para tal, houve a necessidade de construção de um
parser XML. O parser foi desenvolvido utilizando a biblioteca LuaExpat (IERUSALIMSCHY;
CARREGAL; GUISASOLA, 2003). e tem como função verificar os elementos constituintes do
arquivo XML e retirar os dados.
Nesta ferramenta de visualização foi incorporado um ambiente de execução de FBs e rede de

FBs que pode ser executado também através de linha de comando, sem a necessidade de executar
Figura 6.18: Interface gráfica para utilização do compilador desenvolvido, integrado com o
ambiente de visualização
Figura 6.19: Ambiente de visualização de FBs e rede de FBs desenvolvido neste trabalho
juntamente com o visualizador. A linguagem de programação utilizada no desenvolvimento da

ferramenta é a linguagem Lua (2012), que será descrito na seção 6.2.5. Através do visualizador,
pode-se inicializar a execução de uma rede de FBs através de um FB de serviço de interface com
o usuário. A ferramenta inicializa a execução através do FB com a função START, o qual possui
uma interface gráfica com o usuário permitindo a execução, conforme Figura 6.19.
O ambiente de execução é constituído de diversas classes, as quais interagem entre elas. As
principais classes desenvolvidas são:
• FB: é responsável por executar o parser para importação dos dados do XML referente aos
tipos de blocos básico, composto ou serviço de interface. Após a importação dos dados,
é identificado o tipo do bloco para direcionar para a classe específica. A identificação é
realizada pela análise do arquivo XML. Se o XML contém o elemento ECC, é direcionado
para a classe do tipo básico (basicFB). Se for detectado no XML uma rede de FBs,
tem-se um FB do tipo composto, então é direcionado para a classe do tipo composto
(compositeFB). Caso exista o elemento BaseFile no arquivo XML, este identifica que é do
tipo serviço de interface, direcionado então para a classe de serviço de interface (SI);
• Resource: a classe referente ao resource possui muita semelhança com a classe Composi-
teFB. A diferença está na necessidade do resource possuir serviço de interface, devido ao
fato de que o resource não possui eventos de entrada ou saída para a troca de informações.
A classe possui função de agendamento de dados e eventos (scheduler) que corresponde a
uma fila do tipo FIFO (First In, First Out), para um recurso single threaded (GERBER;
HANISCH, 2010);
• Device: instancia as classes de nível mais baixo seguindo a hierarquia dos modelos da IEC
61499;
• System: instancia as classes de nível mais baixo seguindo a hierarquia dos modelos da IEC
61499.
6.2.5 Item 5 - GASR FB Editor
Um editor aderente à norma IEC 61499 foi desenvolvido com o intuito de permitir a construção
e edição de FBs e redes de FBs com facilidade e possuir uma interface gráfica amigável com
o usuário. O desenvolvimento de um editor de FBs foi necessário visto que as ferramentas
existentes possuem algumas limitações/problemas que dificultam o uso. Algumas dessas não
possuem código aberto e em muitas a falta de documentação impossibilita o uso.
O GASR FB Editor foi desenvolvido utilizando a linguagem de programação Lua. O editor

permite construção e edição dos modelos de FBs básico, composto e serviço de interface, modelos
de recursos, de dispositivos e de system.
A ferramenta permite, através de sua interface gráfica, como mostrado na Figura 6.20:
• Criar ou editar:
– FB: permite a edição textual das informações como: nome de eventos e dados de
entrada e saída, relação de dados com eventos, comentários, nome do autor, data de
criação ou modificação e controle de versão. Os FBs devem ser de um dos três tipos:
∗ Básico: para o tipo básico, o editor permite a edição: dos algoritmos através
de uma janela para inserção textual do algoritmo e do ECC adicionando ou
excluindo estados (textualmente) e realizando as transições através da interface
gráfica;
∗ Composto: permite a edição da rede de FBs interna ao bloco. Possui campos

para adicionar ou remover instâncias de blocos pré existentes na biblioteca e
realiza conexões de dados e eventos desses blocos para a formação da rede;
∗ Serviço de Interface: além de permitir a edição da interface do bloco, possui um

campo para edição da sequência temporal;
– Recurso: permite a edição da rede interna através da interface gráfica, adicionando ou

removendo instâncias de tipos de blocos já existentes na biblioteca, e suas conexões;
– Dispositivo: permite a adição ou remoção de instâncias de recursos que irão constituir

o dispositivo. Este se classifica como sendo da classe 2, visto na seção 3.4.5, onde
possui a completa possibilidade de reprogramação dos dispositivos.
– System: permite a adição ou remoção de instâncias de dispositivos;
• Realizar a geração da estrutura XML a partir dos dados editados;
• Visualizar textualmente a estrutura do arquivo XML gerado;
• Realizar o armazenamento da estrutura XML na biblioteca.
O arquivo XML pode ser previamente visualizado pelo usuário através da ferramenta, que
disponibiliza uma caixa de texto contendo a estrutura gerada, conforme pode ser visto na Figura
6.21. No Apêndice A pode ser encontrado um guia do usuário do GASR FB Editor desenvolvido.
Figura 6.20: Interface gráfica do editor desenvolvido neste trabalho (aba selecionada FB Básico)
6.2.6 Item 6 - Biblioteca de FBs
Projetada para armazenar os tipos de FBs e resources necessários, a biblioteca é acessada pelas
ferramentas desenvolvidas para instanciar o tipo solicitado. Os blocos de função e resources
constituintes foram desenvolvidos utilizando o editor descrito na subseção anterior. Os modelos
de resources construídos para a biblioteca são:
• SETUP: projetado com a função de realizar a configuração da máquina para a peça a ser
usinada;
• STEP-NC_DATA: recurso esse gerado dinamicamente pelo compilador conforme já des-

crito;
• COMMUNICATION: construído com a função de leitura do arquivo (gerado durante

a execução) e troca de dados com o controlador de baixo nível. Neste recurso, um FB
com função cíclica foi implementado. Ao ler uma linha de coeficientes presentes no
Figura 6.21: Caixa de texto para visualização da estrutura XML gerada pelo editor desenvolvido
arquivo gerado, ele utiliza os coeficientes e aciona o FB de comunicação para transferi-los

para o controlador de baixo nível. Ao tranferir uma linha de coeficientes, o recurso fica
fazendo a leitura de um registrador do controlador de baixo nível, o qual indica o status do
controlador. Quando verificar status livre, é enviada a próxima linha de coeficientes. O
ciclo dura até alcançar a última linha de coeficientes presente no arquivo;
• DRILLING-ROUND_HOLE_RES, BOTTOM_AND_SIDE_ROUGH_MILLING-SLOT- SIM-

PLE_RES e BOTTOM_AND_SIDE_ROUGH_MILLING-PLANAR_FACE-SIMPLE_RES:
são responsáveis pelo cálculo do caminho da ferramenta e utilização dos parâmetros
de processo fornecidos pelo arquivo STEP-NC fonte. A lógica interna da rede tem por
objetivo central construir equações de retas ou circunferência e escrevê-las sequencia-
mente em um arquivo. Esse arquivo será utilizado pelo recurso COMMUNICATION para
tratamento e envio de dados para o controlador de baixo nível e também para uma saída
que redirecionada para o software Gmsh (GEUZAINE; REMACLE, 2010) que permite
a visualização gráfica das trajetórias da ferramenta. A forma de cálculo do caminho da
ferramenta não será descrito por questão de espaço e por não ser o foco deste trabalho,
mas é visto a necessidade de mais trabalho nesta área, onde pode-se alcançar um melhor
resultado com o apoio de empresas desenvolvedoras de sistemas CAM que já possuem um
conhecimento consolidado nesta área.
A rede interna dos resources desenvolvidos possui FBs básicos, compostos e serviço de
interface. Todos esses blocos estão contidos na biblioteca desenvolvida e foram construídos
com o auxílio do editor GASR FB Editor. Com a biblioteca, foi alcançada a característica de
expansibilidade para o controlador CNC desenvolvido, podendo expandir a biblioteca com a
adição de novos modelos IEC 61499.
Os resources responsáveis pelo cálculo do caminho da ferramenta e uso dos parâmetros

tecnológicos concebidos possuem à disposição todos os argumentos fornecidos pelo modelo de
dados STEP-NC.
6.2.7 Item 7 - Rede de Comunicação PC-CNC
A comunicação entre o PC e o controlador de baixo nível tem a função de troca de dados

para comando e controle da máquina. A comunicação pode ser realizada uilizando diversas
configurações que o fabricante do CLP disponibiliza. Dentre elas, destacam-se: através do meio
físico CAN, utilizando o protocolo CANOpen (CIA, 2008) (Figura 6.22); através da interface
RS485, utilizando o protocolo MODBUS RTU (Figura 6.23) (MODBUS, 2005) ou; através da
interface USB, onde a aplicação se comunica com um gerenciador de comunicação, utilizando
protocolo MODBUS TCP/IP, e o gerenciador comunica com o CLP, utilizando o protocolo
MODBUS RTU (Figura 6.24).
Neste trabalho é implementada a comunicação PC-CLP utilizando o gerenciador de comuni-

cação com interface USB devido à não necessidade de aquisição de um dispositivo físico para
realizar a comunicação, seguindo o modelo apresentado na Figura 6.24. Essa comunicação é
feita utilizando um gerenciador de comunicação que o fabricante do CLP fornece gratuitamente.
A interface USB física faz parte do pacote padrão do equipamento, sem custo adicional.
A máquina possui três servoacionamentos com um CLP incorporado em cada servoconversor.

Com isso, tem-se três CLPs incorporados na rede. Nesta rede, o PC está limitado a comunicar
com apenas um CLP devido à utilização do gerenciador de comunicação e uso da interface
USB. Essa limitação leva ao uso da rede CAN com o protocolo CANOpen (CIA, 2008) para
Figura 6.22: Proposta de utilização da rede CAN para comunicação entre os equipamentos
constituintes da rede.
comunicação entre os CLPs, também inclusos no pacote padrão. Na Figura 6.24 é mostrada como
é efetuada a troca de dados entre os equipamentos, descrevendo a interface e o protocolo utilizado
em cada estágio. Os FBs de serviço de comunicação implementados no PC se comunicam com o
gerenciador de comunicação através do protocolo MODBUS TCP/IP (MODBUS, 2005). Outros
possibilidades de porotocolos de comunicação podem ser adotadas com a utilização de outros
modelos de CLPs onde a solução aqui adotada foi em função do CLP utilizado neste trabalho.
Na solução adotada, a comunicação entre o CLP mestre e os escravos utiliza-se a rede CAN
com o protocolo CANOpen. Dentro deste protocolo, a troca de dados pode ser efetuada através
de pacotes de dados chamados de PDOs (Process Data Objects). Cada CLP possui um número
limite de oito PDOs de transmissão (TxPDO), mais oito PDOs de recepção (RxPDO) de dados.
A configuração da rede construída neste trabalho utiliza os oito pacotes PDOs de transmissão
do mestre. Os oito pacotes são divididos em: dois pacotes de dados gerais enviados para o CLP
escravo 1, três pacotes de dados de eixo também para o CLP escravo 1 e os outros três pacotes
PDOs de dados específicos de eixo para o CLP escravo 2. Outros pacotes de recepção de dados
foram utilizados no CLP mestre. O diagrama, mostrado na Figura 6.25, mostra todos os PDOs
Figura 6.23: Proposta de utilização da rede RS485 para comunicação entre os equipamentos
constituintes da rede.
utilizados para troca de dados entre os CLPs dos servoacionadores da rede, conforme descrito no
texto.
Os FBs de comunicação desenvolvidos para a comunicação entre a aplicação e o gerenciador

de comunicação possuem um arquivo base que contém comandos para chamada de um programa
responsável pela comunicação. Esse programa foi desenvolvido em Java e utiliza a biblioteca
Jamod (WIMBERGER; CHARLTON, 2010) que implementa o protocolo MODBUS TCP/IP. O
programa é responsável por habilitar a comunicação local com o gerenciador de comunicação
distribuído pela WEG, empresa fornecedora dos servoconversor SCA-06 (WEG, 2010a), escrever
múltiplos registradores e efetuar a leitura de múltiplos registradores.
6.2.8 Item 8 - Máquina
O conjunto de hardware mecânico utilizado foi obtido através da doação de uma estrutura
mecânica rígida. Neste trabalho, foi feita a troca dos motores de passo por servoacionamentos.
Algumas adaptações mecânicas foram realizadas para fixação dos servomotores na estrutura
Figura 6.24: Proposta de utilização do gerenciador de comunicação para transeferência de dados

entre os equipamentos constituintes da rede
da máquina. Acoplamentos foram projetados e usinados para conexão dos fusos com o eixo
do motor. Os servoacionamentos SCA-06 adquiridos são fabricado pela empresa WEG (WEG,
2010a).
Para melhor manuseio dos equipamentos, foi construída uma bancada para fixação dos
servoconversores juntamente com os disjuntores, o relé e uma fonte de alimentação. Na Figura
6.26 é apresentada a máquina protótipo construída, onde tem-se no grupo 1 da figura a estrutura
mecânica da máquina, onde estão os três servomotores que acionam os eixos X,Y,Z e uma
retificadora manual portátil que é o acionamento do eixo árvore. No grupo 2, tem-se os três
servoconversores, uma fonte de alimentação em 24Vcc para alimentação da parte de controle do
servoconversor, o relé acoplador para acionamento da retificadora manual portátil e os disjuntores
de proteção. E, por fim, o grupo 3 que é o computador onde estão as ferramentas de software
desenvolvidas para controle da máquina.
O servomotor utilizado neste trabalho é o modelo SWA 40-1.6-30 fabricado pela empresa
WEG (2010a), conforme descrito na seção 4.3.1.
O programa do CLP desenvolvido neste trabalho realiza o tratamento de uma estrutura de

Figura 6.25: Diagrama geral da configuração da rede CAN construída
Figura 6.26: Máquina e protótipo de controlador construído
dados proveniente do PC. A estrutura de dados é constituída por um identificador de mensagem

e parâmetros. A partir do identicador, o programa é desviado para a subrotina responsável por
tratar a mensagem específica. Por exemplo, se o identificador da mensagem é referente a uma
equação circular, então o programa faz o tratamento dos valores recebidos atribuindo as variáveis
internas do CLP, conforme projetado. A estrutura de dados desenvolvida para equação circular é
apresentada nas Figuras 6.27 e 6.28.
Figura 6.27: Estrutura de dados gerais construída para comunicação CAN
Figura 6.28: Estrutura de dados específicos por eixo construída para comunicação CAN
Devido à limitação do número de pacotes de dados possíveis de serem enviados pela

comunicação entre o PC e o mestre da rede CAN, foi adotada a separação entre dados gerais
e dados específicos por eixo. Após o cálculo, é realizado o acionamento dos motores com os
respectivos valores de eixo para movimentação da ferramenta, utilizando um bloco Ladder
projetado para realizar a movimentação, disponibilizado pelo fabricante. O fluxograma do
programa Ladder desenvolvido é mostrado na Figura 6.29.
Figura 6.29: Fluxograma base da programação Ladder desenvolvida
Após ligar os servoacionamentos, os CLPs internos aos servoconversores efetuam uma

inicialização, onde a rede CANOpen também é inicializada e verifica se todos os nós da rede
estão ativos. Após essa inicialização, é disponibilizada uma variável, chamada de “STATUS”
para informar ao computador a condição em que se encontram os CLPs. Caso a variável tenha
o valor 1, significa que os CLPs estão livres, podendo receber novos dados. Após receber um
novo conjunto de dados, os CLPs identificam através de um byte da mensagem, qual o tipo de
informação que está sendo recebida. Após essa identificação, é desviado o programa para o
trecho referente ao código de identificação e executada a rotina. Para as rotinas os são passados
os coeficientes das equações lineares ou circuladores é feita a interpolação destas equações e o
acionamento dos servomotores. O valor de incremento para o interpolador foi determinado via
testes na máquina. Após terminar a execução do trecho do programa, os CLPs retornam para a
condição livre e estão aptos a receberem novos dados do computador.
121
7 Testes e Discussões
Neste capítulo é apresentado o teste realizado e os resultados obtidos a partir de um estudo
de caso. Para esse estudo será utilizado um arquivo STEP-NC gerado, que descreve uma peça
exemplo. Na Figura 7.1 é mostrado o projeto da peça utilizada para a realização do teste. O
arquivo STEP-NC pode ser encontrado no Apêndice B.
Figura 7.1: Projeto da peça utilizada nos testes
A partir do arquivo STEP-NC, tem-se como objetivo a usinagem da peça utilizando as ferra-
mentas desenvolvidas neste trabalho. A peça contém: dois executáveis do tipo PLANAR_FACE,
sendo um com o plano inclinado; cinco executáveis do tipo SLOT e três executáveis do tipo
ROUND_HOLE. A seguir serão detalhados os resultados de cada fase para melhor compreensão,
7.1 Arquivo de entrada STEP-NC, Compilador e Arquivos XML gerados 122
observando que todas as fases estão integradas.
7.1 Arquivo de entrada STEP-NC, Compilador e Arquivos

XML gerados
Dado como entrada para o compilador o arquivo STEP-NC, o compilador executou todas
as fases de análise. No arquivo de entrada para o teste, foi adicionado um erro proposital para
a realização do teste com o compilador. Durante a compilação ocorreram três exceptions. As
exceptions foram referentes à mesma entidade da STEP-NC, onde foi detectado um número
diferente de parâmetros declarados comparado com o número de parâmentros esperado pelo
modelo de dados da STEP-NC. Na Figura 7.2 é mostrada a saída que o compilador gerou. Nas
outras duas exceptions que ocorreram apenas alteravam do valor da entidade e da linha, mas com
a mesma mensagem de erro.
Figura 7.2: Ocorrência de um Exception durante a compilação do arquivo exemplo
Internal
CODE: 113
ENTITY : 127
LINE : 117
MESSAGE : The number o f p a r a m e t e r s do n o t match . : D e c l a r e d : 4 | E x p e c t e d : 5
O modelo de dados STEP-NC define a entidade CUTTING_COMPONENT com cinco

parâmetros, conforme mostrado na Figura 7.3. Para prosseguir com a compilação, foi alterado o
número de parâmetros para cinco conforme especificado. Ao corrigir as três linhas, a compilação
foi realizada com sucesso e os três arquivos necessários para a construção do System contendo as
tarefas STEP-NC foram gerados.
A inclusão do erro proposital foi para mostrar o funcionamento do compilador desenvolvido

perante erros encontrados. Para melhor demonstração dos resultados obtidos nesta fase do
trabalho, o arquivo system gerado como saída do compilador encontra-se no Apêndice C. Pode-se
observar a presença de dez executables encontrados, que condizem com o arquivo STEP-NC
exemplo. Os demais arquivos XML gerados não estão mostrados devido a grande quantidade de
7.2 Editor de FBs e Biblioteca de blocos de função 123
Figura 7.3: Entidade CUTTING_COMPONENT definida pelo modelo de dados STEP-NC
ENTITY c u t t i n g _ c o m p o n e n t ;
tool_offset_length : length_measure ;
its_material : OPTIONAL m a t e r i a l ;
technological_data : OPTIONAL c u t t i n g _ e d g e _ t e c h n o l o g i c a l _ d a t a ;
expected_tool_life : OPTIONAL t i m e _ m e a s u r e ;
its_technology : OPTIONAL t e c h n o l o g y ;
END_ENTITY ;
Fonte: ISO (2003b)
texto, onde editadas, ultrapassariam à quantidade de vinte páginas.
7.2 Editor de FBs e Biblioteca de blocos de função
Para a construção da biblioteca de FBs e resources foi utilizado o editor desenvolvido neste
trabalho. A construção dos arquivos XML aderentes a IEC 61499 foi facilmente realizada através
da interface desenvolvida. A biblioteca possui:
• FB types:
– Básico: 65;
– Composto: 26;
– Serviço de interface: 34.
• Resources:
– SETUP;
– STEP-NC_DATA;
– COMMUNICATION;
– DRILLING-ROUND_HOLE_RES;
– MILLING-SLOT- SIMPLE_RES;
– MILLING-PLANAR_FACE-SIMPLE_RES.
• Device:
– PC.
7.3 Visualizador e Ambiente de Execução 124
Dentre os FBs básicos, tem-se: FBs de manipulação de eventos, operações matemáticas
simples, operações vetoriais, entre outros. Os FBs de serviço de interface implementados são de:
comunicação local, comunicação MODBUS TCP/IP e FB para inicialização da execução (FB
STARTER).
7.3 Visualizador e Ambiente de Execução
A ferramenta de visualização desenvolvida foi testada passando por todos os modelos da

IEC 61499 permitidos pela ferramenta. Na Figura 6.19 foi mostrada uma imagem da tela gerada
ao carregar um modelo do resource exemplo. O ambiente de execução, chamado a partir da
interface gráfica, também foi mostrado na Figura 6.19 e foi testado utilizando a estrutura de
controle aderente a IEC 61499 gerada a partir do arquivo STEP-NC da peça exemplo. O teste
demonstrou o funcionamento esperado das ferramentas desenvolvidas, executando a rede de
blocos de função e efetuando a troca de dados com o controlador de baixo nível. A ferramenta
disponibiliza ainda um arquivo relatório (trecho do arquivo no Apêndice D) descrevendo todas as
atividades executadas pelo ambiente, proporcionado ao usuário uma facilidade para identificação
de falhas e/ou processos executados.
7.4 Rede de Comunicação, CLP e Máquina-ferramenta
Ao executar o arquivo system da peça exemplo, a comunicação entre o PC e o CLP mestre é

inicializada. Ao mesmo tempo, ocorre a troca de dados entre os CLP da rede CAN. Essa troca de
dados obteve o resultado desejado, onde os dados foram transmitidos e recebidos corretamente.
A partir dos dados recebidos, os CLPs realizaram o processamento do programa e efetuaram

o controle da máquina, acionando o eixo árvore e os eixos coordenados para movimentação da
mesa. A estrutura mecânica se comportou dentro do esperado, usinando a peça, mostrando um
pouco de escorregamento entre o eixo do motor e o acoplamento do eixo Y.
7.5 Peça Usinada
A partir da execução da rede de FBs, uma das saídas do bloco de comunicação redireciona
para o software Gmsh (GEUZAINE; REMACLE, 2010) que permite a visualização gráfica das
trajetórias da ferramenta. A trajetória resultante para a peça teste é mostrada na Figura 7.4.
7.5 Peça Usinada 125
Figura 7.4: Visualização gráfica da trajetório de usinagem
Após a realização da troca de dados entre o PC e o controlador de baixo nível, obtém-se a

peça teste usinada, como mostrada na Figura 7.5.
Figura 7.5: Peça exemplo usinada
Na peça usinada estão presentes todos os executáveis (features) que estão listados no arquivo
7.6 Discussões 126
STEP-NC de entrada, obtendo-se assim a peça usinada como resultado final conforme o esperado.
Pode ser observado que não foi realizado o acabamento da peça pois não está implementada a
operação de acabamento.
7.6 Discussões
A partir da construção do CNC-C2 (Compliant to STEP-NC and Compliant to IEC 61499)

foi alcançada a interoperabilidade em toda a cadeia de produção (setor de projeto ao chão de
fábrica), a partir do uso da norma ISO 14649 e foi alcançada também a interoperabilidade no
controle da máquina a partir do uso da norma IEC 61499 onde os arquivos construídos possuem
sua estrutura no formato XML aderente à norma.
A estrutura CNC-C2 desenvolvida extrai de todos os dados dos executáveis listados no

arquivo STEP-NC, deixando a disposição, dentro do recurso, todos os dados para a rede de FBs,
desde dados geométricos, dados de ferramentas, dados tecnológicos, entre outros. Os recursos
desenvolvidos não utilizam todos os dados para cálculo do caminho da ferramenta, porém
disponibiliza-os. Comparando com os trabalhos relacionados, nota-se que o CNC-C2 utiliza um
número maior de informações que os demais, que, na maioria dos casos, são utilizados apenas
dados geométricos.
O CNC-C2 limitou-se à construção de três tipos de recursos: um para a usinagem de um

furo redondo (round_hole), um para ranhuras (slot) circular e reto e um recurso para faceamento
(planar_face) no plano XY e inclinado. Contudo, a sua ampliação é de fácil construção, onde
é necessário criar um novo recurso para cada novo executável STEP-NC desejado seguindo
uma lógica na construção e os blocos de interface de comunicação podem ser reutilizados dos
demais recursos. A entrada dos dados para o recurso sempre deve ser efetuada da mesma forma
para todos os recursos, alterando apenas o tipo do bloco referente ao executável desejado. Por
exemplo, para transferir os dados do executável “SLOT1”, deverá conter dentro do recurso um
bloco SUBSCRIBE_SLOT, o qual contém o número de parâmetros referente ao executável. A
partir daí, é implementada a lógica de utilização dos parâmetros conforme estratégia adotada pelo
projetista, que terá como saída equações geométricas que serão enviadas para fora dos recursos
através de blocos de comunicação com um formato comum a todos os recursos já existentes,
apenas reutilizando-os.
Outra característica observada a partir da utilização da representação de recursos para cada

7.6 Discussões 127
executável STEP-NC está na modularidade da lógica de utilização dos parâmetros STEP-NC.
Com essa modularidade alcançada, é conquistada uma maior facilidade de alteração/ampliação
da lógica de controle, comparado aos trabalhos relacionados apresentados, os quais utilizavam
FBs do tipo básico para representar executáveis STEP-NC, com isso houve um melhoramento
significativo na representação dos Workingsteps em IEC 61499.
Após o cálculo do caminho da ferramenta, um último recurso é executado, que é o recurso

de comunicação que efetua a transmissão das equações para o controlador de baixo nível. Neste
trabalho foi implementado usando o protocolo MODBUS TCP/IP, porém, caso seja alterado o
controlador de baixo nível e for necessário alterar o protocolo de comunicação, apenas o arquivo
base do bloco de comunicação precisa ser alterado. O arquivo base corresponde ao programa que
executará a comunicação, onde realmente está implementado o protocolo. Alterando esse único
arquivo, pode-se obter diferentes protocolos de comunicação, obtendo assim uma adaptabilidade
do controlador.
128
8 Conclusão
Neste trabalho foi apresentado o desenvolvimento de um controlador CNC aderente às normas
ISO 14649 (STEP-NC) e IEC 61499 (FB), chamado de CNC-C2 (CNC Compliant to STEP-NC
and Compliant to IEC 61499). A busca pela alteração do cenário atual foi um dos objetivos, onde
modernas máquinas-ferramenta CNC, apesar das inúmeras funcionalidades, ainda possuem a falta
de adaptabilidade, portabilidade e interoperabilidade. Esta pesquisa apresentou um método de
implementação de especificações em STEP-NC para IEC 61499 na construção de um controlador
aderente a estas normas e provê ferramentas de software capazes de cumprir com os requisitos
deste trabalho na busca por um CNC interoperável. Em um controlador CNC aderente às
normas ISO 14649 e IEC 61499, tem-se as características das normas como: portabilidade,
interoperabilidade, configurabilidade, uso de features, autonomia, distribuição e adaptabilidade.
A STEP-NC foi desenvolvida com o propósito de dispor um padrão consistente e de qualidade

para a manufatura, baseada em CNC. O padrão STEP-NC foi utilizado nesta pesquisa, pois
possui características desejadas para a nova geração de CNCs. STEP-NC provê um modelo de
dados orientado a objetos para CNC, com uma estrutura detalhada de interface de dados que
incorpora a programação baseada em features, onde há uma gama de informações tais como a
feature a ser usinada, o tipo de ferramenta a usar, as operações a realizar e o plano de trabalho.
Com isso, se tem que STEP-NC descreve “o que fazer”, contendo as tarefas, de modo que o
programa de usinagem da peça fornece ao chão de fábrica informações de nível mais elevado,
tratando termos utilizados na manufatura. Essas informações são as tarefas de usinagem e dados
tecnológicos associados às features. Com o uso do padrão STEP-NC, as modificações no arquivo
no chão de fábrica podem ser armazenadas mantendo a integridade das informações com o
departamento de projeto, o que possibilita um melhor intercâmbio e preservação de experiência
e conhecimento na empresa.
A IEC 61499 define um modelo geral e metodologia para descrever os blocos de função em
um formato independente da implementação. Ela permite a definição de um sistema através de
blocos de função conectados, que podem ser distribuídos em diferentes dispositivos. Os blocos
de função encapsulam os algoritmos necessários para cálculo do caminho da ferramenta para os
executáveis STEP-NC e comunicação entre usuário, controlador e máquina.
8 Conclusão 129
O controlador desenvolvido neste trabalho demonstrou a factibilidade do uso de STEP-
NC, provendo interoperabilidade na cadeia de manufatura. Ainda, o uso do modelo de dados
STEP-NC traz o uso do conceito de features, dando significado aos modelos geométricos no
controlador. Contudo, houve a necessidade do desenvolvimento de um compilador para leitura
e interpretação do arquivo de entrada transformando-o em uma aplicação alvo. Como saída, o
compilador gerou arquivos contendo redes de FBs para compor o modelo System, o qual contém
todas as informações STEP-NC e instâncias de modelos IEC 61499, em formato XML como
prevê a norma, facilitando a troca de bibliotecas entre ferramentas e a transferência via Internet.
A geração dos FBs e a geração de redes de FBs em arquivos XML foram realizadas de forma
automática, sem a necessidade de interferência humana na geração destes arquivos, diminuindo
a ocorrência de erros causados pelo operador.
Com o System que contém o conjunto de tarefas a serem executadas e juntamente com a
biblioteca de FBs e resources desenvolvida, foi possível a execução da rede de FBs e a usinagem
da peça de teste. Com a utilização de FBs e dados STEP-NC para a geração de trajetórias
dinamicamente foi atingido no controlador CNC o poder de tomada de decisões e autonomia,
podendo agregar diversos métodos computacionais avançados para otimização dos cálculos.
Neste trabalho, foi construída para cada entidade executable STEP-NC, um modelo de
resource IEC 61499 e foi alcançada maior facilidade para futuras melhorias no cálculo da
trajetória comparado com os trabalhos encontrados na literatura. Isto possibilita maior liberdade
ao projetista de agregar ou retirar FBs da rede para alterar a estratégia de controle. Para representar
os dados STEP-NC em FBs, foi criado dentro do resource STEP-NC_DATA um FB de serviço de
comunicação local contendo os dados para cada executable implementado neste trabalho. Perante
o grande número de dados STEP-NC existentes para cada executable, obteve-se FBs com muitas
variáveis para serem transmitidas a seus resources, porém, como se trata de comunicação local,
não ocorrem maiores dificuldades nesta transmissão. Como saída dos resources, foi criada uma
estrutura de dados comum a todos os resources, que são equações geométricas e não posições no
plano cartesiano. Essas equações geométricas são enviadas para o controlador de baixo nível,
que interpreta esses dados e realiza o acionamento do motor. Com isto, é alcançada a distribuição
de fragmentos de código pelos dispositivos da máquina com capacidade de processar essas
equações.
Outra característica conquistada no controlador desenvolvido foi a adaptabilidade em nível

de comunicação com diferentes controladores de baixo nível (CLP, microcontroladores, micro-
8 Conclusão 130
processadores, entre outros), consquistada pela utilização dos FBs de serviço de interface. Para a
comunicação com o controlador de baixo nível, foi desenvolvido um FB de serviço de interface
contendo o protocolo de comunicação MODBUS TCP/IP, o qual se comunica com o gerenciador
de comunicação do fabricante dos servoconversores. Caso seja substituído o controlador de baixo
nível da máquina (CLP), a única adaptação da rede de FBs é o FB responsável pela comunicação,
ficando com a mesma estratégia de controle para o cálculo do caminho da ferramenta.
Um ambiente de visualização gráfica aderente à IEC 61499 foi desenvolvido, e tem como
finalidade a visualização dos modelos IEC 61499 e das redes de FBs. Um ambiente de execução
também foi desenvolvido e integrado ao ambiente de visualização. A inicialização da execução
da rede pode ocorrer via ambiente de visualização, onde foi implementada uma interface com o
usuário para iniciar a execução da aplicação.
Com o CNC-C2 tem-se disponível uma máquina CNC que utiliza modelos IEC 61499 em
níveis de controle da máquina ferramenta oriundos da compilação de um arquivo STEP-NC
diretamente, sem o uso de código G/M, em uma arquitetura modular, expansível, aderente às
normas, interoperável e adaptável.
As principais contribuições desta pesquisa são:
• Construção de um controlador CNC para uma fresadora 2,5D eixos aderente às normas
ISO 14649 e IEC 61499;
• Implementação de operação de usinagem via FBs;
• Geração automática da rede de FBs;
• Análise léxica, sintática e semanticamente de um arquivo STEP-NC por um compilador;
• Completa ausência de código G/M;
• Estrutura de todos os modelos IEC 61499 descrito em XML aderente à norma;
• Cálculo das trajetórias geradas dinamicamente pelos FBs, permitindo que decisões possam
ser tomadas em tempo de execução;
• Uso do modelo de resource para representação de cada executable STEP-NC;
• Reconhecimento dos vários níveis de dados STEP-NC e utilização de modelos IEC 61499
de todos os tipos e níveis para controle.
8.1 Trabalhos Futuros 131
Limitações do trabalho:
• Implementa um conjunto de features prismáticas limitada: round_hole, slot e planar_face;
• Não disponibiliza um ambiente de simulação 3D para verificações;
• Não executa nenhum planejamento de processo sobre o arquivo STEP-NC.
Este trabalho resultou em um artigo: (no prelo) ROSSO Jr., R. S. U. ; FINKE, Hermann
J. ; HARBS, E. ; HASEGAWA, A. Y. ; HOUNSELL, Marcelo da S. ; LAFRATTA, Fernando
H. .STEP-NC Compliant Compiler, Microcontroller driven Function Blocks as a PC Open
Architecture for CNC Controller. International Journal of Computer Integrated Manufacturing,
2012.
8.1 Trabalhos Futuros
Como trabalhos futuros sugere-se que sejam realizadas as seguintes investigações:
• Desenvolvimento de um ambiente de simulação gráfica 3D a partir dos mesmos dados

enviados para o controlador de baixo nível;
• Expanção do back-end do compilador desenvolvido de maneira a alcançar um maior

número de features e processos STEP-NC, aumentando seu nível de conformidade com a
norma.
• Implementação de diferentes formas de comunicação entre PC e controlador de baixo

nível, adotando por exemplo o protocolo de comunicação CANOpen, tendo uma maior
velocidade de transferência de dados;
• Embarcar o ambiente de execução desenvolvido em diferentes dispositivos de hardware,

como por exemplo em microcontroladores;
• Desenvolvimento do modelo de aplicação aderente à IEC 61499 no software construída,

com a funcionalidade de permissão do usuário definir a distribuição entre os dispositivos
constituintes do sistema com inserção automática de blocos de comunicação durante o
processo de distribuição;
8.1 Trabalhos Futuros 132
• Alcançado o controlador CNC aderente à ISO 14649 e IEC 61499, pesquisa relacionada à
otimização de processo deve ser buscada. A implementação de algoritmos complexos em
rede de blocos de função para cálculo do caminho da ferramenta e uso dos parâmetro STEP-
NC associados às features e processos, deve, por exemplo, buscar na área de inteligência
artificial, soluções para otimização do processo de usinagem, diminuindo tempos de
usinagem, efetuando verificação do desgaste da ferramenta para obter uma vida útil maior
da ferramenta, entre outros fatores de otimização de processo.
Referências
4DIAC. Framework for distributed industrial automation (4DIAC). 2010. Disponível em:
<http://www.fordiac.org>. Acesso em: 10/11/12.
AHO, A. V.; SETHI, R.; ULLMAN, J. D. COMPILERS: principles, techniques, and tools. Boston,
MA, USA: Addison-Wesley Longman Publishing Co., Inc., 1986. ISBN 0-201-10088-6.
BEANSHELL. 2011. Lightweight Scripting for Java. Disponível em:

<http://www.beanshell.org/>. Acesso em: 10/11/12.
BENAVENTE, J. C. T. Um Sistema para o Projeto e Fabricação de Peças Mecânicas a Distância

Via Internet Aderente à Norma ISO 14649 (STEP-NC). Tese (Doutorado) — Universidade
Federal de Santa Catarina, Florianópolis, SC, 2011.
CALABRESE, F.; CELENTANO, G. Design and realization of a step-nc compliant cnc embedded
controller. In: 12th IEEE Conference on Emerging Technologies and Factory Automation (ITFA).
Praga, Republica Checa: International Conference on Emerging Technologies and Factory
Automation, 2007. p. 1010–1017.
CAPELLI, A. Automação Industrial: Controle do Movimento e Processos Contínuos. 1. ed. São

Paulo: Érica, 2006.
CENGIC, G.; LJUNGKRANTZ, O.; AKESSON, K. Formal Modeling of Function Block Ap-
plications Running in IEC 61499 Execution Runtime. In: 11th IEEE International Conference
on Emerging Technologies and Factory Automation (ETFA’2006). Patras, Grécia: International
Conference on Emerging Technologies and Factory Automation, 2006. p. 1269 –1276.
CESCHINI, G. W. Proposta de extensões a métodos e ferramentas de desenvolvimento de

sistemas de automção distribuídos baseados em modelo dados pela UML e pela IEC 61499.
Dissertação (Mestrado) — Escola Politécnica da Universidade de São Paulo - Departamento de
Engenharia de Computação e Sistemas Digitais, 2008.
CHOUINARD, J.; BRENNAN, R. Software for Next Generation Automation and Control. In:
4th IEEE International Conference on Industrial Informatics (INDIN’06). Singapura: IEEE
International Conference on Industrial Informatics, 2006. p. 886–891.
CIA. CANOpen. 2008. Disponível em: <http://www.can-cia.org/index.php?id=canopen>.

Acesso em: 10/11/12.
REFERÊNCIAS 134
DUNBININ, V.; VYATKIN, V. On Definition of a Formal Model for IEC 61499 Function Block.
EURASIP Journal on Embedded Systems, v. 2008, n. 426713, 2008.
ECLIPSE. 2011. Disponível em: <http://www.eclipse.org/>. Acesso em: 10/11/12.
FAY, A.; ZURAWSKI, R. Progress in industrial automation programming and design: from a
primitive to a simple solution. Industrial Electronics Magazine, IEEE, v. 3, n. 4, p. 24 –25, dec.
2009. ISSN 1932-4529.
FBENCH. Open source function block engineering tool. 2008. Disponível em: <http://oooneida-
fbench.sourceforge.net/>. Acesso em: 10/11/12.
FINKE Jr., H. Controle Numérico Computadorizado aderente às Normas STEP-NC e IEC 61499.
Joinville - SC: Universidade do Estado de Santa Catarina, 2011. Monografia - Especialização em
Computação Aplicada.
FINKE Jr., H.; ROSSO Jr. R. S. U.; HARBS, E.; HASEGAWA, A. Y.; HOUNSELL, M. d. S.;
LAFRATTA, F. H. Implementing ISO14649 and IEC61499 to Fulfill Interoperability in CNC. In:
6o COBEF - Congresso Brasileiro de Engenharia de Fabricação. Caxias do Sul - RS: Congresso
Brasileiro de Engenharia de Fabricação, 2011. p. 1–10.
GERBER, C.; HANISCH, H.-M. Does portability of IEC 61499 mean that once programmed
control software runs everywhere? In: 10th IFAC Workshop on Intelligent Manufacturing Systems.
[S.l.: s.n.], 2010. p. 29–34.
GERBER, C.; IVANOVA-VASILEVA, I.; HANISCH, H.-M. A Data processing Model of IEC
61499 Function Blocks with Integer-Valued Data Types. In: IMS’08: 9th IFAC Workshop on
Intelligent Manufacturing Systems. Szczecin, Poland: [s.n.], 2008. p. 239–244.
GEUZAINE, C.; REMACLE, J. Gmsh version 2.6. 2010. Disponível em:

<http://geuz.org/gmsh/>. Acesso em: 10/11/12.
GRABMAIR, G.; ZOITL, A.; STRASSER, T.; FROSCHAUER, R. Modelling Real-time Cons-
traints Regarding Reconfiguration Aspects for IEC 61499 Control Applications. In: 5th IEEE
Internacional Conference on Industrial Informatics (INDIN 2007). Vienna, Austria: IEEE Inter-
national Conference on Industrial Informatics, 2007. v. 2, p. 1089 –1094. ISSN 1935-4576.
HASEGAWA, A. Y.; HARBS, E.; JARENTCHUK, G.; ROSSO Jr., R. S. U. Controlador numérico
de interface aberta step-nc. In: Relatório de Iniciação Científica (relatório interno). UDESC:
[s.n.], 2011.
REFERÊNCIAS 135
Holobloc Inc. Function block development kit (FBDK). 2008. Disponível em:
<http://www.holobloc.org>. Acesso em: 10/11/12.
HUEMEI, H. Distributed and reconfigurable control of lower level machines in automatic

production line. In: 8th World Congress on Intelligent Control and Automation (WCICA). Jinan,
China: [s.n.], 2010. p. 2339 – 2344.
HUNTER, J. JDOM. 2000. Disponível em: <http://www.jdom.org>. Acesso em: 10/11/12.
IERUSALIMSCHY, R.; CARREGAL, A.; GUISASOLA, T. LuaExpat. 2003. Disponível em:

<http://matthewwild.co.uk/projects/luaexpat/>. Acesso em: 10/11/12.
INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC61131-3: Programmable

controllers - part 3: Programming languages. Geneva, January 2003. 210 p.
INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC61499-1: Function blocks -

part 1: Architecture. Geneva, January 2005. 108 p.
INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC61499-2: Function blocks -

part 2: Software tools requirements. Geneva, January 2005. 28 p.
INTERNATIONAL STANDARDS ORGANIZATION. ISO6983-1: Numerical control of machi-

nes - program format and definition of address words - part 1: Data format for positioning, line
motion and coutouring control systems. Geneva, January 1982. 14 p.
INTERNATIONAL STANDARDS ORGANIZATION. ISO10303-1: Industrial automation sys-

tems and integration - product data representation and exchange - part 1: Overview and funda-
mental principles. Geneva, 1994. 17 p.
INTERNATIONAL STANDARDS ORGANIZATION. ISO10303-21: Industrial automation

systems and integration - product data representation and exchange - part 21: Implementation
methods: Clear text encoding of the exchange structure. Geneva, 1994. 72 p.

methods: Java tm programming language binding to the standard data access interface with
internet/intranet extensions. Geneva, 2000. 100 p.
REFERÊNCIAS 136
tems integration — physical device control - data model for computerized numerical controllers -
part 1: Overview and fundamental principles. Geneva, January 2003. 27 p.

tems integration — physical device control - data model for computerized numerical controllers -
part 10: Genereal process data. Geneva, January 2003. 176 p.

methods: Xml representations of express schemas and data, using xml schemas. Geneva, 2007.
309 p.
ISAGRAF. Workbench v.5.0. 2009. Disponível em: <www.isagraf.com>. Acesso em: 10/11/12.
IVANOVA-VASILEVA, I.; GERBER, C.; HANISCH, H.-M. Basics of modelling iec 61499
function blocks with integer-valued data types. In: IMS’08: 9th IFAC Workshop on Intelligent
Manufacturing Systems. Szczecin, Poland: [s.n.], 2008. p. 233–238.
JAVACC. 2012. Java Compiler Compiler. Disponível em: <http://javacc.java.net/>. Acesso em:
10/11/12.
JAVOLUTION. 2012. Disponível em: <http://javolution.org/>. Acesso em: 10/11/12.
JJTREE. 2012. Disponível em: <http://javacc.java.net/doc/JJTree.html>. Acesso em: 10/11/12.
LEWIS, R. Modelling Control Systems Using IEC 61499 - Applying function blocks to distributed
systems. [S.l.]: The Institution of Engineering and Technology, 2001. (Iee Control Engineering
Series). ISBN 9780852967966.
LOFFREDO, D. Fundamentals of STEP Implementation. STEP Tools, 2000. Disponível em:

<http://www.steptools.com/library/fundimpl.pdf>. Acesso em: 10/11/2012.
LUA. 2012. Disponível em: <http://www.lua.org/>. Acesso em: 10/11/12.
LUDER, A.; SCHWAB, C.; TANGERMANN, M.; PESCHKE, J. Formal models for the ve-
rification of iec 61499 function block based control applications. In: Emerging Technologies
and Factory Automation, 2005. ETFA 2005. 10th IEEE Conference on. [S.l.: s.n.], 2005. v. 1, p.
105–112.
REFERÊNCIAS 137
MINHAT, M.; VYATKIN, V.; XU, X.; WONG, S.; AL-BAYAA, Z. A novel open CNC architec-
ture based on STEP-NC data model and IEC 61499 function blocks. Robotics and Computer-
Integrated Manufacturing, NY, USA, v. 25, n. 3, p. 560 – 569, Junho 2009. ISSN 0736-5845.
MINHAT, M.; XU, X. Feature-based machining using function block technology. In: IEEE
International Conference on Control and Automation, 2009. ICCA 2009. Christchurch, New
Zealand: IEEE International Conference on Control and Automation, 2009. p. 2398 –2403.
MINHAT, M.; XU, X.; VYATKIN, V. STEPNCMillUoA - A CNC System Based STEP-NC and
Function Block Architecture. International Journal of Mechatronics and Manufacturing Systems
(IJMMS), v. 2, n. 1/2, p. 3–19, 2009. ISSN 1753-1047.
MODBUS. 2005. Modbus Organization, Inc. Disponível em: <http://www.modbus.org/>.

NEWMAN, S.; NASSEHI, A.; XU, X.; Rosso Jr., R.; WANG, L.; YUSOF, Y.; ALI, L.; LIU,
R.; ZHENG, L.; KUMAR, S.; VICHARE, P.; DHOKIA, V. Strategic advantages of intero-
perability for global manufacturing using cnc technology. Robotics and Computer-Integrated
Manufacturing, v. 24, n. 6, p. 699–708, 2008.
NXTCONTROL. nxtStudio. 2010. Disponível em: <www.nxtcontrol.com>. Acesso em:

10/11/12.
OTTO, A.; HELLMANN, K. IEC 61131: A general overview and emerging trends. Industrial
Electronics Magazine, IEEE, v. 3, n. 4, p. 27 –31, dec. 2009. ISSN 1932-4529.
PACHECO, N. de O.; HARBS, E.; ROSSO Jr., R. S. U.; HOUNSELL, M. S.; LEAL, A. B.;
FERREIRA, J. C. E. Application of the STEP-NC standard in a computer numerical controlled
machining device. In: 21st Brazilian Congress of Mechanical Engineering - COBEM 2011. Natal
- RN: Anais do 21st Brazilian Congress of Mechanical Engineering, 2011.
RAUCH, M.; LAGUIONIE, R.; HASCOET, J.-Y.; XU, X. Enhancing CNC Manufacturing
Interoperability with STEP-NC. Journal of Machine Engineering, v. 4, p. 26–37, 2009.
ROSSO Jr., R.; ALLEN, R.; NEWMAN, S. Future Issues for CAD/CAM and Intelligent CNC
Manufacture. In: Proceedings of the International Manufacturing Conference. Belfast, UK: [s.n.],
2002. p. 115–124.
REFERÊNCIAS 138
ROSSO Jr., R. S. U. STEP Compliant CAD/CAPP/CAM System For Rotational Asymmetric Parts.
176 p. Tese (Doutorado) — Loughborough University, Loughborough, Inglaterra, 2005.
ROSSO Jr., R. S. U.; NEWMAN, S. T. Estrutura de dados para sistemas cad/cam aderente à
step. In: VI Congresso Ibero-Americano de Engenharia Mecânica. Universidade de Coimbra,
Coimbra, Portugal: [s.n.], 2003. p. 1019–1024.
SANTOS, A. A.; SOUSA, M. de. Replicação em Sistemas Distribuidos utilizando o Standard IEC
61499. In: XVII Congresso Brasileiro de Automática. Juiz de Fora - MG: Congresso Brasileiro
de Automática, 2008.
SILVA, E. L. da; MENEZES, E. M. Metodologia da Pesquisa e Elaboração de Dissertação. 3.

ed. Florianópolis - SC, 2001.
THRAMBOULIDIS, K. Development of distributed industrial control applications: the corfu

framework. In: 4th IEEE International Workshop on Factory Communication Systems. Vasteras,
Sweden: [s.n.], 2002. p. 39 – 46.
THRAMBOULIDIS, K.; TRANORIS, C. CORFU FBDK - Quick Start Guide. 0.7.0. ed.
[S.l.], 2003. Disponível em: <seg.ece.upatras.gr/Corfu/dev/CORFU_FBDK_Quick_Guide.pdf>.
Acesso em: 12/02/2011.
VLAD, V.; GRAUR, A.; TURCU, C. E.; FILOTE, C. Using Hierarchically Structured IEC 61499
Applications for Modeling Holonic Control Systems. Mediamira Science Publisher, v. 51, n. 2,
p. 119 – 127, 2010.
VYATKIN, V. IEC 61499 Function Blocks for Embedded and Distributed Control Systems
Design. [S.l.]: O3 neida and Instrumentation Society of America (ISA), 2007.
VYATKIN, V. The IEC 61499 Standard and its Semantics. Industrial Electronics Magazine,
IEEE, v. 3, n. 4, p. 40 –48, dec. 2009. ISSN 1932-4529.
VYATKIN, V. Iec 61499 as enabler of distributed and intelligent automation: State-of-the-art

review. Industrial Informatics, IEEE Transactions on, v. 7, n. 4, p. 768 –781, nov. 2011. ISSN
1551-3203.
VYATKIN, V.; DUNBININ, V. Execution Model of IEC 61499 Function Block based on Sequen-
tial Hypothesis. 2006. Private communication.
REFERÊNCIAS 139
VYATKIN, V.; HANISCH, H.-M. Modeling of IEC 61499 Function Blocks a Clue to their
Verification. In: Design and optimization of intelligent machine tools, Proceedings. Karpacz,
Poland: [s.n.], 2000. p. 59–68.
WANG, H. New Control Strategy for CNC Machines Via STEP-NC. Tese (Doutorado) — The
University Auckland, 2009.
WANG, H.; XU, X.; TEDFORD, J. D. An adaptable cnc system based on step-nc and function
blocks. International Journal of Production Research, v. 45, n. 17, p. 3809–3829, Setembro
2007.
WANG, L.; CAI, N.; FENG, H.-Y. Function blocks enabled dynamic set-up dispatching and
execution monitoring. International Journal of Computer Integrated Manufacturing, v. 22, n. 1,
p. 3–12, 2009.
WANG, L.; FENG, H.-Y.; SONG, C.; JIN, W. Function block design for adaptive execution
control of job shop machining operations. International Journal of Production Research, v. 47,
n. 12, p. 3413–3434, Junho 2009.
WANG, L.; HOLM, M.; ADAMSON, G. Embedding a Process Plan in Function Blocks for
Adaptive Machining. CIRP Annals – Manufacturing Technology, v. 59, n. 1, p. 433–436, 2010.
WANG, L.; JIN, W.; FENG, H. Y. Embedding machining features in function blocks for distribu-
ted process planning. International Journal of Computer Integrated Manufacturing, n. 19: 5, p.
443 – 452, 2006.
WEG. Automação - Servoconversor SCA06 e Servomotor SWA. [S.l.], 2010. Disponível em:
<http://www.weg.net/>. Acesso em: 10/11/12.
WEG. Software WLP - Manual do Usuário. [S.l.], 2010. Disponível em: <http://www.weg.net/>.
WEI, Y. Implementation of IEC 61499 Distributed Function Block Architecture for Industrial Me-
asurement and Control Systems (IPMCS). Tese (Doutorado) — National University of Singapore,
2002.
WIMBERGER, D.; CHARLTON, J. Jamod. 2010. Disponível em:

<http://jamod.sourceforge.net/>. Acesso em: 10/11/12.
REFERÊNCIAS 140
XU, X.; NEWMAN, S. Making CNC machine tools more open, interoperable and intelligent—a
review of the technologies. Computers in Industry, v. 57, n. 2, p. 141 – 152, 2006. ISSN 0166-
3615.
XU, X. W.; WANG, L.; RONG, Y. STEP-NC and function blocks for interoperable manufacturing.
IEEE Transactions on Automation Science and Engineering, v. 3, n. 3, 2006.
YUSOF, Y.; CASE, K. Design of a step compliant system for turning operations. In: 19th Interna-
tional Conference on Flexible Automation and Intelligent Manufacturing - Lean manufacturing
and Services. Robotics and Computer-Integrated Manufacturing: [s.n.], 2010. v. 26, p. 753–758.
YUSOF, Y.; TAN, N. Z. Z.; KASIM, N. Exploring the ISO 14649 (STEP-NC) for Intelligent
Manufacturing System. European Journal of Scientific Research, v. 36, n. 3, p. 445–457, 2009.
ZHANG, X.; NASSEHI, A.; NEWMAN, S. Process comprehension for interoperable cnc manu-
facturing. In: Computer Science and Automation Engineering (CSAE), 2011 IEEE International
Conference on. [S.l.: s.n.], 2011. v. 4, p. 225 –229.
ZHU, X.; WANG, Y.; FU, H. A 3-D Simulation System for Milling Machining Based on STEP-
NC. In: The Sixth World Congree on Intelligent Control and Automation - WCICA. [S.l.: s.n.],
2006. v. 2, p. 6137–6141. ISSN 1-4244-0332-4.
ZOITL, A.; STRASSER, T.; SUNDER, C.; BAIER, T. Is IEC 61499 in harmony with IEC 61131-
3? Industrial Electronics Magazine, IEEE, v. 3, n. 4, p. 49 –55, dec. 2009. ISSN 1932-4529.
141
APÊNDICE A - GASR FB Editor: Guia do Usuário

O GASR FB Editor tem a finalidade de permitir a construção e edição de FBs e redes de FB,
aderente à norma IEC 61499, com facilidade e possuir uma interface amigável com o usuário.
Neste Guia do Usuário serão apresentadas as telas do software e uma explicação sobre seus
campos e funções.
•Tela Inicial - Aba Basic: Ao executar o programa, uma interface inicial é mostrada para
o usuário, conforme mostra a figura a seguir.
Figura: Tela incial do GASR FB Editor (aba FB básico)

APÊNDICE A - GASR FB Editor: Guia do Usuário 142
Na barra de ferramentas (parte superior da tela) tem-se algumas funções que podem ser
executadas pelo usuário, como:
–New block: utilizada para a criação de um novo bloco ou modelo aderente à IEC
61499. Ao cliclar nesta função, uma janela é aberta (conforme figura a seguir) e o
usuário pode inserir o nome do FB a ser criado e seleciona o tipo de modelo IEC
61499.
Figura: Interface para criação de um novo FB
–Load XML block: esta função serve para abrir um FB ou modelo já existente para
editá-lo.
–Settings: esta função é utilizada para selecionar o caminho em que o arquivo XML
gerado deve ser salvo. Este caminho deve indicar o diretório onde está localizada a
bliblioteca de FBs. Uma tela é aberta para facilitar a seleção do diretório, conforme
mostra a figura a seguir.
Figura: Interface para configuração do caminho da biblioteca de FBs
–Generate XML: esta função realiza a geração do arquivo no formato XML a partir das
informações editadas na interface gráfica referente ao modelo IEC 61499 selecionado
nas abas do programa.
–View XML: esta função mostra em uma janela o código XML gerado.
–About: apresenta informações sobre a ferramenta como: versão, data do desenvolvi-

mento e grupo desenvolvedor.
Abaixo da barra de ferramentas, tem-se um quadro chamado “Header” onde existem
campos que podem ser preenchidos com informações de cabeçalho, como:
–FB Name: nome do FB;
–Comment: comentário;
–Organization: organização desenvolvedora do FB;
–Version: versão do FB desenvolvido;
–Author: autor do FB;
–Date: data de criação do FB;
Na tela inicial do GASR FB Editor, a aba selecionada é a aba Basic onde existem campos
a serem preenchidos/editados para a criação ou edição de um FB do tipo básico. Na coluna
da esquerda da tela, tem-se a possibilidade de editar os dados e eventos de entrada e saída.
Essa coluna é semelhante para o bloco do tipo básico, composto e serviço de interface
e é onde são editadas informações referente a estrutura dos blocos. Os eventos e dados
de entrada e saída podem ser adicionados por botões dispostos na interface gráfica onde
existem os campos correspondentes a serem preenchidos de forma bem prática e fácil,
apenas seguindo o detalhamento existente na tela. Na coluna da esquerda da tela, na aba
Basic existem um quadro onde são adicionado algoritmos e esses podem ser editados em
uma janela separadamente. Outro quadro é referente ao controle de execução, o Execution
Control Char, onde possui botões para que o usúário crie estados e transições adicionando
as ações a serem tomadas em cada estado com a seleção do algoritmo a ser executado.
Após editadas todas a informações do bloco, o usuário deve gerar o arquivo XML, podendo
vizualiza-lo posteriormente.
•Aba Composite: Na aba para criação e edição do FB do tipo composto, existe de forma
semelhante à aba Basic já apresenta, uma coluna para criação e edição de dados e eventos
de entrada e saída para a construção da estrutura do bloco. Já na coluna da direita, existe
um quadro chamado Funtion Blocks Network onde são adicionados blocos do tipo básico,
composto e/ou serviço de interface para formarem a rede interna ao FB composto. Neste
quadro também possui campos onde são feitas as conexões de eventos e dados entre
os blocos constituintes da rede e a estrutura do bloco composto a ser criado ou editado,
conforme pode ser visualizado na figura a seguir.
Figura: Interface para criação e edição do FB composto
•Aba Service Interface: essa aba é utilizada para criação ou edição de FB do tipo serviço
de interface. Da mesma forma como para o FB do tipo básico e composto, essa aba possui
a coluna da esquerda (conforme figura a seguir) para a criação e edição dos dados e
eventos de entrada e saída do bloco, construindo assim a estrutura do FB. Na coluna da
direita, a interface dispoinibiliza um quadro para a inclusão do arquivo base do FB, qual
contém o algoritmo necessário para executar a função para que o bloco se destina com
características do hardware onde será implementado o FB. Outro quadro, chamado de
Service (Time-sequence diagram) editing serve para criar ou editar a sequência temporal
do FB conforme tratado na IEC 61499.
Figura: Interface para criação e edição do FB de Serviço de Interface
•Aba Resorce: esta aba tem a finalidade de criação ou edição do modelo de recurso da
IEC 61499. Nela encontra-se campos para a adição de blocos do tipo básico, composto
e/ou serviço de interface que irão compor a rede interna do recurso, fazendo a conexão de
eventos e dados, conforme mostra a figura a seguir.
•Aba Device: esta aba tem a finalidade de criação e edição do modelo de dispositivo da
IEC 61499. Esta aba está em desenvolvimento.
•Aba System: esta aba tem a finalidade de criação e edição do modelo de sistema da IEC
61499. Esta aba está em desenvolvimento.
Figura: Interface para criação e edição do modelo de recurso

147
APÊNDICE B - Arquivo STEP-NC construído

para teste
ISO −10303−21;
HEADER;
FILE_DESCRIPTION ( ( ’ P i e c e f o r FRANK’ ,
’ ’) , ’1 ’);
FILE_NAME ( ’ Peca_FRANK . s t p ’ , ’2012 −06 −20 ’ ,
( ’G . A . S . R . a t S a n t a C a t a r i n a S t a t e U n i v e r s i t y ’ ) , $ ,
’ ISO 1 4 6 4 9 ’ , $ ) ;
FILE_SCHEMA ( ( ’ MACHINING_SCHEMA’ , ’ MILLING_SCHEMA ’ ) ) ;
ENDSEC ;
DATA;
#1= PROJECT ( ’ EXECUTE_SLOTS ’ , # 2 , ( # 7 ) , $ , $ , $ ) ;
#2= WORKPLAN( ’MAIN WORKPLAN’ , ( # 4 0 , # 4 1 , # 4 2 , # 4 3 , # 4 4 , # 4 9 , # 4 5 , # 4 6 , # 4 7 , # 4 8 ) , $ , # 1 4 , $ ) ;
#7= WORKPIECE( ’FOAM PIECE ’ , # 1 3 , 0 . 0 1 , $ , $ , $ , $ ) ;
#13= MATERIAL( ’FOAM’ , ’FOAM ’ , ( ) ) ;
#14= SETUP ( ’ SETUP OF WORKPIECE’ , # 1 0 0 , # 1 0 4 , ( # 1 6 ) ) ;
#16= WORKPIECE_SETUP ( # 7 , # 3 5 0 , $ , $ , ( ) ) ;
#40= MACHINING_WORKINGSTEP( ’PLANAR_FACE’ ,#104 ,#60 ,#80 , $ ) ;

#41= MACHINING_WORKINGSTEP( ’ROUGHING SLOT1 ’ , # 1 0 4 , # 6 1 , # 8 1 , $ ) ;
#46= MACHINING_WORKINGSTEP( ’ DRILL HOLE1’ ,#104 ,#66 ,#86 , $ ) ;
#49= MACHINING_WORKINGSTEP( ’ PLANAR_FACE2’ ,#104 ,#69 ,#87 , $ ) ;
#60= PLANAR_FACE( ’PLANAR FACE1 ’ , # 7 , ( # 8 0 ) , # 1 0 9 , # 1 1 3 , # 1 1 8 , # 1 2 2 , $ , ( ) ) ;

#61= SLOT ( ’ SLOT1 ’ , # 7 , ( # 8 1 ) , # 1 2 5 , # 1 2 9 , # 1 3 2 , # 1 3 7 , ( # 1 4 0 , # 1 4 0 ) ) ;
#62= SLOT ( ’ SLOT2 ’ , # 7 , ( # 8 2 ) , # 1 4 1 , # 1 4 5 , # 1 5 0 , # 1 5 6 , ( # 1 5 9 , # 1 5 9 ) ) ;
#63= SLOT ( ’ SLOT3 ’ , # 7 , ( # 8 3 ) , # 1 6 0 , # 1 6 4 , # 1 6 7 , # 1 7 3 , ( # 1 7 6 , # 1 7 6 ) ) ;
#64= SLOT ( ’ SLOT4 ’ , # 7 , ( # 8 4 ) , # 1 7 7 , # 1 8 1 , # 1 8 6 , # 1 9 2 , ( # 1 9 5 , # 1 9 5 ) ) ;
#65= SLOT ( ’ SLOT5 ’ , # 7 , ( # 8 5 ) , # 1 9 6 , # 2 0 0 , # 2 0 5 , # 2 0 9 , ( # 2 1 2 , # 2 1 2 ) ) ;
#66= ROUND_HOLE( ’HOLE 1 ’ , # 7 , ( # 8 6 ) , # 2 1 3 , # 2 1 5 , # 2 2 0 , $ , # 2 2 2 ) ;
#67= ROUND_HOLE( ’HOLE 2 ’ , # 7 , ( # 8 6 ) , # 2 2 3 , # 2 2 5 , # 2 3 0 , $ , # 2 3 2 ) ;
#68= ROUND_HOLE( ’HOLE 3 ’ , # 7 , ( # 8 6 ) , # 2 3 3 , # 2 3 5 , # 2 4 0 , $ , # 2 4 2 ) ;
APÊNDICE B - Arquivo STEP-NC construído para teste 148
#69= PLANAR_FACE( ’PLANAR FACE2 ’ , # 7 , ( # 8 7 ) , # 2 4 3 , # 2 4 7 , # 2 5 2 , # 2 5 6 , $ , ( ) ) ;
#80= PLANE_ROUGH_MILLING ( $ , $ , ’ FINISH_PLANAR ’ , 1 0 . 0 , $ , # 3 0 0 , # 3 0 4 , # 3 0 5 , $ , # 3 0 6 , # 3 0 7 , # 3 0 8 , 0 . 0 , 0 . 0 ) ;

#81= BOTTOM_AND_SIDE_ROUGH_MILLING ( $ , $ , ’ROUGHING SLOT1 ’ , 1 0 . 0 , $ , # 3 0 0 , # 3 0 4 , # 3 0 5 , $ , # 3 0 6 , # 3 0 7 ,
#308 , $ , $ , 0 . 0 , 0 . 0 ) ;
#308 , $ , $ , 0 . 0 , 0 . 0 ) ;
#308 , $ , $ , 0 . 0 , 0 . 0 ) ;
#318 , $ , $ , 0 . 0 , 0 . 0 ) ;
#308 , $ , $ , 0 . 0 , 0 . 0 ) ;
#86= DRILLING ( $ , $ , ’ DRILL HOLE’ , 1 5 . 0 0 0 , $ , # 3 0 0 , # 3 0 4 , # 3 0 5 , $ , $ , $ , $ , $ , $ ) ;
#87= PLANE_ROUGH_MILLING ( $ , $ , ’ SLIDE ’ , 1 0 . 0 , $ , # 3 1 0 , # 3 1 4 , # 3 1 5 , $ , # 3 1 6 , # 3 1 7 , # 3 1 8 , 0 . 0 , 0 . 0 ) ;
#100= AXIS2_PLACEMENT_3D ( ’ SETUP1 ’ , # 1 0 1 , # 1 0 2 , # 1 0 3 ) ;

#101= CARTESIAN_POINT ( ’ SETUP1 : LOCATION’ , ( 1 0 . 0 , 1 5 0 . 0 , − 3 5 . 0 ) ) ;
#102= DIRECTION ( ’ AXIS ’ , ( 0 . 0 , 0 . 0 , 1 . 0 ) ) ;
#103= DIRECTION ( ’ REF_DIRECTION ’ , ( 1 . 0 , 0 . 0 , 0 . 0 ) ) ;
#104= ELEMENTARY_SURFACE( ’ SECURITIY PLANE’ , # 1 0 5 ) ;
#105= AXIS2_PLACEMENT_3D ( ’ PL_MAIN_SECPLANE ’ , # 1 0 6 , # 1 0 7 , # 1 0 8 ) ;
#106= CARTESIAN_POINT ( ’ SECPLANE1 : LOCATION ’ , ( 0 . 0 , 0 . 0 , 3 0 . 0 ) ) ;
#107= DIRECTION ( ’ AXIS ’ , ( 0 . 0 , 0 . 0 , 1 . 0 ) ) ;
#109= AXIS2_PLACEMENT_3D ( ’PLANAR_FACE_PLACEMENT’ , # 1 1 0 , # 1 1 1 , # 1 1 2 ) ;

#110= CARTESIAN_POINT ( ’ ’ , ( 0 . 0 , 0 . 0 , 0 . 0 ) ) ;
#111= DIRECTION ( ’ ’ , ( 0 . 0 , 0 . 0 , 1 . 0 ) ) ;
#112= DIRECTION ( ’ ’ , ( 1 . 0 , 0 . 0 , 0 . 0 ) ) ;
#113= ELEMENTARY_SURFACE( ’PLANE : DEPTH’ , # 1 1 4 ) ;
#114= AXIS2_PLACEMENT_3D ( ’PLANE : DEPTH’ , # 1 1 5 , # 1 1 6 , # 1 1 7 ) ;
#115= CARTESIAN_POINT ( ’PLANE : DEPTH ’ , ( 0 . 0 , 0 . 0 , − 7 . 0 ) ) ;
#116= DIRECTION ( ’ ’ , ( 0 . 0 , 0 . 0 , 1 . 0 ) ) ;
#117= DIRECTION ( ’ ’ , ( 1 . 0 , 0 . 0 , 0 . 0 ) ) ;
#118= LINEAR_PATH ( $ , # 1 1 9 , # 1 2 1 ) ;
#119= TOLERANCED_LENGTH_MEASURE( 1 0 0 . 0 0 0 , # 1 2 0 ) ;
#120= PLUS_MINUS_VALUE ( 0 . 3 0 0 , 0 . 3 0 0 , 3 ) ;
#121= DIRECTION ( ’COURSE OF TRAVEL DIRECTION ’ , ( 0 . 0 0 0 , 1 . 0 0 0 , 0 . 0 0 0 ) ) ;
#122= LINEAR_PROFILE ( $ , # 1 2 3 ) ;
#123= NUMERIC_PARAMETER( ’ PROFILE LENGTH’ , 1 0 0 . 0 0 0 , ’MM’ ) ;
#125= AXIS2_PLACEMENT_3D ( ’ SLOT1 ’ , # 1 2 6 , # 1 2 7 , # 1 2 8 ) ;

#126= CARTESIAN_POINT ( ’ ’ , ( 2 5 . 0 , 2 0 . 0 , − 7 . 0 ) ) ;
#127= DIRECTION ( ’ ’ , ( 0 . 0 , 0 . 0 , 1 . 0 ) ) ;
#128= DIRECTION ( ’ ’ , ( 1 . 0 , 0 . 0 , 0 . 0 ) ) ;
#129= ELEMENTARY_SURFACE( ’ SLOT1 : DEPTH’ , # 1 3 0 ) ;
#130= AXIS2_PLACEMENT_3D ( ’ SLOT1 : DEPTH’ , # 1 3 1 , $ , $ ) ;
#131= CARTESIAN_POINT ( ’ SLOT1 : DEPTH ’ , ( 0 . 0 , 0 . 0 , − 2 0 . 0 ) ) ;
#132= LINEAR_PATH ( # 1 3 3 , # 1 3 5 , # 1 3 6 ) ;
#133= AXIS2_PLACEMENT_3D ( ’ SLOT1 : TRAVEL_PATH_PLACEMENT’ , # 1 3 4 , $ , $ ) ;
#134= CARTESIAN_POINT ( ’ SLOT1 : TRAVEL_PATH_PLACEMENT ’ , ( 5 . 0 , 0 . 0 , 0 . 0 ) ) ;
#135= TOLERANCED_LENGTH_MEASURE ( 3 0 . 0 , # 1 3 9 ) ;
#136= DIRECTION ( ’ ’ , ( 1 . 0 , 0 . 0 , 0 . 0 ) ) ;
#137= SQUARE_U_PROFILE ( $ , # 1 3 8 , $ , $ , $ , $ ) ;
#138= TOLERANCED_LENGTH_MEASURE ( 6 . 0 , # 1 3 9 ) ;
#139= PLUS_MINUS_VALUE ( 0 . 1 , 0 . 1 , 3 ) ;
#140= OPEN_SLOT_END_TYPE ( ) ;

#142= CARTESIAN_POINT ( ’ ’ , ( 3 0 . 0 , 6 0 . 0 , − 7 . 0 ) ) ;
#143= DIRECTION ( ’ ’ , ( 0 . 0 , 0 . 0 , 1 . 0 ) ) ;
#144= DIRECTION ( ’ ’ , ( 1 . 0 , 0 . 0 , 0 . 0 ) ) ;
#145= ELEMENTARY_SURFACE( ’DEPTH SURFACE FOR SLOT2 ’ , # 1 4 6 ) ;
#146= AXIS2_PLACEMENT_3D ( ’ SLOT2DEPTH ’ , # 1 4 7 , # 1 4 8 , # 1 4 9 ) ;
#147= CARTESIAN_POINT ( ’ SLOT2DEPTH ’ , ( 0 . 0 , 0 . 0 , − 2 5 . 0 ) ) ;
#148= DIRECTION ( ’ ’ , ( 0 . 0 , 0 . 0 , 1 . 0 ) ) ;
#149= DIRECTION ( ’ ’ , ( 1 . 0 , 0 . 0 , 0 . 0 ) ) ;
#150= COMPLETE_CIRCULAR_PATH ( # 1 5 1 , # 1 5 4 ) ;
#151= AXIS2_PLACEMENT_3D ( ’ SLOT2 : TRAVEL_PATH_PLACEMENT’ , # 1 5 2 , $ , # 1 5 3 ) ;
#152= CARTESIAN_POINT ( ’ SLOT2 : TRAVEL_PATH_PLACEMENT’ , ( 0 . 0 , − 1 0 . 0 , 0 . 0 ) ) ;
#153= DIRECTION ( ’ ’ , ( 1 . 0 , 0 . 0 , 0 . 0 ) ) ;
#155= PLUS_MINUS_VALUE ( 0 . 1 , 0 . 1 , 3 ) ;
#156= SQUARE_U_PROFILE ( $ , # 1 5 7 , $ , $ , $ , $ ) ;
#158= PLUS_MINUS_VALUE ( 0 . 1 , 0 . 1 , 3 ) ;
#159= LOOP_SLOT_END_TYPE ( ) ;

#161= CARTESIAN_POINT ( ’ ’ , ( 5 0 . 0 , 9 0 . 0 , − 7 . 0 ) ) ;
#162= DIRECTION ( ’ ’ , ( 0 . 0 , 0 . 0 , 1 . 0 ) ) ;
#163= DIRECTION ( ’ ’ , ( 1 . 0 , 0 . 0 , 0 . 0 ) ) ;
#164= ELEMENTARY_SURFACE( ’ SLOT3DEPTH ’ , # 1 6 5 ) ;
#165= AXIS2_PLACEMENT_3D ( ’ SLOT3DEPTH’ , # 1 6 6 , $ , $ ) ;
#167= PARTIAL_CIRCULAR_PATH ( # 1 6 8 , # 1 7 1 , 2 2 5 . 0 ) ;
#168= AXIS2_PLACEMENT_3D ( ’ SLOT3 : TRAVEL_PATH_PLACEMENT’ , # 1 6 9 , $ , # 1 7 0 ) ;
#169= CARTESIAN_POINT ( ’ SLOT3 : TRAVEL_PATH_PLACEMENT’ , ( 0 . 0 , − 1 0 . 0 , 0 . 0 ) ) ;
#170= DIRECTION ( ’ ’ , ( − 1 . 0 , 0 . 0 , 0 . 0 ) ) ;
#172= PLUS_MINUS_VALUE ( 0 . 1 , 0 . 1 , 3 ) ;
#173= SQUARE_U_PROFILE ( $ , # 1 7 4 , $ , $ , $ , $ ) ;
#175= PLUS_MINUS_VALUE ( 0 . 1 , 0 . 1 , 3 ) ;
#176= LOOP_SLOT_END_TYPE ( ) ;

#178= CARTESIAN_POINT ( ’ ’ , ( − 3 . 0 , 7 0 . 0 , − 7 . 0 ) ) ;
#179= DIRECTION ( ’ ’ , ( 0 . 0 , 0 . 0 , 1 . 0 ) ) ;
#180= DIRECTION ( ’ ’ , ( 1 . 0 , 1 . 0 , 0 . 0 ) ) ;
#181= ELEMENTARY_SURFACE( ’DEPTH SURFACE FOR SLOT4 ’ , # 1 8 2 ) ;
#184= DIRECTION ( ’ ’ , ( 0 . 0 , 0 . 0 , 1 . 0 ) ) ;
#185= DIRECTION ( ’ ’ , ( 1 . 0 , 0 . 0 , 0 . 0 ) ) ;
#186= LINEAR_PATH ( # 1 8 7 , # 1 8 9 , # 1 9 1 ) ;
#187= AXIS2_PLACEMENT_3D ( ’ SLOT4 : TRAVEL_PATH_PLACEMENT’ , # 1 8 8 , $ , $ ) ;
#188= CARTESIAN_POINT ( ’ SLOT4 : TRAVEL_PATH_PLACEMENT ’ , ( 4 5 . 0 , 0 . 0 , 0 . 0 ) ) ;
#190= PLUS_MINUS_VALUE ( 0 . 1 , 0 . 1 , 3 ) ;
#191= DIRECTION ( ’ ’ , ( 1 . 0 , 0 . 0 , 0 . 0 ) ) ;
#192= SQUARE_U_PROFILE ( $ , # 1 9 3 , $ , $ , $ , $ ) ;
#194= PLUS_MINUS_VALUE ( 0 . 1 , 0 . 1 , 3 ) ;
#195= OPEN_SLOT_END_TYPE ( ) ;

#197= CARTESIAN_POINT ( ’ ’ , ( 4 0 . 0 , 5 0 . 0 , − 7 . 0 ) ) ;
#198= DIRECTION ( ’ ’ , ( 0 . 0 , 0 . 0 , 1 . 0 ) ) ;
#199= DIRECTION ( ’ ’ , ( 1 . 0 , 0 . 0 , 0 . 0 ) ) ;
#200= ELEMENTARY_SURFACE( ’ SLOT5 : DEPTH’ , # 2 0 1 ) ;
#201= AXIS2_PLACEMENT_3D ( ’ SLOT5 : DEPTH’ , # 2 0 2 , # 2 0 3 , # 2 0 4 ) ;
#202= CARTESIAN_POINT ( ’ SLOT5 : DEPTH ’ , ( 0 . 0 , 0 . 0 , − 2 2 . 0 ) ) ;
#203= DIRECTION ( ’ ’ , ( 0 . 0 , 0 . 0 , 1 . 0 ) ) ;
#204= DIRECTION ( ’ ’ , ( 1 . 0 , 0 . 0 , 0 . 0 ) ) ;
#205= LINEAR_PATH ( $ , # 2 0 6 , # 2 0 8 ) ;
#207= PLUS_MINUS_VALUE ( 0 . 1 , 0 . 1 , 3 ) ;
#208= DIRECTION ( ’ ’ , ( 1 . 0 , 0 . 0 , 0 . 0 ) ) ;
#209= SQUARE_U_PROFILE ( $ , # 2 1 0 , $ , $ , $ , $ ) ;
#211= PLUS_MINUS_VALUE ( 0 . 1 , 0 . 1 , 3 ) ;
#212= RADIUSED_SLOT_END_TYPE ( ) ;
#213= AXIS2_PLACEMENT_3D ( ’HOLE 1 ’ , # 2 1 4 , $ , $ ) ;

#214= CARTESIAN_POINT ( ’ ’ , ( 7 . 5 , 2 0 . 0 , − 7 . 0 ) ) ;
#215= ELEMENTARY_SURFACE( ’DEPTH SURFACE FOR ROUND HOLE1 ’ , # 2 1 6 ) ;
#218= DIRECTION ( ’ ’ , ( 0 . 0 , 0 . 0 , 1 . 0 ) ) ;
#219= DIRECTION ( ’ ’ , ( 1 . 0 , 0 . 0 , 0 . 0 ) ) ;
#221= PLUS_MINUS_VALUE ( 0 . 1 , 0 . 1 , 3 ) ;
#222= BLIND_BOTTOM_CONDITION ( ) ;

#224= CARTESIAN_POINT ( ’ ’ , ( 7 0 . 0 , 2 0 . 0 , − 7 . 0 ) ) ;
#226= AXIS2_PLACEMENT_3D ( ’ HOLE1 DEPTH’ , # 2 2 7 , # 2 2 8 , # 2 2 9 ) ;
#228= DIRECTION ( ’ ’ , ( 0 . 0 , 0 . 0 , 1 . 0 ) ) ;
#229= DIRECTION ( ’ ’ , ( 1 . 0 , 0 . 0 , 0 . 0 ) ) ;
#231= PLUS_MINUS_VALUE ( 0 . 1 , 0 . 1 , 3 ) ;

#234= CARTESIAN_POINT ( ’ ’ , ( 7 0 . 0 , 8 0 . 0 , − 7 . 0 ) ) ;
#236= AXIS2_PLACEMENT_3D ( ’ HOLE1 DEPTH’ , # 2 3 7 , # 2 3 8 , # 2 3 9 ) ;
#238= DIRECTION ( ’ ’ , ( 0 . 0 , 0 . 0 , 1 . 0 ) ) ;
#239= DIRECTION ( ’ ’ , ( 1 . 0 , 0 . 0 , 0 . 0 ) ) ;
#241= PLUS_MINUS_VALUE ( 0 . 1 , 0 . 1 , 3 ) ;
#243= AXIS2_PLACEMENT_3D ( ’PLANAR_FACE_PLACEMENT’ , # 2 4 4 , # 2 4 5 , # 2 4 6 ) ;

#244= CARTESIAN_POINT ( ’ ’ , ( 8 0 . 0 , 0 . 0 , − 7 . 0 ) ) ;
#245= DIRECTION ( ’ ’ , ( 0 . 0 , 0 . 0 , 1 . 0 ) ) ;
#246= DIRECTION ( ’ ’ , ( 1 . 0 , 0 . 0 , 0 . 0 ) ) ;
#247= ELEMENTARY_SURFACE( ’PLANE : DEPTH’ , # 2 4 8 ) ;
#248= AXIS2_PLACEMENT_3D ( ’PLANE : DEPTH’ , # 2 4 9 , # 2 5 0 , # 2 5 1 ) ;
#249= CARTESIAN_POINT ( ’ SLOT2 : DEPTH ’ , ( 8 0 . 0 , 0 . 0 , − 4 . 0 ) ) ;
#250= DIRECTION ( ’ ’ , ( 1 . 0 , 0 . 0 , 1 . 0 ) ) ;
#251= DIRECTION ( ’ ’ , ( 1 . 0 , 0 . 0 , − 1 . 0 ) ) ;
#252= LINEAR_PATH ( $ , # 2 5 3 , # 2 5 5 ) ;
#253= TOLERANCED_LENGTH_MEASURE( 1 0 0 . 0 0 0 , # 2 5 4 ) ;
#254= PLUS_MINUS_VALUE ( 0 . 3 0 0 , 0 . 3 0 0 , 3 ) ;
#255= DIRECTION ( ’COURSE OF TRAVEL DIRECTION ’ , ( 0 . 0 0 0 , 1 . 0 0 0 , 0 . 0 0 0 ) ) ;
#256= LINEAR_PROFILE ( $ , # 2 5 7 ) ;
#257= NUMERIC_PARAMETER( ’ PROFILE LENGTH’ , 2 0 . 0 0 0 , ’MM’ ) ;
#300= MILLING_CUTTING_TOOL ( ’ENDMILL 6 ’ , # 3 0 2 , ( # 3 0 1 ) , 3 2 . 0 , $ , $ ) ;

#301= CUTTING_COMPONENT ( 1 9 . 0 , $ , $ , $ , $ ) ;
#302= ENDMILL ( # 3 0 3 , 4 , . RIGHT . , . F . , $ ) ;
#303= MILLING_TOOL_DIMENSION ( 6 . 0 , $ , $ , $ , $ , $ , $ ) ;
#304= MILLING_TECHNOLOGY ( 0 . 0 4 , . TCP . , $ , $ , $ , . F . , . F . , . F . , $ ) ;
#305= MILLING_MACHINE_FUNCTIONS ( . F . , $ , $ , . F . , $ , ( ) , . T . , $ , $ , ( ) ) ;
#306= PLUNGE_TOOLAXIS ( $ ) ;
#308= CENTER_MILLING ( $ , $ ) ;
#310= MILLING_CUTTING_TOOL ( ’ENDMILL 6 ’ , # 3 1 2 , ( # 3 1 1 ) , 3 2 . 0 , $ , $ ) ;

#311= CUTTING_COMPONENT ( 1 9 . 0 , $ , $ , $ , $ ) ;
#312= ENDMILL ( # 3 0 3 , 4 , . RIGHT . , . F . , $ ) ;
#313= MILLING_TOOL_DIMENSION ( 6 . 0 , $ , $ , $ , $ , $ , $ ) ;
#314= MILLING_TECHNOLOGY ( 0 . 0 1 , . TCP . , $ , $ , $ , . F . , . F . , . F . , $ ) ;
#315= MILLING_MACHINE_FUNCTIONS ( . F . , $ , $ , . F . , $ , ( ) , . T . , $ , $ , ( ) ) ;
#318= CENTER_MILLING ( $ , $ ) ;
#350= AXIS2_PLACEMENT_3D ( ’ PL_WORKPIECE_EXAMPLE2’ , # 3 5 1 , # 3 5 2 , # 3 5 3 ) ;

#351= CARTESIAN_POINT ( ’ WORKPIECE1 : LOCATION ’ , ( 0 . 0 , 0 . 0 , 0 . 0 ) ) ;
#352= DIRECTION ( ’ AXIS ’ , ( 0 . 0 , 0 . 0 , 1 . 0 ) ) ;
ENDSEC ;
END−ISO −10303−21;
153
APÊNDICE C - Arquivo XML System gerado

Arquivo XML System gerado pelo compilador desenvolvido:
<? xml v e r s i o n = " 1 . 0 " e n c o d i n g ="UTF−8"?>

<!DOCTYPE System SYSTEM " l a p a s . d t d " >
< System Name=" System " Comment ="FRANK−I I i s t h e b e s t m a c h i n e " >

< V e r s i o n I n f o D a t e = " 1 0 / 0 1 / 2 0 1 2 " O r g a n i z a t i o n ="UDESC" A u t h o r ="LAPAS" V e r s i o n = " 7 . 0 " / >
< D e v i c e Name=" RTE_Lua " Type ="PC" dx = " 5 0 " dy ="50" >
< R e s o u r c e Name="STEP−NC_DATA1" Type ="STEP−NC_DATA" dx = " 5 0 " dy = " 1 5 0 " / >
< R e s o u r c e Name="SETUP_FRANK" Type ="SETUP" dx = " 5 0 " dy ="50" >



< R e s o u r c e Name="FINISH_PLANAR_PLANAR_FACE"
Type ="BOTTOM_AND_SIDE_ROUGH_MILLING−PLANAR_FACE−SIMPLE_RES " dx = " 1 5 0 " dy ="50" >



< R e s o u r c e Name="ROUGHING SLOT1_ROUGHING SLOT1"
Type ="BOTTOM_AND_SIDE_ROUGH_MILLING−SLOT−SIMPLE_RES " dx = " 1 5 0 " dy ="50" >


APÊNDICE C - Arquivo XML System gerado 154

< R e s o u r c e Name="SLIDE_PLANAR_FACE2"
Type ="BOTTOM_AND_SIDE_ROUGH_MILLING−PLANAR_FACE−SIMPLE_RES " dx = " 1 5 0 " dy ="50" >


< R e s o u r c e Name="DRILL HOLE_DRILL HOLE1" Type ="DRILLING−ROUND_HOLE_RES" dx = " 1 5 0 " dy ="50" >



< R e s o u r c e Name="COMMUNICATION_FRANK" Type ="COMMUNICATION" dx = " 5 0 " dy ="500" >


</ Device >
</ System >
155
APÊNDICE D - Trecho do Arquivo Relatório do

Ambiente de Execução
S t a r t e r −−− START_WORK e x e c u t i o n c o m p l e t e d
S t a r t e r −−− START_WORK r e t u r n e d e v e n t : s t a r t
RESOURCE−−− STEP−NC_DATA1 −> s t a r t e d w i t h START_WORK . s t a r t
BasicFB−−− "EXECUTABLE_SWITCH" s t a r t e d w i t h e v e n t : START
BasicFB−−−I s on s t a t e : START
BasicFB−−−E v e n t : START i n c o m i n g
BasicFB−−−Changed t o s t a t e : SETUP
BasicFB−−−A c t i o n No . : 1
BasicFB−−−A l g o r i t h m = a l g
BasicFB−−−E v e n t o u t = SETUP
BasicFB−−−A c t i o n c o m p l e t e d
BasicFB−−−I s on s t a t e : SETUP
BasicFB−−−No e v e n t i n c o m i n g
BasicFB−−−Changed t o s t a t e : START
BasicFB−−− "EXECUTABLE_SWITCH" e x e c u t i o n c o m p l e t e d
BasicFB−−− "EXECUTABLE_SWITCH" r e t u r n e d e v e n t : SETUP
SIFB_Publ−−− Publ_8_SETUP1 s t a r t e d w i t h e v e n t : REQ
SIFB_Publ−−− S e r v i c e −> D a t a t r a n s f e r from l o c a l p u b l i s h e r t o l o c a l s u b s c r i b e r
SIFB_Subl−−− Subl_8_SETUP s t a r t e d w i t h e v e n t : IND
RESOURCE−−− SETUP_FRANK −> s t a r t e d w i t h Subl_8_SETUP . IND
RESOURCE−−−∗∗∗Var : Subl_8_SETUP . RD_1 s t o r e d on B u f f e r −R e s o u r c e
F i l e W r i t e r : o r d e r _ m a c h i n e _ h o m e _ p o s i t i o n i n i t i a l i z e d w i t h e v e n t : REQ
F i l e W r i t e r : order_machine_home_position execution complete
F i l e W r i t e r : o r d e r _ m a c h i n e _ h o m e _ p o s i t i o n r e t u r n e d e v e n t RSP
RESOURCE−−−∗∗∗Var : m o v e t o _ w o r k p i e c e _ o r i g i n . d e s t i n a t i o n l o a d e d on b l o c k t a b l e : 02 AF5210
BasicFB−−− " m o v e t o _ w o r k p i e c e _ o r i g i n " s t a r t e d w i t h e v e n t : I n i t
APÊNDICE D - Trecho do Arquivo Relatório do Ambiente de Execução 156
F i l e W r i t e r : o r d e r _ m a c h i n e _ h o m e _ p o s i t i o n r e t u r n e d e v e n t RSP
RESOURCE−−−∗∗∗Var : m o v e t o _ w o r k p i e c e _ o r i g i n . d e s t i n a t i o n l o a d e d on b l o c k t a b l e : 02 AF5210
BasicFB−−− " m o v e t o _ w o r k p i e c e _ o r i g i n " s t a r t e d w i t h e v e n t : I n i t
BasicFB−−−E v e n t : I n i t i n c o m i n g
BasicFB−−−Changed t o s t a t e : INIT
BasicFB−−−A c t i o n No . : 1
BasicFB−−−A l g o r i t h m = l i n e _ e q u a t i o n
BasicFB−−−E v e n t o u t = Send
BasicFB−−−A c t i o n c o m p l e t e d
BasicFB−−−I s on s t a t e : INIT
BasicFB−−−Changed t o s t a t e : START
BasicFB−−− " m o v e t o _ w o r k p i e c e _ o r i g i n " e x e c u t i o n c o m p l e t e d
BasicFB−−− " m o v e t o _ w o r k p i e c e _ o r i g i n " r e t u r n e d e v e n t : Send
RESOURCE−−−∗∗∗Var : m o v e t o _ w o r k p i e c e _ o r i g i n . e q _ i d s t o r e d on B u f f e r −R e s o u r c e
RESOURCE−−−∗∗∗Var : m o v e t o _ w o r k p i e c e _ o r i g i n . c o e f _ a s t o r e d on B u f f e r −R e s o u r c e
RESOURCE−−−∗∗∗Var : m o v e t o _ w o r k p i e c e _ o r i g i n . c o e f _ b s t o r e d on B u f f e r −R e s o u r c e
RESOURCE−−−∗∗∗Var : m o v e t o _ w o r k p i e c e _ o r i g i n . t 0 s t o r e d on B u f f e r −R e s o u r c e
RESOURCE−−−∗∗∗Var : m o v e t o _ w o r k p i e c e _ o r i g i n . t s t o r e d on B u f f e r −R e s o u r c e
RESOURCE−−−∗∗∗Var : m o v e t o _ w o r k p i e c e _ o r i g i n . f i n a l _ p o s s t o r e d on B u f f e r −R e s o u r c e
RESOURCE−−−∗∗∗Var : m o v e t o _ w o r k p i e c e _ o r i g i n . o u t _ s p e e d s t o r e d on B u f f e r −R e s o u r c e
RESOURCE−−−∗∗∗Var : m o v e t o _ w o r k p i e c e _ o r i g i n . v _ c o e f s t o r e d on B u f f e r −R e s o u r c e
RESOURCE−−−∗∗∗Var : o r d e r _ m o v e t o _ w o r k p i e c e _ o r i g i n . P0 l o a d e d on b l o c k 1
RESOURCE−−−∗∗∗Var : o r d e r _ m o v e t o _ w o r k p i e c e _ o r i g i n . P1 l o a d e d on b l o c k t a b l e : 02AF36E0
RESOURCE−−−∗∗∗Var : o r d e r _ m o v e t o _ w o r k p i e c e _ o r i g i n . P2 l o a d e d on b l o c k t a b l e : 02 AF3758
RESOURCE−−−∗∗∗Var : o r d e r _ m o v e t o _ w o r k p i e c e _ o r i g i n . P5 l o a d e d on b l o c k t a b l e : 02 AF37F8
RESOURCE−−−∗∗∗Var : o r d e r _ m o v e t o _ w o r k p i e c e _ o r i g i n . P6 l o a d e d on b l o c k 0 . 0 4
RESOURCE−−−∗∗∗Var : o r d e r _ m o v e t o _ w o r k p i e c e _ o r i g i n . P7 l o a d e d on b l o c k t a b l e : 02AF38C0
F i l e W r i t e r : o r d e r _ m o v e t o _ w o r k p i e c e _ o r i g i n i n i t i a l i z e d w i t h e v e n t : REQ
F i l e W r i t e r : order_moveto_workpiece_origin execution complete
F i l e W r i t e r : o r d e r _ m o v e t o _ w o r k p i e c e _ o r i g i n r e t u r n e d e v e n t RSP
BasicFB−−− " m o v e t o _ w o r k p i e c e _ o r i g i n " s t a r t e d w i t h e v e n t : Req
BasicFB−−−E v e n t : Req i n c o m i n g
BasicFB−−−Changed t o s t a t e : REQ
...
...

CNC-C: Um Controlador Aderente Às Normas ISO 14649 E IEC 61499

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

CNC-C: Um Controlador Aderente Às Normas ISO 14649 E IEC 61499

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC

CENTRO DE CIÊNCIAS TECNOLÓGICAS – CCT

CNC-C2: UM CONTROLADOR ADERENTE ÀS NORMAS

CNC-C2: UM CONTROLADOR ADERENTE ÀS NORMAS

Dissertação submetida à Universidade do Estado

Orientador: PhD. Roberto Silvio Ubertino Rosso

CNC-C2 : UM CONTROLADOR ADERENTE ÀS NORMAS ISO 14649

PhD., Roberto Silvio Ubertino Rosso Jr.

PhD., Marcelo da Silva Hounsell

Dr., André Bittencourt Leal

PhD., João Carlos Espíndola Ferreira

PhD., Neri Volpato

À minha irmã Sandra e meu cunhado Daniel pelo incentivo.

Aos professores e amigos André Bittencourt Leal e Fernando Lafratta.

Ao aluno do curso de ciência da computação, ex-bolsista do grupo, Allan Yoshio Hasegawa,

Ao bolsista Guilherme Jarentchuk pelo apoio e trabalho desenvolvido na construção do

Palavras-chave: STEP-NC, Function Block, Controlador Numérico Computadorizado, intero-

Keywords: STEP-NC, Function Block, Computer Numerical Control, interoperability, integra-

2.1 Exemplo de linha de programa em ISO 6983 . . . . . . . . . . . . . . . . . . . 34

2.3 Descrição geral do modelo de dados . . . . . . . . . . . . . . . . . . . . . . . 38

2.4 Relação entre ISO 10303 e ISO 14649 . . . . . . . . . . . . . . . . . . . . . . 39

2.5 Estrutura de um arquivo físico STEP-NC . . . . . . . . . . . . . . . . . . . . . 41

2.6 Estrutura hierárquica de um arquivo STEP-NC . . . . . . . . . . . . . . . . . 42

3.1 Características gerais do modelo de FB . . . . . . . . . . . . . . . . . . . . . . 48

3.2 Bloco de Função Básico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.3 Bloco de Função Composto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.4 Bloco de função de serviço de interface PUBLISH . . . . . . . . . . . . . . . 53

3.5 Bloco de função de serviço de interface SUBSCRIBE . . . . . . . . . . . . . . 53

3.6 Inicialização da interação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.7 Transferência de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.8 Modelo de Aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.9 Modelo de Recurso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.10 Modelo de Dispositivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.11 Funcionalidade do Dispositivo de Classe 0 . . . . . . . . . . . . . . . . . . . . 58

3.12 Funcionalidade do Dispositivo de Classe 1 . . . . . . . . . . . . . . . . . . . . 58

3.13 Funcionalidade do Dispositivo de Classe 2 . . . . . . . . . . . . . . . . . . . . 59

3.14 Modelo de Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.1 Arquitetura típica de um CNC e seus periféricos . . . . . . . . . . . . . . . . . 62

4.2 Nova arquitetura de um CNC e seus periféricos . . . . . . . . . . . . . . . . . 62

5.2 Arquitetura aberta desenvolvida . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.3 Arquitetura proposta e fluxo de dados da STEPNCMillUoA . . . . . . . . . . . 85

5.4 Controlador baseado em PC . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

6.1 Estrutura do CNC-C2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

6.2 Representação de um modelo EXPRESS e um modelo UML usado para mapear

6.3 Arquitetura do compilador desenvolvido . . . . . . . . . . . . . . . . . . . . . 96

6.4 Objetos usados para trocar mensagens entre componentes do compilador e o

6.5 Exceptions do compilador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

6.6 Componente da análise sintática . . . . . . . . . . . . . . . . . . . . . . . . . 99

6.7 Árvore sintática gerada pelo JavaCC + JJTree . . . . . . . . . . . . . . . . . . 99

6.8 Componente da análise semântica . . . . . . . . . . . . . . . . . . . . . . . . 100

6.9 Diagrama de classes mostrando as classes principais . . . . . . . . . . . . . . . 100

6.10 Diagrama de sequência: interação com o usuário . . . . . . . . . . . . . . . . . 101

6.11 Diagrama de sequência: método Compile . . . . . . . . . . . . . . . . . . . . 101

6.12 Diagrama de sequência: método runSyntacticAnalysis . . . . . . . . . . . . . . 102

6.13 Diagrama de sequência: new EntityTO . . . . . . . . . . . . . . . . . . . . . . 103

6.14 Diagrama de sequência: método runSemanticAnalysis . . . . . . . . . . . . . . 104

6.15 Trecho de código desenvolvido para a aplicação da back-end . . . . . . . . . . 105

6.16 Exemplo de um arquivo system genérico da linguagem de marcação XML gerado

6.17 Exemplo de funcionamento do resource STEP-NC_DATA desenvolvido . . . . 107

6.18 Interface gráfica para utilização do compilador desenvolvido, integrado com o

6.22 Proposta de utilização da rede CAN para comunicação entre os equipamentos

6.23 Proposta de utilização da rede RS485 para comunicação entre os equipamentos

6.24 Proposta de utilização do gerenciador de comunicação para transeferência de