A Norma STEP - ISO10303 AP242 como Instrumento de Integração entre Engenharia de Produto e de Processo

(1)

F

ACULDADE DE

E

NGENHARIA DA

U

NIVERSIDADE DO

P

ORTO

PRODUCT-PROCESS

ENGINEERING INTEGRATION

USING STEP – ISO 10303 AP242

Miguel Ângelo Jesus Vidal Ribeiro

Mestrado Integrado em Engenharia Informática e Computação Supervisor: Prof. José Faria

(2)

(3)

PRODUCT-PROCESS ENGINEERING INTEGRATION

USING STEP – ISO 10303 AP242

Miguel Ângelo Jesus Vidal Ribeiro

Mestrado Integrado em Engenharia Informática e Computação

(4)

(5)

Resumo

As empresas que produzem sob encomenda são constantemente solicitadas para o fornecimento de um número consideravelmente elevado de orçamentos, com base em desenhos 2D ou 3D, sendo a grande maioria do tipo 2D, em suporte PDF. A partir das peças desenhadas fornecidas pelos clientes, a equipa orçamentista estima as necessidades de materiais e os custos de transformação decorrentes das operações, bem como os recursos necessários, de forma a chegar a um preço teórico do custo de produção. Esta tarefa requer grande atenção e cuidado e despende bastante tempo.

A maioria dos sistemas CAD (computer aided design) atuais suporta a exportação dos seus modelos 3D para o formato STEP, um standard ISO. Este formato permite a exportação da infor-mação de geometria bem como dos produtos e da sua estrutura de assemblagem. O uso de modelos 3D exportados no formato STEP permite assim o preenchimento de grande parte do “vazio” que existe entre a engenharia de produto e a engenharia de processo. A norma STEP AP242 está agora a ser adotada e implementada pelos grandes fabricantes de sistemas CAD 3D, contudo as ferramentas que manipulam esses modelos STEP e aproveitam as suas potencialidades do ponto de vista de integração da engenharia de projeto com a engenharia de processo ainda são raras, incompletas e excessivamente caras.

Pretende-se assim o desenvolvimento de uma ferramenta que permita a integração eficiente entre as fases de projeto e de fabrico. Esta ferramenta consistirá num web service que permita a importação da estrutura de um produto e toda a informação associada, bem como adicionar infor-mações de processo. Além disto, possuirá ainda um visualizador simples que permita visualizar os componentes à medida que navegamos na estrutura em árvore importada anteriormente.

(6)

(7)

Abstract

The companies that make custom products are constantly required to provide a considerably high number of price estimates based on 2D or 3D drawings, being that the great majority of them are 2D type in PDF format. In order to give the customer a quote we have to extract from the draw-ings the material requirements, necessary operations and resources. This task requires the utmost attention, care and is time consuming.

Most Computer Aided Design (CAD) systems are capable to export 3D models in STEP for-mat, an ISO standard. This format allows us to extract geometry information and the assembly structure of an product. The use of 3D models exported in STEP format also allows us to narrow the "gap" that exists between product and process engineering.

The STEP AP242 standard is now being adopted and implemented by the major 3D CAD systems manufacturers, yet the tools that manipulate these STEP models and use their potential from the point of view of integrating project and process engineering are still rare, incomplete and overly expensive.

The aim is to develop a simple and accessible tool that allows efficient integration between design and manufacturing stages. This tool will consist of a web service, that extracts from a STEP file the product assembly structure and geometry information of an item to produce, and a simple web based viewer that visualizes the components as we navigate in the product assembly structure previously imported.

(8)

(9)

Agradecimentos

Apesar de uma dissertação ser um documento que representa um trabalho desenvolvido no âmbito académico, é algo que acaba por receber contributos de natureza diversa que não podem, nem devem, deixar de ser realçados. Após esta longa e trabalhosa jornada não posso deixar de agradecer a todos aqueles que estiveram presentes e tanto me apoiaram:

Aos meus orientadores Professor José Faria e Engenheiro Luís Guardão, agradeço pela disponi-bilidade, pelo acompanhamento e pelas críticas e sugestões durante todo este período em que colaboramos por forma a atingir os resultados refletidos nesta dissertação;

Ao INESC-TEC Porto e a todos os seus colaboradores por me acolherem durante o período de realização da dissertação;

Aos meus pais, que sempre primaram pela minha educação e por me oferecerem a oportu-nidade única que é estudar, por sempre me incentivarem perante os desafios, a fazer mais e mel-hor, quero partilhar convosco a alegria de os conseguir vencer continuamente! Uma palavra de reconhecimento muito especial para eles, pelo amor incondicional e pela forma como sempre me apoiaram ao longo de todos estes anos;

À minha namorada, ouvinte atenta de algumas dúvidas, inquietações, desânimos e sucessos, pelo apoio, pela confiança e pela valorização sempre tão entusiasta do meu trabalho, dando-me, desta forma, coragem para ultrapassar a culpa pelo tempo que a cada dia lhe subtraía.

Por fim, a todos os meus amigos, que durante estes últimos anos me fizeram crescer, estiveram presentes nos bons e nos maus momentos e nunca me deixaram desistir;

Um sincero muito obrigado a todos.

(10)

(11)

“Success is only meaningful and enjoyable if it feels like your own.”

(12)

(13)

List of Figures

2.1 Exemplo da estrutura de um produto (BOM - Bill of material) . . . 7

2.2 Relações de precedência entre os objetos da BOM - Bill of material . . . 8

2.3 Estrutura de produto multi-nível . . . 9

2.4 Niveis da BOM - Bill of material . . . 10

2.5 Exemplo da representação de uma entidade em EXPRESS . . . 17

2.6 Componentes da linguagem EXPRESS-G . . . 18

2.7 Descrição de um furo em linguagem EXPRESS conforme o AP 224 . . . 18

2.8 Descrição dos furos em EXPRESS-G conforme AP 224 . . . 19

2.9 SAP Engineering Control Center . . . 20

3.1 Diagrama de atividade do sistema . . . 24

3.2 Módulos da aplicação . . . 25

3.3 Arquitetura Física . . . 27

3.4 Packages Java . . . 27

3.5 Classes presentes em PolyTri . . . 28

3.6 Classes presentes em ProductStructure . . . 29

3.7 Arquitetura Tecnológica . . . 30

3.8 Arquitetura Node . . . 31

3.9 Arquitetura AngularJS . . . 31

4.1 Arquitetura de um ficheiro STEP . . . 33

4.2 Arquitetura de dados de um ficheiro STEP . . . 35

4.3 Arquitetura de dados de um ficheiro STEP . . . 36

5.1 Instâncias que identificam produtos num ficheiro STEP. . . 40

5.2 Exemplo das entidades de PRODUCT . . . 42

5.3 Instâncias que identificam a estrutura de produto num ficheiro STEP. . . 43

5.4 Exemplo das entidades da estrutura de montagem de um produto. . . 44

5.5 Hierarquia geométrica do produto . . . 45

5.6 Exemplo de representação geométrica. . . 47

5.7 Representação de um cilindro. . . 48

5.8 Representação de um orifício cilíndrico. . . 48

5.9 Representação de um orifício cilíndrico inclinado. . . 49

5.10 Representação de uma superfície cónica. . . 49

5.11 Representação de um orifício cónico. . . 50

5.12 Representação de superfície toroidal. . . 50

5.13 Representação de superfície esférica. . . 51

5.14 Representação de um Cross Hole. . . 51

(16)

LIST OF FIGURES

5.16 Cross Hole desalinhado com o eixo. . . 52

5.17 Cross Hole - Through ou Blind. . . 53

5.18 Instâncias que identificam um ficheiro externo. . . 53

5.19 Exemplo das entidades que identificam um ficheiro externo . . . 55

5.20 Estrutura hierárquica de um produto representado em múltiplos ficheiros. . . 56

5.21 Informação geométrica relativa a cada componente. . . 57

5.22 Organização dos ficheiros com informação geométrica. . . 58

5.23 Referenciação da estrutura de montagem com informações geométricas. . . 59

5.24 Ficheiros index.json. . . 61

5.25 Ficheiros shell_idXXX.json. . . 62

5.26 Ficheiros AssemblyStructure.json. . . 63

5.27 Algoritmo Sweep Line . . . 65

5.28 Viewer utilizado. . . 65

A.1 estrutura do projeto STEPapp . . . 75

A.2 Home Page . . . 76

A.3 Load File . . . 77

A.4 Structure of Product . . . 77

A.5 Viewer 3D . . . 78

A.6 Team . . . 78

(17)

List of Tables

3.1 Requisitos do Utilizador. . . 22

3.2 Requisitos de Funcionalidades da Plataforma. . . 22

3.3 Não Requisitos. . . 24 5.1 Atributos de PRODUCT. . . 40 5.2 Atributos de PRODUCT_DEFINITION_FORMATION. . . 41 5.3 Atributos de PRODUCT_DEFINITION_FORMATION_WITH_SPECIFIED_SOURCE. 41 5.4 Atributos de PRODUCT_DEFINITION. . . 42 5.5 Atributos de ASSEMBLY_COMPONENT_USAGE. . . 43 5.6 Atributos de NEXT_ASSEMBLY_USAGE_OCCURRENCE. . . 44 5.7 Atributos de DOCUMENT_FILE. . . 54 5.8 Atributos de DOCUMENT_REPRESENTATION_TYPE. . . 54 5.9 Atributos de DOCUMENT_TYPE. . . 55

(18)

(19)

Abbreviations

STEP STandard for the Exchange of Product model data CAD Computer-Aided Design

CAM Computer-aided manufacturing PLM product lifecycle management ERP Enterprise Resource Planning

SAP Systeme, Anwendungen und Produkte NC Numerical control

CNC Computer Numeric Control CLP Controlador Lógico Programável DNC Direct Numerical Control STL STereoLithography

NURBS Non Uniform Rational Basis Spline IGES Initial Graphics Exchange Specification SET standard d’echange et de transfert B-rep Boundary representation

CAE Computer-aided engineering PMEs Pequenas e Médias Empresas

(20)

(21)

Chapter 1

Introdução

Neste primeiro capítulo expõe-se o contexto onde surge e é desenvolvido este projeto, bem como o problema que se pretende abordar e solucionar e, por fim, a motivação e objetivos do projeto a desenvolver.

1.1 Problema e Enquadramento do Projeto

Este projeto surge no âmbito da área da indústria que fabrica sob encomenda, relacionando-se mais concretamente com a otimização dos processos entre as fases de projeto e produção de um determinado produto. Assim, na base do funcionamento de uma indústria e do seu contacto com os clientes, é possível verificar uma relação na qual o cliente pretende que a empresa industrial fabrique um determinado produto. Para tal, o cliente disponibiliza modelos em 2D e 3D do pro-duto que pretende ver produzido, sendo que estes modelos terão de ser analisados cuidadosamente por uma equipa especializada para que seja calculado o orçamento do custo de produção do de-terminado produto, culminando na sua produção e posterior fornecimento do mesmo ao cliente. Contudo, o que se verifica nos últimos tempos é que os clientes da indústria de fabrico sob en-comenda têm aumentado de forma exponencial, sendo também cada vez mais exigentes, na me-dida em que pretendem um produto feito sob encomenda com determinadas especificações e que o mesmo seja de qualidade e esteja concluído num curto espaço de tempo. Para tal, todos os pro-cessos da indústria produtora devem ser otimizados, desde a fase inicial de engenharia do produto até ao momento em que o produto final é enviado para o cliente, de forma a fornecerem uma boa resposta a este mercado tão exigente. No entanto, o que se verifica na realidade é que o processo de análise dos modelos do produto fornecidos pelo cliente é um processo bastante moroso, exigindo bastante atenção, pois um erro nesta fase pode levar a grandes prejuízos para a empresa. Este aspeto juntamente com a falta de uniformidade nas ferramentas de análise utilizadas nos vários se-tores da indústria dificultam bastante a otimização de todos estes processos, levando muitas vezes

(22)

Introdução

a grandes discrepâncias entre o valor de custo teórico e o valor de custo real de produção de um determinado produto.

A integração entre programas de computador promove a comunicação entre sistemas. Nenhum software funciona de forma eficiente se for utilizado como uma “ilha”, sem que haja interação com outros sistemas. Desta forma, por mais recursos que possua o sistema de gestão A ou o ERP B, nenhum deles consegue ser suficientemente eficaz em tudo. Para uma organização funcionar em harmonia, é preciso haver integração e uma comunicação inteligente entre sistemas. Nas empresas industriais, existem diversos sistemas, como por exemplo, sistemas CAD, CAM e ERP, que devem ser capazes de comunicarem entre si de forma a suportarem o processo de produção da empresa. Esta comunicação é conhecida como integração entre sistemas e pode ser assegurada por formatos próprios para a troca e representação de dados necessários ao fabrico de um determinado produto.

1.2 Motivação e Objetivos

Após a análise deste problema em particular foi possível verificar que não existem atualmente soluções capazes de solucionar em concreto estes problemas de otimização e integração. Exis-tem sim, bastantes recursos e ferramentas capazes de ajudar em alguns dos processos envolvidos no ciclo de vida de um produto, contudo estas soluções/ferramentas não são suficientemente uni-formes e genéricas para que sejam implementadas na grande maioria dos setores de uma indústria de forma a funcionarem em total sintonia, eliminando todas e quaisquer espécies de discrepâncias de valores. Além disso, é de notar que muitas destas ferramentas são muito complexas, de pouca usabilidade para o utilizador e com um custo de implementação bastante elevado. Após a análise do problema que motivou a realização desta dissertação e em conjunto com o cliente com o qual colaborei na realização da mesma, o INESC TEC, foram definidos dois objetivos fundamentais a atingir:

• Criar uma plataforma web, capaz de extrair informação sobre a estrutura do produto repre-sentada num ficheiros STEP de acordo com a norma AP242.

• Desenvolvimento/adaptação de um viewer que permita a visualização web dos componentes e da sua estrutura de montagem, viewer este que possa ser integrado numa aplicação exis-tente e que funcione de forma rápida e fluida além de ser capaz de suportar ficheiros de grandes dimensões.

Desta forma, pretende-se a criação de uma plataforma simples, bastante intuitiva para o uti-lizador e de fácil integração nos sistemas de uma empresa, além de genérica o suficiente para que seja utilizada tanto no processo de engenharia do produto como no processo de fabrico, con-tribuindo assim para uma integração destas duas fases e para a otimização de todos os seus proces-sos. Assim, esta solução, permitirá assegurar uma ponte entre a fase de projeto e a fase de fabrico do produto.

(23)

Introdução

1.3 Estrutura da Dissertação

A dissertação está organizada em sete capítulos, designados por: Introdução, Estado da Arte, Es-pecificação e Arquitetura do Sistema, Arquitetura e Organização de um Ficheiro STEP, Implemen-tação, Resultados e Trabalho Futuro, e Conclusões. Termina com as Referências Bibliográficas e Anexos.

O capítulo 2, Estado da Arte, é dedicado à revisão bibliográfica e está dividido em quatro secções: Estrutura do Produto (Bill of material), Metodologias de Produção Avançadas, Formatos para Troca e Representação de Dados e Ferramentas de Integração CAD em ERP’s. A secção Estrutura do Produto começa com a definição de “bill of material” de acordo com vários autores e com a definição de vários conceitos básicos associados, prosseguindo com a Importância da Estrutura do Produto na Indústria. A secção seguinte é referente a Metodologias de Produção Avançadas utilizadas atualmente na indústria, entre elas os sistemas CAD e CAM. Por sua vez, na secção Formatos para Troca e Representação de Dados, são referidos vários Formatos de represen-tação de dados utilizados, de salientar o formato STEP ISO10303, utilizado na elaboração deste projeto. Por fim, concluindo o capitulo 2, são ainda referidas ferramentas existentes de integração dos sistemas CAD em ERP’s.

No capítulo 3, Especificação e Arquitetura do Sistema, é feita uma análise detalhada da ar-quitetura do sistema a produzir no âmbito desta dissertação. Este capítulo encontra-se dividido em quatro secções, nomeadamente Especificação de Requisitos, onde são especificados todos os requisitos do projeto, Funcionalidades do Sistema, onde é apresentado o fluxo de atividades da plataforma, Módulos de Desenvolvimento do Sistema, onde são analisados os diferentes módu-los de desenvolvimento da aplicação e Arquitetura do Sistema, onde é feita uma abordagem da arquitetura física, lógica e tecnológica do sistema.

No capítulo 4, Arquitetura e Organização de um Ficheiro STEP, é feita uma análise da estru-tura e organização de um ficheiro STEP, por forma, a facilitar a implementação do sistema.

O capítulo 5, enuncia os aspetos relativos à implementação da plataforma, este capítulo está dividido em cinco grandes secções: Identificação de Elementos STEP, onde é feita uma análise dos elementos STEP fundamentais para o projeto, Extração de Elementos STEP, onde é referido a forma como é feita a extração dos elementos necessários, Estrutura e Organização dos Ficheiros JSON criados, onde é referido a estrutura do output obtido depois do processamento dos ficheiros, Triangulação de Polígonos, onde é descriminada a forma como é feita a triangulação dos polígonos representados no STEP, para posterior representação 3D no viewer e, por último, Interface do Utilizador, onde é analisada a interface criada para o utilizador.

No capítulo 6, Resultados e Trabalho Futuro, é feita uma reflexão sobre os objetivos alcança-dos e sobre perspetivas de trabalho futuro.

Por ultimo, segue-se o capítulo 7, Conclusões, onde é feita uma síntese do trabalho desen-volvido durante o período de realização desta dissertação.

(24)

(25)

Chapter 2

Estado da Arte

Neste capítulo é apresentada a bibliografia analisada sobre os principais temas envolvidos no de-senvolvimento deste projeto. Está dividido em quatro secções, correspondentes às áreas estudadas: Estrutura do Produto (BOM - bill of material), Metodologias de Produto Avançadas, Formatos para Troca e Representação de Dados e Ferramentas de Integração CAD em ERP’s. Sendo o foco deste projeto a criação de uma plataforma capaz de analisar a estrutura de um produto através da in-formação disponibilizada por metodologias de produção avançadas, capazes de representarem os dados de um produto num formato universal chamado STEP, são de extrema relevância as difer-entes secções que constituem este capítulo.

2.1 Estrutura do Produto

A estrutura de um Produto (BOM – Bill of material) é uma lista de todas as sub montagens, componentes intermédios, matérias-primas e itens comprados que são utilizados no fabrico e/ou montagem de um produto, mostrando as relações de precedências, a quantidade e a unidade de medida de cada item necessário. A estrutura do produto é considerada uma informação funda-mental que gera integração, uma vez que os seus dados são utilizados na realização das atividades de diversas áreas da empresa, como engenharia de qualidade, PCP (Process Control Plan), com-pras, produção, marketing, vendas, assistência técnica e tecnologias de informação. Além disso a BOMpermite a integração de sistemas, como CAD (Computer Aided Process), CAPP (Computer Aided Process Planning), PDM (Product Data Management), configuradores de produto, ERP (Enterprise Resource Planning), MRP (Manufacturing Resource Planning) e sistemas de planea-mento da produção. Uma vez que o desempenho dessas atividades e sistemas é influenciado pela forma como a estrutura do produto é representada e gerida, uma série de requisitos precisam ser atendidos, tais como [dO99]:

(26)

Estado da Arte

1. Ser precisa e completa

A precisão está associada à não existência de informações incorretas nos números de identi-ficação, nas relações entre um componente pai e os seus componentes filho, nas quantidades necessárias e nas unidades de medida. Além disso, a estrutura do produto deve ser completa incluindo todos os materiais utilizados no planeamento, programação, controlo de produção, e no cálculo do custo do produto. Alguns autores recomendam que a estrutura do produto contenha, não só os itens necessários ao PCP, mas também todos os dados relacionados com o próprio item, servindo assim como espinha dorsal para um sistema de gestão de dados do produto.

2. Ser simples e achatada

A simplificação da estrutura do produto, por meio da redução do número de níveis (“achata-mento”), deve ser uma preocupação constante das empresas. A estrutura do produto mais simples possível é a de dois níveis, um com as matérias-primas e itens comprados e outro com o produto final. A única razão para a criação de níveis intermédios são as necessidades do planeamento, programação e controlo da produção.

3. Estar em sintonia com as estratégias do negócio

A estrutura do produto deve ser elaborada em função das características do negócio que rep-resenta. Essas características podem estar associadas ao produto ou ao processo utilizado. Para suportar essa representação existem diferentes arquiteturas aplicadas à estrutura do produto.

4. Incluir os componentes necessários para o planeamento, programação e controlo da produção

Os componentes fantasma e pseudo componentes são dois tipos especiais de componentes que auxiliam as empresas a atingir o seu objetivo de transformar a estrutura do produto numa representação dos produtos e processos. Componentes fantasma são aqueles produzidos no processo de produção, possuindo “pais” definidos, porém não são tipicamente armazenados. Apesar de existirem fisicamente, são rapidamente consumidos como componentes do item de nível imediatamente superior na estrutura do produto, possuindo assim um lead time1 igual a zero. Os pseudo componentes são uma coleção artificial de componentes que são agrupados para propósitos de planeamento, ao contrário dos componentes fantasma, por essa razão os pseudo componentes nunca possuem um inventário.

5. Ser única e suportar as necessidades de todos os utilizadores

A estrutura do produto promove a integração entre as diversas áreas da empresa, visto que se constitui numa base de dados comum a todos os utilizadores. Por outro lado, a sua não existência implica uma redundância de informações e consequentemente um risco de inconsistência, bem como um aumento do esforço e do tempo de resposta das manutenções.

1_{medida do tempo gasto pelo sistema produtivo para transformar matérias-primas em produtos acabados” (TUBINO}

(27)

Estado da Arte

Entretanto, para que a estrutura do produto atenda aos requisitos dos diversos utilizadores, é necessária a formação de um comité gestor multi funcional com representantes de todos os utilizadores, responsável pela criação e manutenção da estrutura do produto.

2.1.1 Definições

Segundo a AMERICAN PRODUCTION AND INVENTORY CONTROL SOCIETY (APICS) [PA92], a estrutura de produto (BOM - bill of material) é uma lista de todas as submontagens, componentes intermédios, matérias-primas e componentes comprados que são utilizados no fab-rico e/ou montagem de um produto, mostrando as relações de precedência e quantidade de cada componente necessário. Um exemplo simples de uma estrutura de produto pode ser visto na figura 2.1, na qual o componente A é composto por quatro unidades do componente comprado C e duas unidades do componente B, o qual necessita durante o fabrico de uma unidade da matéria-prima D.

Figure 2.1: Exemplo da estrutura de um produto (BOM - Bill of material)

CLEMENT et al. [CLE92], acrescenta que, além desses objetos, a BOM também pode conter outros, tais como, instruções de trabalho ou ferramentas necessárias para suportar o processo de fabrico. Devido à grande diversidade de objetos que a estrutura do produto pode conter, é necessário definir uma nomenclatura padrão para que o uso de cada um deles seja diferenciado e entendido. Segundo a APICS [PA92], os objetos da BOM podem ser classificados em:

• Item (item): qualquer matéria-prima, peça, embalagem, componente, submontagem, mon-tagem ou produto único fabricado ou comprado.

• Componente (component): matéria-prima, peça ou submontagem que é utilizada numa montagem de nível mais alto, ou em outro item. Esse termo pode incluir também em-balagens no caso de itens finais.

(28)

Estado da Arte

• Peça (part): geralmente um item isolado comprado ou fabricado que é usado como com-ponente e não é uma montagem ou submontagem nem matéria-prima. Neste trabalho será acrescentada a classe de objeto “material” a essa classificação com o objetivo de torná-la mais abrangente e em consonância com diversos sistemas integrados existentes

• Material (material): produtos finais, montagens, submontagens, peças, matéria-prima, in-formações, recursos ou serviços utilizados durante o processo produtivo.

Apesar de CLEMENT [CLE92] e CHEN & HSIO [CHE97] identificarem existência de ob-jetos na BOM, não é especificada uma nomenclatura. Assim sendo, o nome “material” foi sele-cionado como consequência da BOM poder ser traduzida para o português como “lista de materi-ais”, logo, o seu objeto mais genérico é o “material”. CHEN & HSIO (1997) [CHE97] destacam que, além dos itens tradicionalmente incorporados na estrutura do produto, é preciso estender o conceito de "material" para as informações associadas ao produto, como modelos geométricos, desenhos, planos de processo e outros documentos de suporte elaborados durante os processos de desenvolvimento e alteração do produto. Dessa forma, a estrutura do produto passa a exercer um papel chave sendo a espinha dorsal dos sistemas de gestão de dados de produtos (PDM -Product Data Management). CLEETUS [CLE95] e KEMPFER [KEM98] acrescentam que essa unificação dos dados do produto numa mesma fonte possibilita que as pessoas naveguem nas in-formações através da estrutura do produto, tornando o processo de busca e acesso mais rápido e fácil. Um esquema com as relações de precedência entre os objetos da estrutura do produto está representado na figura 2.2

(29)

Estado da Arte

Como referido anteriormente, a estrutura do produto é baseada na relação pai/filho entre itens. O componente que está a ser produzido é chamado de pai e os componentes necessários na sua pro-dução são chamados componentes filho. Todas as vezes que é estabelecida uma relação pai/filho entre um componente e os seus componentes diretos, a estrutura do produto formada é chamada estrutura de nível simples. Uma estrutura multi-nível é formada quando as estruturas de um nível são associadas desde as matérias-primas e itens comprados, até produto final, resultando em uma estrutura com dois ou mais níveis. Isso ocorre através de uma técnica chamada explosão [SCH95]. Dessa forma, todos os componentes utilizados direta ou indiretamente na produção de um produto podem ser visualizados [GUE85]. Um nível é criado quando a relação entre um componente pai e seus componentes filho é definida. Os níveis de uma estrutura de produto são basicamente determinados a partir da forma como os componentes intermédios e semi-acabados são tratados no processo de produção, desde a matéria-prima e componentes comprados até ao produto final [SCH95] [CLE92]. Numa estrutura de produto multi-nível, o produto final corresponde ao nível zero da estrutura, os seus componentes diretos são o nível 1 e assim sucessivamente. Quando os relacionamentos de um nível são estabelecidos para componentes pai e filho, os sistemas de informação podem planear e fornecer todos os tipos de informação para os níveis simples ou multi-níveis [CLE92]. A figura 2.3 apresenta uma BOM que resume os principais conceitos discutidos nesta secção.

(30)

Estado da Arte

2.1.2 Importância da Estrutura do Produto na Indústria

Muitas das indústrias não dão a importância devida a um fator muito importante no desenvolvi-mento dos seus produtos. Esse fator é a estrutura do produto. A estrutura do produto ou lista de materiais (Bill of material) é uma árvore de produtos visualizada, nível a nível, que descreve a relação entre componentes pai e componentes filho de um produto. A estrutura do produto é fundamental para uma boa leitura do produto, pois é através dela que se consegue visualizar todos os itens que compõem um produto no momento do seu fabrico. De uma forma geral, a estrutura do produto pode ser definida como um diagrama que identifica e descreve os componentes de um produto final de modo a tornar clara sua composição. A cada linha de componentes na estrutura do produto chamamos de nível. O primeiro nível recebe o número zero (0) e os demais níveis são numerados de forma crescente, isto é, o nível imediatamente abaixo do primeiro é o nível um (1), depois o nível dois (2) e assim por diante, como demonstrado na figura 2.4.

Figure 2.4: Niveis da BOM - Bill of material

A estrutura acima demonstra como um produto é montado em todos os seus níveis, apresen-tando os seus componentes e quantidades em forma de árvore com cada elemento ligado ao nível superior (produto "pai"). É com base nas estruturas que a ordem de produção gera os componentes necessários para a produção de um produto, permitindo a requisição automática dos materiais necessários. Para a formação da estrutura do produto é necessário:

• Conjunto – Produto a ser produzido.

• Componentes – Produtos ou materiais utilizados na produção do conjunto. • Quantidade – Quantidade utilizada para o fabrico de uma unidade de conjunto.

Na atual situação do mercado, torna-se imprescindível a busca incessante por custos menores e redução quase total dos desperdícios, o que se tornou uma obrigação para as organizações que

(31)

Estado da Arte

querem sobreviver no mercado. As grandes transformações nos cenários económicos, políticos e sociais estão a levar as empresas a mudarem radicalmente as estratégias e a avaliação de desem-penho da produção, dado que a redução de custos, por si só, não é suficiente. Muito além do preço baixo, o produto ou serviço tem a obrigação, nos dias de hoje, de vir acompanhado de qualidade, rapidez e confiabilidade.

2.2 Metodologias de Produção Avançadas

O desenho técnico tem sido parte integrante na indústria, pois é o elo de ligação entre o departa-mento de projetos e a produção. O desenho preparado com padrões pré-determinados faz com que a informação seja rapidamente comunicada para o resto da fábrica, proporcionando a confeção do produto idealizado com maior rapidez. Por esse motivo, aliado à grande evolução do poder de processamento e à queda dos preços dos computadores, a cada dia aumenta o número de profis-sionais que utilizam metodologias de produção avançadas como ferramentas de trabalho. Porém, observa-se que a maioria dessas pessoas utilizam estas metodologias apenas para elaboração de desenho, sendo que estes sistemas permitem, além de manipulação e integração de informações, conceber projetos através da representação em três dimensões, possibilitando diferentes formas de visão e conceção de projetos e diminuindo a possibilidade de erros por incoerências.

2.2.1 CAD (Computer Aided Design)

CAD (Computer Aided Design) é o nome genérico de sistemas computacionais (software) utiliza-dos pela Engenharia, Geologia, Geografia, Arquitetura e Design para facilitar o projeto e desen-hos técnicos. No caso do Design, este pode estar ligado especificamente a todas as suas vertentes (produtos como vestuário, eletrónica, etc.), de modo que os jargões de cada especialidade são in-corporados na interface de cada programa. Estes sistemas fornecem uma série de ferramentas para construção de entidades geométricas planas (como linhas, curvas ou polígonos) ou mesmo objetos tridimensionais (cubos, esferas, etc). Também disponibilizam ferramentas para relacionar essas entidades ou esses objetos, por exemplo: subtrair as formas de dois objetos tridimensionais para obter um terceiro. Uma divisão básica entre os softwares CAD é feita com base na capacidade do programa em desenhar apenas em 2 dimensões ou também criar modelos tridimensionais, sendo estes últimos subdivididos ainda em relação a que tecnologia usam como modelador 3D. Existem modelos de CAD específicos que simulam as condições de fabrico, ou seja, as ferramentas usadas no desenho são as mesmas disponíveis no chão de fábrica (estes são geralmente chamados progra-mas CAM). Também na Arquitetura existem CADs específicos que desenham paredes, telhados e outras construções automaticamente. Os softwares mais avançados de CAD usam a chamada modelagem paramétrica, que permite modificações do desenho pela simples entrada de números indicando dimensões e relações entre as entidades ou objetos desenhados. As capacidades do sistemas de CAD modernos incluem:

(32)

Estado da Arte

• Funções paramétricas 3D para modelação de sólidos; • Modelação de superfícies Freeform;

• Desenhos automáticos de conjuntos de peças;

• Gerar automaticamente desenhos 2D a partir dos modelos sólidos 3D; • Reutilização de design de componentes;

• Facilidade na modificação do design do modelo e produção de múltiplas versões; • Gerar automaticamente componentes de design standards;

• Validação/verificação dos designs de encontro a especificações e regras determinadas; • Simulação de designs sem a necessidade do protótipo físico;

• Criação de documentação de engenharia, tal como desenhos para maquinação, listas de materiais, entre outros;

• Saída de modelos diretamente para a fabricação;

• Calcular as propriedades de massa de peças e conjuntos;

• Ajuda à visualização através de uso de sombras, rotação, remoção das linhas escondidas, entre outros;

• Associação paramétrica bidirecional (modificações realizadas ao nível de funções é refletida em todas as informações relacionadas com a mesma; desenhos, propriedades de massa, conjuntos, entre outros e vice-versa);

• Verificação de cinemáticas e interferências em conjuntos de peças. 2.2.1.1 Exemplos de Ferramentas CAD

SolidWorks

SolidWorksé uma ferramenta da Dassault Systemes que possui um conjunto robusto de módulos essenciais para aumentar a produtividade e inclui o software de projeto mecânico em 3D da Solid-Works, uma linha completa de módulos de comunicação do projeto e que apostam no aumento da produtividade CAD.

CATIAV5R16

CATIAV5R16é uma ferramenta, também da Dassault Systemes, líder mundial em soluções 3D e PLM (Product Lifecycle Management). Esta acelera o processo de desenvolvimento de produtos, já com recursos otimizados para processadores de 64 bits.

(33)

Estado da Arte

CIMATRON

CIMATRONé um software dirigido principalmente para a indústria, que engloba as mais diversas áreas da produção como projeto de moldes, elétrodos (EDM), Controladores Numéricos (NC), Die Making e Micro Milingaté à área da engenharia inversa, onde as suas soluções cobrem todo o processo, transformando modelos digitais em geometria pronta para o processamento e produção. A Cimatron possui ferramentas para a criação, manipulação e edição de nuvens de pontos, cur-vas/superfícies NURBS incluindo Stereolitography(STL). Importa facilmente o modelo de dados capturado por qualquer digitalizador robótico, mecânico ou ótico.

AutoDesk

AutoDeské o sucessor do AutoCAD, produto consagrado pela AutoDesk, Inc. Esta nova ferramenta de design 3D apresenta, entre outras funcionalidades, Routed System, para o projeto de cablagens, tubagens, canalizações, simulação com análise de esforços e simulação dinâmica. Devido à ex-istência desta grande diversidade de ferramentas, a procura por ficheiros em formato neutro que tornassem possível a interoperabilidade entre todos os softwares de desenvolvimento existentes aumentou.

2.2.2 CAM (Computer Aided Manufacturing)

Podemos definir CAM como auxílio via computador da preparação da produção, representando as tecnologias usadas na produção, dizendo não só respeito à automação da produção, como: CNC (Comando Numérico Computorizado), CLP (Controlo Lógico Programável), coletores de dados (DNC), como também à tomada de decisão, plano operacional, etc. Apesar de toda esta abrangên-cia, o termo CAM, por vezes, ainda é sinónimo da programação CNC, conceito que ficou muito difundido com a sigla CAD/CAM, que representa módulos de programação CNC em sistemas CAM.

2.2.2.1 Exemplos de Ferramentas CAM Mastercam

A Mastercam tem diversos softwares específicos de CAM, isto é, vocacionados para um deter-minado tipo de máquina de comando numérico ou para uma determinada área da indústria. Com bastantes mais opções que outros programas mais generalistas, a Mastercam disponibiliza para trabalhar com tornos CNC o Mastercam Lathe e para os centros de maquinagem o Mastercam Mill. Um bom exemplo de um software desenhado especialmente para a indústria dos moldes automóveis é o Automold, um software que sugere as dimensões da estrutura e dos acessórios do molde a partir das dimensões da peça a moldar e das especificações do cliente. Além do molde em 3D sólido, o software também consegue gerar automaticamente o desenho do molde em 2D segundo as normas dos moldes, automatizar a maquinação das estruturas e exportar os dados para a gestão de produção.

(34)

Estado da Arte

2.3 Formatos para Troca e Representação de Dados

Existe uma grande variedade de formatos para a representação e intercâmbio de informações de um produto. Estas formas de representação são utilizadas para ligar as mais diferentes plataformas de software. Os formatos mais populares entre as ferramentas descritas anteriormente são o IGES, SET, STL e STEP(ISO 10303).

2.3.0.1 IGES

Nos anos 70 diversas plataformas CAD já estavam a ser utilizadas significativamente na indústria metalomecânica. Devido a este facto emergiu fortemente a necessidade de troca de informação en-tre estas diferentes plataformas forçando a comunidade CAD a criar, em 1979, o primeiro padrão internacional - IGES (Initial Garphics Exchange Specification) [Smi88]. A sua especificação foi publicada pela primeira vez em 1980 nos EUA pela NBS (National Bureau of Standards) [NBS80], contudo a primeira versão foi aceite e disponibilizada apenas em 1982 pela ANSI standards. O padrão neutro IGES é atualmente suportado por todos os grandes produtores de ferramentas CAD, sendo um dos formatos neutros de troca mais conhecidos no mercado. O formato IGES foi de-senvolvido originalmente para a troca de dados entre modelos 2D/3D, texto, dimensionamento de dados e um limitado conjunto de superfícies. Devido a algumas limitações iniciais que este padrão apresentava, este tem sido gradualmente expandido e desenvolvido para suportar novas entidades e possuir uma sintaxe clara e consistente. As últimas versões já apresentam entre outras carac-terísticas geometrias, representações de rascunhos para desenho técnico, elementos dependentes de aplicação e Modelagem por Elementos Finitos (FEM). A unidade fundamental nos ficheiros IGESé a entidade, que é categorizada como geométrica e não-geométrica. A entidade geométrica representa a definição virtual de uma forma física e inclui pontos, curvas, superfícies, sólidos e relações entre coleções de entidades estruturadas de forma similar. Entidades não-geométricas são utilizadas para enriquecer o modelo fornecendo perspetivas de visualização de um desenho planar com as suas respetivas escalas e observações pertinentes. Estes tipos de entidades servem também para especificar atributos e características para uma só entidade ou para um grupos de entidades. As entidades não-geométricas típicas para definição, anotação e dimensionamento dos desenhos são: view, drawing, general note, witness line e leader. As entidades não-geométricas típicas para atributos e agrupamentos são as entidades de propriedade e associação. O ficheiro IGES é composto por seis secções diferentes: Flag, Start, Global, Directory Entry, Parameter Data e Terminate. Cada ocorrência de uma entidade consiste em dois registos - um no Directory Entry e um no Parameter Data. O Directory Entry necessita de um índice e de atributos a incluir na de-scrição da informação gráfica. O Parameter Data define a entidade específica. Todos os Parameter Datasão definidos por registos de comprimento fixo, de acordo com as suas entradas correspon-dentes. Cada instância de uma entidade possui apontadores bi-direcionais entre o Directory entry e a secção Parameter Data. Um dos grandes problemas práticos em trabalhar com ficheiros IGES é o seu tamanho e consequente tempo de processamento. A necessidade de ponteiros bi-direcionais nas secções Directory Entry e Parameter Data em conjunto com a restrição de possuir formatos

(35)

Estado da Arte

de registos fixos têm causado problemas durante a sua utilização por pré e pós-processadores. O padrão IGES está sob o controlo da NCGA (National Computer Graphics Association) e faz parte do U.S. Product Data Association (USPRO) e do IGES/PDES Organisation (IGO).

2.3.1 SET

É um padrão francês para o armazenamento e troca de dados CAE e é suportado por grande parte das plataformas CAD do mercado. O seu acrónimo deriva de "Standard d’Echange et de Transfert". Foi desenvolvido pela indústria aeroespacial em 1983 para a troca de informação entre diferentes plataformas CAD. O objetivo era desenvolver uma alternativa mais autêntica e fiável comparada ao IGES. Em 1985, o padrão SET tornou-se o padrão oficial francês, Afnor Z68-300. Este padrão suporta wireframe, surface e solid models, incluindo CSG e B-Rep. Foram incluídas também entidades para drafting e conectividade entre aplicações, como scientific data e FEM (Finite Element Method). Este formato neutro tem a grande vantagem de não possuir um formato ambíguo, ter um tamanho bastante compacto e ser flexível o suficiente para ser modificado segundo as necessidades da indústria CAD/CAM [Vuo96]. A GOSET é a organização que foi fundada por alguns dos principais utilizadores do SET e é responsável pela promoção, manutenção do padrão e eventuais desenvolvimentos. GOSET é o órgão que possui o serviço de validação para interfaces SET em desenvolvimento. A arquitetura SET é baseada em 3 níveis de hierarquia - data Assemblies, data Blocks e data Sub–blocks. As informações que são comuns a muitos blocks ou assembliessão armazenados numa sessão denominada Dictionary. Assembly é uma coleção de registos que definem informação acerca da peça, como por exemplo a informação sobre as partes mecânicas. Um ficheiro SET pode conter mais de um data assembly. Já o Block consiste num identificador seguido de um número do tipo bloco.

2.3.2 STL

É um formato nativo criado por uma empresa de Valencia, CA, USA chamada 3D Systems para seu Stereolithography CAD software. Este padrão neutro é largamente utilizado sendo o preferido pelos sistemas de prototipagem rápida. Este formato de troca pode ter duas codificações de dados, ASCII ou binária, sendo a codificação binária a mais utilizada devido ao seu reduzido tamanho quando comparado com a codificação ASCII.

2.3.3 STEP (ISO 10303)

A sigla STEP deriva de "the STandard for the Exchange of Product model data" e baseia-se na norma ISO 10303 para representação e troca de informação geométrica de produtos [Owe94], ou seja, é uma série de documentos que facilitam a partilha de informação, utilizada habitualmente no desenvolvimento de produtos. O desenvolvimento do padrão STEP iniciou-se em 1984 num pro-jeto de colaboração mundial. O objetivo principal era definir um padrão que abrangesse todos os aspetos de um produto (geometria, topologia, tolerância, material, etc.), durante todo seu tempo de vida - algo que nunca tinha sido feito anteriormente. O STEP apareceu como uma coleção

(36)

Estado da Arte

de padrões internacionais reunidos para representar e trocar informações sobre produtos. O de-senvolvimento do padrão STEP tem sido controlado pela International Standards Organisation (ISO), Technical Committee 184 (TC184, Industrial Automation Systems) e Subcommitte 4 (SC4, Industrial Data and Global Manufacturing Programming Languages). Este formato é utilizado para partilhar informação CAD, modelos, estruturas complexas e desenhos técnicos de produtos durante o seu tempo de vida, através de um mecanismo independente da plataforma de desenvolvi-mento em que se trabalha. Isto separa a representação da informação do produto dos seus métodos de implementação. A utilização dos métodos voltados para a troca de informação entre diferentes plataformas, com uma única representação, permite a representação da informação unificada de um mesmo produto para diferentes aplicações. Este formato é muito usual na indústria aeroespa-cial, automóvel, naval e da construção civil. A informação geométrica dos produtos foi catalogada pela ISO como padrão 10303, na forma de arquivos de troca, interfaces de programação para aplicações industriais e implementações para bases de dados, recebendo a denominação STEP. O padrão STEP está dividido em diferentes partes:

• Princípios Fundamentais: define os princípios fundamentais do padrão.

• Descrição de Métodos: a linguagem de modelagem de dados EXPRESS [Sch94] que rep-resenta a informação sobre os produtos.

• Implementação dos Métodos: contém a definição da representação física da informação do produto.

• Teste de Conformidade: framework e metodologia de teste de conformidade.

• Recursos Integrados: contém a representação da informação do produto comum a diferentes protocolos de aplicações.

• Protocolos para Aplicação: contém a representação da informação do produto específica para uma área particular de aplicação.

• Testes Abstratos: conjunto de testes abstratos para um protocolo de aplicação suportar os requisitos de conformidade.

Linguagem EXPRESS (ISO 10303-11)

Express é o nome oficial do ISO 10303-11, uma linguagem de programação parecida a PASCAL, usada para a representação de um ficheiro STEP.

A linguagem EXPRESS foi desenvolvida dentro das normas STEP como uma norma ISO para permitir a representação e troca de dados do produto. Foi especialmente criada para especificar um modelo de informações que representa um número de passos no ciclo de vida do produto.

Assim, EXPRESS fornece a sintaxe e a semântica para representar toda a informação de uma forma uniforme, precisa e compacta. A representação em EXPRESS é possível de duas formas:

(37)

Estado da Arte

• Como uma linguagem formal que usa uma notação léxica e uma sintaxe definida por uma gramática própria;

• Como uma representação gráfica (chamada EXPRESS-G), que fornece uma ilustração bas-tante compacta e “amigável” para a representação do produto.

EXPRESS trata-se de uma linguagem de descrição de dados orientada a objetos. Está estru-turada em esquemas que representam o modelo do produto. Um esquema consiste em entidades, que são os principais objetos e tipos de dados na qual se apoiam as definições destas entidades. Dentro das entidades estão encapsulados atributos e vínculos, que restringem os valores dos atrib-utos. Um esquema EXPRESS também tem declarações de FUNÇÕES, PROCEDIMENTOS e REGRAS que restringem uma ou mais entidades ou tipos de dados. A linguagem EXPRESS é definida na norma ISO 10303-11. A figura 2.5 apresenta um exemplo de um esquema com as entidades: ponto e ponto cartesiano.

Figure 2.5: Exemplo da representação de uma entidade em EXPRESS

Os conceitos de modelação da linguagem EXPRESS podem ser separados em cinco catego-rias: esquema, entidade, atributo, relacionamento e restrições.

Um esquema define um scope e o contexto de um conjunto de entidades. As entidades de um esquema partilham definições e semânticas comuns dentro de um mesmo contexto.

Uma entidade é sempre declarada dentro de um esquema e corresponde a um objeto do mundo real ou um conceito de interesse. Uma entidade tem um conjunto de atributos que podem ter relações com outras entidades. Uma declaração de entidade define um tipo de entidade que pode ser usada para definir o domínio de um atributo.

Um atributo define uma parte importante de uma entidade e pode ser um atributo simples ou um atributo agregado/composto. Um atributo é representado por um nome e um tipo.

(38)

Estado da Arte

Os relacionamentos podem ser de dois tipos: “é um” ou “tem um”. A relação “é um” é usada para fazer uma generalização e uma hierarquização especial entre tipos de entidades que estão relacionadas no sentido em que representam uma coisa comum, e.g. um cão “é um” animal. A relação “tem um” é usada para descrever uma associação entre tipos diferentes de entidades, em que um tipo de entidade pode ser considerado como parte de outro tipo, e.g. um carro “tem um” conjunto de quatro rodas.

A linguagem EXPRESS define um mecanismo poderoso de restringir os valores de um atributo e as diferentes relações entre entidades. As restrições podem ser aplicadas localmente para cada entidade ou para todo o esquema, de modo global. Esta linguagem também pode ser apresentada na sua forma gráfica, denominada EXPRESS-G, o que a torna muito mais percetível e simples de entender, figura 2.6.

Figure 2.6: Componentes da linguagem EXPRESS-G

Na figura 2.7 é apresentada a descrição de um furo para o protocolo de aplicação AP224 em EXPRESS, na forma de texto, e na figura 2.8 a mesma entidade na sua forma gráfica em EXPRESS-G.

(39)

Estado da Arte

(40)

Estado da Arte

2.4 Ferramentas de Integração CAD em ERP’s

2.4.1 SAP Engineering Control Center

Em Abril de 2014, a SAP anunciou uma plataforma para empresas capaz de responder às suas necessidades, bem como ajudar as empresas a crescer. Combinando os dados de projeto prove-nientes de CAD com os dados de negócios presentes no SAP, o SAP Engenharia Control Center garante uma definição do produto consistente e precisa para a empresa. Um acesso mais fácil e controlado aos dados de negócios permite, desta forma, libertar mais tempo para atividades cria-tivas. A capacidade de combinar o modelo 3D vindo do CAD com os dados de negócios, em tempo real, oferece um valor único para os utilizadores. A informação em tempo real dos estados de objetos mantidos pelo SAP fica diretamente disponível para o utilizador final, enquanto analisa o modelo. Além disto, esta ferramenta permite selecionar visualmente as peças de montagem e instantaneamente aceder a todas as informações sobre o produto, incluindo classificação, dados de materiais de peças e outros.

SAP Engineering Control Centerpossui, desta forma, vantagens tais como:

• Todos os dados CAD estão disponíveis a qualquer momento para serem usados em qualquer processo, incluindo compras, planeamento de produção, preparação da produção, produção vendas, serviços, etc.

• Os utilizadores podem trabalhar confortavelmente no seu próprio ambiente CAD – não ex-iste uma interface entre ERP e Sex-istemas de PLM.

Figure 2.9: SAP Engineering Control Center

Contudo, o SAP Engineering Control Center é um módulo do SAP e, como tal, implica a existência do ERP na empresa. Desta forma, não é adequado a PME’s pois possui um elevado custo de implementação.

(41)

Chapter 3

Especificação e Arquitetura do Sistema

Neste capítulo descrevem-se detalhadamente as fases de especificação e arquitetura do projeto. O projeto seguiu os parâmetros tradicionais de desenvolvimento de um projeto de engenharia de software, tendo sido orientado a partir das fases de: conceção, desenvolvimento e testes e resultados.

3.1 Especificação de Requisitos

Nesta secção é apresentada a especificação dos requisitos, fazendo distinção entre requisitos cionais e requisitos não-funcionais. Os requisitos funcionais englobam o conteúdo e as fun-cionalidades do sistema e os requisitos não-funcionais estão associados à qualidade do software, nomeadamente ao seu desempenho, usabilidade, fiabilidade, segurança e disponibilidade.

3.1.1 Requisitos Funcionais

Após o levantamento de requisitos foi possível verificar as funcionalidades desejadas para a plataforma pretendida, considerando-se assim como principais os requisitos funcionais, os requisitos para o utilizador e os requisitos de funcionalidades da plataforma. Os resultados são apresentados na tabela 3.1 e na tabela 3.2, respetivamente.

(42)

Especificação e Arquitetura do Sistema

Table 3.1: Requisitos do Utilizador.

Requisitos do Utilizador

UI001 Fazer upload de um ou mais ficheiros STEP UI002 Visualizar estrutura hierárquica do produto UI003 Visualizar Produto em 3D

UI004 Visualizar notas de fabrico

Table 3.2: Requisitos de Funcionalidades da Plataforma.

Requisitos de Funcionalidades da Plataforma

FP001 Fazer upload de ficheiros simples FP002 Fazer upload de ficheiros compostos

FP003 Extrair composição do produto do ficheiro STEP FP004 Extrair informação geométrica do ficheiro STEP FP005 Extrair notas de fabrico do ficheiro STEP

FP006 Representação da informação geométrica/estrutura do produto em json

FP007 Decomposição de informação geométrica/estrutura do produto em vários ficheiros indexados.

(43)

3.1.2 Requisitos Não Funcionais

Tendo em conta a qualidade do software pretendida para este projeto, destacam-se como principais requisitos não funcionais: usabilidade, escalabilidade e extensibilidade. De modo a respeitar estes requisitos foram tomadas algumas decisões relativamente às tecnologias a usar e ao padrão de arquitetura do sistema a adotar, que são detalhadas a seguir:

Tecnologias usadas

De forma a criar uma plataforma de grande usabilidade, fluída e responsiva, foram adotadas as tecnologias web NodeJS e AngualarJS, para a criação de um servidor e uma interface para o utilizador bastante simples e funcionais. Por sua vez, para o tratamento dos ficheiros STEP foi usado JAVA, pois como se trata de uma linguagem orientada a objetos, mostrou-se de grande utilidade para a manipulação dos elementos que constituem um ficheiros STEP.

Independência de módulos

A plataforma criada, encontra-se dividia em módulos independentes podendo, desta forma, ser reaproveitada e integrada em diferentes sistemas. Esta plataforma possui um módulo para análise e tratamento dos ficheiros STEP, outro para a integração do viewer 3D e um terceiro módulo para a interface do utilizador.

Integração de viewer 3D

Para a representação 3D dos produtos e dos seus componentes, foi adotado um viewer já existente open sourcepois, o tempo de realização da dissertação era inviável para a criação de um viewer de raiz. Contudo, o viewer escolhido encontra-se em linguagem web o que torna fácil a sua integração na plataforma desenvolvida.

Performance para ficheiros de grandes dimensões

Devido ás dimensões que os ficheiros STEP podem apresentar, foi tido em conta o carregamento destes ficheiros e de toda a informação extraída dos mesmos. Toda a informação extraída é or-ganizada em vários ficheiros indexados, o que possibilita o carregamento apenas dos ficheiros necessários para a representação de determinado produto ou componente, aumentando assim a performance da plataforma para ficheiros de grande dimensões.

3.1.3 Não Requisitos

Além dos requisitos funcionais e não funcionais, também foram analisados requisitos que pode-riam fazer parte deste projeto mas que, dado o tempo de realização da dissertação não sepode-riam cumpridos. Desta forma, são apresentados na tabela 3.3, os não requisitos da plataforma criada, podendo servir de ponto de partida para um possível trabalho futuro.

(44)

Table 3.3: Não Requisitos.

Não Requisitos

NR001 Criação de um viewer 3D de raiz para posterior visualização do produto e dos seus componentes

NR002 Integração da plataforma desenvolvida com ERP

NR003 Representação 3D para todos os formatos STEP suportados pela norma AP242

3.2 Funcionalidades do Sistema

O sistema desenvolvido possui uma série de funcionalidades que respondem aos requisitos do utilizador. Como mencionado anteriormente, pretende-se um sistema que seja capaz de extrair a estrutura de um produto representada no formato STEP, bem como a visualização 3D dos compo-nentes que constituem um produto. O diagrama apresentado na figura 3.1 demonstra o fluxo das atividades do programa desenvolvido, bem como todas as interações do utilizador com a plataforma criada.

(45)

3.3 Módulos de Desenvolvimento do Sistema

O sistema desenvolvido, foi dividido em diferentes módulos, de forma a simplificar a sua imple-mentação e a facilitar a perceção da lógica de desenvolvimento da plataforma criada. O diagrama apresentado na figura 3.2, representa a organização dos diferentes módulos da aplicação.

Figure 3.2: Módulos da aplicação

Como é possível verificar, são apresentados três grandes módulos: representação da estrutura do produto, viewer 3D para representação do produto e interface do utilizador.

Para a representação da estrutura do produto foi necessário perceber a arquitetura dos ficheiros STEP, de forma a entender como a informação é representada neste formato e de seguida construir uma plataforma capaz de importar qualquer tipo de ficheiro STEP e visualizar a estrutura do produto.

Por sua vez, para a representação 3D dos produtos, foi necessário integrar um viewer open sourceadotado. Depois, foi feita uma análise dos ficheiros JSON que o viewer consome para pos-teriormente identificar e extrair essa informação do ficheiro STEP. Para fornecer toda a informação necessária ao viewer, foi ainda necessário a criação de um método de triangulação de polígonos, por forma a representar as faces do produto e de todos os seus componentes no respetivo viewer 3D.

(46)

3.4 Arquitetura do Sistema

A arquitetura de um sistema de software tem assumido ao longo dos anos um papel fundamental no processo de desenvolvimento de software. Associados à definição de arquitetura de software surgem os conceitos de: padrões de arquitetura e estilos de arquitetura. Segundo Buschmann [FB96], um padrão de arquitetura expressa um conjunto de decisões de arquitetura que são aplicáveis a um problema recorrente. Os estilos de arquitetura relacionam-se com problemas do sistema rel-ativos à especificação da estrutura geral do sistema, isto é, à sua organização, às regras de comu-nicação entre componentes e ao acesso aos dados. Vários autores, entre os quais Krafzing, Banke e Slama [DK05], explicam que a arquitetura de software define em termos computacionais quais são os seus elementos arquiteturais e como ocorre a interação entre eles, envolvendo a descrição dos mesmos e padrões que guiam a composição e as restrições sobre estes padrões. Neste capítulo é definida a arquitetura do sistema, discriminando o desenho da arquitetura e a arquitetura física, lógica e tecnológica aplicadas.

3.4.1 Desenho da Arquitetura

Para facilitar e agilizar o processo de desenvolvimento e implementação, foram analisadas algu-mas frameworks open source de desenvolvimento de aplicações web disponíveis no mercado, que se adequassem aos padrões de arquitetura referidos, tais como Ruby on Rails, Node.js e Sym-fony2, sendo adotada as frameworks Node.js + AngularJs. Além da plataforma Web desenvolvida com recurso a Node.js e a AngularJs, foi desenvolvido um programa em JAVA responsável pela interpretação e extração de toda a informação necessária de um ficheiro STEP. Desta forma, todo o sistema criado pode ser dividido em duas partes - uma parte correspondente à interface com o utilizador e à visualização 3D dos produtos e uma outra parte correspondente ao programa respon-sável pela identificação e extração de toda a informação necessária contida num ficheiro STEP e criação dos ficheiros JSON que posteriormente são fornecidos à aplicação web.

3.4.2 Arquitetura Física

Nesta secção apresenta-se a definição da estrutura física do sistema de software que está a ser de-senvolvido, enfatizando as principais componentes da aplicação, a forma como estão organizadas e as dependências entre elas. A figura 3.3. representa a arquitetura física do sistema, ou seja, as interligações entre os vários componentes físicos. A plataforma apresenta uma arquitetura física constituída pela máquina do utilizador, servidor web e uma aplicação JAVA. A aplicação Java é responsável por disponibilizar a informação necessária para a representação 3D e visualização da estrutura hierárquica do produto, sob forma de ficheiros JSON.

(47)

Figure 3.3: Arquitetura Física

3.4.3 Arquitetura Lógica

Quanto a lógica do sistema, encontra-se concentrada num programa JAVA que recebe os ficheiros STEP e extrai toda a informação necessária para a representação 3D e para a construção da es-trutura do produto. O programa Java encontra-se dividido em duas principais packages, como demonstra a figura 3.4

Figure 3.4: Packages Java

A package "PolyTri" contém todo o código correspondente aos algoritmos de triangulação de polígonos utilizados para a representação 3D. E uma package chamada "ProductStructure" que contém o código correspondente ao tratamento dos ficheiros STEP em particular e à aplicação dos algoritmos descritos na package "PolyTri".

A package "PolyTri", é constituída por duas classes importantes, a classe "Triangulation" que contém métodos para triangulação de superfícies do produto representado nos ficheiros STEP e a classe "Polygon" que contém métodos para criação e representação dos polígonos resultantes da triangulação de superfícies. A figura 3.5 representa as todas as classes contidas na package "PolyTri".

(48)

Figure 3.5: Classes presentes em PolyTri

Por último, a package "ProductStructure" é constituída por oito classes importantes: a classe "ReaderInter", que é a classe main do programa onde se inicia todo o processo de leitura dos ficheiros STEP; a classe "Tree", que representa e guarda a estrutura do produto extraída dos ficheiros STEP; a classe "Node", que representa cada nó da estrutura do produto; a classe "Sur-face", que representa as superfícies do produto a representar; a classe "CartesianPoint", que rep-resenta cada ponto cartesiano necessário para reprep-resentar as superfícies e polígonos; e, por fim, as classes "Product", "Shape" e "Shell", que contém informação importante e necessária para a cri-ação dos ficheiros JSON que posteriormente serão consumidos pelo visualizador 3D. As classes mencionadas podem ser observadas na figura 3.6.

(49)

(50)

3.4.4 Arquitetura Tecnológica

Na figura 3.7 são apresentadas as tecnologias usadas no desenvolvimento do sistema. A plataforma desenvolvida faz uso de diversas tecnologias bastante utilizadas na atualidade. O sistema imple-mentado usa NodeJS para o servidor da aplicação, AngularJS para a interface com o utilizador e Java para o tratamento dos ficheiros STEP.

Figure 3.7: Arquitetura Tecnológica

NodeJS

Node.js é uma plataforma cujo objetivo é a fácil construção de rápidas e escaláveis aplicações de rede. Para tal adota um modelo baseado em eventos e non-blocking I/O. Foi desenvolvido por Ryan Dahl em 2009. Trata-se de um ambiente javascript no lado do servidor, single-threaded, implementado em C/C++. AS aplicações Node.js podem ser escritas utilizando javascript, sendo que, para tal, o framework faz uso da Javascript Engine V8 do Google. A V8 é a implemen-tação javascript utilizada pelo navegador Google Chrome. Esta é extremamente rápida, contudo necessitou de algumas modificações para que apresentasse um melhor funcionamento em outros contextos que não sejam o browser. Para que se tenha I/O baseado em eventos e non-blocking, o Node.js faz uso de bibliotecas C libev e libeio, desenvolvidas por Marc Lehmann. O Node.js é composto por diversos módulos: módulos que fazem parte do núcleo da plataforma, chamados core modules, e módulos desenvolvidos pela comunidade. A arquitetura padrão da plataforma pode ser vista na figura 3.8.

(51)

Figure 3.8: Arquitetura Node

AngularJs

O AngularJS foi construído sob a crença de que a programação declarativa é melhor do que a programação imperativa quando se trata da construção de interfaces para o utilizador e da conexão de componentes software, enquanto a programação imperativa é excelente para a escrita de regras de negócio. Esta framework adapta e estende o HTML tradicional para uma melhor experiência com conteúdo dinâmico, com a ligação direta e bidirecional dos dados (two-way data-binding) que permite sincronização automática de models e views. Como resultado, AngularJS abstrai a manipulação do DOM e melhora os testes. Na figura 3.9, podemos observar a arquitetura do AngularJS.

(52)

(53)

Chapter 4

Arquitetura e Organização de um

Ficheiro STEP

O projeto desenvolvido baseia-se num formato de representação de dados chamado STEP. Este formato foi adotado para a realização desta dissertação por ser um formato extremamente utilizado pelas empresas e sistemas nos dias de hoje, além de que, possui imensas potencialidades, sendo capaz de representar uma quantidade enorme e diversificada de informação acerca de um produto. Um ficheiro STEP segue uma estrutura bem definida constituída por um grupo de tag’s que representam toda a informação associada a um produto, tal como podemos verificar na figura 4.1.

(54)

Arquitetura e Organização de um Ficheiro STEP

HEADER_SECTION A secção HEADER tem uma estrutura fixa que consiste em 3 a 6 grupos na ordem dada. À exceção dos campos FILE_NAME e FILE_SCHEMA todos os campos podem estar vazios.

• description

• implementation level: Versão em conformidade do ficheiro. As versões possíveis são 1,2,3.

1. Para o padrão original de 1994. 2. Correção Técnica de 1995. 3. 2aedição.

FILE_NAME secção com os seguintes elementos.

Name Nome da estrutura. Pode corresponder ao nome do ficheiro num sistema de ficheiros e reflete os dados presentes no ficheiro.

time_Stamp Indica quando o ficheiro foi criado. O tempo é indicado no formato internacional ISO 8601, por exemplo, 20031227T11.

author Identificação do criador do ficheiro.

Organization Organização a que o ficheiro pertence.

processor_version Nome e versão do sistema que produziu o ficheiro.

originating_system Nome e versão do sistema que originalmente produziu a infor-mação contida no ficheiro.

Authorization Identificação das pessoas autorizadas a editar o ficheiro.

FILE_SCHEMA Especifica um ou vários EXPRESS SCHEMAS que regem às infor-mações contidas no ficheiro STEP. Os últimos 3 campos apenas são válidos na 2a edição onde podemos especificar vários SCHEMAS.

FILE_POPULATION Indica uma população válida (conjunto de instâncias), que está em conformidade com os EXPRESS SCHEMAS. Isto é feito através da recolha de dados a partir de várias secções e referenciando instâncias de outras secções de dados. Governing_schema EXPRESS SCHEMA à qual a população indicada pertence e

pode ser validada.

Determination method Método de determinação de instâncias pertencentes à popu-lação. Existem 3 métodos predefinidos:

• SECTION_BOUNDARY

• INCLUDE_ALL_COMPATIBLE • INCLUDE_REFERENCED 5

Governed sections Secções de dados cujas instâncias entidade pertencem totalmente à população.

A Norma STEP - ISO10303 AP242 como Instrumento de Integração entre Engenharia de Produto e de Processo

F

E

U

P

PRODUCT-PROCESS

ENGINEERING INTEGRATION

USING STEP – ISO 10303 AP242

Miguel Ângelo Jesus Vidal Ribeiro

PRODUCT-PROCESS ENGINEERING INTEGRATION

USING STEP – ISO 10303 AP242

Miguel Ângelo Jesus Vidal Ribeiro

Mestrado Integrado em Engenharia Informática e Computação

Resumo

Abstract

Agradecimentos

Contents

List of Figures

List of Tables

Abbreviations

Chapter 1

Introdução

1.1

Problema e Enquadramento do Projeto

1.2

Motivação e Objetivos

1.3

Estrutura da Dissertação

Chapter 2

Estado da Arte

2.1

Estrutura do Produto

2.2

Metodologias de Produção Avançadas

2.3

Formatos para Troca e Representação de Dados

2.4

Ferramentas de Integração CAD em ERP’s

Chapter 3

Especificação e Arquitetura do Sistema

3.1

Especificação de Requisitos

3.2

Funcionalidades do Sistema

3.3

Módulos de Desenvolvimento do Sistema

3.4

Arquitetura do Sistema

Chapter 4

Arquitetura e Organização de um

Ficheiro STEP