trabajo fin de gradobibing.us.es/proyectos/abreproy/90150/fichero/tfg... · trabajo fin de grado:...

Trabajo Fin de Grado

Grado de Ingeniería en Tecnologías Industriales

Análisis y desarrollo de productos en sistemas PLM

Autor: Carlos Bellido Feria

Tutor: Jesús Racero Moreno

Dep. Organización Industrial y Gestión de

Empresas I

Escuela Técnica Superior de Ingeniería

Universidad de Sevilla Sevilla, 2014

Trabajo Fin de Grado

Grado de Ingeniería en Tecnologías Industriales

Autor:

Carlos Bellido Feria

Tutor:

Jesús Racero Moreno

Profesor titular

Dep. Organización Industrial y Gestión de Empresas I

Escuela Técnica Superior de Ingeniería

Universidad de Sevilla

Sevilla, 2014

Trabajo Fin de Grado: Análisis y desarrollo de productos en sistemas PLM

Autor: Carlos Bellido Feria

Tutor: Jesús Racero Moreno

El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros:

Presidente:

Vocales:

Secretario:

Acuerdan otorgarle la calificación de:

Sevilla, 2014

El Secretario del Tribunal

1

Tabla de contenido

1 Introducción y objetivos ....................................................................................................... 11

1.1 Introducción al ciclo de vida del producto. ................................................................... 11

1.2 El ciclo de vida del avión. ............................................................................................. 13

1.3 Objetivos. ..................................................................................................................... 15

2 Ciclo de vida del producto ................................................................................................... 17

2.1 Introducción histórica. .................................................................................................. 17

2.2 Descripción general de PLM. ....................................................................................... 18

2.3 Funciones de un PLM. ................................................................................................. 18

2.4 Otros sistemas ERP, PDM, CAD y relación con PLM. ................................................. 20

2.5 Beneficios en la utilización de un sistema PLM. .......................................................... 23

2.6 Reducción del Time-to-market. .................................................................................... 24

2.7 Herramientas software para sistemas PLM. ................................................................ 25

2.7.1 Requisitos software en un sistema PLM. ............................................................. 25

2.7.2 Fundamentos PLM 2.0 de Dassault Systèmes. ................................................... 27

2.7.3 Herramientas SW orientadas a PLM 2.0. ............................................................. 28

2.8 Definición de los requisitos hardware en un sistema PLM 2.0. .................................... 36

2.8.1 Arquitectura HW. .................................................................................................. 36

2.8.2 Requisitos hardware y software para clientes web. ............................................. 44

2.8.3 Clientes pesados. ................................................................................................ 46

2.8.4 Servidor................................................................................................................ 47

2.8.5 Plataformas adicionales para las licencias de servidores DS. ............................. 49

2.8.6 Equipos certificados del sistema V6..................................................................... 50

2.8.7 Recomendaciones hardware del sistema V6. ...................................................... 52

3 La gestión del ciclo de vida con ENOVIA V6 ....................................................................... 53

3.1 Introducción. ................................................................................................................ 53

3.1.1 Introducción PLM 2.0. .......................................................................................... 53

3.1.2 Valores de PLM 2.0 en V6. .................................................................................. 54

3.1.3 Gestión del ciclo de vida IP. ................................................................................. 55

3.2 Innovación colaborativa. .............................................................................................. 55

3.2.1 Innovación colaborativa. ...................................................................................... 55

2

3.2.2 Colaboración instantánea y 3D Lluvia de ideas. .................................................. 56

3.2.3 Colaboración unificada en vivo. ........................................................................... 56

3.2.4 The Heads-Up Display (HUD). ............................................................................. 57

3.2.5 Modos de conectividad en colaboración. ............................................................. 57

3.2.6 Marco CATIA Live. ............................................................................................... 58

3.3 Herramientas V6. ......................................................................................................... 58

3.3.1 Arquitectura V6. ................................................................................................... 58

3.3.2 Arquitectura V6: acceso remoto a archivos. ......................................................... 59

3.3.3 V6 Express. .......................................................................................................... 60

3.3.4 Interfaz V6 PLM 2.0. ............................................................................................ 60

3.3.5 Plataforma de estudio de modelado ENOVIA (DTE)............................................ 61

3.3.6 Componentes del servidor ENOVIA V6. .............................................................. 62

3.3.7 Esquema ENOVIA. .............................................................................................. 63

3.3.8 Caja de herramientas ENOVIA (ADT). ................................................................. 64

3.3.9 Analizador de esquemas ENOVIA. ...................................................................... 64

3.3.10 Servicios de Procesos de Negocio (Business Process Services - BPS). ............. 65

3.3.11 JSP, JAVA BEANS and JPOs. ............................................................................. 65

3.3.12 Application exchange framework. ........................................................................ 66

3.3.13 Tipos de datos en ENOVIA V6. ............................................................................ 68

3.3.14 Qué es un metadato. ........................................................................................... 68

3.3.15 3D XML. ............................................................................................................... 68

3.3.16 Introducción a la solución “Imagina&Crea” (Imagine&Shape Solution - IMS). ..... 69

3.3.17 Integración con CATIA V6. ................................................................................... 70

3.4 Conexión a V6. ............................................................................................................ 70

3.4.1 Conectarte a V6. .................................................................................................. 70

3.4.2 Contexto de seguridad y roles. ............................................................................ 71

3.4.3 Guardar nuestro proyecto. ................................................................................... 71

3.4.4 Modelo de datos y Acceso. .................................................................................. 72

3.5 Centrales ENOVIA. ...................................................................................................... 72

3.5.1 ENOVIA Program Central. ................................................................................... 72

3.5.2 Introducción a la Central de Ingeniería ENOVIA. ................................................. 74

3.5.3 Central de Requisitos ENOVIA. ........................................................................... 76

3

3.5.4 Central de Variaciones de Configuración ENOVIA. ............................................. 77

3.5.5 Central de Librerías ENOVIA. .............................................................................. 80

3.5.6 Central de recursos ENOVIA. .............................................................................. 81

3.5.7 Central de presupuestos ENOVIA. ...................................................................... 81

3.5.8 Central de Proveedores ENOVIA. ........................................................................ 81

3.5.9 Central de Presupuestos ENOVIA. ...................................................................... 82

3.5.10 Búsqueda Global. ................................................................................................ 82

3.5.11 Gobernancia. ....................................................................................................... 83

3.5.12 ENOVIA VPM. ...................................................................................................... 83

3.6 Organización de la empresa. ....................................................................................... 89

3.6.1 Conceptos ENOVIA. Organización de la empresa. .............................................. 89

3.6.2 Equipo de colaboración en vivo ENOVIA. ............................................................ 90

3.6.3 Objetos de Negocio & Objetos Administrativos. ................................................... 91

3.6.4 Objetos de Negocio en ENOVIA V6. .................................................................... 91

3.6.5 Conceptos de Personas y Organización (P&O). .................................................. 92

3.6.6 Introducción al Esquema Enovia. ......................................................................... 93

3.6.7 Tipos. ................................................................................................................... 94

3.6.8 Atributos. .............................................................................................................. 94

3.6.9 Relaciones. .......................................................................................................... 95

3.6.10 Políticas. .............................................................................................................. 95

3.6.11 Valores. ................................................................................................................ 95

3.6.12 Tiendas. ............................................................................................................... 96

3.7 Líneas de producto y Piezas. ....................................................................................... 96

3.7.1 Líneas de producto. ............................................................................................. 96

3.7.2 Introducción a las Piezas y sus ciclos de vida. .................................................... 97

3.7.3 Ciclo de vida de una Pieza en Desarrollo. ........................................................... 98

3.7.4 Ciclo de vida de una Pieza de la Empresa. .......................................................... 99

3.7.5 Clonación de piezas. .......................................................................................... 101

3.7.6 Creación de especificaciones adjuntas a la pieza. ............................................. 101

3.7.7 Ciclo de Vida de una Especificación de una pieza. ............................................ 101

4 Diseño e implementación de una línea de producto en un sistema a PLM ....................... 103

4.1 Introducción. .............................................................................................................. 103

4

4.2 Conceptos en la implementación. .............................................................................. 103

4.2.1 Definición del producto....................................................................................... 103

4.2.2 Definición de la estructura organizativa. ............................................................ 109

4.2.3 Definición de la línea del producto. .................................................................... 110

4.2.4 Concepto de parte y familia de piezas. .............................................................. 111

4.2.5 Cambios de ingeniería. ...................................................................................... 115

4.2.6 Efectividad del producto. .................................................................................... 118

4.2.7 Lista de materiales del producto. ....................................................................... 119

4.3 Implantación en ENOVIA V6. ..................................................................................... 120

4.3.1 Creación de la estructura organizativa. .............................................................. 121

4.3.2 Creación de Línea de Producto, estructura y sincronización. ............................ 127

4.3.3 Creación de producto. ........................................................................................ 137

4.3.4 Creación de un desarrollo. ................................................................................. 148

4.3.5 Definición de pieza y familia de piezas. ............................................................. 151

4.3.6 Realización de diferentes cambios de ingeniería. .............................................. 163

4.3.7 Definición de efectividad del producto................................................................ 167

4.3.8 Lista de materiales del producto. ....................................................................... 169

5 Conclusiones y extensiones. ............................................................................................. 173

5.1 Conclusiones obtenidas. ............................................................................................ 173

5.2 Posibles extensiones. ................................................................................................ 175

6 Bibliografía ........................................................................................................................ 177

5

Índice de figuras

Figura 1. Ejemplo del número de componentes en diferentes productos [2]. .............................. 12

Figura 2. Representación esquemática del avión A380. .............................................................. 12

Figura 3. Ciclo de vida típico de un programa aeronáutico para un avión civil. ........................... 13

Figura 4. Definición de fases principales e hitos en el ciclo de vida de un avión en Airbus [11]. . 14

Figura 5. Ciclo de vida de un ejemplar de un producto. ............................................................... 15

Figura 6. Globalización de herramientas en PLM ........................................................................ 22

Figura 7. Posibilidades del sistema V6 ........................................................................................ 28

Figura 8. Configuración de licencias de productos para entornos CATIA, DELMIA y ENOVIA ... 29

Figura 9. Licencias de productos disponible en paquete PLM Discovery .................................... 30

Figura 10. Arquitectura a tres niveles de ENOVIA V5 .................................................................. 36

Figura 11. Arquitectura a tres niveles de ENOVIA V6 .................................................................. 37

Figura 12. Configuración física de equipos con ENOVIA V6 ....................................................... 38






Figura 18. Escalabilidad del sistema ENOVIA V6 ........................................................................ 41

Figura 19. Escalabilidad del sistema ENOVIA V6 ........................................................................ 42

Figura 20. Escalabilidad del sistema ENOVIA V6 para entornos colaborativos ........................... 43

Figura 21. Escalabilidad del sistema en producción .................................................................... 44

Figura 22. Base de datos centralizada V6. .................................................................................. 54

Figura 23. Representación de acción colaborativa en HUD. ........................................................ 57

Figura 24. Interfaz CATIA V6. ...................................................................................................... 61

Figura 25. Ejemplo de acceso a los datos de la organización. Contexto de seguridad................ 71

Figura 26. Publicación con estructura resuelta. ........................................................................... 80

Figura 27. Publicación con estructura configurada. ..................................................................... 80

Figura 28. Diferencias entre V5 y V6. .......................................................................................... 84

Figura 29. Cuadrantes de la Brújula de ENOVIA VPM ............................................................... 86

Figura 30. Procesos en el sistema de diseño en V. RFLP. .......................................................... 88

6

Figura 31. Ejemplo de organización y línea de producto de Renault. .......................................... 97

Figura 32. Ciclo de vida de una pieza en desarrollo. ................................................................... 99

Figura 33. Ciclo de vida de una pieza. ....................................................................................... 100

Figura 34. Ciclo de vida de una Especificación de una pieza .................................................... 102

Figura 35. Presentación del producto “Mordaza”. ...................................................................... 104

Figura 36. Subsistemas del producto “Mordaza”. ...................................................................... 104

Figura 37. Vista del sistema de apriete del producto “Mordaza.” ............................................... 105

Figura 38. Componentes del sistema de apriete. ....................................................................... 105

Figura 39. Piezas que conforman el sistema “elementos de apriete”. ....................................... 106

Figura 40. Vista de los elementos de montaje del apriete.......................................................... 106

Figura 41. Vista comprensiva de la unión de los sistemas de sujeción y apriete. ...................... 107

Figura 42. Vista del sistema de sujeción del producto “Mordaza”. ............................................. 107

Figura 43. Vista de los subsistemas del sistema de sujeción del producto “Mordaza”. ............. 108

Figura 44. Vista de los elementos de sujeción. .......................................................................... 108

Figura 45. Vista general de los elementos de montaje de sujeción. .......................................... 109

Figura 46. Vista de las piezas que conforman los elementos de montaje de sujeción............... 109

Figura 47. Esquema lógico de una pieza derivada. Clonación. ................................................. 114

Figura 48. Esquema lógico de una pieza derivada. Reemplazo. ............................................... 114

Figura 49. Contexto de seguridad del usuario inicial. ................................................................ 121

Figura 50. Menú global Herramientas. ....................................................................................... 122

Figura 51. Página de configuración de ENOVIA. ....................................................................... 122

Figura 52. Página de creación de la organización. .................................................................... 123

Figura 53. Página de gestión de las organizaciones. ................................................................. 124

Figura 54. Página de creación del usuario. ................................................................................ 124

Figura 55. Ejemplo de creación del usuario. .............................................................................. 125

Figura 56. Página de gestión de usuarios. ................................................................................. 125

Figura 57. Ejemplo de creación de un proyecto. ........................................................................ 126

Figura 58. Comprobación de datos del nuevo usuario. .............................................................. 126

Figura 59. Comprobación del rol asignado al nuevo usuario. .................................................... 126

Figura 60. Página principal del nuevo usuario. .......................................................................... 127

Figura 61. Menú global “Mi Enovia”. .......................................................................................... 127

Figura 62. Página de Líneas de producto. ................................................................................. 128

7

Figura 63. Menú global “Acciones”. ........................................................................................... 128

Figura 64. Página de creación de una nueva Línea de producto. .............................................. 129

Figura 65. Verificación de creación de Línea de producto. ........................................................ 130

Figura 66. Detalles de la Línea de producto. ............................................................................. 131

Figura 67. Menú “Categorías” de una Línea de Producto. ......................................................... 131

Figura 68. Página de Líneas de productos subordinados. ......................................................... 132

Figura 69. Creación de Línea de producto subordinada. ........................................................... 132

Figura 70. Vista de las Líneas de producto subordinadas creadas. ........................................... 132

Figura 71. Creación de un modelo. ............................................................................................ 133

Figura 72. Página de gestión de los modelos. ........................................................................... 133

Figura 73. Página de creación de un modelo............................................................................. 134

Figura 74. Detalles del modelo creado. ..................................................................................... 135

Figura 75. Página de modelos de las líneas de productos subordinadas. ................................. 135

Figura 76. Detalles del modelo de la línea de productos subordinada. ...................................... 135

Figura 77. Creación de una nueva revisión del modelo. ............................................................ 136

Figura 78. Detalles de revisión del modelo. ............................................................................... 136

Figura 79. Página de productos. ................................................................................................ 136

Figura 80. Agregar pieza a un modelo. ...................................................................................... 137

Figura 81. Detalle de la estructura de la Línea de producto creada. .......................................... 137

Figura 82. Página principal de productos. .................................................................................. 138

Figura 83. Página de creación de un nuevo producto. ............................................................... 138

Figura 84. Clonación por copia selección. ................................................................................. 140

Figura 85. Página de copiar selección. ...................................................................................... 141

Figura 86. Ver informes de dependencia de un modelo. ........................................................... 141

Figura 87. Página de revisiones de un producto. ....................................................................... 142

Figura 88. Creación de una revisión del producto “Mordaza parental”. ..................................... 142

Figura 89. Página de creación de una revisión del producto. .................................................... 142

Figura 90. Acceso a página de versiones del producto. ............................................................ 143

Figura 91. Creación de nueva versión de producto. .................................................................. 143

Figura 92. Página de creación de una nueva versión de producto. ........................................... 144

Figura 93. Detalles de la nueva versión de producto creada. .................................................... 144

Figura 94. Actualización a la versión más reciente. ................................................................... 144

8

Figura 95. Vista de las variantes de un producto. ...................................................................... 145

Figura 96. Acceso a la página de las Carteras. ......................................................................... 145

Figura 97. Creación de una nueva Cartera. ............................................................................... 146

Figura 98. Página de creación de una nueva cartera. ............................................................... 146

Figura 99. Detalle de la cartera creada. ..................................................................................... 146

Figura 100. Selección de objetos a ver en la Línea de tiempo. .................................................. 147

Figura 101. Acceso a la Línea de tiempo. .................................................................................. 147

Figura 102. Creación de un desarrollo ....................................................................................... 148

Figura 103. Página de creación de un nuevo desarrollo. ........................................................... 149

Figura 104. Detalles del desarrollo creado................................................................................. 150

Figura 105. Creación de una nueva pieza. ................................................................................ 152

Figura 106. Página de creación de una nueva pieza. ................................................................ 152

Figura 107. Creación de una nueva familia de piezas. .............................................................. 154

Figura 108. Página de creación de una nueva familia de piezas. .............................................. 154

Figura 109. Vista de las familias de piezas. ............................................................................... 155

Figura 110. Piezas alternativas de la mordaza. ......................................................................... 156

Figura 111. Creación de pieza alternativa. ................................................................................ 156

Figura 112. Vista de piezas alternativas. ................................................................................... 157

Figura 113. Vista de imágenes. ................................................................................................. 157

Figura 114. Ver documentos de referencia. ............................................................................... 158

Figura 115. Página de documentos de referencia. .................................................................... 158

Figura 116. Iconos de acciones. ................................................................................................ 159

Figura 117. Creación de documento de referencia. ................................................................... 159

Figura 118. Página de creación del documento de referencia. .................................................. 160

Figura 119. Selección de archivos a adjuntar en el documento de referencia. .......................... 160

Figura 120. Detalle de los documentos de referencia creados. ................................................. 160

Figura 121. Creación de una pieza derivada. ............................................................................ 161

Figura 122. Clonación de una pieza. ......................................................................................... 161

Figura 123. Página de clonación de una pieza. ......................................................................... 162

Figura 124. Creación de solicitud de cambio de ingeniería........................................................ 163

Figura 125. Página de creación de una nueva solicitud de cambio de ingeniería. ..................... 164

Figura 126. Creación de una nueva orden de cambio de ingeniería. ......................................... 165

9

Figura 127. Página de creación de una nueva orden de cambio de ingeniería. ........................ 165

Figura 128. Creación de orden de cambio de desarrollo de ingeniería. ..................................... 167

Figura 129. Página de creación de orden de cambio de desarrollo de ingeniería. .................... 167

Figura 130. Definición de la Efectividad de una pieza. .............................................................. 168

Figura 131. Editor de efectividad. .............................................................................................. 168

Figura 132. Introducción de los valores de la unidad en la definición de la efectividad. ............ 169

Figura 133. Definición completa de la unidad de efectividad. .................................................... 169

Figura 134. Selección de pieza para la creación de BOM ......................................................... 170

Figura 135. Selección del visor de BOM .................................................................................... 170

Figura 136. Creación del BOM................................................................................................... 171

Figura 137. Selección de especificaciones de la pieza mordaza. .............................................. 171

Figura 138. Sincronización de pieza con ingeniería. .................................................................. 171

Figura 139. Página de sincronización con ingeniería. ................................................................ 172

Figura 140. Sincronización satisfactoria. ................................................................................... 172

11

1 Introducción y objetivos

1.1 Introducción al ciclo de vida del producto.

El acrónimo inglés PLM, que corresponde a las iniciales de “Product Lifecycle Management”,

se refiere a la Gestión del ciclo de vida del producto. Con estas siglas se hace referencia a las

soluciones informáticas de ayuda a la gestión del producto, desde su fase inicial de definición

estratégica de producto, pasando por el diseño de concepto, el diseño de detalle, la ingeniería de

producto, y la producción hasta su comercialización y posterior mantenimiento en los casos en

los que se requiere.

La gestión del ciclo de vida del producto (PLM) es una estrategia empresarial, de dirección y de

gestión de la información. Esto permite a las empresas establecer redes globales de información,

esenciales para el desarrollo y la comercialización de productos de primera clase en el mercado

internacional actual cada día más competitivo.

Se define un PLM como estrategia empresarial al permitir que las organizaciones globales

trabajen en su cadena de valor ampliada como un equipo unificado para innovar, desarrollar,

diseñar, producir, mantener, dar soporte y retirar productos del mercado y, al mismo tiempo,

recoger las prácticas recomendadas y lecciones aprendidas durante el proceso.

Como estrategia de dirección, PLM permite capturar y aprovechar las mejores prácticas que

permitirán acelerar la comercialización, limitar los costes y mejorar los ingresos.

Al igual se puede definir como estrategia de información, ya que ofrece la posibilidad de

construir una estructura de datos coherente consolidando sistemas lógicos y funcionales. Esto

ayudará a conciliar una gestión de la información de los productos de manera eficiente, con una

ágil gestión de todos los procesos y un aumento de la colaboración entre personas de un mismo

equipo, de departamentos distintos o incluso de diferentes organizaciones participantes en el

ciclo de vida del producto. Se evita así las islas de información, en muchos casos provocadas

por falta de centralización e integración de la información. Normalmente estas islas de

información aparecen por la presencia de procesos secuenciales, fragmentados en diferentes

sistemas o basados en papeles.

PLM proporciona a los equipos de producto dispersos por todo el mundo el acceso común a una

ubicación única donde reside el conocimiento de los productos y de los procesos. Además

permite a los equipos de diseño y de fabricación colaborar de forma virtual y compartir datos en

tiempo real.

Se puede utilizar PLM de diversas formas:

- Para integrar los sistemas críticos, ofreciendo una visibilidad total en los flujos de

trabajo y en la toma de decisiones en todas las fases del ciclo de vida del producto.

- Para obtener un mayor valor de los conocimientos, gestionándolos como un valor

intelectual a escala empresarial. Con PLM se utilizan estos conocimientos en múltiples

Introducción y Objetivos

12

programas, proyectos e iniciativas y se maximiza la innovación a lo largo del ciclo de

vida del producto, lo que se traduce en mayores ingresos, mayor cuota de mercado,

menor tiempo de lanzamiento y mayor éxito de los productos.

- Para ampliar la vida útil de estas inversiones, minimizando el coste del ciclo de vida,

sustituyéndose los largos procesos tradicionales por soluciones aceleradas

completamente automatizadas.

Desde el punto de vista de la temática de este proyecto, una de las características más

relevantes del producto aeronáutico es el número de componentes que lo conforman. El

producto final aeronáutico es un avión o aeronave, que tiene un número muy elevado de

componentes, por ejemplo el avión A400M tiene aproximadamente 700.000 componentes,

excluyendo los elementos normalizados tipo tornillería, remaches… [1].Un avión comercial como

el Boeing 747-400 o el Airbus A380 tiene en total más de 6 millones de componentes o piezas

[2]. En la Figura 1 se presenta un ejemplo del número de componentes de diferentes productos,

a fin de poner en contexto la particularidad del producto aeronáutico. Realmente se puede

afirmar que un avión es un producto que se compone de otros productos, que en su nivel más

bajo se corresponden con elementos individuales que también son productos físicos. Para

ilustrar más concretamente un producto aeronáutico en la Figura 2 se muestra una

representación esquemática del Airbus A380.

Figura 1. Ejemplo del número de componentes en diferentes productos [2].

Figura 2. Representación esquemática del avión A380.


13

Una segunda característica importante del avión es su alta longevidad o duración de su ciclo de

vida. Tradicionalmente se tienen ciclos de vida de hasta 50 años, [3] como se puede apreciar en

la Figura 3.

El volumen de producción es también un parámetro relevante y se caracteriza por ser

relativamente bajo en comparación con otros sectores como el de automoción. Actualmente el

modelo A320 es el avión con la mayor tasa de producción en Airbus y se fabrican 42 unidades al

mes, lo que resulta en aproximadamente unos 500 aviones al año [4]. Similar tasa de producción

tiene el modelo Boeing 737 [5].

Desde el punto de vista de la configuración de un avión, como objeto individual, se caracteriza

por ser bastante específica en cada avión en concreto, es decir, hay muy pocos aviones de un

modelo específico, por ejemplo el modelo A320, que sean exactamente iguales. La

diferenciación entre aviones individuales o especímenes radica fundamentalmente en la

personalización dirigida al cliente, que afecta principalmente a la configuración de cabina,

instalaciones y los equipos montados en el avión [6], [7], [8].

Otra particularidad es la necesidad de realizar la certificación del avión, lo que exige el

cumplimiento de una estricta normativa relacionada con aspectos muy diversos del diseño, como

pueden ser: producción, mantenimiento y características operativas del mismo [9].

1.2 El ciclo de vida del avión.

El ciclo de vida de un avión, o del programa aeronáutico para un avión civil, se caracteriza por

ser especialmente largo en comparación con cualquier otro tipo de producto, pudiéndose

alcanzar hasta los 50 años [3]. En la Figura 3 se muestra un gráfico con la distribución en el

tiempo de las etapas más importantes: lanzamiento del programa, entrada en servicio y final de

producción; y la tendencia del acumulado del flujo de caja. Se puede observar por tanto que la

recuperación de la inversión inicial se produce en un plazo muy largo.

Figura 3. Ciclo de vida típico de un programa aeronáutico para un avión civil.

Introducción y Objetivos

14

Desde el punto de vista técnico, en las empresas aeronáuticas, el proceso que va desde la

ideación del producto hasta su entrada en servicio se encuentra estructurado en fases y en hitos

representativos. De hecho, el proceso de diseño de un avión se realiza en conformidad con las

fases especificadas en el estándar RG-AERO-000-40A General recommendation for the

programme management specification [10]. El documento marca una serie de hitos,

denominados MX, para el inicio de cada fase del ciclo de vida de un producto aeroespacial. Y

aunque se trata de una recomendación general, donde se recoge el concepto de concurrencia y

el solape entre las diferentes fases, es la base para los procesos definidos en el sector

aeronáutico.

Desde 1990, el desarrollo del programa de un avión en Airbus se realiza utilizando métodos de

trabajo basados en la ingeniería concurrente, con grupos de trabajo interdepartamentales y uso

intensivo de herramientas informáticas (PLM, CAX) como elemento facilitador para la creación de

la maqueta digital de producto (Digital Mock-Up – DMU) [11][12]. La Figura 4 se muestra un

esquema con las fases principales: viabilidad, concepto, definición, desarrollo y series; y los hitos

más representativos del ciclo de vida de un avión en la compañía Airbus [11][12].

El ciclo de vida de un producto se puede considerar desde perspectivas distintas a la de

ingeniería de producto. Según la técnica de „Lifecycle Analysis‟, se considera que el ciclo de vida

de un producto está dividido en tres fases: „Beginning Of Life‟ (BOL), „Middle Of Life’ (MOL) y

„End Of Life‟ (EOL). Dentro de la fase BOL se considera el diseño y la producción del producto.

Dentro de la fase MOL se considera la utilización y mantenimiento. Dentro de la fase EOL se

están considerando distintos escenarios que comprenden la reutilización del producto con

actualizaciones, reutilización de componentes incluyendo su desmontaje y actualización, retirada

del producto, desmontaje y reciclado [13]. Considerando estas tres fases, el hito M13 „Entry into

service‟ correspondería con el inicio de la fase MOL para un avión concreto, y por tanto todos los

hitos anteriores que están relacionados con el diseño y producción del avión estarían

comprendidos dentro de la fase BOL del ejemplar de avión. En la Figura 5 se muestra el ciclo de

vida de un ejemplar de un producto.

Figura 4. Definición de fases principales e hitos en el ciclo de vida de un avión en Airbus [11].


15

Figura 5. Ciclo de vida de un ejemplar de un producto.

1.3 Objetivos.

El presente proyecto tiene como objetivo general el análisis de los sistemas PLM, describiéndose

las principales características, herramientas y las diferentes posibilidades para su adaptación al

sector productivo. Finalmente se mostrará un pequeño ejemplo de utilización de la herramienta.

El objetivo principal se alcanza mediante la consecución de los siguientes objetivos parciales:

Revisión histórica de los sistemas PLM, describiendo su evolución desde los PDM

(Gestión de datos del producto, Product Data Management) hasta el concepto actual de

PLM 2.0.

Análisis de herramientas para el desarrollo de un PLM, describiéndose las necesidades

hardware y software.

Desarrollo de ejemplos de implantación del sistema PLM en un ámbito productivo.

17

2 Ciclo de vida del producto

2.1 Introducción histórica.

Cronológicamente en los últimos 30 años se han sucedido diferentes herramientas en la gestión

del ciclo de vida del producto. Los proveedores de software PLM, como Cadence, UGS, PTC,

SAP, Dassault Systèmes y Agile, generalmente venden suites de software que hacen muchas

cosas, y que han formado por acumulación durante muchos años.

Los orígenes de PLM se remontan al software de diseño asistido por ordenador (CAD), una

gama de herramientas de diseño basadas en la informática que los ingenieros y arquitectos

comenzaron a utilizar en la década del año 1980. Con las herramientas CAD se consigue un

dimensionamiento 3D de las piezas o productos, incluso la conversión de 3D a 2D o a la inversa,

realizando construcciones de maquetas digitales.

En la década de 1990, a estas herramientas de diseño se le añade la gestión de datos del

producto de software (PDM), que cuenta con las herramientas de diseño CAD ya mencionadas

combinadas con una base de datos de información sobre los componentes. Este tipo de

herramientas estaban principalmente centradas en la gestión de la información del producto

durante el proceso de ingeniería. Comparándolo con el concepto de ciclo de vida de un producto,

las herramientas PDM sólo gestionaban el diseño, el desarrollo y la producción.

En los años posteriores, el mercado se ve inundado por un conjunto de herramientas que

evolucionan a partir de las soluciones PDM para incluir principalmente en sus funciones el

concepto de ciclo de vida (lifecycle) y el trabajo colaborativo: CPDM (Collaborative Product

Definition Management) y CPLM (Collaborative Product Lifetime Management).

Respecto a este baile de siglas podemos entender que PDM (Product Data Management) es el

concepto núcleo y que CPDM (Collaborative Product Definition Management) y CPLM

(Collaborative Product Lifetime Management) son conceptos que evolucionan del anterior y que

añaden nuevas funcionalidades al concepto original pero con dos tendencias diferentes en las

que se solapan y divergen las capacidades de ambas herramientas.

En las últimas décadas nace PLM 1.0 como el siguiente paso, reunificando las características

divergentes e iguales en una única herramienta. Es con PLM 1.0 con quien se desarrolla los

conceptos de gestión del ciclo de vida del producto y los entornos de colaboración en la

empresa. Por tanto PLM 1.0 (Product Lifecycle Management) no es nada más que el estado que

engloba las ideas unificadas de PDM+CPDM+CPLM.

Es en el año 2011 cuando PLM 1.0 desembarca en PLM 2.0 que trae consigo una optimización

de esta colaboración en los procesos empresariales, simulaciones reales y la aplicación de la

experiencia propia y real del propio usuario. Este avance a lo largo del tiempo ha aumentado el

aprovechamiento de la inteligencia colectiva, optimizando sus efectos.

Ciclo de vida del producto

18

Estos sistemas se han ampliado de manera que no son sólo para los diseñadores e ingenieros,

sino que también incluyen herramientas para el uso de los altos directivos y los departamentos

de marketing. En la actualidad, CAD todavía representa el 53% del gasto en PLM, pero en los

últimos sistemas PLM 2.0 se pueden llegar a incluir herramientas tales como "la gestión de

requisitos" y "una gestión de la cartera", herramientas que permiten a los administradores, por

ejemplo, mirar las especificaciones a través de la gama de productos en desarrollo para

asegurarse de que coincide con las demandas del mercado y si no lo hacen, a continuación,

realizar los consecuentes ajustes en las especificaciones o incluso la eliminación del producto.

2.2 Descripción general de PLM.

Con el PLM en un marco definido por la intensificación de la competencia a escala mundial y el

acortamiento del ciclo de negocio en virtud de las exigencias de rapidez en la respuesta al

mercado, la gestión del ciclo de vida del producto aparece como una de las piedras angulares en

la estrategia de la empresa.

Un PLM es un sistema informático que permite aplicar un planteamiento estratégico de negocio.

Consiste en la aplicación de un conjunto de soluciones para apoyar la acción colaborativa en

toda la actividad de la empresa. PLM da soporte en la creación, gestión, difusión y utilización de

información para la definición del producto desde su concepción hasta el final de su vida, lo que

comporta la integración de personas, procesos, sistemas de negocio e información. Esto permite

a las empresas gestionar el ciclo completo de sus productos de forma eficiente y con eficacia en

los costes.

Se trata, pues, de una estrategia encaminada a dotar de agilidad y flexibilidad al proceso de

creación del producto, ayudando a las empresas a ofrecer productos y servicios de más calidad y

más innovadores, además de reducir los costes y el tiempo de salida al mercado, y contribuir a

mejorar las relaciones colaborativas con clientes, suministradores y socios.

2.3 Funciones de un PLM.

Desde una perspectiva funcional los sistemas PLM se pueden clasificar en los siguientes diez

grupos:

1. Almacenar, organizar y proteger los datos.

El PLM agrupa todos los datos del producto en un servidor único. Los datos dejan de estar

dispersos entre las carpetas de Windows. Organiza los documentos de una forma estandarizada,

por criterios lógicos simultáneos tales como proyectos, productos o clientes.

2. Gestionar los documentos y sus cambios.

Entre otras funciones, el PLM graba los documentos en la base de datos, lo que permite buscar y

recuperarlos, crear versiones o validarlas, en definitiva gestionar los documentos y los cambios

que se producen en ellos. Por documento se entiende cualquier objeto creado por el usuario con


19

una aplicación informática. Este puede ser, por ejemplo, un texto de ofimática, un modelo hecho

con un sistema de CAD 3D, o el diseño de una placa electrónica.

Gestionar los cambios: es una función fundamental del PLM que permite la completa trazabilidad

de la historia de los documentos. Éstos pasarán por diferentes etapas en su ciclo de vida, tales

como: borrador, revisado, aprobado y obsoleto. Se controla qué se puede hacer con un

documento en función de su estado. Se guardan todas las versiones y su historial, así como los

detalles de los cambios (quién, cuándo, por qué…).

3. Buscar y recuperar información.

Con el PLM, los usuarios tienen a su disposición potentes mecanismos que permiten encontrar

instantáneamente cualquier documento o conjunto de los mismos. Una vez encontrado el

documento, se puede conocer y recorrer ágilmente toda la estructura documental relacionada a

este. Por ejemplo, a partir de un plano encontrar la pieza asociada y, a partir de la misma, los

conjuntos o ensamblajes a los cuales pertenece.

4. Compartir datos con usuarios de forma controlada.

El PLM permite que varios usuarios puedan acceder a un mismo documento simultáneamente de

manera que se evite el riesgo de sobrescribirlo.

5. Ejecutar procesos y flujos de trabajo.

Los sistemas PLM ayudan a ejecutar y controlar los diferentes procesos que los usuarios tienen

que hacer con la información. Permiten definir fácilmente y de forma gráfica un flujo de trabajo,

indicando las tareas a realizar, las personas que tienen que participar y las reglas de negocio a

cumplir. Un flujo de trabajo habitual es la gestión del cambio de diseño de una pieza.

6. Visualizar datos y documentos.

En un sistema PLM se puede visualizar cualquier documento sin que el usuario tenga instalada

la aplicación que se usó para crearlo. No se permite ningún tipo de manipulación, pero

habitualmente disponen de funciones de comentario y marcaje para poder opinar e informar

sobre el contenido.

7. Crear, clasificar y gestionar artículos.

Es una prestación fundamental y necesaria de un sistema PLM, ya que no basta con gestionar

documentos, sino que éstos han de estar relacionados con los ítems o productos físicos a los

que hacen referencia.

Haciendo uso de esta prestación, los usuarios crean los artículos y los vinculan con los

documentos; estos vínculos se mantienen cuando el artículo se utiliza en un nuevo proyecto o

estructura, de manera que las estructura documental y del producto estarán siempre en

sincronía. Esta es una característica que diferencia claramente los sistemas PLM de los PDM,

los cuales, al no gestionar ítems, no pueden establecer vínculos entre documentos y artículos.

8. Crear estructuras y listas de materiales.

Una vez creados los artículos, el PLM permite que los ingenieros los relacionen entre ellos,

conformando la estructura del producto a diversos niveles. Después, se pueden derivar múltiples

vistas adicionales: la vista de producción, de compras, de mantenimiento…


20

En un producto multidisciplinar, la estructura incluirá todo tipo de artículos: mecánicos, eléctricos,

electrónicos, software, etc. También se pueden crear estructuras con opciones y variantes según

los criterios de configuración.

Habitualmente se dispone de funcionalidades para comparar dos estructuras entre sí, o

interrogar dónde se utiliza un determinado artículo o grupo. Esto permite valorar el impacto de un

cambio de ingeniería. También se pueden generar todo tipo de informes como las listas de

materiales.

9. Integrar la información de ingeniería con otros sistemas y procesos informáticos

empresariales.

Los sistemas PLM ofrecen funciones de exportación de la información generada para que sea

utilizada por otros sistemas de la empresa. La aplicación más relevante es la de transferir

automáticamente los ítems, estructuras y listas de materiales al sistema de gestión, a fin de

hacerlas accesibles a los departamentos de compras y producción. Sin un PLM, éste es un

proceso sin ningún valor añadido, que habitualmente se hace de forma manual, lo que puede

causar graves errores en las fases productivas posteriores.

10. Gestionar proyectos de diseño y desarrollo.

Los sistemas PLM ofrecen funciones específicas para gestionar proyectos o conjuntos de

proyectos (programas o carteras). Se pueden gestionar los recursos, las tareas, los costes, los

tiempos y los “entregables”.

2.4 Otros sistemas ERP, PDM, CAD y relación con PLM.

Los PLM tratan de centralizar y organizar todos los datos e información del producto en un

sistema común accesible por los distintos departamentos de la empresa. En este sentido

permiten representar tanto estructuras de producto simples como complejas con múltiples

vinculaciones entre productos y elementos. Los elementos Computer-Aided Design (CAD), la

fabricación asistida por ordenador (CAM), la ingeniería asistida por ordenador (CAE), la

fabricación digital y la gestión de datos de productos (PDM) convergen en PLM.

A lo largo de los años, PLM ha crecido fuera del marco Product Data Management (PDM). Los

sistemas PLM se han vuelto capaces de manejar no sólo artículos, documentos y listas de

materiales, sino también los resultados de los análisis, las especificaciones de las pruebas y los

resultados, además de la información medioambiental del componente, requisitos del producto,

órdenes de cambio, los procedimientos de fabricación, información sobre el rendimiento de

productos, proveedores de componentes, y mucho más.

Otro aspecto importante que ayuda a entender las posibilidades de un sistema PLM es la

capacidad que estas soluciones tienen para gestionar procesos. Pensemos en procesos como

pueden ser los lanzamientos de nuevos productos, peticiones de cambio de ingeniería, paso a

fabricación, etc.


21

Muchos de los sistemas PLM permiten representar procesos en forma de workflows (flujos de

trabajo) de forma que se puede sistematizar los pasos a realizar indicando las personas a

participar y acciones que deben llevarse a cabo. De esta forma, varios de los PLM existentes en

el mercado nos permiten modelar dichos procesos y ponerlos en marcha en nuestra

organización, incluso ser monitorizados.

El ERP permite gestionar los activos tangibles y en el PLM los activos intangibles, el capital

intelectual. Así como un ERP gestiona la información desde un punto de vista de producción y

compras, PLM gestiona la información que produce la oficina técnica.

En el ERP se gestionan los productos reales y su fabricación desde el momento que se libera la

producción. Sin embargo en el PLM se mantiene el histórico de la evolución del producto con

toda su documentación y procesos asociados. Antes de fabricar y generar el producto, se

generan documentos del mismo interviniendo distintos departamentos, que son gestionados por

el PLM. Además se llevan a cabo procesos que hay que gestionar adecuadamente y solo

cuando llega el momento se libera a producción la estructura del producto con los planos e

información generada y gestionada previamente en el PLM para hacer las compras y

planificación de la producción.

Uno de los puntos más importantes es una buena integración con el sistema CAD, que permita

gestionar revisiones, hacer búsquedas y controlar las aprobaciones de diseños; a partir de aquí

se pueden establecer las conexiones necesarias con el ERP para pasarle información sobre los

artículos.

La virtualización del producto puede ser eficiente solamente si abarca todas las dimensiones del

desarrollo del producto. PLM es algo más que CAD; es probable caer en una concepción errónea

sobre PLM y su relación con los sistemas CAD. Además de ciertas tareas reconocibles de los

sistemas CAD como puede ser el diseño, creación de bocetos, modelado de piezas o creaciones

de ensamblajes entre otras, PLM engloba estas tareas junto a otras herramientas como puede

ser la gestión de proveedores y clientes, informes de costes, listas de materiales, diseño

colaborativo o trabajo en grupos multidisciplinares. De esta forma PLM se conforma como un

grupo de herramientas interrelacionadas, mucho más complejo que una simple unión de diversas

herramientas.


22

Figura 6. Globalización de herramientas en PLM

Un sistema PDM es un subconjunto de un sistema PLM. Maneja principalmente datos de los

productos sólo relacionados con CAD. El Departamento de Diseño es el proveedor principal de

entrada de un sistema PDM, mientras que un sistema PLM requiere la participación y el nivel de

la organización e integra todos los otros sistemas de información de una organización. Esto hace

que sea posible trabajar con mayor rapidez una mayor cantidad de cambios de diseño de un

producto o disminuir de manera considerable el lanzamiento de un nuevo producto, entre otras

cosas.

Los sistemas PDM también centralizan la información del producto en una sola base de datos

autorizada, a veces llamada el "sistema de registro". La base de datos tiene como objetivo

acabar con los planes de negocio en papel y reducir así las posibilidades de error o

malentendido y la pérdida de información durante el proceso. Con los sistemas PDM cualquier

cambio en los planes de un producto se hace rápidamente visible para el equipo de diseño de la

línea de producción en la que se construirá. En la cámara de Nikon, por ejemplo, se llegó a

utilizar para producirla cerca de 15.000 dibujos de diseño en un año que tenían que ser

distribuidos y aprobados. El uso de PDM, redujo la cantidad de papeleo en un 80%, y los dibujos

se pudieron recuperar cinco veces más rápido.

PLM es mucho más que un simple PDM:

Los sistemas de mensajería no pueden sustituir a las negociaciones de ingeniería

creativas.

La gestión de documentos no es suficiente en un diseñador para comprender y analizar

el impacto de un cambio de ingeniería.

La lista de materiales no refleja objetos semánticos complejos de PLM específicos, tales

como enfrentamientos, cinemática, simulaciones…

PLM es mucho más que una Colaboración a través de Internet:

Internet es una infraestructura IT, mientras que el PLM es un middleware, software, y

unas prácticas industriales, todo ello combinado.


23

Las localizaciones de los departamentos PLM colaborativos estarán tan extendidos

como las estrategias globales de la empresa.

Internet puede permanecer sólo virtual; PLM es la plataforma virtual que finalmente

impulsa el diseño real y las actividades de desarrollo (La colaboración con un entorno

estructurado PLM obliga a usar las existentes tecnologías de colaboración basadas en

internet para lograr mucho más en la empresa).

PLM proporciona soluciones reales para los negocios.

Muchas compañías y PYMEs confían en las personas. En ambos casos son las

personas quienes crean, deciden, ejecutan; PLM es para todos ellos.

PLM es un portfolio (cartera) modular, que provee de soluciones a las compañías, en

función de su tamaño.

PLM es la clave en la contribución a las estrategias de negocio.

Tenga en cuenta además que, a la par, usted debe gestionar eficientemente el resto de

documentación e información de producto relativa a departamentos como pueden ser Marketing,

Calidad, I+D, Ventas o cualquier otro que en su caso no esté directamente relacionado con su

ERP aunque sí con su producto. Con PLM toda esta información quedaría adjuntada al producto,

evitando duplicidades de información, pérdidas económicas y consiguiendo una trazabilidad total

de toda la información concerniente al producto.

2.5 Beneficios en la utilización de un sistema PLM.

La aplicación de soluciones PLM se concretan en una mejora en los tiempos de cambio de los

ciclos del producto en torno al 40%; reducción del 15% al 30% en la realización de prototipos;

reducción del 40% en el tiempo de salida al mercado; 25% de mejora en la productividad en el

diseño de ingeniería; reducción del tiempo de desarrollo de una familia de productos del 75% (de

18 meses a 4 meses); y reducción en un 83% del proceso de revisión de la ingeniería (de doce

días a dos días). A estas mejoras cuantificables y ahorros de las soluciones PLM se añaden la

mejora de la capacidad para crear una cultura de innovación al compartir la información a través

de toda la organización empresarial.

Por último, con los resultados obtenidos se ha estimado que las soluciones PLM pueden

proporcionar un 5% de aumento de los ingresos.

Beneficios en la ejecución del negocio:

Disminuye los costes gracias a un mejor acceso a datos coherentes.

Aumenta las oportunidades de negocio.

Fomenta la innovación, la predictibilidad, la flexibilidad y una mejor gestión.

Mejora la calidad, aumenta la velocidad del negocio y la respuesta a los cambios del

mercado: lanzamientos de producto y lanzamientos a producción.

Ayuda a cumplir las normas industriales y las regulaciones gubernamentales.

Mantiene la trazabilidad de las acciones.

Beneficios para la organización:


24

Elimina las barreras geográficas y facilita la internacionalización.

Ayuda a hacer cambios en la organización.

Facilita la subcontratación y participación de proveedores en los procesos.

Fomenta que los proyectistas reutilicen componentes, diseños y procesos.

Consolidando así el conocimiento de toda la organización, tanto de datos como de

procesos.

Disminuye el riesgo de perder conocimientos cuando ocurre una marcha de personal.

Facilita una rápida incorporación de nuevas personas al ofrecerles un entorno de trabajo

organizado.

Maximiza las inversiones hechas en otros sistemas informáticos.

Aumenta la seguridad en el acceso y protección de datos.

Beneficios para los usuarios:

Encuentran en el PLM todos los datos que necesitan.

Ofrece una interfaz de acceso común a todos los datos.

Cohesiona personas, datos y procesos.

Proporciona mayores recursos a los trabajadores.

Reduce la ejecución de tareas administrativas.

Reduce las posibilidades de trabajar sobre datos que están siendo modificados o

sustituidos por otros usuarios.

Beneficios para el producto o servicio:

Fomenta la reutilización de componentes estándar y diseños anteriores.

Facilita la definición y gestión modular del producto.

Reduce los cementerios de piezas y recambios obsoletos.

Permite aumentar la complejidad del producto de forma controlada.

Facilita la extensión de la cartera de productos.

Gestiona las estructuras del producto, las versiones y las configuraciones.

Mejora la respuesta a las solicitudes de los clientes.

Facilita las mejoras del producto en las primeras etapas del diseño.

Disminuye los errores en las configuraciones y listas de materiales, reduciendo su

impacto una vez que el producto ha sido lanzado a producción.

Acorta los plazos de entrega.

Gestiona todos los datos del producto durante todo su ciclo de vida.

2.6 Reducción del Time-to-market.

Los PLM no solo ayudan a los diseñadores e ingenieros, además son utilizados en una amplia

gama de procesos empresariales incluyendo marketing, planificación, aprovisionamientos,

fabricación y servicios del producto. Con esto se fomenta el intercambio de ideas, la creatividad y

la identificación de posibles problemas en fases tempranas del desarrollo de un producto o

servicio. Esto se traduciría en, una reducción del tiempo empleado en el diseño y evitar la

propagación de los errores en la cadena de valor.


25

Gracias al nivel de colaboración que ofrecen estas soluciones, se consigue:

Disminuir los costes y mejorar la rapidez de los proyectos de desarrollo de productos y

su lanzamiento.

Mejorar los procesos de revisión y aprobación de los diseños.

Crear conexiones más fuertes entre departamentos de diseño y fabricación, facilitando la

comunicación eficiente de qué y cómo producir.

Aumentar la velocidad en el lanzamiento de nuevos productos.

Se facilita la creación de listas de materiales (BOM – Bill of Materials) a partir de

estructuras CAD.

Un PLM puede ayudarle a aumentar la calidad de diseño y fabricación mediante la

implementación de procesos y funciones que estandarizan, gestionan y automatizan actividades,

ayudando a las empresas a aprovechar las oportunidades que crean innovación y aportación de

valor a sus productos. Además el PLM provee de información en tiempo real durante todo el ciclo

de vida del producto, permitiendo detectar problemas a través de la actualización continua de los

datos.

2.7 Herramientas software para sistemas PLM.

2.7.1 Requisitos software en un sistema PLM.

La Gestión del ciclo de vida del producto o PLM (Product Lifecycle Management) hace referencia

a aquellas soluciones informáticas de ayuda a la gestión del producto desde su fase inicial de

definición estratégica de producto, pasando por el diseño de concepto, el diseño de detalle, la

ingeniería de producto, y la producción hasta su comercialización y posterior mantenimiento.

Los sistemas PLM se caracterizan por una centralización y organización de la información con

capacidad de accesibilidad por las distintas áreas de la empresa. Los sistemas PLM permiten

representar información de productos simples y complejos incorporando tanto datos estáticos

como dinámicos.

Las soluciones integradas de software en los sistemas PLM incorporan sistemas CAD (Computer

Aided Design) para la concepción del producto, pasando por el análisis y la optimización del

producto con soluciones CAE (Computer Aided Engineering), llegando al análisis de cómo se va

a producir y dar mantenimiento a este producto con soluciones DMF (Digital Manufacturing) y

capturando, reutilizando y compartiendo con cada uno de los actores del ciclo productivo toda la

información generada en cada una de las etapas antes mencionadas con soluciones PDM

(Product Data Management).

Una de las principales soluciones software en la gestión del ciclo de vida del producto es la

herramienta PLM de Dassault Systèmes. Esta herramienta está caracterizada por 5

fundamentos:

http://es.wikipedia.org/wiki/Dise%C3%B1o_asistido_por_computador

http://es.wikipedia.org/wiki/Dise%C3%B1o_asistido_por_computador

http://es.wikipedia.org/wiki/Ingenier%C3%ADa_asistida_por_computadora


26

• Centrado en proceso: la optimización de procesos de negocio específicos de la

industria.

• Espacios de trabajo colaborativos: la comunicación basada en 3D omnipresentes y de

colaboración.

• PPR: Producto único, al igual que el proceso y la descripción de recursos y modelo.

• Conocimiento: capturar, compartir y volver a aplicar el conocimiento corporativo.

• CAA V5: La apertura y la extensión a través de la arquitectura y la comunidad basada en

componentes.

Los principales valores que aportan los sistemas PLM de Dassault son:

1. La validación de productos digitales.

2. Validación de procesos digitales.

3. Síntesis del ciclo de vida.

4. La colaboración mundial.

Las herramientas software para la gestión del ciclo de vida de productos de Dassault son:

• CATIA, para el diseño del producto virtual.

• DELMIA, para la producción virtual (planificar, crear, supervisar y controlar los procesos

de producción y mantenimiento).

• ENOVIA SmartTeam, entorno colaborativo global para la gestión del ciclo de vida del

producto.

• 3DVIA Composer, herramienta que permite el diseño de documentación asociada al

proceso productivo.

• SIMULIA, ofrece funciones de simulación realista para ingenieros y científicos, lo que

permite centrarse en el rendimiento del producto y reducir el número de prototipos

físicos.

Se puede decir que ENOVIA ofrece 2 tipos de productos:

- ENOVIA VPLM: para la gestión de productos complejos, recursos y procesos de

fabricación en medianas y grandes empresas.

- ENOVIA SmarTeam: para diseño de procesos de negocios y desarrollo de productos en

colaboración dirigido a pequeñas y medianas organizaciones.

ENOVIA es una solución PLM que ofrece una arquitectura SOA (orientada a los servicios)

destinada a impulsar la innovación colaborativa en el ámbito de la producción. La versión más

reciente ENOVIA V6, posibilita el uso de PLM 2.0, el entorno colaborativo en línea que involucra

a creadores, colaboradores y consumidores en el ciclo de vida del producto.

ENOVIA SmarTeam fomenta un enfoque basado en roles, en su oferta para facilitar la expansión

modular de la solución. Ofrece una instalación simplificada en todos los productos de cliente,

http://www.3ds.com/catia

http://www.3ds.com/delmia

http://www.3ds.com/enovia

http://www.3ds.com/3dvia


27

soluciones de negocio y visualizadores, con lo que se consigue agilizar la implantación y reducir

costes.

A continuación se describe con mayor grado de detalle las principales características del

software PLM 2.0 que se emplea como base del análisis del siguiente proyecto concretamente el

Software de Dassault Systèmes.

2.7.2 Fundamentos PLM 2.0 de Dassault Systèmes.

En el año 2006, Dassault Systèmes (DS) anunció PLM 2.0 como una nueva generación de

sistemas PLM, que se desarrollarían sobre la plataforma V6.

La definición proporcionada por DS se caracteriza por encontrar algunos términos que ayuda a

comprender las principales aportaciones y capacidades de los sistemas PLM 2.0:

La orientación 3D: El principal punto de vista de Dassault Systèmes en su definición de

PLM 2.0 reside en una visión realista del entorno de trabajo de las empresas, un entorno

donde el 3D es parte fundamental para una virtualización más próxima a la realidad. El

3D como interfaz hacia toda la información relacionada con el producto es un cambio de

paradigma para las empresas que tienen un objetivo claro, saber con el mayor grado de

realismo la estructura del producto, procesos y recursos en la empresa.

Sistemas online colaborativos: La tendencia de los sistemas PLM es hacia la gestión

de procesos de negocios y la disponibilidad en tiempo real de la información sin

necesidad de ningún tipo de tratamiento de la información o importación o exportación

de la misma, solo la capacidad de compartir y filtrar. Esto implica una gestión de

usuarios muy estricta en el sentido que al crear un repositorio común para todos los

usuarios de la empresa y usuarios de empresas colaboradoras o clientes implica mayor

control de la información.

Propiedad Intelectual (Intellectual Property, IP). Aunque nunca se ha indicado como

características de los PLM, la propiedad intelectual es un tópico que está en todas las

agendas de las empresas. El conocimiento de una compañía consiste en un conjunto de

procesos que se aplican, cómo se aplican, los componentes que actúan en los procesos

y la gestión de la calidad de los mismos. Al incorporar sistemas de trabajo colaborativo

es importante una gestión de la información y el conocimiento en base a roles y

prioridades.

La web 2.0 ha supuesto un cambio de filosofía, facilitar el compartir la información, la

interoperabilidad, el diseño centrado en el usuario y la colaboración en World Wide Web

son a grandes rasgos las principales aportaciones. Esta nueva visión ha permitido a las

compañías y personas implementar aplicaciones de otra forma. No sólo sobre premisas

de funcionamiento en tiempo real sino que se toma el software como un servicio;

servicios basado en la nube, procesos de programación y gestión basados en interfaces

estandarizadas e implementación “end-to-end” de los procesos de negocios sin gran

impacto en el funcionamiento actual.


28

El concepto de comunidad. Este concepto abre nuevas perspectivas de colaboración.

Las personas en una misma comunidad tienen intereses o tareas comunes y comparten

los pensamientos y resultados por toda la empresa con el objetivo de poder reutilizar el

conocimiento. Esta perspectiva provee a la empresa y a las personas involucradas de

una mejor visión de los objetivos, de los diferentes negocios y del mercado.

En resumen los sistemas PLM 2.0 amplían los conceptos de PLM incorporando la gestión del

conocimiento y la colaboración en tiempo real entre usuarios.

Este concepto es uno de los principales requerimientos en el proyecto donde se pretende

disponer de un marco colaborativo de información y procesos que gestione todo el ciclo

de vida del producto disminuyendo los tiempos de respuestas y la eficiencia de los

trabajos.

2.7.3 Herramientas SW orientadas a PLM 2.0.

Para alcanzar los requisitos necesarios ha sido necesario conocer las principales características

del concepto PLM2.0. A continuación se describe la principal solución disponible en V6 para PLM

2.0, tantos los productos como los sistemas virtualizados se comportan como el propio sistema

físico, permitiendo a todos los entes y personas involucradas una mayor integración, facilitando

las simulaciones inmersivas que fomenta la innovación sin disminuir las expectativas del cliente.

El sistema V6 permite diseñar el producto con CATIA V6, simular con SIMULIA V6, gestionar los

procesos de fabricación con DELMIA V6, experimentar con 3DVIA V6 y colaborar a todos los

niveles de la empresa con ENOVIA V6.

Figura 7. Posibilidades del sistema V6

La arquitectura V6 está caracterizada porque toda la información es gestionada y almacenada en

una base de datos. Esta base de datos contiene toda la información física, la estructura lógica y


29

los requisitos de los productos y partes. Esta arquitectura permite trabajar sin la necesidad de

hacer copias o almacenar parte de los diseños de forma local. Esto simplifica la gestión de los

datos de procesos y la disponibilidad de la información.

2.7.3.1 Paquetes integrados de productos V6.

Un paquete integrado de licencias consiste en una configuración de varios productos con

diferentes capacidades, en base a las licencias requeridas. La empresa propietaria define

paquetes denominados “tipo” donde se describen los bloques de licencias en base a las

necesidades de las organizaciones. En el ámbito de los productos PLM de Dassault Systèmes

existen varias configuraciones como por ejemplo la descrita en la siguiente figura:

Figura 8. Configuración de licencias de productos para entornos CATIA, DELMIA y ENOVIA

Las columnas de la figura describen los productos disponibles, y por filas el nivel de profundidad

que se puede utilizar.

La fila inferior corresponde a lo que se conoce como PLM Discover, que es un paquete integrado

que incorpora las herramientas CATIA, DELMIA, SIMULIA y ENOVIA quedando 3DVia como

componentes adicionales y no incluidos.

Las principal característica asociada a PLM Discover es que aunque incluye una integración de

varias herramientas no se dispone de los módulos necesarios para la definición de la

estructura de fabricación.


30

Figura 9. Licencias de productos disponible en paquete PLM Discovery

Entre las opciones disponibles en la versión desagregada, donde es posible seleccionar

diferentes configuraciones de productos, destacando los siguientes productos, con el criterio de

ser los más cercanos a las necesidades del proyecto. La descripción de los productos se basa

en cada una de las posibles herramientas que se emplearán en el proyecto.

CATIA Design Master. Producto que tiene como objetivo capacitar la creatividad y diseñar una

amplia gama de piezas desde lo simple a lo complejo. Es el paquete más básico de los

productos existente e incluye las diferentes licencias:

CATIA Mechnical Product Creation (MCE) Part Design (PDG) Mechanical System Design (ASD) Kinematics Mechanism Design (KIM) Photo Studio 1 (PH1) Automated Collaborative Design (ADC) CATIA Mechanical Surface Design (SUR) CATIA Generative Shape Design (GSD) CATIA Freestyle Shaper 1 (FS1) CATIA Developed Shapes (DL1) CATIA Industrial Design Refinement (IDR) CATIA Freestyle Shaper (FSS) CATIA Freestyle Optimizer (FSO) CATIA Freestyle Profiler (FSP) CATIA Photo Studio Pro (PHO) Developed Shapes (DL1) Live Rendering (LRE) CATIA Reverse Engineering (REV) CATIA Digitized Shape Editor (DSE) CATIA Quick Surface Reconst. (QSR) CATIA Shape Sculptor (DSS)


31

CATIA STL Extended Rapid Prototyping (TLE) CATIA IGES Interface (IG1) CATIA Generative Shape Design 1 (GS1) CATIA 3DShape Editor (TSE) ENOVIA VPM Physical Editor (VPE) CATIA Tolerancing & Annotation (TOL) CATIA 2D Layout for 3D Design (LO1) CATIA 3D Functional Tol. & Annot. (FTA) CATIA Live FTA Review (LFT) CATIA Fabricated Part Design (FPD) CATIA Sheetmetal Design (SMD) CATIA Weld Design (WDG) CATIA Plastic Part Design (PPD) CATIA Functional Plastic Part Design (FMP) CATIA Healing Assistant (HA1) CATIA STL Extended Rapid Prototyping (TLE) CATIA Part Design Feature Recognition (FR1) ENOVIA Validation Modeler (VDM) CATIA Rendering (REN) CATIA Photo Studio Pro (PHO) CATIA Real Time Rendering (RTR) CATIA Live Rendering (LRE) CATIA Materials Definition (MAT) CATIA Piping & Tubing Design (PTD) CATIA Piping & Tubing Design (PIP) CATIA Knowledge Advisor (KWA) CATIA Product Knowledge Template Definition (PKT) CATIA Knowledge Expert (KWE) CATIA Product Engineering Optimizer (PEO) CATIA Automated Design Process Creation (DPC) CATIA Distiller (DIS) CATIA Composite Engineering (CEG) CATIA Structure Fonctional Design (SFD)

El conjunto de productos ofrecidos por este paquete de licencias supera con creces las

necesidades exigidas al sistema V6 en el proyecto.

Delmia Manufacturing Advance. Conjunto de productos que tienen como objetivo capacitar el

proceso de planificación en cualquier entorno de fabricación, permite asignar procesos y partes a

recursos e incluye la capacidad de realizar ensamblados de productos y simularlos. Las licencias

incluidas en el paquete son:

DELMIA Process Planning (PRP) DELMIA Process & Ressource Editor (PRE) DELMIA Manufactured Product Planning (MPP) DELMIA Global Production System Planning (SPG) DELMIA Custom Time Analysis (CTA) DELMIA Fastener Process Planning (BPP) DELMIA Assembly Process Simulation (APS) DELMIA Work Instructions Planning (WKI)


32

DELMIA Production System Simulation (PSS) DELMIA Robotics Offline Programming (ROP) DELMIA Robotics Spot Welding (RSW) DELMIA Robotics Virtual Commissioning (RVC)

ENOVIA Master. Este paquete es imprescindible ya que instala el servidor de PLM,

proporcionando capacidades de gestión de proyectos de colaboración con el objetivo de

aumentar la productividad de los usuarios. El sistema permite usuarios distribuidos para la

gestión de proyectos y programas con información en tiempo real que se actualiza

automáticamente a través de enlaces directos a las tareas, documentos, productos entregables,

y otras fuentes de datos. Estas actualizaciones automáticas permiten que el director del proyecto

pueda centrarse en actividades de alto valor en lugar de rastrear el estado de dichas

actualizaciones. Las licencias incluidas son:

ENOVIA VPM Digital Validation (DVA) ENOVIA Program Central (DTH)

Las otras opciones es seleccionar paquetes por herramienta. Los principales paquetes junto con

sus características serán descritos en el siguiente apartado.

2.7.3.2 ENOVIA Team 3DLive (XCL).

Paquete integrado necesario para el funcionamiento del sistema, este contiene las licencias de

los productos del servidor. Este paquete corresponde a lo que desde la licencia por productos se

denomina ENOVIA MASTER y las licencias asociadas a los productos son:

3DLive Product (DSN) 3DVIA Immersive Virtuality Core (IVR) 3DVIA Immersive Virtuality Devices (IVD) 3DVIA Live File Connector Product (LDK) 3DVIA Navigation Builder Extension (DSB) 3DVIA Settings Management Extension (LST) DELMIA Live PPR Navigator & Connector (LMH) ENOVIA Live Advanced Print (APT) ENOVIA Live Collaborative Review (LCV) ENOVIA Live ENOVIA V6 Connector Product (LVP) ENOVIA Live ENOVIA VPM V5 Connector Product (LVV) ENOVIA Live ENOVIAvpm Connector Product (LVM) ENOVIA Live SmarTeam V5 Connector Product (LVS) ENOVIA Live VPM Team Central Connector (LVT) ENOVIA RFLP Live Navigator (RFL) SIMULIA Live MSR Navigator (LMR)

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/cp_xcl.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_dsn.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_ivr.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_ivd.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_ldk.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_dsb.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_lst.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_lmh.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_apt.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_lcv.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_lvp.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_lvv.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_lvm.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_lvs.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_lvt.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_rfl.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_lmr.html


33

2.7.3.3 ENOVIA Team Live Review (XRW).

Paquete de licencias orientado a interactuación entre usuarios y diseño desde 3DLive. Entre las

principales características se incluye anotaciones, medidas e inspección de la geometría 3D para

una revisión del producto. Principalmente este paquete de licencias son orientadas a

visualización y revisión de los productos e incluye productos de 3DVIA, ENOVIA, CATIA y

DELMIA con objetivos de visualización.

3DLive Product (DSN) 3DVIA Immersive Virtuality Core (IVR) 3DVIA Immersive Virtuality Devices (IVD) 3DVIA Live File Connector Product (LDK) 3DVIA Navigation Builder Extension (DSB) 3DVIA Settings Management Extension (LST) CATIA Live FTA Review (LFT) CATIA Live Fastener Review (LFR) DELMIA Live PPR Navigator & Connector (LMH) ENOVIA Live Advanced Print (APT) ENOVIA Live Collaborative Review (LCV) ENOVIA Live ENOVIA V6 Connector Product (LVP) ENOVIA Live ENOVIA VPM V5 Connector Product (LVV) ENOVIA Live ENOVIAvpm Connector Product (LVM) ENOVIA Live SmarTeam V5 Connector Product (LVS) ENOVIA Live VPM (LSV) ENOVIA Live VPM Team Central Connector (LVT) ENOVIA Live Validation (LVD) ENOVIA RFLP Live Navigator (RFL) ENOVIA VPM Team Environment (VTE) ENOVIA Validation Modeler (VDM) SIMULIA Live MSR Navigator (LMR)

2.7.3.4 DELMIA Manufactured Product Planning (MMP).

Este paquete de licencias ofrece capacidades de planificación intersectorial de fabricación que

necesitan la definición de ingeniería de un producto con el fin de ofrecer una definición

MBOM a la planificación de fabricación. Esto incluye la definición de conjuntos de fabricación

y transformación de productos.

Esta definición puede ser perfectamente aprovechada por los procesos posteriores en el flujo de

trabajo de planificación de la fabricación, a partir de instrucciones de proceso, de recursos y la

planificación del trabajo a través de la ejecución de producción.

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/cp_xrw.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_dsn.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_ivr.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_ivd.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_ldk.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_dsb.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_lst.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_lft.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_lfr.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_lmh.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_apt.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_lcv.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_lvp.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_lvv.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_lvm.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_lvs.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_lsv.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_lvt.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_lvd.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_rfl.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_vte.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_vdm.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_lmr.html


34

2.7.3.5 DELMIA Process Planning (PRP).

El paquete de licencias para la planificación de procesos permite el desarrollo de procesos de

planificación en entornos 3D. Esto permite a los planificadores de procesos la creación y

validación de un plan de procesos relacionando la estructura de procesos con la ingeniería del

producto. Así mismo los productos incorporados permiten realizar análisis de tiempos y de carga

de trabajo minimizando y enriqueciendo la planificación desde su concepción hasta la ejecución.

Las licencias incluidas en el paquete son:

CATIA Knowledge Expert 1 (KE1) DELMIA Line Balancing (MLB) DELMIA Manufacturing System Definition (MSD) DELMIA PPR Access (PPR) DELMIA Process Definition (PRD) DELMIA Resource Definition & Layout 1 (MR1) DELMIA Standard Time Measurement (STM) ENOVIA VPM Physical Editor (VPE)

2.7.3.6 DELMIA Process & Resource Editor (PRE).

Este paquete de licencias ofrece a los administradores de proyectos y asistentes de proyectos

una herramienta fácil de usar para crear y administrar el producto, el proceso y los recursos

(PPR). Guiado por una interfaz de usuario intuitiva, los usuarios pueden establecer la estructura

de PPR y hacer conexiones entre los procesos, los recursos, los sistemas de fabricación, y los

productos y adjuntar los documentos justificativos. Agentes implicados pueden utilizar esta

estructura para la planificación de procesos y el detalle. Los directores de proyecto y otras partes

interesadas de todo el proceso de la empresa pueden utilizar PRE en todo el ciclo de

planificación para controlar el progreso del proyecto. El paquete de licencias incluye los

siguientes productos:

DELMIA PPR Access (PPR) DELMIA PPR Editor (PRR) ENOVIA VPM Physical Editor (VPE)

2.7.3.7 DELMIA Process Planning (PRP).

Este paquete ofrece capacidades de planificación de procesos, esenciales en el entorno virtual

en 3D V6 para todas las industrias de manufacturación. Los planificadores de procesos pueden

crear de manera eficiente y validar el plan de trabajo inicial con la estructura del producto de la

ingeniería, modificar el plan a las necesidades específicas, y el producto de enlace y los recursos

para los pasos del plan. Los planificadores también pueden realizar estudios de tiempo estándar

y equilibrar la carga de trabajo entre los recursos. Estos planes pueden ser aprovechados por los

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/cp_prp.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_ke1.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_mlb.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_msd.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_ppr.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_prd.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_mr1.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_stm.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_vpe.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/cp_pre.html


http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_prr.html


http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/cp_prp.html


35

agentes implicados, lo que minimiza la reanudación, ya que enriquecen el plan desde el

concepto hasta la ejecución. El paquete de licencias incluye:

CATIA Knowledge Expert 1 (KE1) DELMIA Line Balancing (MLB) DELMIA Manufacturing System Definition (MSD) DELMIA PPR Access (PPR) DELMIA Process Definition (PRD) DELMIA Resource Definition & Layout 1 (MR1) DELMIA Standard Time Measurement (STM) ENOVIA VPM Physical Editor (VPE)

2.7.3.8 DELMIA Resource Layout (RLT).

Paquete de licencias orientado a planificadores de fabricación avanzada, con herramientas

eficaces para la disposición de los recursos de la fábrica. Este tipo de licencias permite

aprovechar dibujos 2D de fábrica, si están disponibles. RLT incluye un catálogo de recursos

paramétricas como transportadores, estanterías, mesas y contenedores que pueden ser

ajustados a los dibujos en 2D para realizar rápidamente el diseño 3D. La colocación avanzada

hace que sea muy fácil de mover, romper, y alinear estos recursos. RLT crea un entorno de la

Versión 6 en 3D para la definición y validación de diseños de planta, su entrega a la planta de

producción para la construcción, y compartirlos con agentes implicados para enriquecer y validar

planes de proceso. Las siguientes licencias son incluidas en este paquete:

CATIA 2D Layout for 3D Design (LO1) CATIA 3DShape Editor (TSE) CATIA Generative Drafting (GDR) CATIA Interactive Drafting (ID1) CATIA Product Knowledge Template (KT1) DELMIA Resource Definition & Layout (MRL) ENOVIA VPM Physical Editor (VPE)

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_ke1.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_mlb.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_msd.html


http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_prd.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_mr1.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_stm.html


http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/cp_rlt.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_lo1.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_tse.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_gdr.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_id1.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_kt1.html

http://marketing.intrinsys.co.uk/V6_2013x_PDir/portfolio/tp_mrl.html



36

2.8 Definición de los requisitos hardware en un sistema PLM 2.0.

2.8.1 Arquitectura HW.

2.8.1.1 La arquitectura hardware desde ENOVIA V4 a ENOVIA V6.

Una arquitectura es un conjunto de elementos funcionales siguiendo diferentes estándares y

procesos, permitiendo integrar una amplia gama de productos y servicios informáticos, de

manera que pueden ser utilizados eficazmente dentro de la organización.

La arquitectura hardware se refiere al conjunto de equipos y sus características para la

implantación del sistema V6. La arquitectura permite estructurar la información, las

comunicaciones y servicios que dispondrá el sistema.

Las versiones 4 y 5 ENOVIA estaban basados en una arquitectura en dos y tres niveles

respectivamente.

Figura 10. Arquitectura a tres niveles de ENOVIA V5

La arquitectura a dos niveles en las versión 4 era una arquitectura cliente-servidor, que

presentaba poca escalabilidad y las funcionalidades se reducían al almacenamiento de la

definición de la estructura del producto y gestión de grupos de trabajo.

La arquitectura de tres niveles (IIOP/Tier3) incorporada en la versión 5, diferenciaba claramente

la gestión de procesos, con el almacenamiento de la información e incorporaba dos servidores

de aplicación, el de servicios y el de base de datos.

La arquitectura diseñada en ENOVIA V6 se caracteriza por presentar tres capas, una primera

capa de presentación donde se encuentras los equipos de los clientes, destacando que un

cliente puede ser un usuario de clientes pesado (CATIA, DELMIA,…) o clientes ligeros que

directamente acceden al sistema PLM a través de un navegador web (ENOVIA).


37

Figura 11. Arquitectura a tres niveles de ENOVIA V6

La capa o nivel lógico concentra los servidores de aplicación, cuyas comunicaciones con los

clientes ligeros y pesados se realiza mediante protocolos http y https. En este nivel se incluye el

equipo servidor de licencias que da servicios a los clientes ligeros y pesados.

Finalmente la capa de datos destacada por estar estructurada en varios bloques, el sistema V6

incorpora dos sistemas de gestión de datos o repositorios, un primer sistema destinado a la

gestión de contenidos y un segundo sistema de metadatos. Además de manera opcional y con el

objetivo de aumentar la velocidad en acceso a la información se incorpora dos servidores de

indexación, 3D Index y Full Text Index que permite disminuir los tiempos de respuesta.

2.8.1.2 Análisis de requisitos en la arquitectura hardware.

La nueva arquitectura diseñada en ENOVIA V6 proporciona un valor añadido a los sistemas PLM

en relación a:

Una mejora en eficiencia operacional mediante una arquitectura flexible y modular,

centralizando los procesos y abierta hacia aplicaciones CAD externas y sistemas de

gestión como SAP.

Acelerando los tiempos mediante la disminución del ciclo de vida y revisión del producto,

mediante un diseño de la cadena de suministro desde las tareas de diseño hasta la

fabricación del producto y entrega al cliente. Además proporciona un sistema


38

colaborativo en tiempo real con gestión eficiente y segura de accesos lo que permite una

mayor interacción y mejores tiempos de respuesta ante peticiones y mejoras.

Disminuyendo costes, mediante una administración centralizada que permite concentrar

y disminuir el número de equipos o el diseño de sistemas de indexación que reduce los

tiempos de búsqueda o recuperación de la información aumentando la productividad y

finalmente una estructuración de datos mediante “silos” que facilita el almacenamiento y

estructura de la información.

El diseño de ENOVIA V6 (Figura 12) está orientado a una estructura centralizada de datos

(Centralized ENOVIA V6 Servers), en ellas se almacenan los metadatos y los datos de contenido

que se distribuyen entre los usuarios. Los clientes locales acceden al sistema mediante redes

locales aunque en base a la configuración del sistema, se permite implantar servidores de

indexación y duplicación conectados por redes WAN (Una Red de Área Amplia (Wide Area

Network o WAN, del inglés, es un tipo de red de computadoras capaz de cubrir distancias desde

unos 100km hasta unos 1000 km). La sincronización de los equipos es totalmente trasparente al

usuario, siendo así posible disponer de la información en tiempo real.

Figura 12. Configuración física de equipos con ENOVIA V6

La configuración típica de una arquitectura V6 queda reflejada por unos requisitos obligatorios y

otros opcionales:

Live Collaboration Server (MCS). Sistema que permite establecer las condiciones

necesarias para que los usuarios finales puedan colaborar de manera efectiva durante el

desarrollo del producto. Permiten la colaboración entre todos los usuarios con la

seguridad basada en roles funcionales. También permiten la administración para medir

la eficacia del proceso global de desarrollo de productos. ENOVIA Live Collaboration es

un sistema abierto, escalable basado en estándares. Tiene capacidad para soportar una

gran cantidad de información y permite la implantación de sistemas PLM de gran

complejidad.


39

File Collaboration Server (FCS). Sistema de ficheros que permite al cliente crear,

modificar y gestionar archivos de forma eficiente y con un rendimiento elevado. Su

implementación puede ser centralizada o distribuida. La estructura básica es un servidor

de aplicaciones que se comunica con los usuarios mediante un servidor http.


Database Server (DB). Es un repositorio centralizado donde se almacenan los datos de

la empresa. La principal característica que destaca en ENOVIA V6 es que distingue

entre metadatos y datos de contenidos. La disposición física de la base de datos puede

ser centralizada o distribuida, así mismo la gestión de los datos se realiza a través de

MCS (Live Collaboration Server). La principal característica que aporta este servicio es

la gestión de una gran cantidad de información y la gestión de datos para los usuarios es

de forma trasparente.


Dassault Systèmes License Server (DSLS). Es un servidor de licencias que gestiona

las licencias para los usuarios de ENOVIA V6.

Además de los servidores indicados anteriormente, de forma opcional existen disponibles

servidores para mejorar la productividad del sistema:


40

3D Indexing Server (3DX). Este servidor permite generar ficheros de indexación

(ficheros índices) para una búsqueda más eficiente de modelos 3D desde las

aplicaciones del cliente pesado como CATIA, 3DLIVE, DELMIA,… Este tipo de servicio

solo es usado por aplicaciones de clientes, y está diseñado en dos bloques: el creador

de índices y el servidor de índices.


Full Text Search Server (FTS). El servidor FTS permite la indexación de todos los

textos y metadatos. Esta funcionalidad permite la aceleración de la búsqueda de

información mediante palabras claves, atributos o metacaracteres.


Real Time Collaboration Server (RTC). Es una aplicación que tiene como objetivo

habilitar la colaboración de datos entre múltiples usuarios. Las principales características

que incorpora corresponden a la capacidad de compartir aplicaciones, entornos de

comunicación interactivos con audio, video incluyendo chats o pizarras, transferencia de

ficheros, gestión de foros de preguntas y respuestas,… Este sistema se aplica en los


41

clientes web y se integra con herramientas como Lotus SameTime o Microsoft Office

Communicator Server.


2.8.1.3 Infraestructura técnica.

La gran flexibilidad que proporciona los servidores de aplicaciones disponibles en V6 permite

disponer de varias configuraciones en base a las necesidades o características del proyecto. Así

mismo la implantación de una infraestructura técnica no es rígida sino que la estructura con que

ENOVIA ha sido diseñado permite una gran escalabilidad.

Figura 18. Escalabilidad del sistema ENOVIA V6

Así, por ejemplo en el proyecto básico de demostración donde se desea analizar la potencialidad

del sistema V6 sería recomendable un sistema donde todo estuviera integrado en el mismo

equipo. A medida que las necesidades del sistema y uso fueran creciendo es posible una

escalabilidad incremental.

En un análisis orientado a las comunicaciones físicas, se tiene que destacar que para el proyecto

de demostración, los sistemas de comunicaciones son centralizados.


42

Figura 19. Escalabilidad del sistema ENOVIA V6

Lo más destacable en este tipo de proyecto es tener un control de las conexiones de clientes

desde el exterior y un control de balanceo de cargas.

Los entornos de producción y pre-producción destacan por tener distribuidas cada una de las

capas, con sistemas de seguridad entre ellas y conexiones de WAN para clientes internos.


43

Figura 20. Escalabilidad del sistema ENOVIA V6 para entornos colaborativos

Por último, la configuración básica asociada a un proyecto en producción se puede ampliar con

servidores desagregados, es decir compartir la información y aplicaciones entre varios equipos.

En este caso la recomendación es disponer de sistemas balanceadores de carga.


44

Figura 21. Escalabilidad del sistema en producción

2.8.2 Requisitos hardware y software para clientes web.

El cliente base hace referencia a entornos de acceso a la plataforma V6 sin necesidad de

realizar ningún tipo de instalación, simplemente con un explorador web. El siguiente apartado

tiene como objetivo proporcionar una guía de las configuraciones hardware, sistema operativo y

explorador web para el uso de los productos de V6 en un entorno web.

La primera tabla se centra en analizar los requerimientos de equipo para la conexión con

ENOVIA V6, donde solo es necesario un navegador cuyas características se muestran a

continuación.

La tabla, muestra las plataformas en las cuales las interfaces web son soportadas. Las dos

primeras filas indican el sistema operativo y el tipo de procesador necesario, a continuación se

describe los exploradores web que pueden utilizarse y las posibilidades de utilización en base a

las funcionalidades exigidas.

Plataforma Sistema operativo y hardware


45

Vendor Product

Windows 7 SP1

32-bit and 64-bit

Edition

Windows

Server

2008 R2

SP1

Red Hat

Enterprise Linux

5.5 32-bit or 64-

bit Editions

SuSE Linux Enterprise Server 11

SP1 32-bit or 64-bit Edition MacOS 10.7

x86-32 or x86-64

Intel or AMD

x86-64

Intel or

AMD

x86-32 or x86-64

Intel or AMD

x86-32 or x86-64

Intel or AMD

x86

Intel

Exploradores web (IE: Internet Explorer; FX: FireFox; S: Safari)

Mic

roso

ft

Inte

rnet

Inte

rnet

Exp

lore

r 8/

Ora

cle

JRE

7

(32-

bit)

Mic

roso

ft

Inte

rnet

Exp

lore

r

9/ O

racl

e JR

E 7

(32-

bit)

Ope

n S

ourc

e

Fire

fox

10 E

SR

/ Ora

cle

JRE

7 (

32-b

it)

Following products

are not supported :

CST,LES,LHC,LPI,LP

Q,LPX,LRA,PQC,QIC

Ope

n S

ourc

e

Fire

fox

/ Ora

cle

JRE

7 (

32-b

it)

Firefox 3.0.18

(32-bit)

Following

products are not

supported :

ADS,ARN,ARP,A

RS

Firefox 3.5.9 (32-bit)

Following products are not supported

:

ADS,ARN,ARP,ARS

App

le

Saf

ari 5

.1.1

/ S

un J

RE

6 (6

4-bi

t)

Following products

are not supported :

ARS,LES,LHC,LPI,LP

Q,LPX,LRA,PQC,QIC

Tabla 1. Requisitos software para clientes web.

Para internet Explorer 8, es necesario que se desactive la opción vista compatible con todos de

los equipos de la intranet, que por defecto está habilitada.


46

2.8.3 Clientes pesados.

Los clientes pesados corresponden a las aplicaciones software que aumentan las capacidades

de desarrollo, comúnmente son programas instalados en un equipo que están conectados a un

servidor de datos evitando la necesidad de que cada usuario disponga de su propio servidor

local y aumentando la concurrencia en el trabajo. En concreto, el entorno V6 dispone de los

siguientes clientes pesados: CATIA, DELMIA, ENOVIA, SIMULIA y 3DLIVE (incluyendo la

aplicación ENOVIA Studio y ENOVIA 3DLIVE).

2.8.3.1 Sistema operativo y software adicional necesario.

Este apartado describe las necesidades de configuración hardware, incluyendo el sistema

operativo (con las correspondientes actualizaciones necesarias) para la utilización de las

herramientas de cliente V6.

La siguiente tabla muestra la lista de plataformas que soportan las aplicaciones CATIA / DELMIA

/ ENOVIA / SIMULIA / 3DLive.

Sistema Operativo

Windows 7

64-bit (Sin soporte WOW64 )

Prerequisitos

Exploradores

(Cualquiera)

Microsoft Internet Explorer 8 with Oracle Java

plug-in version 7 (32-bit versiones of Internet Explorer

and Sun Java Plug-in)

FireFox 10 ESR with Oracle Java plug-in version

7 (32-bit versions of FireFox and

Sun Java Plug-in)

Microsoft Internet Explorer 9 with Oracle Java

plug-in version 7 (32-bit versions ofinternet Explorer

and Sun Java Plug-in)

XML Parser Embedded OS version

.NET Runtime

Environment

Microsoft .NET Framework 3.5 SP1

Redistributable Package

Java Runtime

Environment Oracle Java Runtime Environment 7

Colaboración

con las

herramientas

office de

Microsoft

a) Microsoft Office Communications Server 2007;

b) Microsoft Office Communications Server 2007

R2;

c) Microsoft Lync Server 2010

(32-bit version)

IBM Lotus Instant Messaging 8.5 (32-bit version of Oracle JRE)

Tabla 2. Requisitos software para clientes pesados. Sistema operativo.


47

En los entornos operativos de Windows el sistema de ficheros debe ser NTFS (New Technology

File System) lo que permite particiones de disco de gran tamaño (hasta 16 terabytes). Su

principal inconveniente es que necesita para sí mismo una buena cantidad de espacio en disco

duro, por lo que no es recomendable su uso en discos con menos de 400 MiB (Mebibytes) libres.

2.8.3.2 Requisitos mínimos de memoria ram.

La siguiente tabla muestra las necesidades mínimas para la utilización de los clientes pesados

de V6.

Windows7

64-bit

RAM (GB) for ENOVIA 3D

Live 2

RAM (GB) for CATIA,

DELMIA and SIMULIA 6

Tabla 3. Requisitos software para clientes pesados. Sistema operativo.

2.8.4 Servidor.

El sistema V6 Server se caracteriza por incorporar un gestor de base de datos y un servidor web

que da servicio a los clientes. La gran variedad de servidores web y de gestores de base de

datos aumentan las posibilidades de que el sistema puede instalarse y las necesidades

requeridas.

A continuación se describe las necesidades de software y hardware para la instalación de V6

Server:

Plataforma Sistema operativo(HARDWARE)

Pro

piet

ario

Pro

duct

o

Windows

Server 2008

R2

Red Hat

Enterprise

Linux 5 64-bit

SuSE Linux

Enterprise Server

11 64-bit

AIX 6.1 64-bit

AIX 7.1 64-bit

HP-UX 11i

HP-UX 11iv3

for Itanium

64-bit Solaris

10

64-bit Solaris

10

64-bit Solaris

11

64-bit Solaris

11

x86-64

Intel or AMD

x86-64

Intel or AMD

x86-64

Intel or AMD

64-bit

POWER 5, 6, 7

64-bit

Itanium

or PA-RISC

64-bit

SPARC III or

higher

x86-64

Intel or AMD

Software servidor de aplicaciones (web server)

http://es.wikipedia.org/wiki/Mebibyte

http://marketing.intrinsys.co.uk/V6_2013x_PDir/prerequisites/server_software_requirements.html#linux_qualified




48

Ora

cle

Web

Logi

c

with

ORACLE

JDK 7.

with

ORACLE

JDK 7.

with ORACLE

JDK 7.

No soporta::

LES,LHC,LPI,LPQ

LPX,LRA,PQC,QIC

with IBM Java

6 .

No soporta:

C3D,C2D

with

ORACLE

JDK 7.

No soporta:

VPM

with

ORACLE JDK

7.

No soporta:

VPM

IBM

Web

Sph

ere

con

bund

led

IBM

JD

K

Productos no

soportado:

LES,LHC,LPI,LPQ

,LPX,LRA,PQC,QIC

Productos no

soportado:

C3D,C2D

Productos no

soportado:

VPM

Ope

n S

ourc

e

Tom

cat

ORACLE

JDK 7.

ORACLE

JDK 7.

ORACLE JDK 7.

Productos no

soportados:

ARN,ARP,LES,LHC

,LPI,LPQ,LPX,LRA,

PQC,QIC

with IBM Java 6.

Productos no

soportados:C3D,

C2D

with ORACLE

JDK 7.

Productos no

soportados:

VPM

with ORACLE

JDK 7.

Productos no

soportados:

VPM

Tabla 4. Requisitos software para servidor. Sistema operativo y servidor de aplicaciones.

DATABASES

Ora

cle

Ora

cle

Dat

abas

e

IBM

DB2

Productos no soportados::

LES,LHC,LPI,LPQ,LPX,LRA

PQC,QIC

Productos no

soportados::

LES,LHC,LPI,LPQ

LPX,LRA,PQC,QI

C

Productos no

soportados: :

LES,LHC,LPI,LPQ

LPX,LRA,PQC,QI

C

Productos no

soportados: :

LES,LHC,LPI,LPQ

, LPX

,LRA,PQC,QIC

Mic

roso

ft

SQL

Serve

r 2008

and

2012

(*)

Productos no soportados :

LES,LHC,LPI,LPQ,LPX,LRA,PQC,QI

C

Tabla 5. Requisitos software para servidor. Gestor de base de datos.

(*) Realmente es necesario SQL Server 2008 R2 ya que incorpora un cliente nativo.

La siguiente tabla muestra los requisitos mínimos de memoria RAM, dependiendo del sistema

operativo y en una instalación donde todos los productos de V6 están instalados y con un

máximo de 50 usuarios.

RAM (GB) Windows Server

64-bit

Red Hat Linux

64-bit

SuSE Linux 64-

bit AIX 64-bit Solaris 64-bit


49

ENOVIA Live Collaboration Server

(CSR) including File Collaboration

Server (FCS) + 3D Index Server (3DX)

+ Full-Text Search (FTS) + Database

Server (DB)

Monolithic Configuration

16 16 16 16 N/A


(CSR) including File Collaboration

Server (FCS) + Full-Text Search (FTS)

+ Database Server (DB)

Monolithic Configuration

4 4 4 4 4

Tabla 6. Requisitos hardware para servidor. Memoria RAM en base al sistema operativo.

Las necesidades de memoria desagregada de forma individual por cada producto serían:

RAM (GB) Windows Server

64-bit Red Hat Linux

64-bit SuSE Linux 64-

bit AIX 64-bit Solaris 64-bit


(CSR)

Stand-alone Server 4 4 4 4 4

Database Server (DB)


File Collaboration Server (FCS)


3D Index Server (3DX)

Stand-alone Server 4 4 4 4 N/A

Full-Text Search (FTS)


Tabla 7. Requisitos hardware para servidor. Memoria RAM en base al sistema operativo y cliente

pesado.

2.8.5 Plataformas adicionales para las licencias de servidores DS.

Finalmente es importante incluir la necesidad de un servidor de licencias cuyas características

son básicamente de sistema operativo:

Windows 7 x86-64 SP1 Enterprise or Professional Edition.


50

2.8.6 Equipos certificados del sistema V6.

Una vez analizados los servicios que provee V6, las configuraciones posibles en base a la

tipología del proyecto acometido y los requisitos hardware en base a los servicios a instalar, se

procede a describir la lista de equipos que Dassault Systèmes certifica para la instalación del

entorno V6.

El listado de equipos certificados que será mostrado a continuación se caracteriza por estar

orientados a una instalación en Windows 7 a 64 bits. Las posibilidades disponibles son:

Estaciones de trabajo portátiles

Estaciones de trabajo de sobremesa

Los equipos certificados se concentran en los siguientes vendedores:

• Boxx

• Dell

• Fujitsu

• Hewlett-Packard

• Lenovo

La siguiente tabla se indica algunos de los equipos certificados que han sido incluidos en el año

2014. Además de los datos propios del ordenador se incluye la memoria RAM y si el tipo de

equipo es portátil o sobremesa.

Vendedor Estación de trabajo Procesador Memoria/disco Adap. Gráfico Tipo Fecha

Dell

Precision M4800 Intel Core i7-

4702MQ @2.80Ghz

Windows 7.

8 / 16 RAM

500/ 256

AMD

FirePro M5100 P (15”) 02/14

Precision M6800 Intel Core i7-

4930MX @3.00Ghz

Windows 7

8/16 RAM

500 / 750

nVidia

Quadro K3100M P(17”) 02/14

Dell Workstation

T3610

Intel Xeon CPU E5-

2650 v2 @ 2.60GHz

Windows 7

8/16 RAM

500 / 1T

nVidia

Quadro K6000

(12 Gigas)

S 12/13

Fujitsu

Celsius J530

Intel Xeon CPU E3-

1225 v3 @

3.20GHz, 4 Core(s)

Windows 7

8/32 RAM

500 GB

nVidia

Quadro K600

(1 Giga)

S 01/14

Celsius M730

Intel Xeon CPU E5-

1603 0 @ 2.80GHz,

4 Core(s)

Windows 7

8/16 RAM

500 / 2T

nVidia

Quadro K4000

(3Gigas)

S 11/13

http://media.3ds.com/support/certified_hardware/Windows_7_64-bit.html

http://media.3ds.com/support/certified_hardware/Windows_7_64-bit.html#Dell

http://media.3ds.com/support/certified_hardware/Windows_7_64-bit.html#Fujitsu

http://media.3ds.com/support/certified_hardware/Windows_7_64-bit.html#HP

http://media.3ds.com/support/certified_hardware/Windows_7_64-bit.html#LeNovo


51

Celsius C620 Rack

Workstation (with

client portal (Teradici

based) Futro L420)

Intel(R) Xeon(R)

CPU E3-1280 V2 @

3.60GHz

Windows 7

8/32 RAM

500 / 2T

nVidia

Quadro K4000

(3 Gigas)

S 11/13

HP

HP Workstation Z820

certified configuration

- Z420/Z620 derived

configuration

Intel Xeon

Processor E5-2697

v2, Chipset Intel

C602

Windows 7

8 RAM

1T

nVidia

Quadro K6000

derived from Quadro

K600

S 01/14

HP Workstation Z820

certified configuration

- Z420/Z620 derived

configuration

Intel Xeon

Processor E5-2697

v2, Chipset Intel

C602

nVidia

Quadro K5000

derived from Quadro

K600

S 12/13

HP Zbook 17"

Intel(R) Core(TM) i7-

4900MQ CPU @

2.80GHz

Windows 7

4 RAM

750 T

nVidia

Quadro K5100M

(16 Gigas)

P 11/13

HP Zbook 15"

Intel(R) Core(TM) i7-

4900MQ CPU @

2.80GHz

Windows 7

4/32 RAM

750 T

nVidia

Quadro K2100M

(2 Gigas)

P 11/13

HP Workstation Z220

Intel Xeon E3-

1240v2, chipset Intel

7 Series C216

Windows 7

8/16 RAM

250 T

nVidia

Quadro K4000

(1 Giga)

P 04/13

IBM

IBM x3650 M3 Rack

(Remote Access

Device WYSE

ThinClient)

Intel Xeon E5506 ,

up to 2.13 GHz,

chipset Intel

5520/5500/X5

Windows 8

Hasta 268 G

16 T

nVidia

Quadro 2000D S 08/11

Lenovo

ThinkPad W540

Intel Core i7

4800MQ @ 2.70

Ghz, chipset Intel

ID8C4F

Windows 7

32 RAM

2 T

nVidia

Quadro K2100M

(2 Gigas)

P 15 01/14

ThinkPad W540

Intel Core i5-4330M

@ 2.80GHz, chipset

Intel ID8C4F

Windows 7

32 RAM

2 T

nVidia

Quadro K1100M P15 01/14

ThinkStation S30

Intel Xeon E5-2680

(2.70 GHz, 8C), Intel

C602 chipset

Windows 7

8/128 RAM

2 T

nVidia

Quadro K6000

derived from Quadro

K600

(1 G)

S 12/13

Tabla 8. Equipos certificados por Dassault Systèmes para instalación de V6.


52

2.8.7 Recomendaciones hardware del sistema V6.

El siguiente apartado pretende resumir las especificaciones mínimas necesarias para el

funcionamiento de los equipos clientes y servidor de V6, aunque es recomendable aumentarla.

Procesador Memoria RAM Memoria Video Sistema operativo

Cliente ligero (web) Básico 4 Gigas 1 Gigas Windows Xp-Windows 7

Cliente pesados

(CATIA, DELMIA,…)

Intel Core i5 8 Gigas,

recommendable 16.

2 Gigas Windows 7 pro 64b bits

Servidor Intel Core i7 8 Gigas Recomendable

16.

- Windows 7 pro 64b bits

Tabla 9. Recomendaciones de hardware y software para instalar V6.

En cuanto a las necesidades de almacenamiento, destacar que los equipos destinados a clientes

ligeros no necesitan un espacio de almacenamiento elevado, al igual ocurre con los clientes

pesados, donde las necesidades de almacenamiento se centran en disponer de espacio para la

instalación de los clientes, en concreto las necesidades de espacio por herramientas son:

Sistema Operativo Windows 7: 16 Gigabytes de almacenamiento.

Clientes ligeros: 50 Megabytes de almacenamiento.

Clientes pesados: CATIA + DELMIA: 1 Gigabytes de almacenamiento.

Servidor: Mínimo 250 Gigabytes.

53

3 La gestión del ciclo de vida con ENOVIA V6

3.1 Introducción.

3.1.1 Introducción PLM 2.0.

Actualmente el término PLM es muy frecuente y cobra fuerza en las grandes empresas. Utilizado

para la descripción de las estrategias de negocio usadas por las empresas para dar apoyo a la

creación colaborativa, la gestión y la información sobre la definición de uso del producto sobre

empresas muy extendidas partiendo del concepto de vida o muerte.

PLM 2.0 adopta la forma de concepto online, comunidades de creación y constitución y la

innovación del producto basado en la Web 2.0.

Los usuarios pueden utilizar la Web 2.0 para hacer funcionar aplicaciones o software utilizando

un buscador. Pueden hacer más utilizando la misma información, pudiendo mantener los datos

en la web 2.0 y controlando estos datos.

La aplicación de PLM 2.0 en esta nueva plataforma (V6) nos da ventajas tales como: una

innovación colaborativa global en la innovación, utilizando la tecnología 3D como medio de

comunicación entre las diferentes comunidades de usuarios, la aplicación de la propia

experiencia de dichos usuarios, una única plataforma PLM para una gestión IP, colaboración y

creación online. V6 ofrece una plataforma lista para aplicar un PLM a procesos empresariales y

un bajo coste de propiedad.

PLM 2.0 en V6 ofrece una experiencia realista: “Primera vida = Virtual + Real”. El usuario real

utiliza su experiencia para innovar de manera virtual a través de la plataforma V6 de una forma

fácil. Podemos realizar un diseño virtual de sistemas, equipos, mecanismos, piezas…

Estos conceptos se pueden someter a una simulación realista, sometiéndolo a un cumplimiento

de requisitos, a un laboratorio digital de pruebas físicas o a una plataforma científica. Por último,

es posible realizar un plan de producción y fabricación digital, gestionar la distribución en planta y

sus diferentes recursos, realizar pruebas de ingeniería de programación y control, incluso una

simulación de ejecución de la producción.

En la arquitectura V6, todos los datos del producto son gestionados y están contenidos en una

base de datos. Esta base de datos contiene los datos físicos, la estructura lógica y los requisitos

de los productos y cada una de sus partes.

La gestión del ciclo de vida en ENOVIA

54

Figura 22. Base de datos centralizada V6.

Podemos trabajar en ellos sin necesidad de copiarlos en nuestro propio pc. Esto simplifica el

proceso de la gestión de datos y compartir la información.

3.1.2 Valores de PLM 2.0 en V6.

En la actualidad las empresas siguen una tendencia basada en:

La internacionalización, con duplicaciones o brechas entre las bases de datos, retrasos

en actualizaciones, datos parciales…

Diseño del escritorio, con oficinas o escritorios CAD especializados…

Portales unificados 3D, con sus correspondientes fuentes de datos y formatos,

comunidades de partición y el software de especialización.

Colaboración, se utilizan interfaces especializadas con datos específicos tales como

formatos, intercambios y migraciones entre disciplinas (Ejemplo: Cálculo, Procesos…).

Toma de decisiones, se producen problemas tales como una propagación dificultosa y

una mala administración de actualizaciones, derivación masiva, necesidad de

modularización, no tiene indicadores de reutilización…

Con la aplicación de la plataforma V6 se le añaden al cliente las siguientes ventajas:

Una colaboración online, con una base de datos central con acceso multi-sitio y la

posibilidad de hacer común el diseño del sitio.

Una reducción de costes operativos introduciendo el acceso web, Linux, Vista,

produciéndose por tanto una escalabilidad.

Simplificación de la experiencia del producto, con controles individualizados,

instrucciones sobre dominios de interés y acceso 3D a todos los usuarios.

Innovación colaborativa global, incluyendo una interfaz unificada, un lenguaje común,

metodologías uniformes y modernos conceptos de comunicación.

Dominio de los procesos de negocio, incluye una base de datos central federada, nos

aporta trazabilidad, nos garantiza el cumplimiento de la legislación, diversidad y la

capacidad de modularización.


55

3.1.3 Gestión del ciclo de vida IP.

El dominio de la gestión del ciclo de vida IP (Intellectual Property) elimina los costosos errores

de desarrollo de productos, permitiendo un mejor diseño del producto multi-funcional, la

planificación de la fabricación y la simulación del rendimiento.

Esto nos prepara la IP para una colaboración multi-funcional y el lanzamiento del producto para:

Identificar y resolver problemas prematuros en el proceso de desarrollo.

Gestión colaborativa multi-disciplinar diseñando el WIP en un sistema con múltiples

equipos y herramientas CAD.

Gestionar entornos colaborativos multi-disciplinares que integran la mayoría de las

aplicaciones MCAD/ECAD/EDA.

Disminuir costes y promover la transferencia del conocimiento mediante la clasificación

de IP para reusar.

3.2 Innovación colaborativa.

3.2.1 Innovación colaborativa.

La plataforma V6 nos proporciona una plataforma única para la gestión IP (Intellectual

Property) y para apoyar tanto las aplicaciones de modelado IP que abarcan todas las

disciplinas de ingeniería como los procesos colaborativos de negocios (CBP

“Collaborative Business Processes”) que cubren todo el ciclo de vida del producto.

Las herramientas para un diseño virtual las proporcionaría la aplicación CATIA, para una

simulación real SIMULIA y para la fabricación y producción digital la aplicación DELMIA.

En estas herramientas se basa la implantación de un PLM utilizando la herramienta

ENOVIA. Englobaríamos desde una colaboración unificada en vivo, gestión del ciclo de vida del

producto IP, búsquedas globales y un gobierno total del proyecto. Además nos permitiría

implementar sistemas ERP, SRM, CRM, VPM…

Por último podemos dar rienda suelta a nuestra imaginación y jugar con los productos, pudiendo

aplicar nuestra propia experiencia personal, dando la oportunidad a una mejora del producto que

tal vez no estuviese contemplada, todo ello basado en la herramienta 3DVIA.


56

3.2.2 Colaboración instantánea y 3D Lluvia de ideas.

PLM 2.0 V6 habilita a todos los participantes de una extensa empresa a comunicarse alrededor

del producto 3D al mismo tiempo. Además proporciona las herramientas para una colaboración

en el desarrollo del producto.

Usando las herramientas de colaboración, puede interactuar con otros usuarios trabajando en el

mismo producto, enviando mensajes de texto, realizando anotaciones en los datos 3D y

compartiendo vistas instantáneas. También puede realizar una revisión 3D online, incluso

realizar un trabajo concurrente en el mismo diseño. Con un puesto de trabajo virtual colaborativo,

V6 nos ofrece una colaboración “ad-hoc” para equipos multidisciplinares y geográficamente

dispersos.

A disposición se encuentra el servicio del chat 3D con el que el usuario se sumergirá en la

comunidad del proyecto, optando a diferentes vías de chat (individuales, colectivos…) entre los

diferentes usuarios de la empresa. Un simple chat de texto puede extenderse a una revisión o

“revisión cooperativa” online. Una revisión cooperativa es una sesión que permite compartir

visiones y acciones online con otros usuarios a través de la red. Cada participante de la

revisión cooperativa es un actor y no un oyente.

La colaboración instantánea es totalmente escalable desde la comunicación local

persona-persona a una extensa configuración de una empresa.

Existen formas diferentes de trabajar en un mismo proyecto:

- Ingeniería Concurrente: Trabaja al nivel del producto. Los usuarios gestionan las

diferentes representaciones del ensamblaje.

- Diseño colaborativo: Trabaja al nivel de representación. Los usuarios pueden

modificar características de la misma representación.

Se puede intercambiar instantáneas 3D del producto con cualquier usuario del proyecto.

Llegando a la opción de un Real-time con los diferentes usuarios y cargos, para una revisión del

producto en cooperación, incluso pudiéndose realizar un diseño en cooperación de manera

instantánea o a un tiempo asíncrono. Esto proporcionará una gran cohesión a los grupos de

ingeniería multidisciplinares situados en diferentes lugares.

3.2.3 Colaboración unificada en vivo.

Este dominio permite a las empresas desplegar los procesos del ciclo de vida del producto a

toda la empresa. Esto nos proporciona una particular visión de la IP en todo el dominio del

proceso de negocio, potenciando las capacidades de la gestión de los procesos.

La Colaboración unificada en vivo despliega los procesos de desarrollo del producto en toda la

empresa para:


57

Permitir a los usuarios una búsqueda fácil y sencilla de todos los productos

pertenecientes a la empresa basados en IP.

Tratar la extensa empresa como entera, como un sistema simple capaz de proporcionar

consistencia a los datos y procesos.

Aprovechar la información de productos de sistemas de otras empresas para federar su

IP a una cuenta maestra de material.

Evitar la personalización y la reducción del TCO (Total Cost of Ownership) con modelos

gráficos simples.

3.2.4 The Heads-Up Display (HUD).

Es una pantalla transparente que representa las colaboraciones que están ocurriendo entre dos

usuarios que comparten una sesión de V6. Tiene un área delimitada y ofrece herramientas para

una eficiente comunicación e intercambio de archivos.

Figura 23. Representación de acción colaborativa en HUD.

3.2.5 Modos de conectividad en colaboración.

Existen dos tipos de modo de conexión para una colaboración. Estos dos modos son

completamente independientes. Puede utilizar el modo persona-persona o el modo

Cliente/Servidor.

Existen dos tipos de intercambio de datos: el modo sincronizado y el modo asíncrono.

- El modo sincronizado: en el modo persona-persona donde ambos usuarios están

en línea. Es un chat simple en el cual se puede intercambiar cualquier dato.


58

- El modo asíncrono: Le permite almacenar sus datos en carpetas que a su vez se

almacenan en espacios de trabajo que pueden compartirse en la base de datos de

PLM.

Esta capacidad es útil para modelos más complejos en los que usted necesita dividir el trabajo

entre un grupo de diseñadores. Después de terminar con los diseños independientes, se pueden

combinar los datos y crear el modelo final.

ENOVIA Live Collaboration usa las siguientes aplicaciones:

Studio Customization Toolkit: es una API Java de nivel bajo. Es la responsable del

manejo de los objetos atómicos del sistema, como objetos de negocio y relaciones.

Proporciona documentación, código de búsqueda, archivos…

Business Process Services: es una colección de esquemas definidos, también

llamados JPOs y Java Server Pages (JSPs) que pueden ser usadas con el Studio

Customization Toolkit para crear sus propias aplicaciones.

3.2.6 Marco CATIA Live.

El marco CATIA Live es una herramienta híbrida de modelado. Permite crear y diseñar

conceptos e ideas en 3D ya sea partiendo de cero o de geometrías existentes. El marco CATIA

Live está construido en el modelador B-Rep de geometría, totalmente integrado en el modelador

de CATIA. Los usuarios pueden crear una pieza simplemente utilizando el ratón. Destacar que

su código es reusable con CATIA o con cualquier programa de tipo CAD.

CATIA Live permite una colaboración instantánea en lluvia de ideas en 3D y puesta en común de

las ideas con la comunidad de usuarios. Esto nos proporcionará un gran ahorro de tiempo en

modificaciones, que será potenciado también con modificaciones universales en entornos

existentes V4, V5 y otros sistemas CAD. Todo ello influirá en la rapidez en la toma de decisiones

del proceso mediante la iteración.

3.3 Herramientas V6.

3.3.1 Arquitectura V6.

La plataforma V6 proporciona una compatibilidad con la arquitectura abierta. Se pueden agrupar

y reunir diferentes tipos de clientes, servidores, proveedores de seguridad, bases de datos,

sistemas operativos, lenguajes de programación… Por tanto con V6 se consigue una

arquitectura abierta sin imponer restricciones de ningún tipo a los diferentes usuarios

facilitándose la comunicación y trabajo entre los diferentes niveles y entidades de trabajo.


59

El principio de la arquitectura de V6 es partir de dos tipos de servidores, un servidor con función

de base de datos (RDBMS) donde residen los metadatos y otro servidor de archivos (FCS)

donde residen los archivos.

Estos dos servidores están interconectados con otros dos servidores: uno web y otro de

aplicaciones (MCS). Estos últimos servidores a través de la red junto a la colaboración en vivo

ENOVIA y otros productos ENOVIA, se conectan con los clientes web, y los propios clientes de

VPM V6.

3.3.2 Arquitectura V6: acceso remoto a archivos.

La arquitectura V6 está diseñada para centralizar los datos, metadatos y contenidos distribuidos.

Los clientes pueden acceder al contenido con WAN. El contenido está sincronizado de

manera segura con el WAN a los servidores remotos de archivos.

Los clientes remotos acceden a los metadatos y a las páginas web a través de WAN,

pero no pueden acceder al contenido completo (textos y 3D) en un servidor local de

archivos.

La frase “Fuente de la verdad” toma sentido porque la central conoce dónde se localiza

el contenido y quién tiene acceso a él en cualquier momento.

Con todo esto la arquitectura de ENOVIA V6 ofrece diversos beneficios tales como:

Metadatos centralizados que equivale a una “Fuente de la verdad”.

Seguridad de inicio a fin mediante firewalls y VPNs.

Acceso local a los archivos PLM.

WAN optimizada para acceder a los metadatos.

Control centralizado para la gestión del acceso y derechos.

Reducción del coste total de propiedad (TCO – Total Cost of Ownership).

Existen dos tipos de clientes en V6:

Cliente web: este tipo de cliente puede acceder a las Centrales ENOVIA y a los

Aceleradores a través de buscadores web. Solo existe un protocolo http entre el cliente

web y ENOVIA V6 MCS y los servidores FCS.

Clientes ricos: 3DLive, CATIA V6, DELMIA V6 y SIMULIA V6, al igual que otros

programas CAD están al alcance de los clientes ricos que pueden acceder a través de

ENOVIA V6. Existe un protocolo http entre los clientes ricos y ENOVIA V6 MCS, FCS,

3D Search y servidores DSLS. Requieren los módulos del Servidor VPM para clientes

V6 y el Diseñador Central junto al diseño colaborativo para clientes xCAD.


60

3.3.3 V6 Express.

V6 PLM Express es una oferta racionalizada basada en una vista filtrada de toda la cartera de

productos de la plataforma V6. El paquete PLM Express incluye los productos del equipo V6 y se

agrupa de acuerdo a los roles para satisfacer las necesidades de los usuarios del mercado

intermedio.

V6 PLM Express es una solución “lista para usar” que proporciona de manera rápida y sencilla

un despliegue de CATIA V6 en la arquitectura de ENOVIA.

Tiene un fácil acceso, pensado en el día a día para la gestión de datos CATIA V6, poniendo fin a

un uso de complejas tecnologías y haciendo que V6 PLM Express sea accesible desde CATIA a

los usuarios sin un soporte específico.

Individual o en pequeños grupos de trabajo, con PLM Express ya no se tiene que lidiar con

autorizaciones (como ocurría en V5). Simplemente necesita ser el “Administrador de Proyecto”

de un único Proyecto, y mantendrá todos los datos de su trabajo fuera del control de versiones.

3.3.4 Interfaz V6 PLM 2.0.

A continuación se presenta la interfaz de PLM 2.0. V6 que incluye dos ventanas de interfaz de

usuario, llamadas navegador y redacción.

- VPM Navegador: Revisión de la maqueta digital (DMU - Digital Mock-Up). Puede

explorar los objetos de V6 en el Navegador VPM (fondo plateado). Puede ver

representaciones gráficas de objetos en la tabla giratoria, buscar objetos PLM, navegar

en la estructura del producto y ver los objetos.

- Interfaz CATIA V6: Modificación de la maqueta digital (DMU - Digital Mock-up).

Puede modificar objetos en V6 en la ventana de redacción (fondo azul). CATIA le

permitirá editar datos en 3D (diseñar, estructurar…) y publicar los cambios en la base de

datos del servidor.


61

Figura 24. Interfaz CATIA V6.

Los elementos que aparecen numerados son:

1 Árbol 2 Barra de herramientas 3 Brújula 4 La barra 5 El robot

El árbol muestra toda la estructura de nuestro producto y las piezas que lo componen.

La barra de herramientas proporciona todas las herramientas de CATIA para la realización de

nuestro proyecto.

La brújula le permite un acceso instantáneo a la información de PLM en cualquier momento y a

cualquier objeto. La brújula está presente en cualquier ventana de un documento y está

compuesta de 4 cuadrantes (Norte, Sur, Este y Oeste).

Norte Información del Personal.

Este Información de Relaciones.

Oeste Información de Forma.

La Barra proporciona un acceso rápido a diversas herramientas: Buscador de datos, Búsqueda

de impactos o modificaciones, colaboraciones con otras personas, guardar las modificaciones en

la base de datos…

Con el robot podemos mover, girar y voltear en los diferentes ejes el escritorio con todas las

piezas que se estén mostrando. Esto facilita la comprensión y visualización de las diferentes

piezas.

3.3.5 Plataforma de estudio de modelado ENOVIA (DTE).

Adapta y personaliza la implementación de ENOVIA para cumplir únicamente con las

necesidades requeridas de negocio y así mantener ventajas competitivas.


62

Un departamento centralizado y un servidor de testeo puede ser cargado con ENOVIA y también

software third-party (terceros, software libre) usado en el sistema de producción. Además el

software third-party puede ser usado para simular la red de producción y el rendimiento del

servidor (si se utiliza en múltiples instancias, se necesita una licencia para cada una de ellas).

Uno o más entornos “sandbox” (areneros) pueden ser creados por los miembros del equipo de

implementación. Esto les permite a ellos desarrollar y probar cambios específicos en las

funcionalidades estándar del producto sin afectar a la producción. Los cambios están integrados

en el departamento central de desarrollo y en el servidor de pruebas para después ser aplicados

a la producción (cada “sandbox” debe tener una licencia personal).

Las herramientas de modelado gráfico permiten a los desarrolladores realizar cambios de

manera fácil y dinámica, en el comportamiento, en los datos de los elementos y en la apariencia

de la interfaz del usuario de los procesos de negocios.

La plataforma de modelado ENOVIA es un software cliente/servidor compuesto de los

siguientes componentes:

- Sistema de administración ENOVIA: usada para llevar a cabo actividades

relacionadas con la configuración y mantenimiento de los lugares de

almacenamiento de la base de datos.

- Modelador de negocios ENOVIA: se usa para construir el modelo de datos con los

objetos usados, con sus atributos, las reglas de procesos y las personas asociadas a

estos objetos.

- Navegador matricial ENOVIA: usado para crear instancias específicas de los

objetos que han sido definidos en el estudio de modelado.

- Estudio MQL ENOVIA (Matrix Query Language): actúa como una interfaz de

comandos dirigida a todos los componentes anteriores. Ayuda al administrador de

sistema o de negocio, realizando pruebas y puestas a punto de la base de datos de

manera rápida y eficiente. También puede ser usado con el estudio de modelado

para crear programas personalizados.

3.3.6 Componentes del servidor ENOVIA V6.

Se presentan algunos de los componentes de la estructura del entorno ENOVIA V6:

Live Collaboration Server (MCS): proporciona la lógica de negocio y el acceso web.

File Collaboration Server (FCS): gestiona el contenido y el flujo de datos de

almacenamiento.

Database Server (DB): se encarga del almacenamiento de metadatos.

DS License Server (DSLS): es el servidor de licencias de internet.

Estos servidores son requisito indispensable para ENOVIA V6, los siguientes serían

opcionales:

3D Indexing Server (3DX): recuperación acelerada de datos 3D.


63

Full Text Search Server (FTS): recuperación acelerada de datos de texto.

3rd Party Real-Time Collaboration Server (RTC): colaboración instantánea con las

aplicaciones de nuestros clientes.

Ventajas de esta infraestructura:

Única base de datos como "una fuente de la verdad", aislada de la interacción directa de

los usuarios.

Reducción de costes al habilitar la arquitectura de componentes.

Arquitectura modular diseñada para una ampliación futura.

ENOVIA V6 tiene una arquitectura que proporciona una gran flexibilidad al usuario en función del

tipo de trabajo y los requisitos técnicos que le vayan a ser necesarios, desde un entorno de

demostración, a uno de entrenamiento, a otro de prueba de conceptos o hasta el de producción

de un prototipo.

3.3.7 Esquema ENOVIA.

La plataforma de estudio de modelado ENOVIA engloba cuatro módulos de software diferentes:

Navegador ENOVIA.

Estudio de modelado de negocio.

Gestor de sistema ENOVIA.

Cliente MQL (MQL = Matrix Query Language).

Estos 4 módulos representan diferentes herramientas, aunque todas ellas accedan a la misma

información de la base de datos. Normalmente estos módulos están reservados a los

Administradores de Negocio, de Sistema y Usuarios Finales autorizados que tienen tareas

específicas administrativas.

ENOVIA Matrix Navigator: es la herramienta original del Usuario Final en un

entorno no-web. Proporciona la gestión de los objetos de negocio y sus

archivos. Proporciona un comienzo directo con el software de las empresas

subcontratadas. No necesita derechos administrativos y además proporciona

acceso y funcionalidad basada en el modelo de datos preparado por el

Administrador de Negocio.

Business Modeling Studio: es la herramienta donde los datos del modelo son

creados, modificados y mantenidos. Los objetos que componen el modelo de

datos se denominan “Objetos Administrativos”. Las personas que accedan al

Modelador de Negocio deben ser Administradores de Negocio. El Administrador

de Negocio define los pre-requisitos de trabajo de los usuarios finales. El

Administrador de Negocio solo puede definir y permitir el acceso de los usuarios

finales a los Objetos de Negocio.

ENOVIA System Manager: como el Modelador de Negocio, la herramienta de

Gestión del Sistema oferta Objetos Administrativos. Estos objetos se refieren a


64

una administración arquitectónica que engloba la comunicación entre ENOVIA y

la base de datos, esto incluye el almacenamiento de datos, metadatos y

archivos. Las personas que trabajan con el Gestor del Sistema deben ser del

tipo Administrador de Sistema. Hay una clara diferencia entre el

Administrador de Negocio que toma parte en los datos del modelo y el

Administrador de Sistema que toma parte en asuntos del entorno y la

arquitectura.

MQL Client: es una herramienta de comandos, donde el usuario puede utilizar

comandos MQL. Los usuarios que pueden acceder dependen de la definición de

usuario que tengan asignada. Es posible realizar las mismas acciones en el

MQL Client que en los otros módulos, pudiendo crear objetos administrativos y

de negocio o incluso cambiar alguno de estos tipos de objetos. Uno de los usos

más importantes de MQL Client es extraer información de la base de datos. Esta

información puede ser extraída como información ad-hoc o se puede poner en

un formato de archivo. También es posible exportar e importar objetos desde y a

la base de datos, se puede importar/exportar solo objetos seleccionados con un

criterio definido específicamente, o también exportar/importar bases de datos

enteras incluyendo los modelos de datos enteros y los objetos de negocio.

3.3.8 Caja de herramientas ENOVIA (ADT).

La caja de herramientas ENOVIA (ADT) permite una incorporación de datos sin costuras, desde

los sistemas de la empresa al sistema PLM ENOVIA. Las siguientes capacidades son posibles:

- Leer datos de otros sistemas de la empresa, como si estuviesen almacenados desde

siempre en ENOVIA.

- Opcionalmente se puede escribir a otros sistemas de la empresa desde la interfaz

de usuario de ENOVIA.

- Ampliar datos a partir de otros sistemas de la empresa con el “procesado de datos

de negocio colaborativo” ENOVIA.

- Migrar datos de la empresa durante un tiempo a ENOVIA como parte de un proceso

de gestión de negocios o realizar una subida de datos masiva a la red.

3.3.9 Analizador de esquemas ENOVIA.

Con el lenguaje UML podemos diseñar y definir extensiones del modelo de datos antes de

crearlas, y también crear informes del sistema. Los procesos de actualización al nuevo ENOVIA

liberan y reconcilian las diferencias de esquema, simplificándolas usando el informe automático

de comparación.


65

El generador de informes de esquemas es fácil de usar y rápido, ahorrándole al administrador

grandes cantidades de tiempo.

3.3.10 Servicios de Procesos de Negocio (Business Process Services - BPS).

BPS proporciona una interfaz de usuario configurable, un esquema y opciones que son usadas

en todos los productos ENOVIA, como colecciones, discusiones, gestión de documentos y

perfiles de compañías.

También permite la colaboración de usuarios internos y externos (tales como proveedores),

mientras mantiene controlado el acceso a los datos, y proporciona métricas de capacidad de

informes para evaluar el desempeño sobre la base de datos del producto.

BPS combina las siguientes aplicaciones (que antes se separaban por entidades):

Application Exchange Framework.

Common Components.

Team Central.

Business Metrics.

Es una combinación de elementos tales como tablas, formas, diálogos de búsqueda comunes,

etc. El esquema común permite a todas las aplicaciones coexistir y compartir datos. El esquema

consiste en instancias de objetos de negocio, relaciones y atributos. BPS incluye el código de

programación Java necesario para manipular el esquema predefinido.

3.3.11 JSP, JAVA BEANS and JPOs.

JSP – Java Server Pages proporcionan un método simple de programación para mostrar y

actualizar el contenido de la página web. JSP se ha convertido en una herramienta que sustituye

a los servlets ya que codificar en JSP es más simple que codificar un servlet. JSP combina

HTML, JavaScript y código Java.

JPO – Java Program Object es otro tipo de objeto de programa que contiene código escrito en

lenguaje JAVA. Los JPOs facilitan echar a correr programas Java nativos dentro del kernel, sin

crear un proceso separado y con la integración de un objeto-orientado verdadero que se opone a

trabajar en MQL.

Java Beans: JavaBeans encapsula la lógica de negocio que de otra manera podría aparecer en

una JSP.


66

3.3.12 Application exchange framework.

La Application Exchange Framework (AEF) nos muestra cómo empezar a usar los Servicios

de Procesos de Negocio (BPS) y los productos ENOVIA.

Interfaz de usuario:

La página pedirá registrarse al usuario y si no está todavía registrado presentará la

página de registro. La aplicación utilizará la información para mostrar las opciones según

el rol permitido y toda la información de la empresa a la que tiene acceso, además solo

podrá trabajar en los artículos que tiene permitido.

Si la empresa utiliza Contexto de Seguridad, se debe especificar los detalles de registro

después de elegir el contexto. La ventana del Contexto de Seguridad se mostrará

solamente si el usuario tiene más de un contexto asignado a su perfil.

Navegación: este campo proporciona las diferentes herramientas para navegar por la

información que el usuario precise.

Buscador: este campo ayuda a buscar diversos objetos utilizando la “Búsqueda

Avanzada”.

IconMail: los mensajes con productos ENOVIA son llamados IconMail. Este campo

permite el envío de notificaciones y mensajes por usuarios que no utilicen otro tipo de

sistema de email externo.

Los componentes comunes incluyen herramientas que son comunes para muchos productos de

ENOVIA. Entre ellos se incluyen:

Gestión de perfiles comunes.

Rutas y tareas, y plantillas de ruta.

Gestión de documentos comunes.

Subscripciones.

Discusiones.

Flujos de trabajo (workflows).

Gestión de problemas.

Lista de miembros.

Búsqueda de archivos comunes.

Piezas y familia de piezas.

Cambios de ingeniería.

Gestión de imagen.

Primero, como se va a representar una empresa, es necesario definir la Organización de la

Empresa usando los Componentes Comunes como:

Compañía.

Unidades de Negocio.

Departamentos.

Localizaciones.

Plantas.


67

Regiones.

También se deberá definir las “Collaboration Partners” (compañías con las que la

organización lleva a cabo los negocios) y las “Supplier Companies” (proveedores).

Otros componentes comunes que son necesarios para el usuario de ENOVIA son:

Decisiones: usados para racionalizar la creación o existencia de requisitos u otros

objetos o documentos para una reunión planeada o una cita.

Relaciones: utilizada para crear y gestionar citas como piezas de tu equipo de

colaboración.

Seguimiento de problemas: usado para informar sobre problemas de productos

específicos, proyectos, piezas, u otros objetos de negocio.

Rutas: es un conjunto de tareas que se necesitan para completar una actividad de

negocio. Las rutas pueden tener un contenido que ayude a los miembros de la ruta a

completar sus tareas asignadas.

Piezas: es el término genérico para referirse a cualquier cosa de la empresa que pueda

fabricar o mantener en inventario. Una pieza puede ser un simple componente o un

ensamblaje de piezas.

Familia de piezas: suele ser un grupo de series de piezas que tienen parecida función

general, arquitectura similar e incluso componentes comunes.

El ENOVIA Live Collaboration Team ayuda a completar los proyectos más rápido y con una

eficiencia mayor por la unión de los diferentes usuarios, que pueden estar dentro o fuera de la

empresa, además su aporte es crítico en la finalización del proyecto. Por ejemplo el Project

Leader puede usar las opciones de “Equipo” para crear un entorno de trabajo, donde los

miembros de su equipo pueden reunir todos los objetos relacionados con el proyecto.

Un entorno de trabajo “Workspace” es una colección de carpetas que contienen los documentos

y demás informaciones necesarias para llevar a cabo las necesidades particulares de negocio.

También da el acceso a las personas de varias organizaciones, que necesitan acceder al

contenido de las carpetas.

Un entorno de trabajo puede proporcionar:

Personas.

Roles (todas las personas de la empresa que se le asigna un rol pueden acceder al

entorno de trabajo).

Sourcing Central Buyer Desk (todos los compradores asignados a la tienda de clientes

pueden acceder al entorno de trabajo).

Los miembros del equipo pueden suscribirse a:

Cambios en el entorno de trabajo.

Rutas.

Carpetas y sub-carpetas.

Archivos.

Archivos de Discusiones y respuestas a mensajes.


68

3.3.13 Tipos de datos en ENOVIA V6.

ENOVIA V6 tiene tres tipos de datos:

o Metadato: un metadato describe un objeto de negocio y sus relaciones. Está

almacenado en la base de datos.

o Contenido: se refiere a los archivos físicos y la geometría almacenada en el servidor de

archivos (FCS – File Server).

o Índice: los índices aceleran el acceso a los datos que se acceden mediante 3D Index

Server y el Full Text Search Server.

3.3.14 Qué es un metadato.

Un Metadato es un dato estructurado que describe las características de un objeto en la

base de datos. Un registro metadato consiste en un número de atributos del objeto

específico.

Podemos comparar el concepto de metadato con el catálogo de una librería. En el catálogo

aparece el título, autor, fecha de publicación, código de identificación… al igual ocurre con un

metadato asociado a un objeto. La ventaja de los metadatos es el aumento de la velocidad

en el proceso de búsqueda.

3.3.15 3D XML.

Los archivos 3D XML exportados usan dos opciones: “Redacción” y “Revisión”.

Para “Redacción”: (Se utilizaría la ventana de redacción, ventana azul de CATIA) Se exportaría

el archivo 3D XML de la base de datos al ordenador del usuario. Podría almacenarlo o enviarlo

por email o por la red. Importando el archivo 3D XML se podría importar a la base de datos de

CATIA V6 o se podría editar en V6 en el entorno de redacción.

Para “Revisión”: el archivo 3D XML se puede insertar en una página HTML o en un archivo

WORD.

Es posible buscar archivos 3D XML en la base de datos introduciendo las palabras contenidas

en el nombre del archivo.


69

3.3.16 Introducción a la solución “Imagina&Crea” (Imagine&Shape Solution -

IMS).

¿Qué es IMS?

El principal objetivo de IMS es convertir los dibujos de estilo en 2 dimensiones en formas en 3D.

El diseñador deforma una bola de arcilla virtual, la manipula y refina la textura a través de

rotaciones, translaciones, escalas y subdivisiones de superficies hasta llegar al estilo deseado.

Además los diseñadores pueden crear interactuando modelos reales para una validación.

La solución IMS consiste en:

FSK Freestyle Sketch Tracer: para importar dibujos de diseño 2D de estilo a CATIA.

IMA Imagine and Shape: se puede utilizar para crear rápidamente complejas formas

estéticas utilizando las subdivisiones de superficies.

RTR Real Time Rendering: para crear imágenes de representación realistas.

¿Qué es una subdivisión de superficie?

Es una técnica algorítmica que permite generar una superficie lisa a partir de una secuencia

sucesiva de refinamiento mediante mallas de poliedros. La subdivisión de algoritmos es simple,

ellos trabajan de manera arbitraria sobre el control de las mallas y producen superficies lisas. Se

pueden introducir características en la superficie realizando elecciones especiales en las reglas

de subdivisión.

Trazador de bocetos.

El trazador de bocetos se utiliza para importar los dibujos del estilista al mundo 3D. Usando este

producto puede convertir imágenes 2D en escenarios 3D para crear elementos 3D con sus

propios bocetos, incluso con otras imágenes.

Diseño de ensamblaje.

Con esta opción puede hacer el diseño del ensamblaje de las diferentes piezas de nuestro

producto en un entorno versátil y flexible.

Simulación de cinemática.

Esta simulación permite con un conjunto de herramientas simular los movimientos del

mecanismo ensamblado.

Parte de Modelado Funcional.

El objetivo del modelado funcional es permitir a los diseñadores de producto enfocarse en los

objetivos funcionales y diseñar las restricciones de sus productos.

Redacción.

La redacción proporciona funciones para generar dibujos de las piezas 3D y las definiciones de

su montaje.

Vista de diseño (DesignSight).


70

La introducción a productos SIMULIA en plataforma V6 con la estructura Vista de Diseño permite

a los diseñadores realizar una simulación real robusta. La gama de productos es determinada

por la comunidad de diseño y realizar la simulación no requiere una extensa experiencia.

Programación de Maquinaria.

En este apartado generaremos el programa de control numérico para fabricar el producto. El

mecanizado prismático nos permite definir y gestionar los programas de control numérico

dedicados a mecanizar partes diseñadas en entornos 3D o geometrías sólidas usando técnicas

de mecanizado de 2.5 ejes.

3.3.17 Integración con CATIA V6.

Las aplicaciones propias de V6 (CATIA, DELMIA y SIMULIA) están construidas en una

arquitectura con una gestión de datos comunes. Estas aplicaciones están ya integradas en el

entorno de ENOVIA V6.

Podemos realizar las siguientes operaciones directamente desde CATIA V6:

Gestionar la autorización de la sesión y los datos V6 (Nuevo, Abrir, Propagate (guardar),

editar atributos, ingeniería concurrente…).

Gestión del ciclo de vida (madurez, bloqueado/desbloqueado, transferencia propia,

duplicar, borrar, nueva versión…).

Gestión de documentos (obtener archivos desde Windows, adjuntar documentos a los

datos PLM).

Acceder a la EBOM (requiere las licencias de ENOVIA Engineering Central (ENG) o la

ENOVIA Team BOM Editor (TBE)) para navegar, comparar y generar los datos de la

EBOM.

Importar y exportar datos V6 en archivos de formato 3D XML.

3.4 Conexión a V6.

3.4.1 Conectarte a V6.

Cuando inicia V6, se le pedirá al usuario registrarse en un servidor. Para ello deberá rellenar los

siguientes campos:

- Nombre del Servidor.

- Usuario y contraseña.

- Contexto de seguridad. Seleccionará el ámbito en el cuál trabaja.


71

3.4.2 Contexto de seguridad y roles.

En V6, el acceso a los datos de la organización y las características de aplicación se basa en

torno al rol que tiene asignado cada usuario. En V6 Academia hay predefinidos una serie de

roles por defecto: Administrador de proyecto, Líder de proyecto, Creador, Experimentador

y Espectador.

La combinación del rol, la empresa y el proyecto conforman el “Contexto de seguridad”.

Es obligatorio seleccionar un contexto de seguridad para registrarnos y conectarnos a la

base de datos V6. Por ejemplo: la persona con atribución “Creador” está registrada en “Mi

Empresa” para el proyecto “Dis_V6”. Él sólo tendrá acceso en esta combinación).

Figura 25. Ejemplo de acceso a los datos de la organización. Contexto de seguridad.

A continuación se realizará una presentación de los diferentes roles:

Observador o Espectador: el usuario con el rol de Observador tendrá acceso a las

definiciones de diseño y evaluación. Puede crear objetos como carpetas y favoritos.

Probador o Experimentador: Evalúa el diseño, pero no lo puede cambiar. Crea

objetos como revisiones de la maqueta digital (DMU) y simulaciones de FEA.

Creador: es el usuario encargado de realizar el diseño. Gestiona objetos tales como el

producto, las partes 3D, el dibujo, documentos, contexto PPR y definiciones cinemáticas.

Líder del proyecto: Gestiona los recursos de diseño. Gestiona tanto los materiales, el

catálogo, la plantilla PLM, las piezas o familias de piezas y los guiones.

Administrador de proyecto: Puede modificar los datos publicados. Puede realizar la

modificación de atributos, de representaciones (Objetos 3D, dibujos…).

3.4.3 Guardar nuestro proyecto.

Existen dos opciones para guardar el proyecto: “Propagate” y “Local Save”:

- Propagate: con esta operación se guardarán los datos (de la sesión activa) en

la base de datos PLM.

- Local Save: esta función guarda los datos (de dicha sesión) en el propio

ordenador del usuario.


72

3.4.4 Modelo de datos y Acceso.

Es posible acceder a los datos de tres formas diferentes:

- Interfaz Web: a través de la interfaz web se puede acceder a los procesos de

producción, de gestión de los proyectos y de liberación.

- Ventana de Navegación: es una ventana de visualización, se usa para buscar,

revisar y compartir datos 3D.

- Ventana de Edición: en la ventana de edición se puede crear y modificar los datos en

3D.

Todas estas interfaces acceden a la misma base de datos. Las ventanas de edición y

navegación necesitan una instalación del cliente.

3.5 Centrales ENOVIA.

3.5.1 ENOVIA Program Central.

El programa Central de ENOVIA es una herramienta de gestión del proyecto que permite crear

programas y proyectos, y almacenarlos en la base de datos. También permite modificar esos

objetos, definir y modificar tareas, asignar tareas a los miembros del proyecto, y promover las

tareas a los niveles superiores para su aprobación. Además permite tener una visión del

proyecto y la información asociada a él para monitorizar su progreso.

El programa central ENOVIA (botón verde esquina superior izquierda) se utiliza para la gestión

de los proyectos. Proporciona una visión en tiempo real de todos los proyectos. La información

se puede gestionar a través de enlaces directos a los procesos productivos, documentos y otros

datos.

El Programa Central ENOVIA permite:

Gestionar el coste del proyecto, los beneficios y riesgos.

Tener accesos directos a los proyectos para activar los procesos productivos.

Eliminar los informes de estado realizados de manera manual, propensos a errores.

Aumentar el aprendizaje mediante plantillas reutilizables.

El Programa Central simplifica los esfuerzos en la gestión de los proyectos de diversas formas:

Las plantillas de proyectos dinámicos se pueden crear en base a las respuestas de las

preguntas predefinidas.

La distribución automática de tareas y rutas para una revisión en la finalización del

proyecto.


73

Las tareas y entregables están asignadas y gestionadas completamente con el

programa. De esta forma, el seguimiento del estado de la tarea es siempre en tiempo

real.

Los informes de estado contienen detalles de todo el proyecto. Para ello no es necesario

actualizar el proyecto por separado.

Los documentos son comprobados y gestionados en el sistema con las tareas.

Los foros de discusión pueden ser configurados para compartir comentarios entre todos

los revisores.

La integración de Microsoft Project con el Programa Central ENOVIA puede ayudar de manera

significativa la agilización de la gestión del proyecto.

3.5.1.1 Detalles del programa central ENOVIA.

Programa: es el proyecto o requisito fundamental a cumplir con toda la serie de sub-requisitos.

También tiene otra acepción que lo define como una colección de proyectos.

Proyecto: es una colección de tareas que se deben realizar para lograr un objetivo. Existen dos

tipos de proyecto: Concepto de proyecto (o proyecto preliminar) y Proyecto.

Ruta: una ruta es un conjunto de tareas específicamente definidas para un grupo de personas.

Estructura de desglose de trabajo (“WBS – Work Breakdown Structure”): es la jerarquía de

tareas y sub-tareas que se requieren para completar el proyecto.

Asignación de tareas: cada tarea en la estructura de desglose de trabajo se asigna a una

persona que puede o no ser miembro del proyecto. Estas asignaciones permiten:

- Ver las tareas y las relaciones entre tareas.

- Añadir o quitar sub-tareas de las tareas asignadas.

- Crear rutas ad-hoc en las tareas.

- Delegar las tareas en otro miembro del proyecto o alguien de la empresa.

Tarea entregable o Entrega: una entrega es un documento o un objeto añadido a la WBS que

contiene una tarea a completar. Pueden ser piezas, dibujos, informes o cualquier objeto que

necesita ser creado o completado.

Dependencia de la tarea: las tareas son interdependientes. Existen cuatro tipos de

dependencias:

- FS – “Finish to Start”: la siguiente tarea no puede comenzar antes de que la tarea

anterior finalice.

- SS – “Start to Start”: la siguiente tarea no puede comenzar antes de que la anterior

empiece.

- FF – “Finish to Finish”: la tarea siguiente no puede finalizar antes de que la previa

haya finalizado.

- SF – “Start to Finish”: la tarea siguiente no puede finalizar sin que antes la tarea

previa haya comenzado.


74

Riesgo: un riesgo identifica un problema potencial que puede alterar o dificultar la realización del

proyecto o de una tarea.

Cuadro de mandos “Dashboard”: en la realización del proyecto, los miembros de la gestión

pueden acceder al cuadro de mando del proyecto para tener una vista detallada de todas las

tareas y del estado de desarrollo de cada una de ellas.

El cuadro de mandos visualiza la siguiente información:

- Estado del proyecto: indica el estado actual del proyecto.

- Desliz de días: indica el número de días que el proyecto tiene de retraso.

- Estado de tareas – código de color. Indica el estado de la tarea:

o Rojo: la tarea está retrasada.

o Amarillo: la tarea va a incurrir en un retraso.

o Verde: la tarea ha sido completada.

Foros de discusión: los miembros del proyecto pueden participar en las discusiones sobre

cualquier punto relacionado con el proyecto. El usuario puede escribir mensajes, ver mensajes

de otros miembros del proyecto y responder a los mensajes.

Financiación del proyecto: todos los proyectos tienen asociados costes y beneficios. Es

posible adjuntar un presupuesto al proyecto y realizar un seguimiento del presupuesto a medida

que el proyecto avanza.

3.5.2 Introducción a la Central de Ingeniería ENOVIA.

La Central de Ingeniería es una aplicación que permite a los usuarios colaborar y gestionar los

procesos de cambios de ingeniería. Esto permite la gestión de BOM de manera funcional,

reduciendo la necesidad de un departamento de producto y se incrementa la innovación.

La Central de Ingeniería ENOVIA hace fácil a los diseñadores y a los ingenieros de diseño la

creación, revisión y eliminación de piezas y sus modelos asociados CAD, dibujos y otra

documentación técnica. La Central de Ingeniería ENOVIA además permite la gestión del

contenido del producto y la gestión de cambios de ingeniería con un sistema de seguridad.

Se promueve el modelo de negocio DAMA (Design Anywhere, Manufacture Anywhere) que

proporciona al usuario final un entorno de trabajo virtual con un fácil acceso a: el producto,

información/contenido de la pieza, cambios de ingeniería en piezas y procesos.

El modelo DAMA elimina de manera significativa barreras en los procesos y datos de

comunicación que existen entre las diferentes disciplinas de ingeniería (mecánica, electrónica,

informática…).

La Central de Ingeniería permite a la empresa la gestión de los siguientes procesos de negocio:

- Gestión de piezas, familias de piezas, listas de materiales (BOMs).

- Gestión de dibujos/bocetos asociados a piezas.

- Gestión de cambios en piezas, BOMs y bocetos con ECRs y ECOs.


75

- Piezas avanzadas y gestión de capacidades de BOM para una gestión y

combinación de software, electrónica e información mecánica del producto.

Los principios básicos de la interfaz de usuario en ENOVIA son las siguientes:

- Aplicación basada en web: como usuario final debe especificar la dirección del

servidor de ENOVIA en la ventana de un buscador de internet. La Central de

Ingeniería está basada totalmente en una página web, por tanto no es necesario la

instalación previa de ningún software ENOVIA.

- Inicio/Registro seguro: necesita un usuario y contraseña para conectarse al

servidor de ENOVIA. El administrador de la empresa es el responsable de crear los

perfiles de los usuarios y administrarles los derechos apropiados. El usuario tan solo

podrá acceder a las características y funciones que le hayan sido atribuidas a su

perfil de usuario.

- Interfaz de usuario simple: proporciona a la Central de Ingeniería una interfaz de

usuario sencilla y fácil de usar.

A continuación se presentan algunos de los beneficios de la Central de Ingeniería ENOVIA:

o Se incrementa la comunicación y colaboración con un desarrollo global de equipos

compartiendo recursos externos e internos.

o Proporciona la capacidad de gestión de Partes avanzadas y de listas de materiales.

o Seguimiento del desarrollo global del producto y de los cambios en los procesos.

La Central de Ingeniería permite generar diversos informes sobre EBOMs, ECRs y ECOs.

Algunos de ellos son:

ECR Summary Report: tiene una cabecera que muestra el nombre y la fecha de la ECR cuando

fue generada. Los usuarios con los siguientes roles pueden generar este informe: Ingeniero de

Diseño, Ingeniero de Diseño Senior, Ingeniero de Fabricación e Ingeniero de Fabricación Senior.

ECO Summary Report: tiene una cabecera que muestra el nombre y la fecha de la ECO cuando

fue generada. Los usuarios con los siguientes roles pueden generar este informe; Ingeniero de

Diseño, Ingeniero de Diseño Senior, Ingeniero de Fabricación e Ingeniero de Fabricación Senior.

BOM Compare Report: La estructura BOM compara funcionalmente dos montajes, basados en

parámetros específicos. Los parámetros pueden ser especificados para la comparación de los

diferentes montajes.

Los dos montajes siguientes pueden ser comparados:

- EBOM: La BOM en la vista de Ingeniería.

- MBOM: la BOM en la vista de la Planta específica.

Para generar el informe de comparación de BOM es necesario especificar un criterio de

comparación. Basado en este criterio, el informe será generado.

Engineering Effectivity Report: El informe de Efectividad de la lista de materiales proporciona

la habilidad de crear informes de históricos de BOMs. Este informe está basado en el histórico de

un usuario específico en una fecha determinada. Este informe está permitido solo para las piezas

de la empresa liberadas. El informe muestra la configuración de las piezas de la BOM basándose


76

en la última revisión liberada, que ha sido efectiva para un usuario específico en un momento

concreto.

Consolidated Report: muestra todos los artículos en la BOM basándose en el número de

niveles seleccionados mientras se realiza el informe. El resultado de la vista de la estructura

anidada es una lista que contiene el tipo, nombre y revisión de cada pieza y su cantidad. Este

informe es configurable.

Late Approvals Report: cuando se procesa la ECO o ECR activa, ocasionalmente puede estar

inactiva o estancada por problemas operacionales o logísticos no relacionados directamente con

la ECO o la ECR (por ejemplo, un aprobador de una ruta, tiene que aprobar una ECR y está

inactivo o de vacaciones). El ECR Coordinator puede generar un informe de todas las ECRs y

ECOs que tienen o que tendrán una aprobación tardía.

3.5.3 Central de Requisitos ENOVIA.

La Central de Requisitos es una herramienta de gestión de cambios que permite crear y

mantener requisitos de cambios propuestos de los productos. Con esta central es posible

capturar e importar los requisitos desde unas especificaciones externas, trabajar con informes de

trazabilidad relacionados con las especificaciones de los requisitos y gestionar las decisiones

tomadas en base a esos requisitos.

Los requisitos del producto describen las características que el producto debe contener.

Los parámetros están definidos en los requisitos del producto, desde el diseño hasta la solución

del producto.

La representación del cliente o de marketing es la responsable de trasladar los resultados de los

estudios de marketing a los requisitos del cliente para después implementarlos a los requisitos

del producto.

TERMINOLOGÍA:

1. Especificación de requisito: la especificación de requisitos permite a los documentos

de requisitos ser gestionados en cuanto los requisitos son detectados. Esto ayudará a

través de las actividades que se deberán realizar en el proceso de producción. Existen

filtros para acceder a las especificaciones más fácilmente de los procesos que están

Activos, Aprobados y Obsoletos.

2. Gestor de especificaciones: proporciona una vista de la estructura, esto permite

trabajar con las especificaciones, componentes, comentarios, requisitos.

3. Editor del contenido de la estructura: es un editor de texto que permite abrir las

especificaciones de requisitos y editar los textos correspondientes a la estructura de las

especificaciones.

4. Requisitos: son concebidos para proporcionar cambios o adiciones al hardware o

software del producto. Se crean para añadir información de necesidades del producto.

Es el punto de partida a analizar para la creación de un producto. Son creados por el


77

Requirement Manager con la ayuda de la información de entrada de la definición de

producto. Los requisitos son el punto de partida para analizar una solicitud.

5. Sub Requisitos: elabora algunos aspectos de los requisitos originales. No proporciona

ninguna información nueva, solo realiza aclaraciones de la información ya dada.

6. Requisito derivado: no proporciona una nueva información. Esta información es

derivada de los requisitos originales.

7. Capítulos: un capítulo es una aplicación que está instalada en MS Word o MS Excel

para capturar e importar requisitos de un documento de especificaciones externo.

8. Casos de prueba: es un conjunto de entradas y resultados esperados que al realizar

ejercicios del componente determinan si hay errores o fallos.

9. Casos de uso: son documentos que describen el uso funcional de un objeto, son

creados y adjuntados a los casos de prueba y los requisitos.

10. Captura de requisitos: es una aplicación para importar requisitos de un archivo de

especificaciones externo como Word o Excel.

El modo de prueba es una simple acción de prueba al objeto creado para testearlo. Esto

permitirá detectar errores y fallos. Está pensado para corregir cambios, casos de uso,

requisitos…

La Central de Requisitos ENOVIA permite realizar los siguientes Informes de Trazabilidad:

o Informe de trazabilidad requisito-requisito: permite la trazabilidad desde los niveles

inferiores de requisitos hasta los niveles superiores.

o Informe de trazabilidad requisito-caso de prueba: proporciona una trazabilidad de los

requisitos que han sido probados y están asociados, verificados y validados.

o Informe de trazabilidad de requisito lógico-requisito funcional: los requisitos pueden

ser usados en el Editor Funcional VPM ENOVIA y ser emparentados a los sistemas de

elementos lógicos y funcionales.

o Informe de trazabilidad característica-requisito: puede informar de dos maneras

diferentes: un informe en el que aparecen los requisitos con las características y unidos

por los productos, o también, un informe en el que aparecen los requisitos con todas las

características y productos.

Los requisitos Candidatos son los requisitos de un nuevo producto, que está como Modelo

y que tiene la intención de convertirse en un producto específico.

3.5.4 Central de Variaciones de Configuración ENOVIA.

La Central de Variaciones de Configuración ENOVIA se centra en la configuración de la

introducción de un nuevo producto. Establece la plataforma de los sistemas de ingeniería para

optimizar el proceso de diseño de productos con altas variabilidades. La Central de Variaciones

de Configuración ENOVIA ayuda a la empresa a introducir al mercado nuevas variantes de forma

más rápida, basadas en las necesidades de los clientes y la innovación tecnológica.


78

Generalmente la primera acción que toma el Departamento de Marketing es hacer uso de la

Central de Variaciones de Configuración definiendo características de marketing en las líneas de

producto. Cuando las características de marketing están definidas, el Manager de Producto

define la estructura del producto, las opciones de marketing y las reglas de configuración.

Tras realizar todo el trabajo preliminar, el Manager de Producto genera diferentes variantes del

producto y configuraciones del producto usando las reglas y características definidas.

3.5.4.1 Central de Variaciones de Configuración ENOVIA – Detalles.

Características de Marketing: estas son las características de un producto que son posibles

para un cliente:

- Es preferible crear tantas características de marketing a nivel de línea de producto

como sea posible, para reducir la proliferación de características en el diseño de

producto.

- La estructura de características de marketing es una representación jerárquica de las

características del producto.

Características Técnicas: es la lista de posibles características de diseño para cumplir con la

selección de características de marketing.

- La estructura de características técnicas es la representación conceptual/técnica de la

BOM de un Producto. Todas las variaciones de diseño posibles están recogidas en

esta estructura.

- Por último las características técnicas están implementadas con piezas reales y son

utilizadas para generar la EBOM.

Reglas de Configuración: son definidas según diferentes características:

- El departamento de Marketing normalmente se centra en las reglas de configuración

de marketing relacionadas.

- El Sistema de Ingeniería mantiene las reglas de configuración técnicas de ingeniería

en el nivel base del producto.

Las siguientes reglas de tipo de configuración pueden ser conectadas con el nivel de Línea de

Producto (reglas de marketing):

- Reglas de configuración de compatibilidad: define las relaciones de compatibilidad.

- Preferencias de Marketing: define las posibles opciones de características en la

configuración de un producto.

- Recursos: limita el número de opciones ordenadas.

- Extensión de reglas: son validaciones globales para buscar posibles flujos.

Las siguientes reglas de configuración pueden ser conectadas con el nivel de Producto (reglas

técnicas):

- Compatibilidad.

- Compatibilidad del producto.


79

- Extensión de reglas.

- Inclusión.

Variantes de diseño: son las especificaciones de diseño utilizadas para definir la variación de

las características técnicas. Por ejemplo, si las características técnicas son un sistema de

sonido, las variantes de diseño pueden incluir el reproductor de CD o la radio FM/AM.

Variante de Producto: permite al Manager de Producto y al equipo de Ingeniería pre-configurar

o minimizar la variabilidad y controlar el número de configuraciones posibles. Una variante de

producto representa un modelo base que ha sido configurado parcialmente para contener

capacidades específicas.

Matriz de efectividad de producto: permite la selección de características en base a una matriz

que contiene múltiples productos, usando el criterio de Standard (S) u Opcional (O).

Configuración de Producto: es la vista comercial de un producto que contiene una única lista

de características, sub-características (opciones) y cantidades.

La interfaz de Configurador de Producto se utiliza para crear una nueva Configuración de

Producto. Cuando las opciones de marketing son seleccionadas, todas las reglas de

configuración asociadas a la opción seleccionada son evaluadas inmediatamente (regla de

procesado dinámico).

Una vez validado, dos tipos de BOMs pueden ser generadas desde el Configurador de Producto:

- EBOM: puede ser generada desde el configurador de Producto en cualquier estado.

Representa la implementación física de las características técnicas seleccionadas

para la configuración del producto.

- PBOM (Precise Bill of Materials): solo puede ser creada en el estado de Configuración

validada en el configurador de producto. Es la lista de todas las piezas/productos

necesarios para realizar la Configuración de Producto.

Los productos y sus configuraciones creados en la Central de Variantes de Configuración

ENOVIA pueden ser publicados en ENOVIA VPM.

3.5.4.2 Publicación de configuraciones en ENOVIA VPM.

Existen dos formas de publicar en ENOVIA VPM:

- Primera forma: Estructura resuelta.

El objetivo es gestionar la configuración de procesos en ENOVIA Variant

Configuration Central; la configuración de producto y las EBOMs que son

creadas en ENOVIA Variant Configuration Central. Después solamente la

EBOM es publicada en ENOVIA VPM V6.


80

Figura 26. Publicación con estructura resuelta.

- Segunda forma: Estructura Configurada.

El objetivo es la gestión del conjunto de configuraciones bajo la

responsabilidad de ENOVIA VPM V6.

Figura 27. Publicación con estructura configurada.

3.5.5 Central de Librerías ENOVIA.

Una vez que las piezas han sido creadas es posible almacenarlas en librerías que pueden

usarse en diversos proyectos. Es una aplicación para reusar las librerías y reducir el tiempo de

salida al mercado.

La Librería Central proporciona 4 objetos con relaciones entre ellos que simula una biblioteca

electrónica.

- Documento de librería: son los objetos que están en el nivel superior de la jerarquía.

- Estanterías: son conectadas con la librería y con colecciones de libros con tópicos

relacionados.


81

- Libros: conectados a la vez con las estanterías y también con grupos de documentos.

- Documentos: archivos electrónicos individuales.

Esta estructura se puede cambiar mediante el administrador de sistema según los requisitos de

la organización. Los objetos de negocio que son derivados de los tipos de documento pueden

ser accesibles a través de ENOVIA usando el gestor de documentos comunes (CDM).

3.5.6 Central de recursos ENOVIA.

Es una parte integrada a la aplicación de procesos de negocio ENOVIA. La Central de Recursos

ayuda en las peticiones de presupuestos de materiales directos y bienes de ingeniería. Una vez

que el producto ha sido diseñado, los compradores pueden enviar peticiones de presupuesto a

los proveedores directamente usando la Central de Recursos ENOVIA.

Esto nos permite que el cliente tenga una visión mayor de nuestra organización, un aumento de

peticiones agregadas de otros productos y su compra e incluso la formalización de contratos de

compra, además de aumentar la capacidad de respuesta del proveedor sin imputar costes

adicionales operativos.

3.5.7 Central de presupuestos ENOVIA.

La central de presupuestos ENOVIA permite a los proveedores de una empresa participar en la

negociación electrónica. De esta forma los proveedores pueden evaluar la contraoferta y

rápidamente responder a las oportunidades de los clientes.

Esto es una aplicación de gestión que forma parte de la Gestión de Relaciones de Proveedores

de ENOVIA (SRM – ENOVIA Supplier Relationship Management) para ayudar en el desarrollo de

las solicitudes de presupuesto.

3.5.8 Central de Proveedores ENOVIA.

La Central de Proveedores ENOVIA es una solución colaborativa que facilita la información

compartida y un control de calidad entre los clientes y proveedores en un entorno seguro de

internet. Con la Central de Proveedores se pueden establecer las relaciones de colaboración con

los proveedores, para realizar una implementación de un mundo real y empresa-empresa.

La utilidad más destacada de esta central es la gestión del proceso de compra de una empresa.

La empresa puede gestionar el proceso de compra tanto para materias primas como para

materiales personalizados mucho más rápido y con un menor coste de efectividad.


82

La Central de Proveedores de ENOVIA proporciona dos roles primarios con conjuntos de reglas

diferentes que controlan el acceso a la información del sistema.

Comprador: personal de la empresa encargado al control de la compra de piezas.

Proveedor: personal de la empresa encargado de la organización de proveedores,

también llamado Representante de Proveedores o Ingeniero de Proveedores que

responde a las solicitudes de compra.

Algunas características adicionales de la central de proveedores:

Las personas de la empresa cliente, según sus roles asociados, pueden ver o gestionar

detalles acerca de los proveedores, piezas, informes de calidad de piezas, objetivos de

proveedores…

El cliente puede usar las funciones de gestión de calidad para controlar y gestionar la

calidad de las piezas proporcionadas por los proveedores.

El personal de la empresa proveedora, dependiendo de su rol, también puede ver y

actualizar las negociaciones e informaciones solamente de su propia empresa.

3.5.9 Central de Presupuestos ENOVIA.

Permite a los proveedores participar en la negociación electrónica y los procesos de petición de

presupuestos a la empresa, de esta forma los proveedores pueden responder de manera más

rápida a las oportunidades de los clientes.

3.5.10 Búsqueda Global.

El dominio de Búsqueda Global permite a las empresas aprovechar las capacidades de la

cadena de suministro en todo el ciclo de vida del producto y hacer que sus proveedores sean

una parte integrante del desarrollo de productos.

Aprovecha las capacidades de la cadena de suministro en todo el ciclo de vida del producto de

las siguientes formas:

Implementando una estrategia de “diseño para suministro” con procesos de búsquedas

de material directo repetitivo y estandarizado que proviene de la última información de

diseño para suministrar cambios.

Participar activamente en el desarrollo de proveedores mediante el diseño, la

implementación.


83

3.5.11 Gobernancia.

El dominio de la Gobernancia permite a las empresas el lanzamiento de las instrucciones de un

nuevo producto en toda la empresa a tiempo y dentro del presupuesto.

Esto permite a las empresas lanzar nuevos productos para:

1. Seguir y programar todos los aspectos de los procesos de desarrollo del producto en

tiempo real a la vez que se completa el trabajo.

2. Capturando la voz de los clientes para planear nuevos productos con el mayor impacto

de marketing.

3. Determinar el conjunto (mix) óptimo de productos para conocer la demanda y minimizar

los costes de ingeniería.

4. Asegurar que el desarrollo del producto cumple con las regulaciones jurídicas.

3.5.12 ENOVIA VPM.

La Central VPM ENOVIA está integrada y construida en una arquitectura de gestión de datos

común, con las aplicaciones propias de V6 (CATIA, DELMIA y SIMULIA).

Esto ayudará a escoger los productos de la tienda más rápido gracias a la colaboración

proporcionada por VPM Virtual Product Management, de productos complejos, procesos e

información de recursos.

La Central VPM ENOVIA gestiona el diseño, fabricación y simulación de la propiedad intelectual.

También permite reusar diseños mediante el catálogo de piezas, proporcionando revisiones y

validaciones de diseño, intercambios de información, reutilización de datos V4 y V5,

escalabilidad para todos los usuarios y los productos complejos gestionados.

Permite trabajar en tareas predefinidas de diseño, la suscripción a modificaciones de diseño y

estudiar el impacto del diseño, analizando y evaluando las alternativas potenciales y los cambios

que fuesen posibles.

En resumen, la Central VPM ENOVIA gestiona una gran cantidad de equipos de ingeniería con

un entorno sencillo de PLM.

Usando la Central VPM es posible:

Activar la colaboración de ingeniería multidisciplinar.

Acceder a la EBOM a través del VPM.

Evaluar los impactos de diseño de las modificaciones en tiempo real.

Seguir las modificaciones de diseño en tiempo real.

Gestionar las tareas de ingeniería.

Colaboraciones multifuncionales con otros usuarios de la empresa.

Acceso al catálogo de componentes de diseño para una rápida reutilización.

Realizar revisiones digitales.


84

Soportar una estructura CAD como CATIA V6, CATIA V5 y SolidWorks.

Migrar datos de Dassault Systèmes PLM Systems.

Acomodar varios entornos, como V4 y V5 de Dassault Systèmes.

Administrar los recursos de las aplicaciones CATIA.

A continuación se representará de forma gráfica las principales diferencias entre V5 y V6 en la

estructura de productos.

Figura 28. Diferencias entre V5 y V6.

3.5.12.1 ENOVIA VPM – Barra de Ciclo de Vida.

La barra de herramientas del Ciclo de Vida proporciona las herramientas necesarias activas a

cada usuario para realizar las tareas que tradicionalmente se realizaban de manera secuencial,

de un mismo conjunto de datos de manera paralela.

Este desarrollo en paralelo ayuda a reducir el tiempo en general del desarrollo en ingeniería de

manera significativa.

La barra de herramientas del Ciclo de Vida proporciona las siguientes herramientas:

- Bloquear.

- Desbloquear.

- Nueva versión.

- Cambiar estado de maduración.

- Transferir propiedad (de objeto/s seleccionado/s).

3.5.12.2 ENOVIA VPM – Versión de Edición.

La versión autorizada permite ciertas capacidades:


85

- Cargar la estructura del producto en la ventana de edición con las diferentes versiones

del mismo producto con sus respectivas representaciones.

- Crear una nueva versión del producto o una representación usando:

o La ventana VPMNav.

o La ventana autorizada.

- Además la ventana de edición proporciona:

o Un reemplazo automático de todos los casos de una referencia que ha sido

cargada en la sesión.

o Un reemplazo de las relaciones en la sesión cargada.

o La capacidad de reemplazar la versión del producto o su representación con

una versión diferente (última versión o la versión seleccionada).

3.5.12.3 ENOVIA VPM – Actualizaciones optimizadas.

Análisis de actualizaciones: el gráfico de actualizaciones permite ver los elementos que han

sido actualizados. Esto permite actualizar el montaje paso a paso.

Algoritmo optimizado de actualizaciones:

- Ofrece una integración sin problemas con la carga/descarga selectiva, mientras se

descarga una actualización global para una reunión gigante de usuarios.

- Permite elegir entre actualizaciones clásicas (más rápido pero necesita más memoria)

y las nuevas actualizaciones (son más lentas pero requieren menos memoria).

- Permite tener una mejor escalabilidad.

3.5.12.4 ENOVIA VPM – Interfaz de usuario.

Las siguientes herramientas de V6 son accesibles a ambas ventanas, la ventana de navegación

y la ventana de edición, dichas herramientas son: la brújula PLM, la barra de herramientas PLM y

el robot.

ENOVIA VPM – Brújula.

La brújula PLM proporciona un acceso instantáneo a la información PLM en cualquier momento y

en cualquier ventana de un documento.

Pulsando en un cuadrante, se activa y se cambia la representación visual del objeto

seleccionado. (Norte: Personal, Oeste: forma y representación y Sur: estructura).

Cuando un cuadrante es activado y un objeto es seleccionado (o viceversa), V6 cambiará el

color del objeto y mostrará una etiqueta que contendrá el nombre y algunas características que

sean relevantes del cuadrante activo.


86

Figura 29. Cuadrantes de la Brújula de ENOVIA VPM

El cuadrante ESTE es diferente dependiendo de que el usuario se encuentre en la ventana de

navegación o en la ventana de edición:

- En la ventana de navegación (VPM Navegador): cuando el cuadrante Este es

seleccionado, la etiqueta muestra el mensaje de “Información no disponible”.

- En la ventana de edición: el cuadrante Este proporciona información sobre enlaces y

conocimientos.

A tener en cuenta que toda la información mostrada por la brújula PLM es recogida directamente

de la base de datos.

ENOVIA VPM – Barra de herramientas PLM.

La barra de herramientas PLM sirve como un acceso rápido para: búsqueda de datos, examinar

el impacto de las modificaciones, colaboración con otras personas o también para propagar las

modificaciones a la base de datos.

3.5.12.5 ENOVIA VPM – Gráfico de impacto.

El gráfico de impacto se puede encontrar en la ventana de navegación. Son posibles las

siguientes opciones:

- Impactos sobre o impactado por.

- Información y estados.

- Sincronización, versión, estado de madurez y estado de carga.

- Análisis detallados, como las publicaciones de soporte.

Las opciones gráficas sirven para filtrar y personalizar los resultados:

- El análisis selectivo permite seleccionar cualquier referencia y expandir sus

hijos/padres en el árbol de niveles.

- Los elementos repetidos son destacados en el gráfico.

- Resaltado con cruz: cuando un elemento seleccionado en el gráfico, le corresponde

un resaltado.


87

3.5.12.6 ENOVIA VPM – Edición de enlaces.

La función de edición de enlaces es accesible solo desde la ventana de edición. Los

enlaces pueden ser visualizados en otra lista o en una ventana gráfica. Los filtros pueden ser

usados para ordenar los contenidos de la ventana de edición de enlaces.

La información de contexto nos puede ayudar para saber cuál nivel está siendo analizado y qué

contexto está siendo cargado y listo para guardar.

El contexto puede ser cambiado: automáticamente (si sólo es una vez) o de manera manual

(solo un grupo de opciones es posible).

3.5.12.7 ENOVIA VPM – Detalles.

Opciones existentes en el entorno de diseño:

- Explorar parentesco: permite al usuario seguir la ruta de la estructura del producto.

Cada instancia de los padres de la parte seleccionada aparecen en una lista en el

panel de la izquierda de la pantalla.

- Filtro de datos usando el filtro de atributos o el filtro de configuración: estos

cambios visuales solamente se aplican en la sesión actual y no afectan

permanentemente a la estructura de la siguiente sesión.

- Filtros persistentes: creados por la PLM Root References, estos filtros permanentes

permiten a los diferentes usuarios buscar y volver a usar filtros existentes de forma

rápida y fácil.

Organizar los datos:

- El usuario puede crear búsquedas permanentes para cualquier objeto y además

pueden ser reutilizadas por múltiples usuarios.

- Las carpetas pueden estar organizadas por vistas específicas o enlaces de

actividades. Una vez hecho esto, la carpeta puede ser definida con información

necesaria para cada actividad.

- También es posible organizar los datos en función de archivos favoritos, con accesos

directos a los archivos favoritos. Además se pueden gestionar los accesos favoritos

usando: añadir a favoritos, en la ventana de búsqueda de resultados, abriendo

favoritos, buscando favoritos o intercambiando favoritos.

3.5.12.8 Visión de conjunto de RFLP.

RFLP es un sistema de procesos de ingeniería basado en el ciclo en V de diseño de procesos.

Consiste en la conversión de unas necesidades en un producto que las satisfaga. Para obtener

una solución, serán necesarias las herramientas de ingeniería que se utilizarán a lo largo del

proceso. Dicho proceso ocupa desde la definición de las especificaciones, pasando por el diseño

del producto para finalizar en la implementación.


88

Las siglas RFLP provienen de los diferentes procesos del ciclo en V:

R: Requirements Management (Gestión de requisitos).

F: Functional Analysis (Análisis funcional).

L: Logical Architecture Definition (Definición de la arquitectura lógica).

P: Physical Design (Diseño físico).

Figura 30. Procesos en el sistema de diseño en V. RFLP.

3.5.12.9 Sistema de definición funcional lógica ENOVIA (DFL – ENOVIA System

Functional Logical Definition).

La Central VPM permite definir y navegar en los elementos funcionales y lógicos para un

modelado preciso y una simulación de sistemas complejos. Esto proporciona las siguientes

ventajas:

- Incrementar la productividad del sistema ingenieril con una navegación avanzada y

accesos directos a la información de los requisitos.

- Permite buscar, navegar, trabajar y colaborar en la definición RFLP del producto en

tiempo real usando los datos 3D y todas las capacidades de búsqueda 3D con la

estructura física y lógica 3D.

- Optimizar el sistema de diseño en general con un acceso a los requisitos desde el

sistema CATIA.

- Incrementar la productividad de la edición funcional y lógica.


89

3.5.12.10 ENOVIA VPM Change Tracking (CHT).

La central VPM proporciona un control y trazabilidad total en las modificaciones de diseño

a través de varios niveles del ciclo de desarrollo del producto (diseño, fabricación,

mantenimiento…)

- Esto permite iniciar y monitorizar las modificaciones de diseño a través del ECA –

Engineering Change Actions.

- Asegura que los cambios son trazables a lo largo de todo el ciclo de vida del producto.

- Se puede realizar en complejos sistemas, asignando cambios que provienen de

múltiples grupos de ingeniería.

3.6 Organización de la empresa.

3.6.1 Conceptos ENOVIA. Organización de la empresa.

Se puede definir los siguientes conceptos dentro de ENOVIA:

Persona: representa un usuario de ENOVIA.

Organización: define a un grupo de personas. Puede ser una unidad de negocio o el

departamento de una empresa.

Rol: define una actividad (trabajo o función) que una persona puede realizar con el

sistema PLM.

Proyecto: representa una tarea de la empresa prevista.

La organización, los roles y el proyecto pueden estar estructurados de manera jerárquica. Una

persona o usuario puede tener diferentes roles asignados y cada rol puede incluir varias

personas o grupos.

Con el mecanismo de bloqueo y desbloqueo se puede permitir el acceso a las modificaciones y

un sistema de colas de peticiones de modificaciones. El mecanismo de objetos bloqueados

asegura que tan solo una persona pueda modificar una parte en un solo instante. Esto permite

eliminar el riesgo de una pérdida accidental de datos.

El mecanismo de bloqueo permite al usuario bloquear sus propios objetos cuando el propio

usuario quiere usarlos, y desbloquearlos cuando el trabajo esté finalizado. Esto ayuda al sistema

de colas con precisión, en las solicitudes de modificación.

Objetos de negocio: son metadatos creados en la base de datos que se utilizan como

objetos administrativos, identificados por una única combinación de valores TNR.

Atributos: son las características de un objeto. Los atributos son creados en el estudio

de modelado o también vía MQL. Pueden ser reusados de los tipos de objetos de

negocio (Ejemplo: fecha, forma, nombre, propietario…)


90

Los objetos de negocio tienen un metadato asociado. Los objetos de negocio provienen del

documento de tipos de objetos, que puede tener archivos asociados (el contenido del

documento). No hay una fuerte correlación entre el archivo y los metadatos asociados, por tanto,

ambos son manejados de diferente manera.

Bóvedas: Una bóveda es un subconjunto de la base de datos donde los metadatos son

organizados y almacenados. Cada objeto de negocio tiene un único metadato asociado

a él. Las bóvedas son a menudo manejadas en una ventana a parte en ORACLE.

Tiendas: Una tienda es una ubicación de almacenamiento para los archivos que quieran

guardarse. Una tienda de archivos simplemente define un lugar donde un archivo puede

ser localizado. Si se desea se pueden separar tiendas de archivos que pueden ser

definidas como dibujos CAD, archivos de documentación… Cualquier objeto de negocio

que proviene del documento de tipos de objetos puede tener archivos asociados a él.

Los archivos pueden ser almacenados y recuperados bajo el control de aplicaciones de

procesos de negocios como puede ser Ingeniería o la Biblioteca central.

Política: La política es un conjunto de reglas que gobiernan la jerarquía de un proyecto

de negocios. Esto incluye el ciclo de vida de producto, privilegios de acceso, esquemas

de revisión, archivos de formato asociados a los objetos y el dónde y el cómo almacenar

archivos en la base de datos. La política gobierna los diferentes estados que un objeto

pasará a lo largo del ciclo de vida, las personas que tienen acceso a los objetos en cada

estado y las condiciones requeridas para cambiar de un estado a otro.

Ciclo de vida: El ciclo de vida es una serie de estados por las que un proyecto de

negocio ha de pasar a lo largo de su existencia. El ciclo de vida está disponible en VPM

como Estado de Madurez. El ciclo de vida se refiere a los pasos necesarios para

madurar y realizar un proyecto, además el ciclo de vida de un producto depende de la

política del proyecto.

Revisión: La revisión se refiere a la modificación de un objeto una vez que ha llegado a

este particular estado. Hay que tener en cuenta que los requisitos de privilegios pueden

variar durante el ciclo de vida del producto.

Colección: Una colección es un conjunto de objetos como piezas, proyectos,

características… Podemos crear y guardar colecciones (sólo el creador que ha creado la

colección puede acceder y usarla). De esta forma un contexto puede ser guardado. Se

pueden añadir a una colección partes o piezas del proyecto, que después pueden ser

buscadas. Para ello se utilizará el buscador permitiendo realizar una búsqueda refinada.

3.6.2 Equipo de colaboración en vivo ENOVIA.

La aplicación del equipo en ENOVIA permite un espacio de trabajo seguro y estructurado que

permite una colaboración en vivo a los equipos de trabajo multidisciplinares y dispersos

geográficamente. El Líder del proyecto puede usar la opción “Equipo” para crear un espacio de

trabajo donde los miembros del equipo podrán trabajar.


91

Un espacio de trabajo es un grupo de carpetas que contienen todos los documentos e

informes necesarios para un proyecto. El acceso a estas carpetas se puede restringir de

diferentes formas: de forma individual, por roles o por el centro de clientes (todos los clientes

asignados pueden acceder al espacio de trabajo).

Los miembros del equipo pueden suscribirse a los cambios del espacio de trabajo, a las rutas,

carpetas y subcarpetas, documentos, discusiones de documentos y respuestas de mensajes.

3.6.3 Objetos de Negocio & Objetos Administrativos.

Se debe diferenciar entre el mundo del Usuario y el mundo del Administrador cuando hablamos

sobre objetos en ENOVIA. El mundo del Usuario representa todos los datos que son necesarios

en las actividades diarias de negocio. Esto consiste en todos los Objetos de Negocio que son

creados por el usuario final.

Por otra parte, el mundo del Administrador proporciona al usuario las herramientas y derechos

de acceso para crear dichos datos. Esto incluye que debe ser el Administrador de Negocio quien

cree todos los Objetos Administrativos, que son pre-requisitos para la creación de los Objetos de

Negocio. Los usuarios finales trabajan con Objetos de Negocio, mientras que los administradores

trabajan con los Objetos Administrativos. Estos objetos definen el contexto en el cual el usuario

trabajará. El derecho de acceso a los objetos se concede en función de varias condiciones como

el estado del objeto, roles del usuario que necesita para el acceso, valores de propiedad…

3.6.4 Objetos de Negocio en ENOVIA V6.

Los objetos de negocio en ENOVIA pueden representar cualquier tipo de información que el

cliente pueda necesitar almacenar en su sistema como un metadato. Son creados y modificados

por el usuario final. Tienen varias propiedades que definen su utilización.

Ejemplos de Objetos de Negocio:

Un simple dibujo: el objeto de negocio sirve como recipiente de la marca en el archivo.

Un ensamblaje: el objeto es conectado a un conjunto de otros objetos, los cuales

pueden conformar la lista de materiales del ensamblaje.

Una tarea de proceso: el objeto de negocio contiene toda la información que es

afectada por la tarea, esta información puede ser personas que tienen que completar la

tarea, objetos concernientes a la tarea o futura información.

Una persona: el objeto de negocio sirve como un representante de la persona en el

sistema. Esto permite calificar a la persona, por ejemplo un proveedor, con ciertas

propiedades.


92

3.6.5 Conceptos de Personas y Organización (P&O).

Antes de representar una empresa, es necesario definir la Organización de la empresa usando

componentes comunes como: Empresa, unidades de negocio, departamentos, localizaciones,

plantas de trabajo, regiones…

Después se tendrá que definir los socios colaboradores (las empresas con las que se realizarán

negocios) y las empresas que son proveedores. También se deberá definir:

Decisiones: se utilizan para racionalizar la creación o existencia de los requisitos de un

producto, documento o planificación de reuniones.

Relaciones: usado en la creación y gestión de las relaciones entre las diferentes partes

del equipo de trabajo/colaboración.

Seguimiento de problemas: permite informar sobre problemas en productos

específicos, proyectos, partes de productos u otros objetos de negocio.

Rutas: son un grupo de operaciones que se deben completar para finalizar una actividad

de negocio. Las rutas pueden contener información que ayude a los miembros asignados

a la ruta a completar las actividades asignadas.

Piezas: es el término genérico para referirse a cualquier objeto que la empresa pueda

construir o mantener en inventario. Una pieza puede ser una pieza simple o un

ensamblaje de partes.

Familia de piezas: es un grupo de series de piezas que tienen en común una función

general, pueden tener la misma arquitectura incluso componentes comunes.

Personas.

Una Persona es alguien que trabaja con la plataforma de ENOVIA. El sistema utiliza a las

personas que se definen para controlar el acceso, notificaciones, propiedad, licencias e historial.

Todos los usuarios que quieran acceder a la plataforma ENOVIA necesitan ser definidos como

un Objeto Administrativo “Persona” en el esquema de ENOVIA, de no ser así no tendrá acceso a

la base de datos.

Roles.

Un rol es una colección de personas que tienen un tipo de trabajo común. El rol identifica el

trabajo o función de cada Persona. El rol consiste en un grupo de personas que comparten

tareas y que incluso, en ciertas circunstancias, comparten el mismo acceso a los objetos de

negocio. Algunos ejemplos de roles son Ingeniero de Diseño, Ingeniero de Diseño Senior, Buyer,

Customer, ECO Chairman...

Grupos.

Un grupo puede ser un departamento, la empresa, una unidad de negocio, un subsidiario, un

equipo de proyecto…

En un grupo las personas con diferentes talentos y habilidades pueden actuar en diferentes

trabajos/roles. Un grupo consiste en un grupo de Personas quienes dentro de unas


93

circunstancias, comparten el mismo acceso a los objetos de negocio. Un Grupo comparte el

acceso a Objetos de Negocio específicos.

Asociaciones.

Una asociación es una combinación de diferentes grupos y/o Roles u otras asociaciones, las

cuales son conectadas usando conectores AND, AND/OR, ONLY y NOT.

Si varios usuarios necesitan acceder a un tipo de objeto de negocio, se debe considerar la

creación de un grupo, un rol o una asociación para representar el conjunto de usuarios. Crear

una categoría de usuario evita el problema de la inclusión de cada usuario en la política o

definición de reglas. No obstante se debe incluir la categoría de usuario.

Para decidir qué tipo de categoría de usuario se debe crear, hay que considerar cuáles usuarios

tienen un objeto de negocio en común y por qué ellos necesitan el mismo acceso. Algunas

propiedades solamente las atribuye los roles como la visualización o la distribución. Hay que

destacar que directamente una persona no puede ser añadida a una asociación.

3.6.6 Introducción al Esquema Enovia.

El Esquema ENOVIA es una colección de Objetos Administrativos, los cuales son necesarios

para los usuarios finales para crear sus datos de negocio. Esto incluye los tipos de objeto de

negocio y sus atributos de objeto asociados. Cada tipo es gobernado por una política que

contiene el último estado, el cual puede especificar uno o más formatos.

Un esquema comprende las dimensiones, objetos de programa, valores, almacenes, relaciones,

reglas y el modelo organizacional consistente en personas, roles, grupos y asociaciones.

El Esquema (también llamado “Modelo de datos”) es definido por el Administrador de Negocio

usando el Modelador de negocios. Solo las definiciones que existen en el modelo pueden ser

usadas por los usuarios de acuerdo a los accesos permitidos a cada uno.

Ahora veremos algo de terminología y conceptos de un esquema básico:

Esquema: es el modelo de datos en la base de datos. Es la configuración específica de

la base de datos incluyendo qué puede ser creado, qué está permitido, cuántas cosas

están controladas y cómo interactúan unas con otras. Resumiendo, un esquema es

único en cada negocio y cada problema de negocio, y especifica las reglas de para qué

se almacena y quién tiene acceso a la información almacenada.

ENOVIA Studio Modeling Platform: es una colección amplia de aplicaciones de

software de los clientes utilizado para crear, gestionar y extraer la información desde y

hacia la base de datos en capacidad administrativa.

Business Modeler: es el software de modelado de negocio. Es una extensa aplicación

de software de cliente usada para modelar y gestionar el esquema.

Business Administrator: es la persona que irá creando el esquema.

El Esquema es único para la empresa que utiliza ENOVIA. Pero que sea único no quiere

decir que esté estandarizado y tenga un tiempo establecido de implementación, o que la


94

funcionalidad esté configurada previamente. Cada esquema necesita una evaluación

propia en cada uno de estos puntos.

La creación de un esquema de base de datos en ENOVIA es un proceso relativamente fácil. No

obstante esto requiere documentación fiable y un trabajo estructurado. El esquema que se quiera

crear puede ser tan simple o complejo como el proceso quiera ser modelado.

Los siguientes Objetos Administrativos son esenciales para definir un esquema funcional

ENOVIA:

1. Dimensiones.

2. Atributos.

3. Tipos.

4. Relaciones.

5. Programas.

6. Formatos.

7. Valores.

8. Tiendas.

9. Usuarios:

a) Personas.

b) Roles.

c) Grupos.

d) Asociaciones.

10. Políticas.

11. Reglas.

3.6.7 Tipos.

Representan las clases, categorías o formas de los objetos de negocio que puedan existir en

nuestra propia base de datos. Los objetos de negocio son casos de los Tipos. Los objetos de

negocio son identificados únicamente por propiedades básicas como el Tipo, Nombre y Revisión.

Los objetos de negocio del mismo tipo en su sistema normalmente diferirán en el nombre y/o

revisión.

3.6.8 Atributos.

Son piezas adicionales de información descriptiva usada para especificar los valores asociados

con los objetos de negocio o de una relación.


95

3.6.9 Relaciones.

Son usadas para conectar objetos de negocio dentro de las estructuras, por ejemplo en la lista

de materiales. Las relaciones definen las reglas de conectividad de los objetos de negocio,

también pueden realizar otras conexiones durante las operaciones de revisión o clonación. Los

objetos de negocio solo pueden ser conectados con otros si siguen las reglas (relaciones)

definidas por el Administrador de Negocio.

Las relaciones de los Objetos Administrativos son creados para permitir la conexión entre dos

objetos de negocio (los cuales corresponden al Tipo que ha sido especificado) o entre los objetos

de negocio y otras relaciones (en este caso solo un Tipo ha sido especificado y solo una relación

ha sido especificada).

También se pueden asignar Atributos a las relaciones. Todas las relaciones siempre existen

entre dos objetos de negocio o un objeto de negocio y una relación, uno es el emisario y otro el

destino.

La cardinalidad define el número de conexiones de una relación específica que un objeto de

negocio puede tener.

Uno a uno 1>1

Uno a varios 1>N

Varios a uno N>1

Varios a varios N>N

3.6.10 Políticas.

Las políticas son los elementos más importantes en el modelo de datos. Ellas traen

consigo un número de definiciones de esquemas que controlan el comportamiento de los

objetos de negocio.

La política controla el comportamiento de los objetos de negocio controlando las reglas de

acceso del usuario, el ciclo de vida, comportamiento de la revisión… Un objeto de negocio

siempre sigue solamente una política a la vez.

3.6.11 Valores.

Un valor es un grupo de objetos similares que se encuentran en la base de datos ENOVIA, y que

también comparte la misma localización de almacenamiento para los metadatos que describen

esos objetos. Los valores son utilizados para organizar los Objetos de Negocio.

Hay dos categorías de Valores:


96

Valores de Objetos de Negocio: se utilizan para organizar los objetos de negocio con

la base de datos.

Valores de Objetos Administrativos: se utilizan solo para propósitos administrativos y

sirven para el valor de la definición máster.

Existen cuatro tipos de Valores:

Valores Locales: es una parte de la instalación propia y normalmente se refieren a las

unidades designadas para almacenar junto con la base de datos.

Valores Remotos: son utilizados para base de datos con un acoplamiento flexible.

Valores Extranjeros: son utilizados para acceder a una base de datos externa.

Valores Externos: se utilizan para acceder al legado externo y las bases de datos del

no-legado usando los Servicios Web.

3.6.12 Tiendas.

Una tienda es la localización de almacenamiento físico de los archivos comprobados.

Cuando un archivo es comprobado, ENOVIA lo mueve o copia en una localización

conocida como “Tienda de archivos”.

Existen tres tipos de tiendas:

DesignSync.

External.

Capturated

3.7 Líneas de producto y Piezas.

3.7.1 Líneas de producto.

La Gestión de Líneas de Producto es una potente herramienta de gestión de productos, que

permite crear, modificar y trabajar con líneas de producto, productos, modelos, carteras,

construcciones y objetos asociados.

El Gestor de Productos define las Líneas de Producto, que son los servicios y productos

que la empresa oferta a sus clientes.

Definir las líneas de producto y modelos permite a las empresas dar a conocer los

productos y servicios que ofrecen. Además una línea de productos puede tener una o

más sub-líneas de productos.


97

Una línea de producto es una colección de modelos. Un modelo proporciona una vista completa

de las creaciones del producto y su configuración, además de todas sus revisiones y la gestión

de todas ellas.

Un producto puede tener infinidad de características, revisiones y versiones identificadas de

manera propia e unívoca.

Figura 31. Ejemplo de organización y línea de producto de Renault.

Por defecto el gestor de líneas de producto ENOVIA proporciona tres tipos de producto:

Hardware product.

Software product.

Service product.

Además se distinguen dos tipos de construcciones:

Software builds.

Hardware builds (serían los productos físicos producidos mediante una fabricación).

3.7.2 Introducción a las Piezas y sus ciclos de vida.

Una pieza es un componente simple de un producto, mientras que una colección o grupo de

piezas forman un ensamblaje. El Ingeniero de Diseño y el Ingeniero de Diseño Senior, junto al

Ingeniero de Fabricación y el Ingeniero de Fabricación Senior pueden crear piezas de alto nivel y

sub-tipos de piezas. Los usuarios del equipo de edición de la BOM con el rol de VPLMCreator o

VPLMProjectLeader pueden crear departamentos o Piezas EC.


98

Cuando una pieza nueva es creada se genera una parte maestra creada a la misma vez y

conectada con la pieza y con la relación de revisiones de la pieza. Todas las piezas relacionadas

con la pieza maestra son revisadas al revisar una de las piezas. Cada revisión de una pieza tiene

solamente una pieza maestra a la misma vez.

La necesidad de una pieza nueva se inicia con una ECO, cuando entra en el estado de definición

de componentes. En este punto las piezas nuevas y las nuevas revisiones de las piezas para

una parte pre-configurada son creadas y empiezan a moverse a través de sus propios ciclos de

vida.

El Ingeniero de Fabricación es responsable de revisar y aprobar las piezas y los objetos

adjuntos, teniendo que realizar justificaciones de los atributos tales como Efectividad y Coste

estimado.

Las piezas pueden estar incluidas en grupos lógicos llamados Familias de Piezas. Las Familias

de Piezas pueden ser editadas y modificadas añadiendo o quitando piezas del grupo.

Tipos de piezas:

En la Central de Ingeniería aparecen los siguientes tipos de piezas definidos:

Pieza en desarrollo: es el concepto de pieza creada por la propia empresa. Es revisada

por el Ingeniero de Diseño Senior y el Ingeniero de Fabricación Senior y puede llegar a

convertirse en una pieza EC, cuando se encuentre en el estado “Completado”.

Pieza de la empresa: estas piezas son fabricadas de manera propia por la empresa.

Piezas equivalentes (EP – Equivalent Parts): son parecidas a las piezas de la

empresa pero están subcontratadas a un proveedor. Una pieza de la empresa puede

tener una o más piezas equivalentes de fabricantes con números de piezas únicos y con

diferentes proveedores.

Pieza Alternativa: es aceptada para reemplazar la pieza original en todos los

ensamblajes, donde la pieza real exista. Tiene la misma forma grosor y función que la

pieza original.

Pieza Sustituta: es aceptada para reemplazar alguna pieza solamente en un

ensamblaje. No tiene la misma forma, grosor y funcionalidad en los diferentes

ensamblajes.

Pieza de aplicación: es funcionalmente equivalente a las piezas de la empresa, con una

o más EPs, con ambos contextos, el de ensamblaje y de localización.

Parte Derivada: es un componente creado para clonar y reemplazar una pieza. Cuando

una pieza es clonada las diferentes relaciones son creadas entre la pieza clonada y la

pieza fuente.

3.7.3 Ciclo de vida de una Pieza en Desarrollo.

El Desarrollo de una pieza tiene los siguientes estados en su ciclo de vida:


99

Crear: en este estado, los ingenieros de diseño crean una nueva pieza o una revisión de

pieza. Pueden también revisar las siguientes tareas:

- Crear la lista de materiales (BOM) para identificar los componentes que se requieren

para fabricar las piezas.

- Adjuntar las especificaciones requeridas describiendo las piezas.

- Promover las piezas al estado “Pendiente de revisión”.

Pendiente de Revisión: en este estado, el responsable que es el Ingeniero de Diseño

Senior revisa las piezas. Además puede realizar una de las siguientes tareas basadas

en la revisión:

- Promover las piezas al estado “Completado”.

- Devolver las piezas al estado “Crear” si la pieza necesita un nuevo trabajo sobre ella

al no estar bien realizada.

Completado: en este estado el sistema automáticamente notifica al usuario que esté

suscrito a este evento de la pieza.

Obsoleto: en este estado la pieza no puede ser usada en ninguna BOM nueva. Los

usuarios pueden empezar usando la pieza para trabajar sobre ella, solamente los

Managers de Productos Obsoletos pueden devolver la pieza al estado de COMPLETO.

Figura 32. Ciclo de vida de una pieza en desarrollo.

3.7.4 Ciclo de vida de una Pieza de la Empresa.

Las piezas de la Empresa tienen los siguientes estados en su ciclo de vida:

Preliminar: en este estado los Ingenieros de Diseño crean nuevas piezas o nuevas

revisiones de piezas. También pueden realizar las siguientes tareas:

- Adjuntar ECOs.

- Construir la lista de materiales BOM para identificar los componentes requeridos

para fabricar piezas.

- Adjuntar las especificaciones que definen la pieza.

- Promover las piezas al estado “Revisión”.

Hay que destacar que una pieza no puede ser promovida del estado de Revisión sin que tenga

las especificaciones, los documentos de referencia (con archivos) adjuntados a la pieza (esto

estará en el estado de Revisión) y una ECO conectada a la pieza.

Revisión: en este estado los ingenieros de fabricación revisan la pieza. Además pueden

realizar las siguientes tareas:

- Entrar o modificar la efectividad, el coste estimado u cualquier otro valor de un

atributo.


100

- Promover las piezas al siguiente estado “Aprobado”.

Aprobado: en este estado el ingeniero aprobará la pieza que ascenderá al estado de

“Liberado”.

Una vez que todos los elementos afectados que están conectados a la ECO son promovidos

al estado Aprobado, la pieza será auto-promovida al estado Liberado una vez que la ECO

haya sido promovida al estado Liberado.

Liberado: en este estado la pieza es bloqueada y no se podrá realizar ningún cambio en

ella. El sistema automáticamente moverá todas las relaciones con las revisiones previas

a la versión actual incluyendo todos los componentes de la EBOM, especificaciones y

dibujos.

Obsoleta: la pieza será promovida al estado de Obsoleta cuando no haya sido usada

durante un largo período de tiempo. Debería ser devuelta al estado de liberada por el

Manager de Productos Obsoletos para usarla en la lista de materiales.

Figura 33. Ciclo de vida de una pieza.

Para Crear una Pieza solo los roles de Ingeniero de Diseño, Ingeniero de Diseño Senior,

Ingeniero de Fabricación o Ingeniero de Fabricación Senior pueden crear una nueva pieza.

Hay diferentes tipos de piezas, en la Central de Ingeniería aparecen ya algunos pre-definidos:

Piezas de hardware: Piezas eléctricas (Pieza capacitiva, Placa de circuito, conector, resistencia,

transistor), Piezas mecánicas (Extrusiones, mecanizados, moldeados…)…

Para crear la pieza se necesita rellenar los siguientes campos:

Tipo: selecciona el tipo de las piezas pre-definidas.

Nombre pieza: escribe el nombre de la pieza o elige la pestaña AutoName.

AutoName Series: selecciona la serie A, B, C o D de la lista. El nombre de la pieza empezará

con la letra seleccionada.

Modo de pieza: elige uno de los modos:

- No-configurado: la salida de la EBOM estará basada en la última revisión de

efectividad liberada.

- Configurada: la EBOM estará basada en la efectividad de la Unidad de Producto.

Política: selecciona cualquier desarrollo o Pieza EC de la lista.

Número de Piezas: introduce el número de piezas de la creación. Esto crea múltiples piezas,

solo cuando el campo AutoName está activo y la Serie AutoName seleccionada.

Nivel de Revisión Personalizado: actualización automática basada en la política seleccionada.

Responsabilidad de Diseño: puede ser un Responsable de la Organización de Diseño (RDO –

Responsible Design Organization) como una unidad de negocio, empresa, departamento o

planta.


101

El responsable de la organización de diseño RDO debe ser asignado antes de que los objetos

alcancen el estado Revisado en su ciclo de vida.

3.7.5 Clonación de piezas.

Se puede clonar piezas creando una pieza similar en la que podemos incluir previamente

seleccionados, diversos campos tales como EBOM, especificaciones, alternativas, adjuntos…

Las piezas pueden clonarse a la vez hasta un máximo de 10 piezas de una vez. Las piezas

pueden ser clonadas por los usuarios asignados con los siguientes roles:

Ingeniero de componentes, Ingeniero de diseño, Ingeniero de Diseño Senior, Ingeniero de

Fabricación e Ingeniero de Fabricación Senior.

Para clonar múltiples piezas solo se puede en los siguientes casos:

- La pieza es creada con AutoNaming activo.

- La pieza es creada seleccionando antes una familia de piezas. Al seleccionar la

familia de piezas AutoNaame es automáticamente seleccionado.

3.7.6 Creación de especificaciones adjuntas a la pieza.

Especificación de la pieza es un campo que puede incluir cualquier tipo de documento que

queramos conectar con la pieza. Las especificaciones se utilizan para definir la pieza y pueden

ser de diversos tipos tales como modelos CAD, dibujos CAD, dibujos o especificaciones de

piezas

Un modelo CAD es una geometría tridimensional que describe la pieza. Un dibujo CAD es un

dibujo bidimensional que nos da una representación que describe la pieza.

Los Documentos de Referencia pueden ser conectados a la pieza en cualquier estado del ciclo

de vida, incluso cuando está liberado, todos estos documentos no tienen por qué definir la pieza.

Los documentos pueden ser asociados con la pieza con las relaciones de los documentos de

referencia para diferenciarse de las especificaciones que sí definen la pieza.

Los documentos de referencia pueden existir sin estar conectados a una pieza, en este caso no

se requiere una ECO para liberar el documento.

3.7.7 Ciclo de Vida de una Especificación de una pieza.

Los objetos de especificación tienen 4 estados en su ciclo de vida:


102

Preliminar: en este estado la nueva especificación o revisión de una especificación existente es

creada. El Ingeniero de Diseño realiza las siguientes tareas en este estado:

- Conecta las especificaciones con la apropiada ECO y con los objetos de las piezas.

- Comprueba el archivo representando el dibujo en el objeto de especificación.

Revisado: en este estado el Ingeniero de Fabricación revisa la pieza y los dibujos

completamente para dejar seguro que el dibujo define correctamente la pieza.

Aprobado: es un estado de espera, cuando todos los elementos (incluidas las especificaciones)

están en el estado Aprobado, pasan automáticamente al siguiente estado “Liberado”. Esto

sucede cuando la ECO está promovida al estado Liberado.

Liberado: las especificaciones comienzan a ser las últimas liberadas y esto bloquea la pieza, no

pudiendo realizar cambios adicionales.

Figura 34. Ciclo de vida de una Especificación de una pieza

103

4 Diseño e implementación de una línea de producto en un

sistema a PLM

4.1 Introducción.

Para finalizar el presente proyecto, se procederá a la implementación de diversas herramientas

de ENOVIA V6 en un ejemplo real, que como más adelante se describirá es un producto de

sujeción llamado “Mordaza”. Partiendo desde la estructura organizativa de una empresa, se

diseñará la estructura de una empresa genérica, con definiciones tales como la propia

organización o los usuarios. Se continuará con la definición de conceptos relacionados con el

producto y las líneas de producto además de los conceptos relacionados con las propias piezas

y las familias de piezas. Por último se definirán los cambios de ingeniería que afectarán al

producto, el rango de efectividad del producto y la lista de materiales que componen el producto.

En este apartado se seguirá una estructura basada en la definición teórica de los diferentes

conceptos en el apartado 4.2 y una posterior implementación en ENOVIA V6 con un ejemplo real

en el apartado 4.3.

4.2 Conceptos en la implementación.

4.2.1 Definición del producto.

A continuación se realizará la descripción del objeto “Mordaza” que será utilizado como producto

en los diferentes apartados de la implementación de la línea de producto en un sistema PLM.

Diseño e implementación de una línea de producto en un sistema PLM

104

Figura 35. Presentación del producto “Mordaza”.

La “Mordaza” es una herramienta utilizada como mecanismo de sujeción por fricción. En el caso

que se presenta, la mordaza se utilizaría para la unión de piezas cilíndricas.

Para dicha unión la mordaza está provista de dos sistemas de piezas con objetivos diferentes: el

“Sistema de apriete” y el “Sistema de sujeción”.

Figura 36. Subsistemas del producto “Mordaza”.

A. El sistema de apriete.

El sistema de apriete (Figura 33) está formado por todas las piezas del ensamblaje que tienen

por función el apriete dentro de la Mordaza.


105

Figura 37. Vista del sistema de apriete del producto “Mordaza.”

Dentro de este ensamblaje se puede diferenciar dos grupos a los cuales se les ha dado el

nombre de “Elementos de apriete” y “Elementos de montaje del apriete”.

Figura 38. Componentes del sistema de apriete.

El sistema “elementos de apriete” está formado por las piezas “Rosca

seguro”, “Seguro” y “Arandelita”.


106

Figura 39. Piezas que conforman el sistema “elementos de apriete”.

El sistema “Elementos de montaje del apriete” está formado únicamente por la

pieza “Pin anillo” que serviría como unión entre el “Sistema de sujeción” y el

“Sistema de apriete”.

Figura 40. Vista de los elementos de montaje del apriete.


107

Figura 41. Vista comprensiva de la unión de los sistemas de sujeción y apriete.

B. El sistema de sujeción.

El sistema de sujeción está formado por todas las piezas que toman parte en la

sujeción de la mordaza a la pieza o piezas.

Figura 42. Vista del sistema de sujeción del producto “Mordaza”.

Dentro del sistema de sujeción encontramos dos subsistemas llamados “Elementos de

sujeción” y “Elementos de montaje de sujeción”.


108

Figura 43. Vista de los subsistemas del sistema de sujeción del producto “Mordaza”.

El sistema “Elementos de sujeción” está formado por dos piezas idénticas

contrapuestas llamadas cada una “Anillo”. Estas piezas serían las que entrarían

en contacto con la pieza o piezas a unir.

Figura 44. Vista de los elementos de sujeción.

El sistema “Elementos de montaje de sujeción” está formado por las piezas

“Placa anillo” y dos piezas iguales llamadas “Pin anillo”.


109

Figura 45. Vista general de los elementos de montaje de sujeción.

Figura 46. Vista de las piezas que conforman los elementos de montaje de sujeción.

4.2.2 Definición de la estructura organizativa.

Antes de definir e implementar conceptos relacionados con el producto como pueden ser las

líneas de producto, piezas, familias de piezas, cambios de ingeniería… es necesario definir la

estructura organizativa. En el presente proyecto se definirá una estructura básica de una

organización o empresa. No se entrará en un profundo nivel de detalle, ya que la definición

completa de una organización excede por completo los conceptos que se han abordado y

adquirido en la realización de este proyecto.

La estructura organizativa comienza con la definición de la Organización que representaría a la

empresa como una entidad de negocio y reconocida como tal por ENOVIA V6. Se continuaría

con la definición de los diferentes Usuarios pertenecientes a la Organización. Estos usuarios

tendrán asignados los diferentes roles (ya descritos en el apartado 3.4.2) según sus perfiles de

trabajador dentro de la empresa. Por último, se definiría el Proyecto que se va a realizar

asignándole los diferentes usuarios y el rol con el que pueden acceder a dicho proyecto.


110

4.2.3 Definición de la línea del producto.

Una línea de producto clasifica tanto los servicios como los productos que una empresa ofrece a

sus diversos clientes. La línea de producto se crea y gestiona en el contexto de usuario de la

empresa y los productos se crean y gestionan en el contexto de las líneas de producto.

La definición de las líneas de producto y de modelos permite a las empresas dar a conocer los

productos y servicios que ofrecen a sus distintos clientes. Una línea de producto puede tener una

o más líneas de producto subordinadas.

4.2.3.1 Definición de producto.

Un producto es creado y gestionado en el contexto de línea de producto. Por defecto, el Product

Line Management proporciona tres tipos de productos: producto hardware, producto software y

por último un servicio.

El producto puede tener de 0 a N características asociadas a él y se le identifica mediante las

revisiones y versiones. Los productos se mantienen como “Productos Maestros” y están

relacionados con la línea de producto. La primera vez que se crea una revisión de producto, un

nuevo producto maestro es creado a la vez. El primer caso de un producto solo puede ser una

revisión de producto. Podemos elegir entre revisar una revisión de producto ya creada o crear

una versión de producto nueva. Cuando un producto es revisado o versionado, todas las

características directamente enlazadas con la revisión N son directamente enlazadas por defecto

a la revisión N+1. Solo los usuarios con los roles de Product Manager o System Engineer

pueden reemplazar el GBOM para liberar un producto o una característica.

4.2.3.2 Definición de desarrollo.

Un desarrollo de un producto puede ser creado en el contexto de un producto o de una

configuración de producto. Cuando un desarrollo es creado en el contexto de producto, se

conecta el desarrollo a un modelo que está asociado con ese producto. Cuando un desarrollo es

creado en el contexto de una configuración de producto, el desarrollo es conectado con el

producto asociado a esa configuración de producto y el modelo es asociado con ese producto.

Existen dos tipos de desarrollos, los desarrollos hardware y los desarrollos software. Cada tipo

de desarrollo está definido para un producto específico.

Los desarrollos Hardware contienen la construcción física del producto por Fabricación. A cada

desarrollo físico se le asigna un número serial. Los desarrollos hardware son adjuntados o

relacionados a los productos hardware. Los productos software pueden tener a la vez adjuntados

desarrollos software.

Los desarrollos software abarcan los archivos físicos que son distribuidos como CDs o como

productos hardware.


111

Para gestionar o crear un desarrollo se debe tener asignado uno de los siguientes roles:

- Un Software Engineer, Senior Software Engineer, Product Manager o un System

Engineer puede crear desarrollos.

- Un Software Engineer, Senior Software Engineer, Design Engineer, Product

Manager o un System Engineer puede mantener un desarrollo.

4.2.4 Concepto de parte y familia de piezas.

4.2.4.1 Definición de pieza.

Las piezas pueden ser definidas por (Senior) Design Engineers y por (Senior) Manufacturing

Engineers que pueden crear los niveles más altos de las piezas y sus sub tipos de piezas.

Los usuarios con el rol de VPLMCreator y VPLMProjectLeader pueden definir piezas utilizando la

política de Desarrollo de piezas.

La necesidad de crear una nueva pieza la inicia una ECO cuando entra en el estado de Definir

componentes. En este punto las piezas nuevas y las nuevas revisiones de piezas para piezas no

configuradas son creadas y comienzan a progresar en sus ciclos de vida. Una vez que la pieza

es creada, otros objetos pueden ser adjuntados a las piezas si fuese necesario, incluyendo

bocetos, modelos CAD, dibujos CAD, documentos de soporte y especificaciones.

El Responsible Manufacturing Engineer revisa y aprueba las piezas y sus objetos adjuntados,

también realiza ajustes en los atributos como efectividad y costes estimados si fuese necesario.

Las piezas pueden ser incluidas en grupos lógicos llamados familias de piezas. Las familias de

piezas pueden ser editadas y modificadas, añadiendo o quitando piezas del grupo.

Cuando una nueva pieza es creada, una pieza maestro es automáticamente creada a la misma

vez y conectada a la pieza mediante la relación de Revisión de pieza. Después de que la pieza

haya sido creada, también podemos editar sus detalles a través de los diferentes menús. Las

piezas resueltas pueden ser revisadas y todas las revisiones de una pieza particular resuelta

están conectadas a la misma pieza maestra. Cada revisión de una pieza tiene exclusivamente

una pieza maestra en todo momento.

Una vez que la pieza ha sido creada, otros objetos pueden ser adjuntados a la pieza si fuese

necesario, incluyendo bocetos, modelos CAD, dibujos CAD, documentos de soporte y

especificaciones.

También se puede clonar una pieza a partir de otra pieza ya existente, que heredará

automáticamente todas las opciones y atributos de la pieza que ya existía. No obstante cualquier

valor puede ser cambiado durante el proceso de clonación. Por ejemplo, si el usuario tiene una

pieza A ya existente y quiere crear una pieza nueva B que sea igual pero que el coste estimado

sea diferente, puede clonar la pieza A y cambiar solamente el valor de costes estimados en la

pieza B.


112

4.2.4.2 Familia de piezas.

Las empresas pueden agrupar piezas en familias lógicas para poder gestionarlas como una

familia íntegra. Esto permite a las especificaciones de producto ser asociadas con la familia

antes que con cada pieza individual.

Una serie de piezas puede tener la misma función general. Estas piezas comparten la misma

arquitectura y además pueden tener diversos componentes en común. La familia puede no estar

citada en el BOM como un sub componente porque los miembros de la familia, pueden ser

similares, aunque no tengan la misma forma, constitución y función.

La página de creación de una familia de piezas permite a los usuarios con el rol de Part Family

Coordinator asignado, crear nuevas familias de piezas. Las familias de piezas normalmente

comparten nombres similares, ya sea la misma base numérica, la secuencia paterna, prefijos o

sufijos. Cuando se crea una nueva familia de piezas, se define el nombramiento de todas las

piezas que están incluidas en la familia.

Una vez que la información preliminar ha sido introducida para la nueva familia de piezas, es

posible acceder a la página de propiedades de la familia de piezas, donde se podrá editar los

detalles y acceder a los miembros de la familia de piezas.

4.2.4.2.1 Definición de una serie de piezas.

Una serie de piezas es un grupo de piezas que pertenecen a una familia y comparten la misma

funcionalidad y dimensiones, pero varían en apariencia. Una serie de piezas consiste en una

pieza maestra y sus piezas referencia.

La pieza maestra es una pieza cuyas especificaciones, como los modelos CAD y bocetos se

aplican a toda la serie. Las piezas referencia están asociadas con la pieza maestra. Los usuarios

que tienen el rol de Part Family Coordinator pueden asignar piezas maestras y añadirle piezas

referencia a estas piezas maestras.

La estructura de una serie de piezas controla cómo las especificaciones se aplican a dichas

piezas.

Cuando se añade una pieza referencia a una pieza maestra, todas las

especificaciones de la pieza referencia previas son desconectadas. Las

especificaciones de la pieza maestra son copiadas y enlazadas a la pieza referencia.

Las nuevas especificaciones de la pieza referencia aparecerán como “solo lectura”

cuando accedamos desde la pieza referencia.

Las especificaciones de las piezas maestras se aplicarán a todas las piezas

referencia. Todos los cambios de las especificaciones deben producirse en la pieza

maestra y cuando estas especificaciones se liberen, todos los cambios

automáticamente se aplicarán a las diferentes referencias.


113

Cuando una especificación es añadida o eliminada de la pieza maestra, la

especificación será añadida o eliminada de todas las piezas referencia.

Cuando se elimine una pieza referencia desde la pieza maestra, las especificaciones

de la pieza referencia empezarán a ser editables y se podrá añadir nuevas

especificaciones a la pieza.

Los usuarios que tienen el rol de Part Family Coordinator pueden visualizar y gestionar series de

piezas desde la página “Maestra”. Esta página contiene filtros que pueden limitar el número de

miembros de la familia de piezas. Por defecto, todas las piezas maestras son mostradas, y las

piezas referencia se muestran solo cuando las piezas maestras se extienden. Las piezas de la

familia no asignadas aparecen al final de la lista.

4.2.4.3 Clonación de una pieza.

Si queremos crear una pieza que sea similar a una pieza existente, podemos clonar la pieza

existente y aplicarle cambios en diferentes opciones o atributos. Por defecto, las piezas pueden

ser clonadas por los usuarios que tengan asignados algunos de los siguientes roles: Component

Engineer, Design Engineer, Senior Design Engineer, Manufacturing Engineer, o Senior

Manufacturing Engineer.

La clonación no valida la estructura. Por ejemplo, ciertas relaciones pueden que no se validen en

el estado “Preliminar” de la pieza (el estado en el que la producción de piezas es creada).

4.2.4.4 Definición de una pieza alternativa.

Una pieza alternativa es un componente que puede reemplazar a otra pieza en cualquier

ensamblaje en el cuál la pieza original toma parte. Hay que tener cierto cuidado al hablar de

pieza alternativa y de pieza sustituta, ya que son muy parecidas. Recordemos que una pieza

sustituta es un componente que puede reemplazar a otra pieza solamente en un ensamblaje en

el cual la pieza original tome parte. Por tanto la diferencia entre la pieza alternativa con la pieza

sustituta está en la unicidad o totalidad de ensamblajes en los que toma parte.

4.2.4.5 Documentos de referencia de piezas.

Podemos asociar documentos a las piezas con las relaciones de los Documentos de referencia

para diferenciarlos de una especificación, la cual definiría una pieza. Las relaciones de los

Documentos de Referencia se utilizan para la regulación o como requisitos de negocio internos.

Un documento de referencia puede estar conectado a una pieza en cualquier estado de su ciclo

de vida.

Un documento de referencia puede existir sin estar conectado a una pieza. En dicho caso, no se

requiere una ECO para liberar el documento.


114

La página de Documentos de referencia muestra una lista con los documentos conectados a las

piezas mediante las relaciones de Documentos de referencia. Se pueden añadir documentos

adicionales desde la base de datos o de un servidor externo.

4.2.4.6 Definición de una pieza derivada.

Una pieza derivada es un componente creado mediante clonación o reemplazamiento de una

pieza.

- Pieza clonada: cuando el comando de clonación de una pieza se utiliza, la relación

derivada va siempre desde la pieza clon hasta el contexto de la pieza en su nivel

superior. Por tanto puede haber diversas piezas clonadas a partir de una pieza

simple. Por ejemplo, si una pieza A es clonada para hacer una pieza B, la relación

derivada va desde la pieza B hacia la pieza A.

Figura 47. Esquema lógico de una pieza derivada. Clonación.

- Pieza reemplazada: cuando una pieza es reemplazada por otra pieza, ya sea nueva

o existente, la relación derivada es entre la pieza sustituida y su origen. Por ejemplo

si la pieza F es reemplazada por la pieza K, la relación derivada va de la pieza K a la

pieza F.

Figura 48. Esquema lógico de una pieza derivada. Reemplazo.


115

4.2.5 Cambios de ingeniería.

Una ECR (solicitud de cambio de ingeniería) es utilizada para identificar los problemas o

requisitos para un cambio en una pieza existente o en una Especificación de una Pieza. Diversas

ECRs pueden estar basadas en una pieza simple o una especificación de una pieza, cuando ella

está en el estado “Preliminar”. La ECR contiene la lista de piezas afectadas por los cambios, las

especificaciones de las piezas y las recomendaciones para los cambios. Los usuarios con los

siguientes roles asignados podrán crear una ECR:

Ingeniero de Diseño, ECR Chairman, ECR Coordinator, Manufacturing Engineer, Part Family

Coordinator, Product Obsolescence Manager, Senior Design Engineer y Senior Manufacturing

Engineer.

Las ECRs son evaluadas y revisadas por el equipo asignado y pueden ser aprobadas,

rechazadas o revisadas de nuevo. Cuando una ECR es aprobada es enviada al ingeniero de

diseño, quien creará la ECO (Engineering Change Order) para definir cómo los cambios

requisados van a ser implementados.

Una ECO identifica lo siguiente:

- Todas las piezas nuevas y/o especificaciones creadas para acomodar los cambios.

- Todas las piezas y/o especificaciones revisadas.

- Cualquier pieza y/o especificación existente que esté actualmente obsoleta o que no

haya sido requerida en un largo período de tiempo.

- Detalles específicos de cambios de piezas existentes y/o especificaciones.

- Efectividad de Ingeniería de todas las piezas identificadas en la ECO.

Una ECR (Engineering Change Request) es creada cuando un problema es identificado en una

pieza o en una especificación de una pieza, o cuando ambas necesitan modificaciones. La ECR

es adjuntada a las piezas específicas y dibujos que son afectados. Una ECR también puede ser

generada para introducir un producto nuevo en la base de datos o un producto obsoleto con una

pieza existente.

La ECR debe pasar por un proceso de revisión y aprobación para determinar si los cambios han

sido realizados. Si la ECR ha sido aprobada, será enviada al Ingeniero de Diseño que creará la

ECO (Engineering Change Order).

La ECO identifica las piezas y especificaciones que deben ser revisadas, los cambios exactos

que se deben producir y la efectividad del cambio. Las nuevas Especificaciones serán

adjuntadas a la ECO para que sean revisadas.

Para realizar los cambios identificados en la ECO, el Ingeniero de Diseño creará nuevas piezas o

revisará las piezas existentes, creando una BOM de las piezas y adjuntando las especificaciones

requeridas.

Una vez que la ECO ha sido revisada y aprobada por el Ingeniero de Fabricación, las piezas

nuevas revisadas o las especificaciones son liberadas para ser fabricadas.


116

4.2.5.1 Solicitud de cambio de ingeniería (Engineering Change Request - ECR).

Cuando se requiere un cambio en una pieza que pertenece a una línea de producto de la

empresa, se crea una Solicitud de Cambio de Ingeniería (ECR – Engineering Change Request)

detallando los cambios que son necesarios hacer. Las ECRs se utilizan para identificar

problemas o cambios requeridos, relacionados con el objeto de negocio existente. El ECR

Originator puede adjuntar croquis, piezas, o dibujos en función del detalle de trabajo que

necesita la implementación del cambio.

Las ECRs son revisadas por el ECR Evaluator, que revisa toda la documentación aportada y la

disposición de piezas para determinar el impacto, después decidirá si aprobar o rechazar la

solicitud. Si la solicitud es aprobada, el Responsible Design Engineer asignado creará una

“Orden de cambio de ingeniería (Engineering Change Order - ECO)” que definirá cómo se

implementará el cambio e incluirá las piezas y dibujos adjuntos necesarios.

Una vez que los ingenieros de diseño y los delineantes presentan los diferentes documentos

CAD y listas de materiales necesarias, el Responsible Manufacturing Engineer revisa la ECO e

incluso puede actualizar alguno de sus atributos.

Cuando una ECR se promueve al estado “Completado” o una ECO es promovida al estado

“Liberado”, se le asigna un usuario especial llamado “Corporate”. Esto tiene el efecto de bloqueo

de la ECR o la ECO, no pudiéndose realizar cambios adicionales.

Una ECR tiene los siguientes estados en su ciclo de vida:

- Creado: la ECR ha sido creada y se nombrará automáticamente por el sistema. El

creador de la ECR tiene la opción de adjuntar piezas y especificaciones que serán

afectadas por estos cambios. Después de crearla el creador promoverá la ECR al

estado “Presentación”.

- Presentación: en este estado el propietario es automáticamente cambiado y la ECR

dirigida al Coordinador de ECR de la organización. El ECR Coordinador puede

añadir más artículos afectados de la ECR y puede promover la ECR al estado

“Evaluado” o también cancelar la ECR.

- Evaluado: en este estado el propietario es automáticamente cambiado al

Responsable Ingeniero de Diseño especificado, el cual deberá asignar todos los

artículos afectados añadidos por el ECR Coordinator y el ECR Originator. El

Ingeniero de Diseño Responsable evaluará la ECR y la promoverá al estado

“Revisado” o cancelará la ECR.

- Revisado: se cambiará la propiedad automáticamente al ECR Chairman. El ECR

Chairman revisará la ECR y la promoverá al estado Plan ECO o cancelará la ECR.

- Plan Eco: se cambiará la propiedad automáticamente al Ingeniero de Diseño

Responsable, al cual ha sido dirigida la ECR. El Ingeniero de Diseño asignará los

artículos afectados para la implementación de una nueva o existente ECO. Una vez

hecho esto se activará el menú de asignaciones a la ECO, este menú es propio del

estado Plan ECO.


117

- Completado: en este estado la propiedad cambiará automáticamente a un usuario

especial llamado Corporate. Esto bloquea la ECR aguas abajo no permitiendo

cambios adicionales. La ECR puede ser promovida a este estado manualmente

desde el estado Plan ECO o cuando alguna ECO adjunta a la ECR es elevada al

estado “Liberada”.

- Cancelado: la ECR es cancelada. La ECR puede ser cancelada en cualquier estado

anterior al estado Plan ECO. Esto finaliza el proceso de gestión de cambios para

todos los artículos afectados.

Por defecto, las solicitudes de cambio de ingeniería pueden ser creadas por usuarios que tengan

asignados alguno de los siguientes roles: Design Engineer, Senior Design Engineer,

Manufacturing Engineer, Senior Manufacturing Engineer, ECR Evaluator, ECR Chairman, Part

Family Coordinator o Product Obsolescence Manager.

4.2.5.2 Orden de cambio de ingeniería (Engineering Change Order - ECO).

Por defecto, las órdenes de cambio de ingeniería pueden ser creadas por usuarios que tengan

alguno de los siguientes roles: Design Engineer, Senior Design Engineer, Manufacturing

Engineer o Senior Manufacturing Engineer.

Una ECO puede ser creada a partir de una ECR ya existente o sin una ECR. Las ECOs que son

creadas sin una ECR describen todos los requisitos de cambio para los objetos afectados.

La ECO tiene los siguientes estados en su Ciclo de Vida:

Creado: en este estado la ECO es creada y nombrada automáticamente por el sistema por

defecto. El estado Creado permite: adjuntar una o más ECRs si la ECO es liberada de piezas o

especificaciones de piezas. Y también promover al siguiente estado “Definir componentes”.

Definir Componentes: es el estado en el que la ECO es dirigida al responsable, que será un

Ingeniero de Diseño. El ingeniero de diseño puede: revisar las ECRs adjuntados si es preciso,

identificar las piezas y dibujos que son afectadas, crear nuevas piezas o revisar piezas

existentes y adjuntar todo ello a la ECO. Por último puede promover la ECO al estado “Trabajo

de diseño”.

Trabajo de diseño: en este estado el trabajo de diseño se lleva a cabo. En este estado el

ingeniero de diseño puede asignar a los delineantes o ingenieros de diseño para trabajar en las

piezas que necesitan cambios. El ingeniero de diseño revisa el trabajo y lo asigna si es

aceptable. Una vez que todas las piezas y dibujos están conectadas a la ECO, pasan a estar en

el estado “Aprobado”, la ECO puede ser promovida al estado “Revisado”. Un método alternativo

es cuando las piezas/dibujos están en el estado “Revisado”, que la ECO sea promovida al

estado “Revisado”.

Revisado: en este estado la ECO es automáticamente dirigida al Ingeniero responsable de la

Fabricación. El ingeniero de Fabricación puede: probar la efectividad de los datos para las

nuevas piezas, actualizando el lead time y los costes estimados o promover la ECO al estado

“Liberado”.


118

Liberado: en este estado la ECO se bloquea y no puede realizarse ningún cambio adicional en

ella.

Implementado: en este estado los cambios que han sido definidos por la ECO serán

implementados por Fabricación.

Cancelado: en este estado la ECO es cancelada. Esto podía haberse realizado antes del estado

Liberado. El sistema desconecta todos los procesos de revisión, termina con todas las rutas y

borra todas las tareas asociadas.

4.2.5.3 Orden de cambio de desarrollo de ingeniería (Development

Engineering Change Order - DECO).

Las Órdenes de cambio de desarrollo de ingeniería son utilizadas para mover el último desarrollo

de una pieza al estado “Completado” y controlar los cambios en las siguientes revisiones o sub

secuencias de revisión. Cualquier rol derivado del rol Team Design Engineer puede trabajar en el

proceso de las Órdenes de cambio de desarrollo de ingeniería.

Por defecto, una DECO no es obligatoria para completar el desarrollo de una pieza. Esta opción

es configurable utilizando la propiedad emx.TeamEngineering.TeamChange.Mandatory que por

defecto se encuentra en el estado “False”. No obstante, una vez que una revisión de una pieza

es asignada a una DECO, los siguientes cambios son controlados por la DECO.

Los usuarios con los roles VPLM Creator y VPLM Project Leader tienen acceso a la creación de

una DECO. Cuando la Central de Ingeniería está instalada, los usuarios con el rol Design

Engineer pueden crear cambios en el desarrollo.

Solo las piezas en desarrollo pueden ser añadidas como objetos afectados a una DECO. Si un

desarrollo de una pieza está conectado a una DECO, la misma pieza no puede estar conectada

a otra DECO diferente. La cardinalidad entre la pieza y la DECO es 1:1.

La revisión de la pieza se hará siempre de forma manual vía Pieza > Revisión > Crear nueva.

Una vez que una revisión ha sido asignada a una DECO, los cambios consecuentes serán

controlados por la DECO.

Los desarrollos de piezas en el estado “Creado” o un estado anterior pueden ser añadidos como

objetos afectados a la DECO. Las piezas en el estado “Completado” no pueden ser añadidas

como objetos afectados.

La DECO controla la liberación de los objetos afectados. Todas las piezas afectadas deberían

estar en el estado “Revisión” antes de ser promovidas al estado “Completado”.

4.2.6 Efectividad del producto.

Los servicios de Configuración y Efectividad ENOVIA proporcionan una interfaz para definir el

criterio de efectividad para el cual cada objeto será válido dentro de un grupo parental. Las


119

opciones de efectividad incluyen fecha, unidad, revisión de producto, y opciones de

características.

ENOVIA V6 añade la definición de efectividad basada en secuencias de valores o de una fecha

como novedad. Esto nos permitirá definir relaciones de efectividad entre los diferentes objetos.

La Efectividad define el criterio por el cual un objeto es válido dentro del grupo parental. Por

ejemplo, una especificación particular dentro de una carpeta de especificaciones puede ser

válida solamente dentro de cierto rango de fechas. También puede ser un requisito del producto

válido para determinadas revisiones de producto. Podemos crear una definición de efectividad

para cualquier objeto cuyo “Tipo” haya sido configurado con efectividad. El System Administrator

debe configurar la efectividad para el Tipo del objeto o sus relaciones.

El Editor de Definición de Efectividad es un formulario que puede ser utilizado para definir la

efectividad del objeto o de sus relaciones, dependiendo del contexto para el que queremos que

aparezca activo. El formulario contiene tres secciones:

- El contenido de la sección “Selector de efectividad” varía dependiendo de la

selección hecha en la lista “Tipo”, la cual contiene los tipos de efectividad que están

disponibles en el contexto del objeto o de sus relaciones. Al seleccionar el valor

“Tipo” se actualiza de manera dinámica y se muestran los diferentes valores en los

correspondientes campos que afecte el tipo de efectividad.

- La sección “Expresión de Efectividad” es el lugar donde construimos la expresión.

- La sección “Expresión completada” es un campo de lectura en el que se muestra la

forma legible de la expresión de Efectividad.

4.2.7 Lista de materiales del producto.

4.2.7.1 BOM.

La lista de materiales (BOM) es un informe tabulado de todas las piezas que están incluidas en

un ensamblaje. Contiene información que puede ser buscada por números, referencias,

unidades de medida, cantidades, descripciones o usos.

La lista de materiales contiene un modo de vista que proporciona una información comprensible

de la pieza y enlaza varios informes de listas de materiales. En el modo edición, la página de la

Lista de materiales permite una edición en un nivel simple o en múltiples niveles

A la BOM se puede acceder desde el menú Categorías de la pieza. Esto nos sirve como un

recurso de información sobre cada pieza e incluye el estado de cada pieza en el BOM.

Los BOMs por defecto son únicos basándose en los números de búsqueda, pero pueden ser

configurados como únicos basándose en los identificadores de referencia de diseño u otros

atributos. El Business Administrator tiene información de cómo los BOMs son configurados para

la instalación.


120

Podemos crear una Lista de materiales (BOM) añadiendo una pieza nueva o piezas que ya

existan en la base de datos. Podemos copiar la estructura de una BOM de piezas ya existente en

la base de datos y editarla para crear una nueva BOM.

El BOM PowerView proporciona la habilidad de ver, modificar y generar diferentes informes

basados en la BOM. Esto nos permite el copiado de una BOM para después utilizarla como

estructura modelo de una nueva estructura.

La funcionalidad BOM go to Production nos da la habilidad de mover la BOM completa y

desarrollada a la producción. Para promover la BOM a la producción se deben cumplir las

siguientes condiciones:

- El desarrollo de la pieza debe estar en la última revisión y en el estado

“Completado”.

- Los usuarios puedan tener los accesos a Revisar, Cambiar política y modificar de la

pieza.

Todas las piezas jóvenes de la BOM deben ser elegidas para moverlas a la producción,

satisfaciendo las siguientes condiciones: todas las piezas jóvenes tienen que ser Piezas en

Desarrollo y además deben estar en la última revisión y en el estado “Completo”.

La EBOM (Engineering Bill of Materials) o lista de materiales de ingeniería muestra la jerarquía

de los elementos usados en la fabricación de la pieza. Los elementos son clasificados como

padres e hijos en la jerarquía. Además de esta jerarquía la EBOM muestra el número de

elementos (cantidades) requeridos para el ensamblaje de la pieza. También contiene información

sobre la localización exacta de la pieza en la EBOM.

4.2.7.2 Sincronización de BOM.

Los usuarios con los roles de VPLM Creator o VPLM Project Leader pueden modificar y

sincronizar las listas de materiales (BOM) entre VPM y el Team BOM Editor (TBE) o la

Engineering Configuration Central. Cuando el producto es promovido al estado Liberado, es

automáticamente sincronizado con el BOM si fue manualmente sincronizado con el BOM alguna

vez anteriormente. No obstante, si anteriormente no ha sido sincronizado con el BOM, la

sincronización automática no sucederá.

4.3 Implantación en ENOVIA V6.

A continuación se realizará la implementación de los conceptos definidos en el apartado anterior,

para ello se utilizará el producto “Mordaza” descrito anteriormente y se realizará una descripción

del procedimiento para la aplicación de ENOVIA V6 en la implementación de los diferentes

conceptos.


121

4.3.1 Creación de la estructura organizativa.

En este primer apartado se realizará la definición de toda la estructura organizativa de una

empresa. Se implementarán los conceptos de Organización, Usuario y Proyecto, y se

describirán las diferentes relaciones entre ellos.

Antes de comenzar con la implementación de toda la estructura organizativa hay que destacar

que se trabajará con un usuario genérico con el rol VPLM Administrator asignado, con la

empresa que trae ENOVIA V6 por defecto al igual que el proyecto.

Figura 49. Contexto de seguridad del usuario inicial.

Una vez que se ha abierto ENOVIA V6 tras el registro, aparecerá la página principal de ENOVIA.

Tanto para la definición de la organización, el usuario como el proyecto se deberá acceder al

menú global “Herramientas” y seleccionar en la sección “Experience Configuration” el apartado

“Configure My ENOVIA”.


122

Figura 50. Menú global Herramientas.

Se abrirá la página de configuración de ENOVIA, a partir de la cual se creará toda la estructura

organizativa. A continuación se hará una descripción del procedimiento de creación de una

organización, un usuario y un proyecto a partir de esta página.

Figura 51. Página de configuración de ENOVIA.

4.3.1.1 Creación de la organización.

Para definir la organización a partir de la página de configuración de ENOVIA, se debe

seleccionar “Organization” y después seleccionar “Create”, aparecerá la siguiente página:


123

Figura 52. Página de creación de la organización.

Aparecen diferenciadas 4 secciones: “Organización”, “Tipo de organización”, “Dirección” y

“Organización parental”.

En la sección “Organización” se deberá rellenar el campo “Organization name” (único campo

obligatorio) y el identificador de la organización.

La sección “Tipo de organización” ofrece tres posibilidades a elegir: “Unidad de negocio”,

“Departamento” y “Compañía” que aparecerá por defecto.

En la sección “Dirección” se debe rellenar los campos relacionados con la dirección de la

empresa tales como calle, ciudad, país…

Por último, en la sección de “Organización parental” se debe elegir entre las diferentes

organizaciones si fuese el caso de que hubiese una empresa matriz que englobase la

organización que se está creando o no elegir ninguna seleccionando “None”, creándose así una

empresa matriz.

En la implementación de la organización se creará una empresa llamada “TFG Organization

Mordaza”, por tanto el tipo de organización será “Company” y no tendrá relación parental. Para

crearla pulsaremos el botón “Create”.

Para comprobar que la organización ha sido creada, en el menú de gestión de la organización en

el apartado “Búsqueda” se deberá seleccionar “Search” con el campo “Name” relleno por un

asterisco (por defecto) o utilizar los diferentes campos rellenándolos con la información necesaria

para buscar la organización deseada.

Se abrirá una nueva página mostrando todas las organizaciones creadas y su información

relacionada:


124

Figura 53. Página de gestión de las organizaciones.

En esta página también se podrá modificar y editar la información de todas las organizaciones

creadas.

4.3.1.2 Creación del usuario.

Al igual que en la creación de la organización, una vez en la página de configuración de ENOVIA

se debe seleccionar “Person” y seguidamente “Crear”. Aparecerá una nueva página con los

diferentes campos a rellenar para la creación del usuario.

Figura 54. Página de creación del usuario.

Se deberá rellenar la información sobre el usuario especificando campos tales como nombre,

apellidos, email, teléfono…

El identificador de usuario (campo obligatorio) será el nombre de usuario y la contraseña que se

deberá introducir para entrar en ENOVIA.

Después de rellenar los datos personales del usuario se deberá especificar la organización a la

que pertenece, la organización de la cual es miembro y la organización actual.

El administrador deberá asignar las licencias correspondientes al nuevo usuario según su

función dentro de la empresa. Por último deberá asignar los proyectos a los que el nuevo usuario

tendrá acceso y el rol con el que podrá acceder.

A continuación se creará un nuevo usuario con diferentes licencias y accesos:


125

Figura 55. Ejemplo de creación del usuario.

Al igual que con la organización, se pueden ver todos los usuarios y administrarlos según se

quiera que estén activos o no. Para ello tan solo hay que acceder a la página “Búsqueda”:

Figura 56. Página de gestión de usuarios.

4.3.1.3 Creación del proyecto.

Para crear un proyecto tan solo hay que seleccionar en la página de configuración de ENOVIA la

opción “Project” y seleccionar “Crear”. Se abrirá una nueva página en la que se definirá el

proyecto, la organización a la que pertenece y los usuarios que pueden acceder a dicho proyecto

con sus respectivos roles asignados.

A continuación se definirá un proyecto, asociado a la organización y al usuario anteriormente

creado.


126

Figura 57. Ejemplo de creación de un proyecto.

Por último tan solo hay que comprobar que el usuario puede acceder con su rol, organización y

proyecto asignado, conformando de esta forma el contexto de seguridad. Es muy importante

destacar que el ID del usuario se utilizará como nombre del usuario y contraseña, en nuestro

caso para el ejemplo “jesusnun”.

Figura 58. Comprobación de datos del nuevo usuario.

Figura 59. Comprobación del rol asignado al nuevo usuario.

Se comprueba que la creación del usuario, organización y proyecto ha sido satisfactoria.


127

Figura 60. Página principal del nuevo usuario.

4.3.2 Creación de Línea de Producto, estructura y sincronización.

En este apartado se definirá una nueva línea de producto y a partir de esta los diferentes

modelos y líneas de producto subordinadas en una distribución ramificada, proporcionando la

estructura de la Línea de Producto. Una vez realizada la Línea de Producto se podrá sincronizar

con el VPM las diferentes partes.

Comenzaremos con la vista de las diferentes líneas de producto, para ello se seleccionará en el

menú “Mi Enovia” el apartado “Línea de productos”

Figura 61. Menú global “Mi Enovia”.


128

Aparecerá una nueva ventana que mostrará todas las líneas de producto creadas. Al no tener

ninguna línea de producto, esta página se muestra vacía.

Figura 62. Página de Líneas de producto.

Se creará por tanto una nueva Línea de Producto, que en nuestro caso será la Mordaza con sus

diferentes elementos y montajes.

Seleccionando en el menú “Acciones” “Crear Línea de Productos”

Figura 63. Menú global “Acciones”.


129

Figura 64. Página de creación de una nueva Línea de producto.

Aparecerá una nueva ventana en la que habrá que especificar en cada campo las características

de la nueva línea de producto. Los diferentes campos son:

- Nombre: se especificará el nombre de la nueva línea de producto o se tendrá que

seleccionar en la pestaña el nombramiento automático. Este nombramiento sigue el

formato PL-nnn, donde “nnn” representa un número secuencial. En general, las

líneas de producto son nombradas mediante siglas descriptivas cortas. Hay que

tener especial atención con ciertos caracteres que no son permitidos en el campo

Nombre.

- Tipo: se tendrá que especificar el nombre del tipo o lo buscaremos en el botón

contiguo para elegir el tipo o subtipo de línea de producto. El valor por defecto es el

tipo Línea de Producto. Es un campo obligatorio a rellenar.

- Descripción: en este campo se especificarán los detalles de la Línea de Producto.

Se pueden utilizar los botones de edición para asignarle un formato al texto (negrita,

cursiva, subrayada…) si se desea.

- Propietario: se hará la elección en el botón contiguo del propietario. Por defecto, el

propietario es la persona que está creando la Línea de Producto.

- Compañía: en el botón contiguo se tendrá que elegir entre las diferentes unidades

de la compañía o la empresa que trabajan en dicha línea de producto. Por defecto,

la compañía es la propia compañía del creador. Es un campo obligatorio.

- Nombre de Marketing: automáticamente este campo se nombra con el Nombre que

se haya introducido. Se puede nombrar con el nombre por defecto o asignarle un

nombre diferente. Es un campo obligatorio. Al igual que en el campo Nombre, ciertos

caracteres no están permitidos en este campo.

- Responsabilidad del diseño: en el botón contiguo se asignará la responsabilidad del

diseño de la línea de producto a una organización o a otro proyecto.

o Sin pinchamos en Borrar eliminaremos la responsabilidad de diseño,

quedando la línea de producto accesible a todos los Product Managers y


130

System Engineers de la compañía. Este cambio se hará efectivo cuando

pinchemos en “Listo”. Si la responsabilidad es asignada a un grupo en el

que el usuario no está incluido, no tendrá acceso en el futuro a los datos.

- Programa: se seleccionará entre los diferentes programas el asociado a la nueva

línea de producto.

- Directiva: es un campo que muestra por defecto la directiva que controla la línea de

producto.

- Texto de marketing: campo en el que se introducirá el texto con la descripción de la

línea de producto desde el punto de vista del marketing.

Una vez rellenos todos los campos según los datos de la nueva línea de producto se pulsará el

botón “Listo” y la línea de producto será creada.

Figura 65. Verificación de creación de Línea de producto.

A continuación aparecen las propiedades de la nueva línea de producto que muestra la

información sobre los modelos, sub-líneas de producto, historial, imágenes y ciclo de vida.

Podemos acceder a esta página seleccionando el nombre de cualquier línea de producto desde

cualquier lugar del Gestor de Líneas de Productos. Cuando una página de propiedades de línea

de productos es abierta, a la izquierda aparece toda la estructura de la línea de productos con

todos los artículos asociados.

A destacar que dichas propiedades se pueden editar de la línea de productos. Sólo los Product

Managers y los System Engineers pueden realizar cambios a las líneas de productos. A la

página de edición de detalles se accede a través de la página de propiedades de la Línea de

producto.


131

Figura 66. Detalles de la Línea de producto.

Si una línea de producto está formada por más de una Línea de Productos, se puede decir que

esta Línea de Productos puede ser representada como el padre de todas esas Líneas de

Producto.

Realizaremos un ejemplo para nuestro caso. A partir de la Línea de Producto “Mordaza”

crearemos varías sub-líneas de productos (Mordaza sección cuadrada y Mordaza sección

circular).

Para ello en el apartado Categorías de la página de propiedades de la Línea de Productos se

seleccionará “Líneas de productos subordinados”

Figura 67. Menú “Categorías” de una Línea de Producto.

Aparecerá la siguiente página:


132

Figura 68. Página de Líneas de productos subordinados.

Seleccionaremos “Activar Editar”, elegiremos la Línea de Producto e iremos al apartado

“Acciones” donde aparecerán diferentes opciones:

- Crear nuevo: aparecerá de nuevo la página para crear una nueva línea de producto

o sub-línea de producto.

- Agregar existente: ofrece la posibilidad de añadir una Línea de Producto existente en

la base de datos como sub-línea de producto.

- Eliminar: elimina cualquier sub-línea de producto de la Línea de Productos elegida y

también la elimina de la base de datos.

- Quitar: elimina cualquier relación entre la Línea de Productos padre y la sub-línea de

producto elegida. Aunque esto no elimina la sub-línea de productos de la base de

datos.

En nuestro caso crearemos las dos sub-líneas de producto al no tener diferentes Líneas de

Productos. Una vez creadas las dos sub-líneas de producto se guardarán los cambios pulsando

el botón “Guardar”.

Figura 69. Creación de Línea de producto subordinada.

Figura 70. Vista de las Líneas de producto subordinadas creadas.


133

A continuación añadiremos tanto a la Línea de Productos padre como a la sub-línea de producto

“Mordaza sección circular” un modelo.

Un modelo proporciona una visión completa de las creaciones de productos y sus

configuraciones gestionadas por ese modelo. Los modelos controlan las unidades o rango de

construcciones de cada producto y asigna un número a cada unidad según las construcciones y

revisiones del producto gestionado. Un modelo es una colección de productos, características y

requisitos. Cuando se crea un modelo, automáticamente se crea un producto con el mismo

nombre.

Figura 71. Creación de un modelo.

Comenzando con la mordaza padre, en el menú de propiedades al igual que agregar sub-líneas

de producto aparece “Modelos”, la seleccionamos apareciendo una nueva página. En ella

seleccionaremos “Acciones” desplegándose las diferentes opciones: crear nuevo, agregar

existente, agregar a la cartera, eliminar y quitar.

En este ejemplo se creará un modelo nuevo y por tanto un nuevo producto.

Figura 72. Página de gestión de los modelos.

Hay que rellenar diferentes campos especificando:


134

Figura 73. Página de creación de un modelo.

- Nombre: hay que escribir el nombre del modelo o elegir el nombre automático que el

sistema asignará a este modelo. Es un campo obligatorio.

- Tipo: se tiene que seleccionar el tipo de modelo. Por defecto el tipo es “Modelo”. Es

un campo obligatorio.

- Línea de productos: seleccionaremos la línea de producto para este modelo. Si

estamos creando el modelo desde el contexto de la línea de productos, este campo

aparecerá relleno con el nombre de la línea de producto desde la que estamos

realizando la operación.

- Prefijo de modelo: elegiremos el prefijo que marcará a todos los productos y sus

configuraciones que pertenezcan al modelo. Se pueden utilizar tanto números como

letras, y debe ser único.

- Descripción: en este campo se describen todos los detalles asociados al modelo.

- Propietario: se asignará el propietario. Por defecto se le asignará a la persona que

está creando el modelo.

- Responsabilidad de diseño: se asignará la responsabilidad del modelo a una

organización o proyecto diferente.

- Nombre de marketing: este campo se rellenará automáticamente con el nombre que

se haya especificado en el campo Nombre. Podemos aceptar el nombre que se

asigne por defecto o especificarlo. Es un campo obligatorio.

- Texto de marketing: especificaremos en este campo el texto de marketing asociado

al producto.


135

- Directiva: es un campo de lectura que muestra por defecto la directiva que controla

el modelo.

Siguiendo el ejemplo creamos el modelo de la Línea de Productos padre:

Figura 74. Detalles del modelo creado.

Se puede observar que en la página de Modelos aparecen diferentes campos que se han

especificado en la creación del modelo.

Análogamente crearemos el modelo “Alfa” para la sub-línea de productos:

Figura 75. Página de modelos de las líneas de productos subordinadas.

Figura 76. Detalles del modelo de la línea de productos subordinada.

Si seleccionamos uno de los modelos (“Mordaza parental” o “Alfa”) se abrirá una nueva página

de propiedades del Modelo.

Se pueden editar detalles, añadir el modelo a una cartera ya existente, añadir piezas al nivel

superior del modelo, también podemos crearlas o eliminarlas.


136

Al igual que en las Líneas de Producto, en los modelos todas estas propiedades se pueden

cambiar, para ello hay que tener el rol de Product Manager o System Engineer.

También hay que destacar que un modelo puede incluir múltiples revisiones de los productos.

Para ello, en la página del modelo seleccionamos en “Acciones” “Crear nueva revisión” y

especificaremos la Revisión y la descripción de dicha revisión.

Figura 77. Creación de una nueva revisión del modelo.

Figura 78. Detalles de revisión del modelo.

Tenemos toda la estructura de la línea de productos pero falta adjuntar las piezas. Para ello, con

el ejemplo usaremos el modelo “Mordaza parental” para adjuntar todas las piezas.

Primero debemos salir del gestor de Líneas de Productos, en el menú general “Mi Enovia”, en el

apartado “Línea de productos” seleccionaremos “Productos”, se abrirá una nueva ventana en la

que aparecen todos los “Modelos” o “Productos” existentes.

Figura 79. Página de productos.


137

Tras seleccionar el modelo “Mordaza parental” en la página de propiedades de nuestro modelo

en el apartado “Categorías” seleccionaremos GBOM. De nuevo aparecerá una nueva página en

la que seleccionaremos en el apartado “Acciones” la opción “Agregar pieza existente”.

Seleccionamos en nuestro caso la pieza “mordaza”.

Figura 80. Agregar pieza a un modelo.

Volviendo al gestor de Líneas de Productos se puede observar la estructura creada en la nueva

Línea de Productos “Mordaza” con sus diferentes sub-líneas de productos, modelos, revisiones y

piezas.

Figura 81. Detalle de la estructura de la Línea de producto creada.

4.3.3 Creación de producto.

La página de productos muestra una lista con todos los productos propios existentes o asignados

por el usuario. Podemos acceder a la página de Productos mediante la barra de herramientas

global. Para ello en el menú “Mi Enovia” debajo de Línea de producto, seleccionamos


138

“Productos”. Podemos utilizar el filtro que se encuentra en la esquina superior derecha de la

página con el que podemos cambiar la lista de productos que se muestra.

Figura 82. Página principal de productos.

Figura 83. Página de creación de un nuevo producto.

Para crear un producto, a partir de la página “Productos” tan solo tenemos que seleccionar en el

menú Acciones “Crear”.

Los diferentes campos que hay que rellenar son:


139

- Nombre: escribiremos el nombre del nuevo producto o seleccionamos Nombre

automático. Si no utilizamos nombre automático el valor de este campo se copiará al campo

Nombre de marketing. Cuando se crea una revisión inicial del producto, un modelo es

automáticamente creado con el mismo nombre y es conectado al producto. Si estamos creando

un producto bajo el contexto de un modelo, el campo del nombre es automáticamente rellenado

con el nombre del modelo y solo se puede leer. Es un campo obligatorio.

- Tipo: seleccionamos el tipo de producto que queremos crear. Por defecto, las opciones

son “Producto Hardware” (por defecto),”Producto de Servicio” o “Producto Software”. Es un

campo obligatorio.

- Rev.: muestra el número o código de revisión. También es un campo obligatorio.

- Prefijo de modelo: se designará el prefijo del modelo que llevarán todos los productos y

configuraciones de productos creadas bajo ese modelo. Utilizará caracteres alfanuméricos. El

prefijo debe ser único en toda la base de datos.

- Descripción: una descripción de los detalles del producto. Se puede dar formato al

texto, aunque hay ciertos caracteres que no están permitidos.

- Compañía: se puede asignar diferentes compañías al nuevo producto. Por defecto la

compañía que se asignará será la propia del creador.

- Propietario: se tendrá que seleccionar el propietario que, por defecto, será la persona

que está creando el nuevo producto.

- Responsabilidad de diseño: asignaremos la responsabilidad de diseño del producto a

las diferentes organizaciones o proyectos. Si seleccionamos “Borrar”, eliminaremos la

responsabilidad de diseño, quedando la línea de productos accesible a todos los Product

Managers y System Engineers de la compañía. Este cambio se hará efectivo una vez pulsemos

el botón “Hecho”. Si la responsabilidad es asignada a un grupo al que no pertenecemos, no

tendremos acceso a los datos. Hay que destacar que el Responsible Design Organization (RDO)

puede actualizar todos los productos que permanezcan en el estado “Preliminar”. Una vez que

se promueve de este estado, el RDO no puede realizar cambios. Una vez que la responsabilidad

de diseño es asignada, todas las revisiones que se realicen pertenecerán al mismo responsable.

- Nombre de marketing: este campo será automáticamente rellenado con el mismo valor

que el campo Nombre. Pudiendo aceptar el nombre por defecto o cambiarlo. Ciertos caracteres

no están permitidos. Es un campo obligatorio.

- Texto de marketing: contiene el texto de marketing del nuevo producto.

- Precio base: muestra el precio inicial del nuevo producto.

- Inicio de efectividad: seleccionaremos la fecha de inicio de la efectividad del producto.

- Fin de efectividad: seleccionaremos la fecha de finalización de la efectividad del

producto.

- Disponibilidad web: seleccionaremos el estado de disponibilidad web: Productos

liberados, Productos liberados y efectivos o No disponible. Si seleccionamos Producto liberado y


140

efectivo, y las fechas de inicio y fin de efectividad están vacías, aparecerá un mensaje de error,

teniendo que introducir dichas fechas para continuar.

- Directiva: es un campo de lectura que muestra la directiva que controla el producto.

4.3.3.1 Clonar un producto por copiar selección.

Esta herramienta permite usar “Copiar selección” para copiar la definición de la estructura. Esta

acción permite la selección de un producto solamente a la vez. Si más de un producto es

seleccionado a la vez, aparecerá un error. Esta selección incluye toda la estructura y reglas del

producto incluyendo:

- Características de los niveles superiores del producto seleccionado.

- Características de los hijos del producto seleccionado, reglas del producto

seleccionado.

- Piezas del nivel del producto.

- Todas las especificaciones relacionadas.

La función de clonar no copia:

- Construcciones.

- Revisiones.

- Versiones.

- Rutas.

- Problemas.

Figura 84. Clonación por copia selección.

Para clonar un producto: seleccionaremos el producto a clonar, que en nuestro caso será el

producto “Alfa”. Seleccionaremos en el menú Acciones la opción “Copiar seleccionado”.

Se nos abrirá una nueva página


141

Figura 85. Página de copiar selección.

Seleccionaremos el Destino del producto donde la estructura y sus reglas serán copiadas.

Finalizaremos seleccionando “Listo”.

4.3.3.2 Informes de dependencia.

Los informes de dependencia son utilizados por los Product Managers para ver el árbol de

dependencias entre los diferentes productos cuando seleccionamos una estructura de producto.

Para ver un informe de dependencia seleccionaremos uno de los productos y cuando estemos

en la página de propiedades del producto seleccionaremos en “Informes” la opción de “Informe

de dependencia”. En nuestro caso no hay ninguna relación de dependencia.

Figura 86. Ver informes de dependencia de un modelo.

4.3.3.3 Revisión de un producto.

Un producto puede ser revisado en cualquier estado de su ciclo de vida. Cuando un producto es

revisado o versionado, todas las características son heredadas por defecto. La actual revisión de

producto liberada representa la definición de producto “mejor vista”. Se puede anular este poder

durante cualquier proceso de revisión o versión.


142

La página de Revisiones de Producto aparece una lista con todo el historial de revisiones. Para

acceder a dicha página tan solo hay que seleccionar en el menú de Categorías de cualquier

página de un producto o modelo. Para ver el historial de revisiones de un producto se puede:

- En la página de propiedades del modelo, en el menú Categorías, seleccionar

“Revisiones de producto”.

- En la página de propiedades del producto, en el menú Categorías, seleccionar

“Revisiones”.

Figura 87. Página de revisiones de un producto.

A continuación crearemos una revisión del producto “Mordaza parental”. Para ello accederemos

a la página del modelo, en el menú Acciones seleccionaremos “Crear revisión…”.

Figura 88. Creación de una revisión del producto “Mordaza parental”.

Figura 89. Página de creación de una revisión del producto.


143

4.3.3.4 Versión de un producto.

Un género de producto puede consistir en un conjunto de versiones. Los Product Managers y los

System Engineers pueden mantener múltiples versiones de productos en su poder y son

responsables de ellos. Los productos software pueden tener versiones “libres” que serán

enviadas a clientes específicos. Las versiones de producto son adjuntadas al contexto de

revisión de producto. Las versiones de producto pueden ser creadas exclusivamente junto a una

revisión de producto. Un producto puede ser versionado desde cualquier revisión. Cuando una

revisión de producto es revisada, todas las versiones existentes no tienen por qué salir adelante.

La página de versiones, al igual que la de revisiones muestra en una lista todas las versiones de

los productos. Para acceder a ella tan solo tendremos que desde la página de un producto o

modelo seleccionar en el menú Categorías “Versiones”.

Figura 90. Acceso a página de versiones del producto.

A continuación se creará una versión de un producto. Los productos pueden tener una o más

versiones. Cuando se crea una nueva versión, se le adjunta una copia de la estructura por

defecto, que podemos cambiar o añadir características y opciones. La secuencia de revisiones

de los productos es alfabética. Las versiones de los productos son alfa-numéricas. Podemos

cambiar estas opciones en el Business Modeler.

Para crear una versión seleccionaremos “Crear nuevo” dentro de la página de versiones del

producto.

Figura 91. Creación de nueva versión de producto.


144

Figura 92. Página de creación de una nueva versión de producto.

Nos aparecerá una nueva versión de la mordaza parental:

Figura 93. Detalles de la nueva versión de producto creada.

Si volvemos a la página de productos podemos observar que se ha creado la versión y que la

versión “A” contiene un símbolo que indica que existe una versión más reciente.

Figura 94. Actualización a la versión más reciente.


145

4.3.3.5 Variante del producto.

Para ver las variantes de un producto, de manera análoga a las versiones y revisiones

accederemos mediante el menú categorías dentro de la página del producto seleccionando

“Variantes”- “Acciones” y “Ver variantes de producto”.

Figura 95. Vista de las variantes de un producto.

4.3.3.6 Creación de una cartera.

Una cartera es un conjunto de productos y modelos que pueden ser usados para ver la hoja de

ruta de estos productos y modelos. Las hojas de ruta permiten a los Product Managers asociar

tareas WBS desde proyectos creados en el ENOVIA Program Central con productos para

representar importantes hitos en el proceso de lanzamiento de los productos. Las hojas de ruta

pueden ser vistas como una tabla o en una línea de tiempo gráfica.

La página de Carteras contienen en una lista todas las carteras, que pueden ser filtradas

mediante un filtro. Para acceder a dicha página en el menú Mi Enovia, en la sección de Líneas

de producto seleccionaremos “Carteras”.

Figura 96. Acceso a la página de las Carteras.

A continuación se creará una nueva cartera, para ello en primer lugar debemos acceder a la

página de carteras. Una vez que nos encontremos en la página de carteras, seleccionaremos

“Crear nuevo” del menú Acciones.


146

Figura 97. Creación de una nueva Cartera.

Figura 98. Página de creación de una nueva cartera.

Figura 99. Detalle de la cartera creada.

4.3.3.7 Creación de una línea de tiempo.

Las líneas de tiempo presentan los hitos de una hoja de ruta particular en un formato gráfico. El

gráfico es una línea de tiempo representando el comienzo real o estimado y el fin del hito en el

eje horizontal y los diferentes objetos de la hoja de ruta en el eje vertical. Las Líneas de tiempo

contienen un filtro que permite seleccionar los hitos de acuerdo a las relaciones de atributos

entre la hoja de ruta y estos hitos.

La página de la Línea de tiempo muestra el progreso de la hoja de ruta basándose en los hitos.

El eje vertical muestra los objetos de la hoja de ruta. Los objetos de la hoja de ruta aparecen

como una imagen y son mostrados junto al nombre y título. Si hacemos click en la imagen nos

mostrará toda la información sobre las propiedades del objeto.

El eje horizontal corresponde a los diferentes objetos de hojas de ruta individuales. Esto abarca

desde el primero hasta el último hito. Los hitos aparecen en la Línea de tiempo según su fecha


147

(ya sea la fecha real o estimada de comienzo o finalización) proporcionada. Por defecto, el

nombre de la hoja de ruta está enlazado a la página de Propiedades.

Para ver la Línea de tiempo, tenemos varias opciones:

- Acceder al menú principal Mi Enovia y en la sección Líneas de producto

seleccionaremos “Productos”.

- Acceder a la página de contenidos de las carteras.

- Acceder a la página de propiedades de un modelo y seleccionar “Revisiones de

productos” del menú Categorías.

Después seleccionaremos uno o más productos o modelos que queramos ver en la Línea de

tiempo y seleccionaremos “Escala de tiempo” en el menú Informes de la barra de herramientas.

Se abrirá una nueva página con la Línea de tiempo de los objetos seleccionados.

Figura 100. Selección de objetos a ver en la Línea de tiempo.

Figura 101. Acceso a la Línea de tiempo.

En el caso que se presenta, al no haberle atribuido a ningún modelo ni producto ninguna hoja de

ruta ni ningún hito, la Línea de tiempo aparece vacía. Los conceptos de hoja de ruta y de hito en

el producto son un nivel de profundización mayor en el entorno ENOVIA V6 y por tanto no

corresponden a los objetivos de este proyecto.


148

4.3.4 Creación de un desarrollo.

A continuación se creará un desarrollo, para ello hay que realizar uno de los siguientes pasos:

- En el menú global Mi Enovia, en la sección de Línea de productos seleccionamos

Desarrollos y en la página que se abrirá seleccionamos en la barra de herramientas

“Crear nuevo”.

- En el menú global Acciones, en la sección de Línea de productos seleccionamos

“Crear Desarrollo”.

- En el contexto de un producto, una versión de producto o una configuración de

producto, en la página de propiedades, seleccionamos Categorías -> Desarrollos ->

Acciones -> Crear nuevo…

- En el contexto de un modelo, en la página de Propiedades en el menú Categorías

seleccionamos Unidades y Crear nueva.

Figura 102. Creación de un desarrollo

Se abrirá una nueva página en la que se tendrá que rellenar diferentes campos para crear el

desarrollo:


149

Figura 103. Página de creación de un nuevo desarrollo.

- Nombre: escribiremos el nombre del nuevo desarrollo o seleccionaremos Nombre

automático. Si el número de desarrollos es mayor de 1 debemos utilizar el nombre

automático.

- Tipo: hay que seleccionar entre hardware y software. Después de seleccionar el tipo

de desarrollo únicamente esas políticas serán las permitidas según el tipo de

desarrollo elegido. Es un campo requerido.

- Cantidad de desarrollos: escribiremos el número de desarrollos a generar. Podemos

generar hasta 100 desarrollos. Por defecto aparecerá 1.

- Descripción: escribiremos los detalles que describen el desarrollo.

- Propietario: asignaremos un propietario. Por defecto aparecerá la persona que está

creando el desarrollo como propietario.

- Producto: seleccionaremos el contexto del producto para el cuál el desarrollo ha sido

creado. Si estamos creando el desarrollo en el contexto de un producto, por defecto,

este campo inicialmente aparecerá relleno con el producto pero podemos

seleccionar cualquier producto bajo el modelo asociado con el producto en contexto.

Después de seleccionar el producto, solamente las configuraciones de producto

asociadas con el producto son permitidas para el campo Configuración de producto.

- Configuración del producto: seleccionaremos el contexto de configuración de

producto para el que se ha creado el desarrollo. Si estamos creando un desarrollo

en el contexto de una configuración de producto, este campo aparecerá relleno con

esa configuración de producto por defecto. El campo Producto aparecerá relleno

automáticamente con el producto asociado con esa configuración de producto.


150

- Responsabilidad del diseño: seleccionaremos la organización responsable de este

desarrollo. Si el contexto de producto está seleccionado, la responsabilidad de

diseño se rellenará con la responsabilidad de diseño del producto.

- Disposición del desarrollo: seleccionaremos el estado o disposición del desarrollo.

Este atributo es utilizado además del estado del ciclo de vida del desarrollo. Los

valores posibles de este valor son: Producción, enviado, servicio, inventario, N/A y

(en blanco).

- Cliente: seleccionaremos el cliente satisfecho por este desarrollo. Podemos

seleccionarlo a partir de una lista con todos los clientes.

- Número de contrato: escribiremos el número del contrato que este desarrollo

satisface.

- Planta: seleccionaremos la planta responsable de este desarrollo.

- Fecha de desarrollo planificada: seleccionaremos la fecha para la que está planeada

el desarrollo.

- Fecha real de desarrollo: seleccionaremos una fecha posterior a la fecha planeada

de desarrollo, para el desarrollo real del desarrollo.

- Fecha de envío: seleccionaremos una fecha posterior a la fecha real en la que

enviaremos el desarrollo al cliente o al almacén de inventario.

- Directiva: la directiva que gobierna este objeto.

- Valor: seleccionaremos el valor del desarrollo.

Nos aparecerá en la página de desarrollos nuestro desarrollo creado.

Figura 104. Detalles del desarrollo creado.

Las diferentes columnas muestran la información de los desarrollos diferenciadas en bloques. El

primer bloque contiene el nombre, tipo, estado, propietario, originador y descripción que serían

columnas comunes a otros contextos ya vistos anteriormente.

Un segundo bloque llamado Planificación/Disposición que contiene:

- Número de serie del desarrollo: muestra el número de serie del desarrollo.

- Número de unidad de desarrollo: el número de unidad es autogenerado según los

desarrollos creados en el contexto de producto y/o configuración de producto. El

número de unidad generado corresponde al último número de unidad generada bajo

el contexto de modelo de ese producto.

- Notación abreviada: muestra la notación abreviada asociada al desarrollo. Cuando

un desarrollo es creado en el contexto de un producto, la notación abreviada del

producto es automáticamente asignada al desarrollo.


151

- Disposición del desarrollo: muestra la disposición del desarrollo.

- Fecha de desarrollo planificada: muestra la fecha planificada del desarrollo.

- Fecha real de desarrollo: muestra la fecha real del desarrollo.

- Fecha de envío: la fecha en la que el desarrollo se enviará al cliente o al almacén de

inventario.

El bloque de Información de fabricación que contiene las columnas:

- Planta: la planta responsable del desarrollo.

- Planes de fabricación: los planes de fabricación que han sido asignados al

desarrollo. Los Manufacturing Planners y los Product Managers pueden asignar los

desarrollos definidos para los productos, a los planes de fabricación definidos para

ese producto.

El bloque Asignación/Cliente que describe:

- Cliente: el cliente satisfecho por este desarrollo.

- Número de contrato: el número de contrato satisfecho por este desarrollo.

El bloque de Información de piezas según se diseñó muestra:

- Número de pieza: muestra el número de pieza asignado al desarrollo.

- Revisión de pieza: número de revisión del número de pieza asignado al desarrollo.

Por último el bloque Efectividad del producto nos presenta:

- Producto: el contexto de producto del desarrollo. Esta columna aparecerá solo si a la

página accedimos desde otro punto que no fuese el contexto del producto.

- Configuración de producto: el contexto de configuración de producto del desarrollo.

La configuración de producto debe estar relacionada con el contexto de producto del

desarrollo.

4.3.5 Definición de pieza y familia de piezas.

A continuación se creará una pieza. A destacar que el rol con el que se trabajará será VPLM

Project Leader. Es posible crear una pieza desde:

- El menú global Acciones, en la sección Ingeniería “Crear pieza…”.

- En la página que se muestra la lista con todas las piezas, “Crear nueva” en el menú

Acciones.

- En el modo edición de la BOM (Lista de materiales), seleccionando “Añadir nueva” o

“Reemplazar con nueva” en el menú Acciones de la barra de herramientas.


152

Figura 105. Creación de una nueva pieza.

Figura 106. Página de creación de una nueva pieza.

La página que se abrirá será como la mostrada anteriormente, en la que aparecerán los

siguientes campos:

- Tipo: seleccionaremos el tipo de pieza que queremos crear. Si estamos creando un

subtipo lo seleccionaremos mediante el icono.

- Nombre de la pieza: el nombre de la pieza será generado por el sistema

automáticamente o podemos escribir el nombre de la nueva pieza. Escogeremos

entre escribir el nombre de la pieza en su campo o seleccionar una de las opciones

del campo “Serie de nombre automático”. Si la política de producción y desarrollo ha

sido seleccionada, la revisión es generada en base a la política de secuencia de

revisión.

- Directiva: si queremos usar otra directiva que la que nos ofrece por defecto (Pieza

de desarrollo), la seleccionaremos de la lista.


153

- Nivel de revisión personalizada: si queremos utilizar un número de revisiones

diferente al definido en la directiva seleccionada, escribiremos el número o código de

revisiones. Si la directiva es EC Part, el valor por defecto es 1. Si la directiva es

Development Part, el valor por defecto es A.

- Cantidad de piezas: escribiremos el número de piezas que queremos crear. El valor

máximo permitido es 10. Cuando creamos piezas múltiples a la vez, debemos

seleccionar y activar una familia de piezas que tenga el generador de nombre activo.

- Familia de piezas: seleccionaremos la familia de piezas que será asociada.

Una sección llamada “Básico” en la que aparecerán los diferentes campos:

- Descripción: describe los detalles de la pieza nueva.

- Propietario: selecciona el propietario de la nueva pieza.

- Responsabilidad del diseño: asigna la responsabilidad del diseño a los diferentes

ingenieros de diseño.

- ECO para emitir: en este campo se seleccionará la ECO a emitir.

- Fecha de emisión objetivo: en este campo se seleccionará la fecha de emisión de la

pieza objetivo.

Una sección para “Fabricación” en la cual aparecen:

- Código de Fabricación|Compra para producción: se le asignará el código de

fabricación o compra.

- Elemento final: determina si es un elemento final la pieza.

- Código de servicio de Fabricación|Compra: se le asignará el código de servicio de

fabricación.

- Pieza de repuesto: en este campo se indicará la pieza de repuesto a la nueva pieza.

- Compra del diseño: se debe seleccionar si el diseño es propio o ha sido comprado.

- Lead time: se seleccionará de la lista el tiempo que tardará en fabricarse la pieza.

La sección dedicada a la “Adquisición”:

- Coste estimado: se incluirá una estimación del coste de la nueva pieza.

- Coste objetivo: se introducirá el coste objetivo de la pieza que la empresa quiere que

se cumpla.

Una sección llamada “Técnico” en la que aparecen:

- Unidad de medida: se seleccionará la unidad de medida (IN – pulgada, LB – libra,

GA – galón, FT – pies…).

- Categoría del material: se seleccionará el material en el que se ha construido la

pieza (metal, plástico, vidrio, goma…).

- Peso: se introducirá el peso de la pieza y se seleccionará del campo de la unidad de

medida, la unidad que se está utilizando.

- Clasificación de piezas: se seleccionará una categoría general de los diferentes tipos

de piezas (extrusión, hardware, mazo de cables, mecanizado, moldeado, otro, placa

de circuito impreso, sin asignar y software).


154

Y otros atributos como:

- Nombre del producto VPM: indica el nombre del producto para el atributo VPM.

- VPM visible: selecciona si la pieza podrá ser sincronizada con VPM.

4.3.5.1 Crear una familia de piezas.

Para crear una familia de piezas tan solo hay que acceder al menú global Acciones y en la

sección Ingeniería seleccionar “Crear Familia de piezas”.

Figura 107. Creación de una nueva familia de piezas.

Algunos de los campos como el Tipo, Nombre y Descripción son comunes y ya vistos

anteriormente.

El separador de patrón es el carácter utilizado entre el prefijo y el nombre de la pieza, o también

entre el nombre de la pieza y la secuencia paterna. El número base es el número de comienzo

del nombre de la pieza. Si el generador de nombre está activado, todas las piezas añadidas a la

familia serán automáticamente nombradas. Los patrones de sufijo y prefijo son las letras o

números al final/comienzo del nombre de cada pieza de la familia de piezas.

Figura 108. Página de creación de una nueva familia de piezas.


155

En nuestro ejemplo hemos cambiado el separador de patrón y además el patrón de secuencia

que hemos asignado como 007070. También hemos atribuido un patrón de sufijo y de prefijo.

Si accedemos a la vista de Familia de piezas, mediante el menú Mi Enovia en la sección

Ingeniería seleccionando “Familia de piezas”, se mostrará en una página todas las familias de

piezas, en la que aparecerá la familia de piezas que se acaba de crear.

Figura 109. Vista de las familias de piezas.

Al crear una familia de piezas, podemos especificar la secuencia paterna que se utilizará para

nombrar las piezas de esa familia. Esto establece la longitud y el número de ceros antecesores

para el siguiente número generado como nombre de una pieza. El formato debería mimetizar la

secuencia definida en la política de gobierno y debe finalizar con tres periodos. La numeración

siempre comienza en 1. Algunos ejemplos de numeraciones:

Secuencia paterna Números de piezas generados

0000 0001, 0002, 0003…

0010 0011, 0012, 0013…0020, 0021…

00B0 00B1, 00B2, 00B3… 0010, 0011, 0012…

B1 B1, B2, B3… 10, 11, 12, 13…

0B501 0B501, 0B502,… 0B100, 0B101,… 01000, 01001…

4.3.5.2 Crear una pieza alternativa.

Para ver las piezas alternativas correspondientes a una pieza, accederemos a la página de

propiedades de la pieza, después seleccionaremos en el menú Categorías de la barra de

herramientas “Alt.Sust.Equiv.”


156

Figura 110. Página de propiedades de la pieza.

Se abrirá una nueva página en la que aparecerán las piezas sustitutas y alternativas.

Como ejemplo vamos a tomar la mordaza que como se puede ver en la imagen inferior no tiene

ninguna pieza alternativa.

Figura 111. Piezas alternativas de la mordaza.

Por tanto vamos a crear una pieza alternativa a la mordaza y observaremos como se añade a la

lista de piezas sustitutas de la mordaza.

Para crear la pieza alternativa, dentro del menú de piezas sustitutas y alternativas de la pieza

que queremos sustituir, seleccionaremos en el menú Acciones “Agregar existente”. Tras

seleccionar la pieza, aparecerá en la página de piezas sustitutas y alternativas.

Figura 112. Creación de pieza alternativa.


157

Figura 113. Vista de piezas alternativas.

4.3.5.3 Creación de documentos de referencia de piezas.

Entre las diferentes posibilidades de trabajo que ofrece ENOVIA, en este apartado describiremos

algunas que están relacionadas con las Líneas de Productos.

Empezaremos con las imágenes, que pueden ser accedidas desde diferentes contextos como

productos, modelos o características. Por defecto solo los Product Managers, Marketing

Managers y los System Engineers tienen el acceso a crear una imagen. La imagen creada

representa de manera simple el objeto al que pertenece. Una vez creadas, las imágenes no

pueden ser editadas a través del Gestor de Líneas de Productos.

Solo los formatos GIF, JPG, PNG, GIFF y JPEG pueden ser aceptados. Durante la última

revisión de la imagen, se convertirá a JPG solamente.

Figura 114. Vista de imágenes.

Además de imágenes podemos adjuntar todo tipo de documentos a nuestros productos. Estos

documentos pueden estar almacenados en nuestro ordenador o en la base de datos. La

categoría “Documentos de referencia” muestra una lista de todos los documentos referencia

adjuntados a los objetos parentales. La página “Documentos” muestra los documentos adjuntos

a los objetos, características, productos o requisitos. Como ejemplo tomaremos nuestro modelo

“Mordaza parental” y seleccionaremos “Documentos de referencia”


158

Figura 115. Ver documentos de referencia.

Aparecerá la página “Documentos” totalmente vacía ya que no contiene ningún archivo adjunto.

Figura 116. Página de documentos de referencia.

Las diferentes columnas muestran los siguientes campos:

- Icono de bloqueo: muestra el número de archivos que están bloqueados. Si

seleccionamos algún link subrayado nos direccionará a la página de archivos.

- Nombre: nombre del documento de referencia. Esta columna contiene links

subrayados. Seleccionando cualquier nombre de la columna podemos ver la página

“Propiedades” de ese objeto.

- Título: el título del documento.

- Revisión: indica la revisión actual del documento. Seleccionando alguno de los links

de la columna accederemos a la página de “Revisiones”.

- Versión: muestra la versión actual del documento de referencia. Seleccionando

alguno de los links subrayados de la columna, abriremos la página “Versiones”.

- Tipo: Tipo del documento.

- Acciones: los siguientes iconos (Figura 116 ) muestran las diferentes acciones que

podemos realizar con el contenido de la lista:

o Suscripción: ver y seleccionar suscripciones a un documento.

o Descarga: podemos descargar uno o varios archivos a nuestro ordenador.


159

o Comprobar y bloquear: comprobar uno o varios archivos y los bloquea para

que el resto de usuarios no pueda desbloquearlo.

o Actualizar archivos: actualiza los archivos a la siguiente versión.

o Registrar: registra y desbloquea uno o más archivos.

- Descripción: vista del contenido del documento.

- Estado: el estado actual del documento de referencia en su ciclo de vida.

Figura 117. Iconos de acciones.

En la categoría “Acciones” podemos desde crear un nuevo documento para adjuntar a nuestro

producto o elegirlo de nuestra base de datos.

En nuestro caso crearemos un nuevo documento para la mordaza parental que llamaremos

“Documentación Mordaza parental”. En la segunda página que nos mostrará, tendremos que

seleccionar los archivos de nuestro ordenador que vamos a adjuntar.

Figura 118. Creación de documento de referencia.


160

Figura 119. Página de creación del documento de referencia.

Destacar que se pueden adjuntar varios archivos a un solo documento.

Figura 120. Selección de archivos a adjuntar en el documento de referencia.

Una vez finalizado aparecerán en la página “Documentos” del modelo Mordaza parental los

documentos que hemos adjuntado.

Figura 121. Detalle de los documentos de referencia creados.

4.3.5.4 Crear una pieza derivada.

Para acceder al menú de piezas derivadas, tendremos que acceder a la página de propiedades

de una pieza y en el menú Categorías seleccionar “Piezas derivadas”.


161

Figura 122. Creación de una pieza derivada.

Como se definió en el apartado 4.1.4.6 “Definición de una pieza derivada”, las piezas derivadas

se pueden formar por clonación de piezas o reemplazamiento. En este proyecto analizaremos la

clonación de una pieza.

4.3.5.4.1 Clonar una pieza.

A continuación se muestra un pequeño ejemplo de clonación de una pieza. Para ello

accederemos al menú global Acciones, y en la sección Ingeniería seleccionaremos “Crear clon

de pieza…”.

Figura 123. Clonación de una pieza.


162

Figura 124. Página de clonación de una pieza.

Se abrirá una nueva ventana en la que tendremos que rellenar los siguientes campos:

- Clon basado en: si el nombre de la pieza aún no está escrito selecciónalo de la lista

que se mostrará al seleccionar el icono.

- Incluir datos relacionados: seleccionaremos los objetos que queremos que se

incluyan en la nueva pieza. Si no seleccionamos ningún dato, la pieza nueva se

creará sin ninguna estructura.

- Nombre de la pieza: el nombre de la pieza puede ser generado automáticamente por

el sistema, o podemos escribir el nombre de la nueva pieza. Si una familia de piezas

ha sido seleccionada, el campo “Nombre de la pieza” estará desactivado y el nombre

de la pieza será generado basándose en los requisitos de la familia de piezas.

- Serie de nombre automático: si la pieza está generada a partir de una familia de

piezas u otro tipo de objeto con un nombre automático, directamente aparecerá el

nombre de ese tipo de objeto y se nombrará al clon siguiendo la nomenclatura del

objeto.

- Nivel de revisión personalizada: si queremos utilizar un nivel de revisiones diferente

al definido por la directiva seleccionada, escribiremos el número de revisión o

código. Si la directiva es EC Part o Manufacturing Part, por defecto el nivel de

revisión será 1. Si la directiva es Development Part, por defecto aparecerá un nivel

de revisión A.

- Familia de piezas: si la pieza base no está clasificada (esto quiere decir, si aún no

pertenece a una familia de piezas), tenemos la opción de clasificar el clon.

Seleccionaremos la familia de piezas a la que será asociada el clon para la

clasificación o la generación del número de la pieza. El nombre del clon será

generado después desde la familia de piezas.

- Cantidad de piezas: definiremos el número de piezas que queremos crear. El valor

máximo permitido es 10 piezas. Cuando creamos varias piezas a la misma vez,


163

debemos tener seleccionada una familia de piezas que tenga el atributo de generar

el nombre activo o debemos utilizar el nombre automático y seleccionar el

nombramiento automático de la serie.

4.3.6 Realización de diferentes cambios de ingeniería.

4.3.6.1 Solicitud de cambio de ingeniería.

Para crear una ECR debemos seguir los siguientes pasos. Primero acceder a la página de Crear

una ECR. En la barra de herramientas global, en el menú “Acciones” seleccionaremos de la

sección Ingeniería “Crear ECR”. Después rellenaremos los diferentes campos con los datos de la

solicitud de cambio de ingeniería.

Figura 125. Creación de solicitud de cambio de ingeniería.

Debemos tener en cuenta a la hora de completar los diferentes campos ciertas necesidades. En

la selección de “Responsabilidad del cambio” aparecerá la organización que tiene la

responsabilidad del cambio de la ECR, para ello dicha organización debe tener definidos los

roles de ECR Chairman y ECR Coordinator.

El ingeniero responsable de diseño que elijamos deberá estar autorizado para revisar la ECR.

Este usuario deberá tener alguno de los siguientes roles asignado Design Engineer o Senior

Design Engineer. Además deberá ser miembro de la organización que tenga la responsabilidad

del diseño o cambiar la responsabilidad de los objetos afectados por la ECR. Si no hay definido

un responsable de diseño en la organización, todos los usuarios de la empresa con el rol Design

Engineer serán mostrados.


164

Toda la información de la ECR se mostrará en la página de Propiedades de la ECR. Dicha

información puede ser editada posteriormente a través de la página de Propiedades de la ECR.

Crearemos, siguiendo los pasos descritos, una ECR para la mordaza que tenemos como

ejemplo.

Figura 126. Página de creación de una nueva solicitud de cambio de ingeniería.

4.3.6.2 Orden de cambio de ingeniería.

Para crear una ECO se procede igual que una ECR, es decir, menú global Acciones, sección

Ingeniería, apartado Cambio, solo que debemos elegir la opción “Crear ECO”.


165

Figura 127. Creación de una nueva orden de cambio de ingeniería.

Figura 128. Página de creación de una nueva orden de cambio de ingeniería.

Una vez que aparece la página de creación de la orden de cambio de ingeniería tendremos que

rellenar los siguientes campos:

- Tipo: seleccionaremos el tipo o sub-tipo. Por defecto al seleccionar “Crear ECO”

aparecerá el campo relleno con “ECO”.

- Directiva: si queremos utilizar otra directiva que no sea la que aparece por defecto,

pulsaremos la flecha para seleccionar las diferentes directivas que nos ofrece la lista

descendente.

- Descripción: proporcionaremos los detalles sobre la ECO.

- Categoría del cambio: seleccionaremos la categoría de la lista. Podemos elegir

entre: Error de borrador, Facilitar fabricación, Mejora del producto, Presentación de

nueva producción, Reducción de costes, Requisito de proveedor, Requisito de

marketing y Sin asignar.

- Informado: buscaremos y seleccionaremos la pieza o documento.

- Responsabilidad del diseño: seleccionaremos la organización que tiene la

responsabilidad del diseño de la ECO.

- Ingeniero responsable de la fabricación: escribiremos directamente el nombre o

seleccionaremos a un usuario con el rol Senior Manufacturing Engineer que estará

autorizado para revisar la ECO.

- Ingeniero responsable del diseño: escribiremos el nombre o seleccionaremos a un

usuario con el rol Senior Design Engineer que tendrá autorización para revisar la

ECO. Esta persona obligatoriamente debe ser miembro de la organización que

producirá el cambio, responsable de la ECO.

- Lista de revisores: seleccionaremos la plantilla de ruta que contiene la lista de

personas que revisarán la ECO.


166

- Lista de distribución: seleccionaremos la lista de miembros que recibirán

notificaciones sobre la Orden de cambio de ingeniería.

- Lista de aprobaciones: elegiremos la plantilla de ruta que contendrá la lista de

personas que participarán en el proceso de aprobación de la ECO.

- Gravedad: en este campo aparecen las opciones Alta, Media y Baja para asignar la

prioridad a la ECO. Por defecto aparecerá Baja.

- ECR relacionada: este campo se rellenará automáticamente basándose en los

objetos asignados de la ECR a la ECO. Si los objetos son asignados desde varias

ECRs, las ECRs aparecerán en una lista. Podemos seleccionar una ECR de la lista

que no aparezca en este campo por defecto.

- Omitir plantas: seleccionaremos localizaciones que no deberían ser incluidas en la

orden de cambio. Se mostrará exclusivamente si tenemos instalado el X-BOM

Manufacturing.

No obstante, en la realidad pueden cancelarse los procesos de cambio por diversos motivos:

fabricación, producción, viabilidad… En ENOVIA podemos cancelar una ECO. Cualquier usuario

que tenga acceso a la modificación de la ECO puede cancelarla si todavía no ha llegado al

estado “Liberada”. Hay importantes razones de negocio por las que podríamos cancelar una

ECO durante el proceso de gestión del cambio:

Existe una ECO similar en proceso.

Un error significante interrumpe la implementación de la ECO.

Un error funcional o de seguridad ha sido descubierto después de que se

aprobara la ECO.

Cuando se cancela una ECO hay diferentes consecuencias, entre ellas:

Todos los objetos afectados que están conectados a la ECO se desconectarán.

Todas las rutas conectadas a la ECO son desconectadas. El propietario de la

ruta recibirá una notificación de que la ruta ha sido cancelada. Si la ECO es el

único contenido de la ruta, la ruta se paralizará.

Las plantillas de ruta conectadas a la ECO serán desconectadas.

Todas las asignaciones, listas de distribución y listas de miembros revisores, así

como el creador de la ECO serán notificados de que la ECO ha sido cancelada.

Las tareas relacionadas serán eliminadas de las páginas de tareas de la ECR y

la ECO, además de la página de “Mis tareas” de cada usuario.

La ECO será promovida al estado “Cancelada”.

4.3.6.3 Orden de cambio de desarrollo de ingeniería.

Para crear una DECO tan solo tenemos que seleccionar en el menú global Acciones, sección

Ingeniería, apartado Cambio la opción “Crear DECO”.


167

Figura 129. Creación de orden de cambio de desarrollo de ingeniería.

Figura 130. Página de creación de orden de cambio de desarrollo de ingeniería.

Los diferentes campos a rellenar son similares a los descritos en las solicitudes y órdenes de

cambio de ingeniería, por tanto no se volverán a describir.

4.3.7 Definición de efectividad del producto.

A continuación se procederá la definición de la Efectividad de un objeto. Los usuarios pueden

definir la efectividad de los objetos que han sido configurados por el Business Manager para

utilizar los Servicios de Efectividad. El Business Manager puede configurar la efectividad para

cualquier objeto. Cuando los objetos están configurados para utilizar la efectividad, los controles

para la definición de la efectividad aparecen en las páginas de Editar y Crear.

La Efectividad puede ser definida cuando creamos un nuevo objeto o cuando editamos un objeto

ya existente. Por ejemplo, supongamos que el Business Manager ha configurado la efectividad

para los Requisitos. Esta técnica describe como definir la Efectividad para un nuevo Requisito

que ha sido configurado para usar la fecha como Efectividad.


168

En el presente proyecto se describirá el editor de selección de efectividad y se definirá la

efectividad para la unidad:

o Construir la expresión de Efectividad.

Para construir la expresión de Efectividad, en el menú global "Acciones" seleccionaremos “Crear

PUE ECO”.

Figura 131. Definición de la Efectividad de una pieza.

A continuación en la ventana que se abrirá, en el campo “Efectividad”, habrá que seleccionar el

símbolo “Editar detalles” .

Se abrirá así el Editor de selección de efectividad, se tendrá que seleccionar los artículos en el

Selector de Efectividad y después añadir los artículos seleccionados a la caja de expresiones. Se

pueden insertar los artículos uno a uno y construir la expresión linealmente, o insertar un grupo

de artículos y añadir paréntesis y conectores “OR” si fuese necesario, después utilizaremos los

iconos representados por flechas hacia arriba y abajo para mover los artículos en la caja de

expresiones hacia las posiciones que queremos que ocupen.

Figura 132. Editor de efectividad.

A. Editar la unidad de Efectividad.


169

Se puede configurar la efectividad entre diferentes modelos según el número de unidades, para

ello una vez en el editor de selección de efectividad, se seleccionará en el campo “Tipo” el valor

“Unidad” y seleccionaremos el símbolo para elegir los diferentes modelos. Los diferentes

modelos aparecerán en el editor, se volverán a seleccionar y se deberá pulsar . De esta

forma se añadirán los diferentes modelos a la caja de edición de la expresión de efectividad.

Seleccionando las expresiones de los modelos con el botón derecho del ratón, se podrá

introducir los valores de las unidades para los que la expresión de efectividad será válida.

Figura 133. Introducción de los valores de la unidad en la definición de la efectividad.

Figura 134. Definición completa de la unidad de efectividad.

4.3.8 Lista de materiales del producto.

4.3.8.1 BOM.

Para crear una Lista de materiales de una pieza, debemos en primer lugar elegir la pieza de la

que crearemos la BOM.


170

Figura 135. Selección de pieza para la creación de BOM

Una vez elegida, en nuestro caso será la pieza “mordaza”, en el menú Categorías de la pieza

seleccionaremos “PowerView de BOM”.

Figura 136. Selección del visor de BOM

Seleccionaremos “Editar todo” y añadiremos nuevas piezas o piezas ya existentes. Por último

guardaremos.


171

Figura 137. Creación del BOM

4.3.8.2 Sincronización de BOM.

Realizaremos un ejemplo con nuestra pieza “mordaza”. Comenzaremos accediendo a las

especificaciones de la pieza.

Figura 138. Selección de especificaciones de la pieza mordaza.

En la barra de herramientas seleccionaremos en el menú Acciones “Synchronize with

Engineering…”.

Figura 139. Sincronización de pieza con ingeniería.


172

Figura 140. Página de sincronización con ingeniería.

Seleccionaremos el contexto de seguridad, el nivel de profundidad que se expandirá en el VPM y

deberemos seleccionar la opción Transfer Control para que se transfieran los datos a VPM.

Figura 141. Sincronización satisfactoria.

173

5 Conclusiones y extensiones.

5.1 Conclusiones obtenidas.

El desarrollo del presente proyecto ha contribuido de manera muy importante a identificar y

resaltar los puntos más destacados de la gestión del ciclo de vida y su implementación en los

sistemas PLM 2.0, concretamente con la herramienta ENOVIA V6.

La finalización de este proyecto trae consigo la aportación de ciertos conceptos que quedan en la

reflexión y abiertos a diferentes conjeturas, y la profundización, asentamiento y refuerzo de

conceptos muy importantes, que se podrían catalogar como puntos angulares en una

implementación sólida y optimizada de un sistema PLM 2.0.

Entre los puntos que se han considerado más importantes dentro de un proyecto de esta

naturaleza, se encuentran la detección de las necesidades reales de los propios usuarios que

trabajarán a diario con los sistemas PLM 2.0, que los procesos operativos de la organización

dentro del sistema PLM 2.0 sean un fiel reflejo de los procesos de negocio diarios y que no se

convierta en un obstáculo burocrático, consiguiéndose una involucración total de todos los

usuarios. De esta forma se conseguiría una definición concreta y tangible de los beneficios

económicos, laborales y de otra índole que se fijarían como objetivos a alcanzar con el sistema

PLM 2.0, de manera que todos los usuarios pertenecientes a la empresa sabrán cómo se van a

beneficiar particularmente de la implementación de un sistema PLM 2.0.

Se debe mencionar que uno de los problemas más frecuentes para que un PLM 2.0 no cumpla

su objetivo y por consiguiente su implementación sea un fracaso, es dejar al margen del sistema

a los operarios que trabajan en las operaciones diarias de la empresa. Se traduciría en la

implementación de un sistema sin tener certeza de cuáles son las necesidades básicas dentro

de la empresa y por consiguiente la pérdida de vista del objetivo general de la misma,

incurriendo en un gasto en lugar de una potencial inversión.

En relación a la involucración de toda la empresa, uno de los objetivos es el estándar de calidad

y su mejora sucesiva del producto de la organización. El sistema PLM 2.0 por sí solo no realiza

una mejoría en dicho nivel de calidad, sin embargo sí puede ser una potente herramienta que

permita a los diferentes usuarios dedicarse a tareas más productivas en vez de a las tareas

administrativas y por consiguiente un incremento en el nivel de calidad ofrecido al cliente.

No obstante dicha involucración debe estar respaldada de una formación de todo el personal de

la empresa, ya que sin dicha formación, el desarrollo y la implementación total del PLM 2.0 en la

empresa es muy probable que se venga abajo, sustituyendo las herramientas ofrecidas por el

PLM 2.0 por otras y haciendo que todos los beneficios que se preveían con la implementación no

se consigan o incluso empeoren. Un ejemplo típico es el miedo de los diferentes usuarios de una

empresa a utilizar la herramienta por el temor a la equivocación. Este tipo de problemas se

Conclusiones y extensiones

174

verían solventadas de manera eficaz con la formación, desarrollándose capacidades como la

colaboración, innovación y trabajo en grupos multidisciplinares.

A medida que se ha investigado en la herramienta ENOVIA V6 se han ido detectando puntos

clave para afianzar diversos procesos, oportunidades para mejorar el servicio al cliente en

diversos departamentos de la empresa, tener una visión más clara del conjunto de la empresa y

sus funcionalidades, así como la detección de gastos que tienen la posibilidad de reducirse.

También otra característica que se ve muy influenciada es la gestión de información en la

resolución de problemas y toma de decisiones, potenciándose la secuenciación de los procesos

en sus ciclos de vida y las capacidades de cada usuario en cada etapa según sus roles. Se le

atribuye a la información la importancia que se merece dentro de la empresa, con el consiguiente

cuidado y protección en su procesado mediante la implementación del PLM 2.0.

Al concluir el proyecto se ha analizado los diferentes sistemas o herramientas (ERP, PDM, CAD)

que engloba PLM 2.0 y cómo su evolución es la unión y cohesión de dichos sistemas,

obteniéndose PLM 2.0 como una herramienta polivalente y multifuncional. Además se han

obtenido los beneficios que puede aportar un PLM 2.0 frente a los beneficios particulares

ofrecidos por cada herramienta de forma individual. Con la implantación de un sistema PLM 2.0

no sólo se evitan problemas en la implementación y unión de las diferentes herramientas,

además se consigue desde el primer momento de la implantación un acceso rápido a las

diferentes herramientas y a toda la información que permanece centralizada.

Respecto a la implantación del hardware y el software, se han analizado los diferentes requisitos

y certificados necesarios para la inclusión de un sistema PLM 2.0, así como la arquitectura de los

sistemas y bases de datos. Se ha podido observar una gran escalabilidad de la herramienta,

pudiéndose implementar desde una pequeña empresa hasta una empresa internacional

extendida por todo el mundo.

En el concepto de gestión del ciclo de vida del producto se ha profundizado en el apartado de la

innovación colaborativa y cómo beneficia al trabajo en equipo, eliminando barreras como la

distancia entre organizaciones, gestión de las diferentes informaciones y acceso simultáneo con

posibilidad de realizar cambios en los productos. Con estas facilidades se potencia la aplicación

del conocimiento y la experiencia de los diferentes usuarios disminuyendo los tiempos de diseño

y minimizando el número de errores o fallos en la futura producción y fabricación.

Con la herramienta ENOVIA V6 se ha podido tomar conciencia de su utilidad y funcionalidad,

definiéndola como una potente herramienta en gestión de información y aplicación de las tareas

reales dentro de la empresa, centralizando gran parte del trabajo de la empresa en la

herramienta con su correspondiente almacenamiento y trazabilidad tanto de los flujos de trabajo

como de la información. También se ha podido obtener los beneficios de la división de trabajos

mediante los roles con sus características y el establecimiento de un procedimiento fijo en la

gestión del ciclo de vida del producto.

En el aspecto práctico de la herramienta ENOVIA V6, se ha analizado desde la estructura

organizativa y las diferentes relaciones que se dan entre sus elementos, como las diferentes

centrales dentro de ENOVIA V6 y su utilidad. Entre las diferentes centrales se han analizado con

mayor detalle la Central del Programa y la Central de Ingeniería, realizándose un ejemplo

práctico. Esto ha permitido afianzar los conceptos de objeto de negocio y objeto administrativo


175

así como los conceptos de organización y persona. Dentro del ejemplo se ha analizado desde la

implantación de una línea de producto hasta la asignación de la pieza real al concepto de

producto. Esto ha permitido tener una noción de cómo ENOVIA V6 gestiona estructuras lógicas

con toda la información adjunta, que se unen a las estructuras reales de manera virtual mediante

una sincronización y los beneficios que puede aportar a la hora de asimilar, entender y gestionar

toda la información de manera conjunta. En este sentido también se han analizado las listas de

materiales y las facilidades que ofrecen para el entendimiento de toda la estructura y ensamblaje

del producto.

En el aspecto operativo, los cambios de ingeniería han proporcionado la herramienta de

comunicación entre los diferentes usuarios y departamentos, estableciendo un proceso definido

con la actuación de los diversos usuarios en las diferentes decisiones. Esto ayuda al flujo de

información entre los diferentes usuarios y la acotación de las tareas de cada uno de ellos,

reduciendo los tiempos de cambio.

Por último hay que destacar la efectividad y su gran capacidad de ayuda, en especial si se

gestiona una gran cantidad de piezas y modelos con gran variabilidad en su utilización por

diversos motivos. Aunque en la implantación tan solo se ha analizado la efectividad por unidad,

se pueden sacar muchas conclusiones y muy positivas.

Finalizar estas conclusiones destacando que el análisis de la herramienta ENOVIA V6

realizado en el presente proyecto es tan solo una sección del abanico de posibilidades

que ofrece. Por tanto hay una gran parte de la herramienta por investigar, dando por

sentado que las soluciones que ofrece ENOVIA V6 son mucho más extensas y de una

complejidad mayor, convirtiéndola en una potente herramienta dentro de una empresa

con un impacto inmediato tras una implementación eficaz.

5.2 Posibles extensiones.

Tras la finalización del presente proyecto, con el análisis realizado a los sistemas PLM 2.0 y en

particular a la herramienta ENOVIA V6 se puede establecer diversas ramas para continuar la

investigación:

Comenzando con la innovación colaborativa, desde su implementación con las

herramientas de diseño hasta la gestión y puesta en común de la información en un

entorno con diversos usuarios.

En relación a la acción colaborativa, la implementación de la herramienta en diferentes

organizaciones que estuviesen en diferentes localizaciones y el análisis de la

centralización de toda la información en la base de datos común.

El análisis de las diferentes centrales, en especial las Centrales de Presupuestos y de

Proveedores. Con estas centrales el sistema incluiría las relaciones con terceras

organizaciones. Se agilizarían muchas operaciones que son repetitivas como los

pedidos o la generación de presupuestos para los clientes, quedando archivadas y

proporcionando una trazabilidad de las mismas.

Conclusiones y extensiones

176

Otro aspecto de gran importancia sería la orden a fabricación, ya que ENOVIA V6

permite enviar a planta las órdenes de activación o pausa de la fabricación y el

seguimiento de las mismas, incluso el diseño del lote.

Aunque se haya abordado de manera parcial, el estudio total de la efectividad, ya que

con esta herramienta se facilita en gran medida la gestión de los diversos modelos de

una forma rápida estableciendo relaciones lógicas. Al igual ocurriría con la Central de

Variaciones.

Análisis de costes y comparaciones entre las diferentes listas de materiales manejadas

por la organización.

Finalizar destacando la gran amplitud de la herramienta ENOVIA V6 y que las extensiones

propuestas son una parte de todas las posibles dentro de ENOVIA V6.

177

6 Bibliografía [1] F. Mas, J. L. Menéndez, M. Oliva and J. Ríos, Collaborative Engineering: an Airbus case

study, Procedia Engineering, vol. 63, pp. 336-345, 2013.

[2] S. Kalpakjian, S. R. Schmid, Manufacturing Engineering and Technology, 6th Edition, 2010, Prentice Hall.

[3] European Commission, "Aeronautics And Air Transport: Beyond Vision 2020 (Towards 2050)," Office for Official Publications of the European Communities, Luxembourg, 2010

[4] Airbus, Airbus to raise A320 Family production to 46 a month by Q2 2016, [Online], accessed on 13/1/2014, http://www.airbus.com/newsevents/news-events-single/detail/airbus-to-raise-a320-family-production-to-46-a-month-by-q2-2016/

[5] Boeing, Boeing to Start Building First Next-Generation 737 at Increased Production Rate, [Online], accessed on 13/1/2014, http://boeing.mediaroom.com/2014-02-04-Boeing-to-Start-Building-First-Next-Generation-737-at-Increased-Production-Rate

[6] Airbus, Airbus panoramic view of 2050, [Online], accessed on 13/1/2014, http://www.airbus.com/presscentre/pressreleases/press-release-detail/detail/airbus-presents-a-panoramic-view-of-2050/

[7] Y. Yong, M. Younus, L. Hu, F. Yuqing, Research of module-based airplane configuration management technology, Proceeding of the 2nd International Conference on Advance Computer Theory and Engineering,Cairo,Egypt,vol.1, pp 817-824, Sep 2009.

[8] M. K. Napier, Achieving mas customization in the Boeing Wire Responsibility Center, MSc. Thesis, MIT, 2000.

[9] F. De Florio, Airworthiness: An Introduction to Aircraft Certification, Elsevier Ltd. 2011.

[10] Bureau de normalisation de l'aeronautique et de l'espace, RG-AERO-000-40A. General recommendation for the programme management specification, Bureau de Normalisation de l'Aéronautique et de l'Espace, 1999

[11] T. Pardessus, Concurrent engineering development and practices for aircraft design at Airbus, in Proceedings of the 24th ICAS meeting, Yokohama, 2004.

[12] R. Haas and M. Sinha, Concurrent engineering at Airbus - a case study, International Journal of Manufacturing Technology and Management, vol. 6, no. 3/4, 2004.

[13] D. Kiritsis, A. Bufardi, P. Xirouchakis, Research issues on product lifecycle management and information tracking using smart embedded systems, Advanced Engineering Informatics, vol. 17, pp. 189-202, 2003.

[14] Academy.3ds.com. (s.f.). Discover PLM 2.0 on V6 Platform.

[15] Economist, T. (s.f.). http://www.economist.com/node/4368176.

[16] EOI. (s.f.). http://www.eoi.es/blogs/mtelcon/2013/02/15/la-gestion-del-ciclo-de-vida-del-producto-plm/.

[17] Management, I. (s.f.). https://informationmanagement.wordpress.com/category/sistemas-de-informacion/pdm/.

[18] PLM Automation Siemens. (s.f.). http://www.plm.automation.siemens.com/es_es/plm/.

[19] Prodintec. (s.f.). http://www.prodintec.es/catalogo/ficheros/aplicaciones/fichero_7_0210.pdf.

[20] Systèmes, D. (s.f.). Curso "Discover PLM 2.0 on V6".

[21] Systèmes, D. (s.f.). CURSO ENOVIA Engineering Central Essentials.

http://www.airbus.com/newsevents/news-events-single/detail/airbus-to-raise-a320-family-production-to-46-a-month-by-q2-2016/



http://boeing.mediaroom.com/2014-02-04-Boeing-to-Start-Building-First-Next-Generation-737-at-Increased-Production-Rate



http://www.airbus.com/presscentre/pressreleases/press-release-detail/detail/airbus-presents-a-panoramic-view-of-2050/

http://www.airbus.com/presscentre/pressreleases/press-release-detail/detail/airbus-presents-a-panoramic-view-of-2050/

http://www.economist.com/node/4368176

https://informationmanagement.wordpress.com/category/sistemas-de-informacion/pdm/

https://informationmanagement.wordpress.com/category/sistemas-de-informacion/pdm/

Bibliografía

178

[22] Systèmes, D. (s.f.). CURSO Getting Started with ENOVIA for IT Personnel.

[23] Systèmes, D. (s.f.). CURSO GETTING STARTED WITH ENOVIA V6.

[24] Systémes, D. (s.f.). CURSO V6 for ACADEMIA DISCOVERY Workshop.

[25] Systèmes, D. (s.f.). CURSO V6 PLM Express Essentials.

[26] Tsiplmcustomerportal. (s.f.). http://www.tsiplmcustomerportal.com/index.php?option=com_content&view=article&id=50&Itemid=56.

[27] Guía de Dassault Systèmes sobre el entorno V6.

trabajo fin de gradobibing.us.es/proyectos/abreproy/90150/fichero/tfg... · trabajo fin de grado:...

Documents