Análisis y desarrollo de productos en sistemas PLM
Anuncio
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 Tabla de contenido 1 2 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 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 3 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 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 1 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 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 2 Herramientas V6. ......................................................................................................... 58 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.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 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 4 Organización de la empresa. ....................................................................................... 89 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 Diseño e implementación de una línea de producto en un sistema a PLM ....................... 103 4.1 Introducción. .............................................................................................................. 103 3 4.2 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 5 6 4 Conceptos en la implementación. .............................................................................. 103 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 Conclusiones y extensiones. ............................................................................................. 173 5.1 Conclusiones obtenidas. ............................................................................................ 173 5.2 Posibles extensiones. ................................................................................................ 175 Bibliografía ........................................................................................................................ 177 Í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 13. Configuración física de equipos con ENOVIA V6 ....................................................... 39 Figura 14. Configuración física de equipos con ENOVIA V6 ....................................................... 39 Figura 15. Configuración física de equipos con ENOVIA V6 ....................................................... 40 Figura 16. Configuración física de equipos con ENOVIA V6 ....................................................... 40 Figura 17. Configuración física de equipos con ENOVIA V6 ....................................................... 41 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 5 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 6 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 7 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 8 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 9 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 11 Introducción y Objetivos - 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. 12 Análisis y desarrollo de productos en sistemas PLM 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. 13 Introducción y Objetivos 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]. 14 Análisis y desarrollo de productos en sistemas PLM 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. 15 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. 17 Ciclo de vida del producto 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 18 Análisis y desarrollo de productos en sistemas PLM 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… 19 Ciclo de vida del producto 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. 20 Análisis y desarrollo de productos en sistemas PLM 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. 21 Ciclo de vida del producto 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: 22 Internet es una infraestructura IT, mientras que el PLM es un middleware, software, y unas prácticas industriales, todo ello combinado. Análisis y desarrollo de productos en sistemas PLM 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: 23 Ciclo de vida del producto 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. 24 Análisis y desarrollo de productos en sistemas PLM 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: 25 Ciclo de vida del producto • 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, 26 Análisis y desarrollo de productos en sistemas PLM 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. 27 Ciclo de vida del producto 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 28 Análisis y desarrollo de productos en sistemas PLM 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. 29 Ciclo de vida del producto 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: 30 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) Análisis y desarrollo de productos en sistemas PLM 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) 31 Ciclo de vida del producto 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: 32 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) Análisis y desarrollo de productos en sistemas PLM 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. 33 Ciclo de vida del producto 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 34 Análisis y desarrollo de productos en sistemas PLM 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) 35 Ciclo de vida del producto 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). 36 Análisis y desarrollo de productos en sistemas PLM 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 37 Ciclo de vida del producto 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: 38 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. Análisis y desarrollo de productos en sistemas PLM 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. Figura 13. Configuración física de equipos con ENOVIA V6 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. Figura 14. Configuración física de equipos con ENOVIA V6 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: 39 Ciclo de vida del producto 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. Figura 15. Configuración física de equipos con ENOVIA V6 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. Figura 16. Configuración física de equipos con ENOVIA V6 40 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 Análisis y desarrollo de productos en sistemas PLM clientes web y se integra con herramientas como Lotus SameTime o Microsoft Office Communicator Server. Figura 17. Configuración física de equipos con ENOVIA V6 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. 41 Ciclo de vida del producto 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. 42 Análisis y desarrollo de productos en sistemas PLM 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. 43 Ciclo de vida del producto 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 44 Sistema operativo y hardware Análisis y desarrollo de productos en sistemas PLM Vendor Windows 7 SP1 32-bit and 64-bit Edition Windows Server 2008 R2 SP1 Red Hat Enterprise Linux 5.5 32-bit or 64bit 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 Product Microsoft Internet Internet Explorer 8/ Oracle JRE 7 (32-bit) Microsoft Internet Explorer 9/ Oracle JRE 7 (32-bit) Open Source Firefox 10 ESR / Oracle JRE 7 (32-bit) Open Source Firefox / Oracle JRE 7 (32-bit) Apple Safari 5.1.1 / Sun JRE 6 (64-bit) Exploradores web (IE: Internet Explorer; FX: FireFox; S: Safari) Following products are not supported : CST,LES,LHC,LPI,LP Q,LPX,LRA,PQC,QIC Firefox 3.0.18 (32-bit) Firefox 3.5.9 (32-bit) Following Following products are not supported products are not : supported : ADS,ARN,ARP,ARS ADS,ARN,ARP,A RS 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. 45 Ciclo de vida del producto 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. Windows 7 Sistema Operativo 64-bit (Sin soporte WOW64 ) Exploradores (Cualquiera) Prerequisitos 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; (32-bit version) c) Microsoft Lync Server 2010 IBM Lotus Instant Messaging 8.5 (32-bit version of Oracle JRE) Tabla 2. Requisitos software para clientes pesados. Sistema operativo. 46 Análisis y desarrollo de productos en sistemas PLM 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: Producto Propietario Plataforma Sistema operativo(HARDWARE) Windows Red Hat Server 2008 Enterprise R2 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 x86-64 x86-64 Intel or AMD Intel or AMD x86-64 Intel or AMD 64-bit POWER 5, 6, 7 64-bit Itanium or PA-RISC 64-bit Solaris 10 64-bit Solaris 10 64-bit Solaris 11 64-bit Solaris 11 64-bit SPARC III or higher x86-64 Intel or AMD Software servidor de aplicaciones (web server) 47 WebLogic with ORACLE JDK 7. with ORACLE JDK 7. Tomcat Open Source IBM WebSphere con bundled IBM JDK Oracle Ciclo de vida del producto ORACLE JDK 7. 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 Productos no soportado: LES,LHC,LPI,LPQ ,LPX,LRA,PQC,QIC Productos no soportado: C3D,C2D Productos no soportado: VPM 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. No soporta: VPM with ORACLE with ORACLE JDK 7. JDK 7. Productos no Productos no soportados: soportados: VPM VPM Tabla 4. Requisitos software para servidor. Sistema operativo y servidor de aplicaciones. Microsoft IBM Oracle Database Oracle DATABASES DB2 Productos no soportados:: LES,LHC,LPI,LPQ,LPX,LRA PQC,QIC Productos no Productos no Productos no soportados:: soportados: : soportados: : LES,LHC,LPI,LPQ LES,LHC,LPI,LPQ LES,LHC,LPI,LPQ LPX,LRA,PQC,QI LPX,LRA,PQC,QI , LPX C C ,LRA,PQC,QIC SQL Serve r 2008 Productos no soportados : and LES,LHC,LPI,LPQ,LPX,LRA,PQC,QI 2012 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) 48 Windows Server Red Hat Linux 64-bit 64-bit SuSE Linux 64bit AIX 64-bit Solaris 64-bit Análisis y desarrollo de productos en sistemas PLM 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 ENOVIA Live Collaboration Server (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 Red Hat Linux 64-bit 64-bit SuSE Linux 64bit AIX 64-bit Solaris 64-bit ENOVIA Live Collaboration Server (CSR) Stand-alone Server 4 4 4 4 4 Database Server (DB) Stand-alone Server 6 6 6 6 6 File Collaboration Server (FCS) Stand-alone Server 2 2 2 2 2 3D Index Server (3DX) Stand-alone Server 4 4 4 4 N/A Full-Text Search (FTS) Stand-alone Server 4 4 4 4 4 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. 49 Ciclo de vida del producto 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 Dell Estación de trabajo Procesador Precision M4800 Intel Core i74702MQ @2.80Ghz Precision M6800 Intel Core i74930MX @3.00Ghz Memoria/disco Windows 7. 8 / 16 RAM 500/ 256 Windows 7 8/16 RAM 500 / 750 Windows 7 Dell Workstation T3610 Intel Xeon CPU E52650 v2 @ 2.60GHz Windows 7 Celsius J530 Intel Xeon CPU E31225 v3 @ 3.20GHz, 4 Core(s) Intel Xeon CPU E51603 0 @ 2.80GHz, 4 Core(s) 8/16 RAM 500 / 1T Adap. Gráfico Tipo Fecha AMD FirePro M5100 P (15”) 02/14 nVidia Quadro K3100M P(17”) 02/14 nVidia Quadro K6000 (12 Gigas) S 12/13 S 01/14 S 11/13 8/32 RAM nVidia Quadro K600 500 GB (1 Giga) Windows 7 8/16 RAM nVidia Quadro K4000 500 / 2T (3Gigas) Fujitsu Celsius M730 50 Análisis y desarrollo de productos en sistemas PLM HP Celsius C620 Rack Workstation (with client portal (Teradici based) Futro L420) Intel(R) Xeon(R) CPU E3-1280 V2 @ 3.60GHz Windows 7 HP Workstation Z820 certified configuration - Z420/Z620 derived configuration Intel Xeon Processor E5-2697 v2, Chipset Intel C602 HP Workstation Z820 certified configuration - Z420/Z620 derived configuration Intel Xeon Processor E5-2697 v2, Chipset Intel C602 Windows 7 HP Zbook 17" Intel(R) Core(TM) i74900MQ CPU @ 2.80GHz Lenovo 500 / 2T (3 Gigas) Windows 7 8 RAM 1T S 11/13 nVidia Quadro K6000 derived from Quadro K600 S 01/14 nVidia Quadro K5000 derived from Quadro K600 S 12/13 P 11/13 P 11/13 P 04/13 S 08/11 P 15 01/14 P15 01/14 S 12/13 4 RAM nVidia Quadro K5100M 750 T (16 Gigas) Intel(R) Core(TM) i74900MQ CPU @ 2.80GHz Windows 7 4/32 RAM nVidia Quadro K2100M 750 T (2 Gigas) Intel Xeon E3HP Workstation Z220 1240v2, chipset Intel 7 Series C216 Windows 7 8/16 RAM nVidia Quadro K4000 250 T (1 Giga) IBM x3650 M3 Rack (Remote Access Device WYSE ThinClient) Intel Xeon E5506 , up to 2.13 GHz, chipset Intel 5520/5500/X5 Windows 8 Windows 7 ThinkPad W540 Intel Core i7 4800MQ @ 2.70 Ghz, chipset Intel ID8C4F Intel Core i5-4330M @ 2.80GHz, chipset Intel ID8C4F Windows 7 Intel Xeon E5-2680 (2.70 GHz, 8C), Intel C602 chipset Windows 7 HP Zbook 15" IBM 8/32 RAM nVidia Quadro K4000 ThinkPad W540 ThinkStation S30 Hasta 268 G 16 T nVidia Quadro 2000D 32 RAM nVidia Quadro K2100M 2T (2 Gigas) 32 RAM 2T 8/128 RAM 2T nVidia Quadro K1100M nVidia Quadro K6000 derived from Quadro K600 (1 G) Tabla 8. Equipos certificados por Dassault Systèmes para instalación de V6. 51 Ciclo de vida del producto 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: 52 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. 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. 53 La gestión del ciclo de vida en ENOVIA 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: 54 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. Análisis y desarrollo de productos en sistemas PLM 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. 55 La gestión del ciclo de vida en ENOVIA 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: 56 Análisis y desarrollo de productos en sistemas PLM 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. 57 La gestión del ciclo de vida en ENOVIA - 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. 58 Análisis y desarrollo de productos en sistemas PLM 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. 59 La gestión del ciclo de vida en ENOVIA 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. - - 60 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. Análisis y desarrollo de productos en sistemas PLM 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. 61 La gestión del ciclo de vida en ENOVIA 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: 62 3D Indexing Server (3DX): recuperación acelerada de datos 3D. Análisis y desarrollo de productos en sistemas PLM 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 63 La gestión del ciclo de vida en ENOVIA 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. 64 Análisis y desarrollo de productos en sistemas PLM 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. 65 La gestión del ciclo de vida en ENOVIA 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: 66 Compañía. Unidades de Negocio. Departamentos. Localizaciones. Plantas. Análisis y desarrollo de productos en sistemas PLM 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. 67 La gestión del ciclo de vida en ENOVIA 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. 68 Análisis y desarrollo de productos en sistemas PLM 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). 69 La gestión del ciclo de vida en ENOVIA 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: - 70 Nombre del Servidor. Usuario y contraseña. Contexto de seguridad. Seleccionará el ámbito en el cuál trabaja. Análisis y desarrollo de productos en sistemas PLM 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. 71 La gestión del ciclo de vida en ENOVIA 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: 72 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. Análisis y desarrollo de productos en sistemas PLM 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. 73 La gestión del ciclo de vida en ENOVIA 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: - 74 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. Análisis y desarrollo de productos en sistemas PLM - 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 75 La gestión del ciclo de vida en ENOVIA 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 76 Análisis y desarrollo de productos en sistemas PLM 5. 6. 7. 8. 9. 10. 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. Sub Requisitos: elabora algunos aspectos de los requisitos originales. No proporciona ninguna información nueva, solo realiza aclaraciones de la información ya dada. Requisito derivado: no proporciona una nueva información. Esta información es derivada de los requisitos originales. 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. Casos de prueba: es un conjunto de entradas y resultados esperados que al realizar ejercicios del componente determinan si hay errores o fallos. 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. 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. 77 La gestión del ciclo de vida en ENOVIA 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): 78 Compatibilidad. Compatibilidad del producto. Análisis y desarrollo de productos en sistemas PLM - 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. 79 La gestión del ciclo de vida en ENOVIA 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. - 80 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. Análisis y desarrollo de productos en sistemas PLM - 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. 81 La gestión del ciclo de vida en ENOVIA 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: 82 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. Análisis y desarrollo de productos en sistemas PLM 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. 83 La gestión del ciclo de vida en ENOVIA 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: 84 Análisis y desarrollo de productos en sistemas PLM - - 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. 85 La gestión del ciclo de vida en ENOVIA 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: - 86 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. Análisis y desarrollo de productos en sistemas PLM 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. 87 La gestión del ciclo de vida en ENOVIA 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: - - 88 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. Análisis y desarrollo de productos en sistemas PLM 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…) 89 La gestión del ciclo de vida en ENOVIA 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. 90 Análisis y desarrollo de productos en sistemas PLM 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. 91 La gestión del ciclo de vida en ENOVIA 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 92 Análisis y desarrollo de productos en sistemas PLM 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 93 La gestión del ciclo de vida en ENOVIA 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. 2. 3. 4. 5. 6. 7. 8. 9. Dimensiones. Atributos. Tipos. Relaciones. Programas. Formatos. Valores. Tiendas. 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. 94 Análisis y desarrollo de productos en sistemas PLM 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: 95 La gestión del ciclo de vida en ENOVIA 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. 96 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. Análisis y desarrollo de productos en sistemas PLM 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. 97 La gestión del ciclo de vida en ENOVIA 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: 98 Análisis y desarrollo de productos en sistemas PLM 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. 99 La gestión del ciclo de vida en ENOVIA - 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. 100 Análisis y desarrollo de productos en sistemas PLM 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: 101 La gestión del ciclo de vida en ENOVIA 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 102 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. 103 Diseño e implementación de una línea de producto en un sistema PLM 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. 104 Análisis y desarrollo de productos en sistemas PLM 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”. 105 Diseño e implementación de una línea de producto en un sistema PLM 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. 106 Análisis y desarrollo de productos en sistemas PLM 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”. 107 Diseño e implementación de una línea de producto en un sistema PLM 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. 108 El sistema “Elementos de montaje de sujeción” está formado por las piezas “Placa anillo” y dos piezas iguales llamadas “Pin anillo”. Análisis y desarrollo de productos en sistemas PLM 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. 109 Diseño e implementación de una línea de producto en un sistema PLM 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. 110 Análisis y desarrollo de productos en sistemas PLM 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. 111 Diseño e implementación de una línea de producto en un sistema PLM 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. 112 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. Análisis y desarrollo de productos en sistemas PLM 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. 113 Diseño e implementación de una línea de producto en un sistema PLM 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. 114 Análisis y desarrollo de productos en sistemas PLM 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. 115 Diseño e implementación de una línea de producto en un sistema PLM 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: - - - - 116 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. Análisis y desarrollo de productos en sistemas PLM - - 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”. 117 Diseño e implementación de una línea de producto en un sistema PLM 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 118 Análisis y desarrollo de productos en sistemas PLM 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. 119 Diseño e implementación de una línea de producto en un sistema PLM 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. 120 Análisis y desarrollo de productos en sistemas PLM 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”. 121 Diseño e implementación de una línea de producto en un sistema PLM 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: 122 Análisis y desarrollo de productos en sistemas PLM 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: 123 Diseño e implementación de una línea de producto en un sistema PLM 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: 124 Análisis y desarrollo de productos en sistemas PLM 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. 125 Diseño e implementación de una línea de producto en un sistema PLM 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. 126 Análisis y desarrollo de productos en sistemas PLM 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”. 127 Diseño e implementación de una línea de producto en un sistema PLM 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”. 128 Análisis y desarrollo de productos en sistemas PLM 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 129 Diseño e implementación de una línea de producto en un sistema PLM - 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. 130 Análisis y desarrollo de productos en sistemas PLM 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: 131 Diseño e implementación de una línea de producto en un sistema PLM 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. 132 Análisis y desarrollo de productos en sistemas PLM 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: 133 Diseño e implementación de una línea de producto en un sistema PLM Figura 73. Página de creación de un modelo. - - - - 134 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. Análisis y desarrollo de productos en sistemas PLM - 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. 135 Diseño e implementación de una línea de producto en un sistema PLM 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. 136 Análisis y desarrollo de productos en sistemas PLM 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 137 Diseño e implementación de una línea de producto en un sistema PLM “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: 138 Análisis y desarrollo de productos en sistemas PLM - 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 139 Diseño e implementación de una línea de producto en un sistema PLM 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 140 Análisis y desarrollo de productos en sistemas PLM 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. 141 Diseño e implementación de una línea de producto en un sistema PLM 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. 142 Análisis y desarrollo de productos en sistemas PLM 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. 143 Diseño e implementación de una línea de producto en un sistema PLM 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. 144 Análisis y desarrollo de productos en sistemas PLM 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. 145 Diseño e implementación de una línea de producto en un sistema PLM 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 146 Análisis y desarrollo de productos en sistemas PLM (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. 147 Diseño e implementación de una línea de producto en un sistema PLM 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: 148 Análisis y desarrollo de productos en sistemas PLM 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. 149 Diseño e implementación de una línea de producto en un sistema PLM - - - 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: - - 150 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. Análisis y desarrollo de productos en sistemas PLM - 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. 151 Diseño e implementación de una línea de producto en un sistema PLM 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: - - 152 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. Análisis y desarrollo de productos en sistemas PLM - - - 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). 153 Diseño e implementación de una línea de producto en un sistema PLM 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. 154 Análisis y desarrollo de productos en sistemas PLM 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.” 155 Diseño e implementación de una línea de producto en un sistema PLM 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. 156 Análisis y desarrollo de productos en sistemas PLM 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” 157 Diseño e implementación de una línea de producto en un sistema PLM 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: - - 158 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. Análisis y desarrollo de productos en sistemas PLM - 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. 159 Diseño e implementación de una línea de producto en un sistema PLM 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”. 160 Análisis y desarrollo de productos en sistemas PLM 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. 161 Diseño e implementación de una línea de producto en un sistema PLM Figura 124. Página de clonación de una pieza. Se abrirá una nueva ventana en la que tendremos que rellenar los siguientes campos: - - - - - - 162 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, Análisis y desarrollo de productos en sistemas PLM 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. 163 Diseño e implementación de una línea de producto en un sistema PLM 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”. 164 Análisis y desarrollo de productos en sistemas PLM 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. 165 Diseño e implementación de una línea de producto en un sistema PLM - - 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”. 166 Análisis y desarrollo de productos en sistemas PLM 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. 167 Diseño e implementación de una línea de producto en un sistema PLM 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. 168 Análisis y desarrollo de productos en sistemas PLM 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. 169 Diseño e implementación de una línea de producto en un sistema PLM 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. 170 Análisis y desarrollo de productos en sistemas PLM 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. 171 Diseño e implementación de una línea de producto en un sistema PLM 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. 172 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 173 Conclusiones y extensiones 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 174 Análisis y desarrollo de productos en sistemas PLM 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. 175 Conclusiones y extensiones 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. 176 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, 6 th 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-eventssingle/detail/airbus-to-raise-a320-family-production-to-46-a-month-by-q22016/ [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-04Boeing-to-Start-Building-First-Next-Generation-737-at-IncreasedProduction-Rate [6] Airbus, Airbus panoramic view of 2050, [Online], accessed on 13/1/2014, http://www.airbus.com/presscentre/pressreleases/press-releasedetail/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-delproducto-plm/. [17] Management, I. (s.f.). https://informationmanagement.wordpress.com/category/sistemas-deinformacion/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. 177 Bibliografía [22] [23] [24] [25] [26] Systèmes, D. (s.f.). CURSO Getting Started with ENOVIA for IT Personnel. Systèmes, D. (s.f.). CURSO GETTING STARTED WITH ENOVIA V6. Systémes, D. (s.f.). CURSO V6 for ACADEMIA DISCOVERY Workshop. Systèmes, D. (s.f.). CURSO V6 PLM Express Essentials. Tsiplmcustomerportal. (s.f.). http://www.tsiplmcustomerportal.com/index.php?option=com_content&view=article&id=50&It emid=56. [27] Guía de Dassault Systèmes sobre el entorno V6. 178
