methodology for design and integration of collaborative e-engineering environments

INSTITUTO TECNOLÓGICO Y DE ESTUDIOS

SUPERIORES DE MONTERREY

CAMPUS MONTERREY

DIVISIÓN DE INGENIERÍA Y ARQUITECTURA PROGRAMA DE GRADUADOS EN INGENIERÍA

METHODOLOGY FOR DESIGN AND INTEGRATION OF COLLABORATIVE E-ENGINEERING ENVIRONMENTS

TESIS

PRESENTADA COMO REQUISITO PARCIAL PARA OBTENER EL GRADO ACADÉMICO DE

MAESTRO EN CIENCIAS CON ESPECIALIDAD EN SISTEMAS DE MANUFACTURA

RICARDO MEJÍA GUTIÉRREZ

DICIEMBRE 2003

Ricardo Mejía Gutiérrez

SUMMARY

The globalization of the industrial activities and decentralization of the product life cycle activities, have lead companies to work collaboratively and simultaneously with distant engineering partners. The expansion of Internet-based tools has opened new opportunities for collaborative work improvement, through the development of a new generation of tools designed to support this kind of activities. For these reasons the creation of Collaborative e-Engineering Environments (CeEE) has been a key issue in nowadays Information Technology’s challenges, in order to enable people to collaborate and interact on the development of a new product regardless of their geographic locations. The presented research describes a methodology for the design and integration of CeEE. The definition of this methodology was accomplished under an action research approach, as the research methodology used, where the experiences in developing Collaboration environments has lead the author to define an structured way of creating CeEE in order to transfer these concepts to the industry. The methodology has four main steps: I) Define the company requirements and model AS-IS development process, II) Assess AS-IS model, and model TO-BE development process, III) Design and integration of environment and applications, which includes: III.1) Modeling the workflow (MODEL), III.2) Selection and Integration of e-Engineering applications (INTEGRATE), III.3) Connection of environment and application using standard and web protocols (CONNECT) and III.4) Definition of performance measures and monitoring techniques (MONITOR). The last stage IV) Execute and manage the CeEE. The methodology was used for the development of three CeEE, and the action research cycles allow the improvements detection from one to the next one. The principal results obtained were: 1) A taxonomy for supporting applications in Integrated Product Development was proposed, based on the experiences of applying and improving the methodology and it is used as a tool for the computer applications integration, 2) A revised and improved methodology for the CeEE design, integration and transfer to the industry was developed; and 3) the improvement of the methodology was achieved applying it in three CeEE scenarios. The major conclusions from this research are: a) The applications taxonomy allows the identification of the necessary tools that engineers needs as a minimal support in their activities execution, b) Not all the activities require collaboration supporting tools, but all of them requires the exchange of information and knowledge, c) the functional tools, are specific supporting tools, used on specific activities, while the coordination, collaboration and Information management are platforms standardized to the whole engineering life cycle, d) the technology may not be an obstacle in the collaboration efforts of the enterprises, and e) related to the application of Action Research, it can be concluded that cycling process of execution and reflection, allow identification of improvements both, for Technologies as well as for the automated process in execution (workflow). As a result, the enterprises must consider that in the near future collaborative activities for engineering will be the key for the competitive position in a globalized market.

i


CONTENTS

SUMMARY ....................................................................................................... I

CONTENTS ...................................................................................................... II

LIST OF FIGURES..............................................................................................VI

LIST OF TABLES..............................................................................................VIII

CHAPTER 1. INTRODUCTION........................................................................... 1

1.1 Background ..................................................................................................1 1.2 Research justification ..................................................................................1 1.3 Objective and relevance of the research....................................................3 1.4 Scope of the research..................................................................................3 1.5 Thesis organization......................................................................................4

CHAPTER 2. LITERATURE REVIEW................................................................. 6

2.1 Introduction ..................................................................................................6 2.2 Market analysis.............................................................................................8

2.2.1 From traditional engineering, to Collaborative Engineering.......... 8 2.2.2 Industry background ......................................................................... 9

2.3 Collaborative Engineering Environments ................................................10 2.3.1 Context ............................................................................................. 11 2.3.2 Related research .............................................................................. 13

CHAPTER 3. RESEARCH METHODOLOGY................................................... 17

3.1 Introduction ................................................................................................17 3.2 What is action research?...........................................................................19 3.3 Action research cycles ..............................................................................20

ii


iii

CHAPTER 4. METHODOLOGY FOR DESIGN AND INTEGRATION OF COLLABORATIVE E-ENGINEERING ENVIRONMENTS ................................. 23

4.1 Step I: Define the company requirements and model the AS-IS of the development process ................................................................................26

4.2 Step II: Assess the AS- IS, and model the TO-BE....................................27 4.2.1 Process Domain............................................................................... 28 4.2.2 Information /Knowledge Domain .................................................... 29 4.2.3 Organization Domain....................................................................... 30 4.2.4 Technology Domain......................................................................... 31

4.3 Step III: Design and integration of environment and applications.........32 4.3.1 MODEL: Modeling the workflow ..................................................... 32

4.3.1.1 Create and model the Workflow............................................ 33 4.3.1.2 Define the people involved in modeling................................. 35 4.3.1.3 Follow the modeling steps..................................................... 35

4.3.2 INTEGRATE: Selection and Integration of e-Engineering applications ...................................................................................... 36 4.3.2.1 Identification of Functional tools ............................................ 38 4.3.2.2 Definition of Coordination, Collaboration and

Information/Knowledge Management tools ........................... 40 4.3.3 CONNECT: Connect environment and applications using

standard and web protocols ........................................................... 41 4.3.3.1 Identify required information from partners involved ............. 43 4.3.3.2 Define connectivity solution through exchange formats ........ 45

4.3.4 MONITOR: Definition of performance measures and monitoring techniques .................................................................... 48 4.3.4.1 Identify the types of measures (default from WFMS and

user-defined) ......................................................................... 50 4.3.4.2 Define customized performance measures........................... 51 4.3.4.3 Determine the monitoring level.............................................. 53

4.4 Step IV: Execute and manage the CeEE...................................................54 4.4.1.1 Configure the generic environment settings .......................... 54 4.4.1.2 Release the workflow model ................................................. 55 4.4.1.3 Execute the Workflow Runtime ............................................. 56

CHAPTER 5. CASE STUDY ............................................................................. 58

5.1 Cycle 1: Php groupware Technologies ....................................................60 5.1.1 Step I. AS-IS ..................................................................................... 60 5.1.2 Step II. TO-BE ................................................................................... 60 5.1.3 Step III. Environment ....................................................................... 61

5.1.3.1 Step III.1 - MODEL................................................................ 62 5.1.3.2 Step III.2 - INTEGRATE ........................................................ 63


5.1.3.3 Step III.3 - CONNECT........................................................... 64 5.1.3.4 Step III.4 - MONITOR............................................................ 64

5.1.4 Step IV. Execute ............................................................................... 64 5.2 Cycle 2: Free-ware applications................................................................65

5.2.1 Step I. AS-IS ..................................................................................... 66 5.2.2 Step II. TO-BE ................................................................................... 66 5.2.3 Step III. Environment ....................................................................... 66

5.2.3.1 Step III.1 – MODEL ............................................................... 66 5.2.3.2 Step III.2 – INTEGRATE ....................................................... 67 5.2.3.3 Step III.3 – CONNECT .......................................................... 68 5.2.3.4 Step III.4 – MONITOR........................................................... 68

5.2.4 Step IV. Execute ............................................................................... 69 5.3 Cycle 3: Industrial Scenario - Case Study................................................70

5.3.1 General description of the scenario............................................... 70 5.3.1.1 Industry networks management ............................................ 70 5.3.1.2 Customer Background .......................................................... 71 5.3.1.3 Product description ............................................................... 73

5.3.2 Design the Collaborative e-Engineering Environment for Aerospace Maintenance Tooling .................................................... 73 5.3.2.1 Step I. AS-IS ......................................................................... 73 5.3.2.2 Step II. TO-BE....................................................................... 77 5.3.2.3 Step III. Environment............................................................. 77

5.3.2.3.1 Step III.1 – MODEL ..............................................81 5.3.2.3.2 Step III.2 – INTEGRATE ......................................82 5.3.2.3.3 Step III.3 – CONNECT .........................................84 5.3.2.3.4 Step III.4 – MONITOR..........................................85

5.3.2.4 Step IV. Execute ................................................................... 86

CHAPTER 6. RESULTS AND CONCLUSIONS................................................ 89

6.1 Results ........................................................................................................89 6.2 Conclusions:...............................................................................................89 6.3 Further research:........................................................................................91

REFERENCES ................................................................................................... 92

APPENDIXES……………………………………………………………………........97 APPENDIX A. Collaborative environments related research (description) APPENDIX B. Computer Applications Taxonomy B.1 Functional Tools

iv


B.1.1 Functional Tools based on Information B.1.2 Functional Tools based on Models

B.2 Coordination Tools B.3 Collaboration Tools B.4 Tools for information / knowledge Management APPENDIX C. The IGES, DXF and STEP exchange formats C.1 IGES (Initial Graphics Exchange Specification) C.2 DXF (Data eXchange Format) C.3 STEP (STandard for the Exchange of Product model data) APPENDIX D. Process domain for cycle 3: product transfer case study APPENDIX E. IBM - WebSphereTM E.1 Technology Architecture and Application Architecture. E.2 High-level overview of the WebSphere platform

E.2.1 WebSphere Foundation & Tools E.2.2 WebSphere business portals E.2.3 WebSphere Business Integration products

E.3 Applications to Implement CeEE Architecture from Cycle 3: Landing Gear case study

v


LIST OF FIGURES

Figure 1-1 Integrated e-Services offered by e-HUBs [Molina, 2003].................... 3

Figure 2-1 Tendencies to 21 Century engineering and manufacturing [Wright,

2001]

st

.................................................................................................. 7

Figure 2-2 Global product development [Molina, 2003]. ...................................... 9

Figure 2-3 A Virtual Collaborative Design Environment conceptual model

[Bochenek and Ragusa, 2001] ......................................................... 12

Figure 2-4 Opportunity in early design stage [Wang, et. al., 2002] .................... 16

Figure 3-1 Understand action research [Iversen, et. al., 2002] .......................... 17

Figure 3-2 Concept of action research [Kemmis and McTaggart, 1992]............ 21

Figure 3-3 Action Research evolution through cycles [Crane and Richardson,

2000] ................................................................................................ 22

Figure 4-1 e-Engineering Transfer Model to the industry................................... 24

Figure 4-2 Methodology for Technology Transfer .............................................. 25

Figure 4-3 Generic project core process, activities and configurable sub-activities

......................................................................................................... 27

Figure 4-4 AS-IS / TO-BE process development assessment ........................... 28

Figure 4-5 Design and integration of environment and applications .................. 32

Figure 4-6 Workflow based on the four domains of the Particular model for an

instance of Product/Process/Facility design ..................................... 33

Figure 4-7 Connect applications of Customers and Suppliers ........................... 44

Figure 4-8 Performance Measures definition..................................................... 49

Figure 4-9 Executed steps from Collaborative Environments Design ................ 55

Figure 4-10 Workflow Reference Model [Hollingsworth, 1994] .......................... 57

Figure 5-1 Case studies: Performed Action Research Spiral............................. 58

Figure 5-2 Integrated High-Tech Product Development Process....................... 61

Figure 5-3 Stages of Product Development process in the PHP CeEE............. 62

Figure 5-4 Php groupware architecture ............................................................. 64

vi


vii

Figure 5-5 PHP-Groupware characteristics ....................................................... 65

Figure 5-6 Stages of Product Development process in freeware based CeEE..67

Figure 5-7 MSN collaborative tools (Messenger and groups)TM ........................ 69

Figure 5-8 Virtual Enterprise Broker projects..................................................... 72

Figure 5-9 Installation/removal tool for airplane landing gear ............................ 73

Figure 5-10 Generic product transfer process based on the quality

documentation .................................................................................. 74

Figure 5-12 Selected activity to exemplify the Environment design (Step III) .... 77

Figure 5-11 Product transfer TO-BE.................................................................. 78

Figure 5-13 3D solid model of the Pick-up tool .................................................. 80

Figure 5-14 TO-BE assessment for the selected activity ................................... 81

Figure 5-15 Workflow model for product transfer (in LotusWF )TM ..................... 82

Figure 5-16 Applications identification in the Product Transfer Engineering

changes activity ................................................................................ 83

Figure 5-17 Information exchange in Engineering changes activity from Product

transfer process................................................................................ 85

Figure 5-18 Performance measures definition in engineering changes activity .86

Figure 5-19 CeEE architecture with WebSphere Technologies. ........................ 87

Figure 6-1 Recommended sequencing for CeEE design................................... 90


LIST OF TABLES

Table 2-1 Collaborative Engineering Environments Review .............................. 14

Table 4-1 Computer applications Classification that supports integrated product

development ..................................................................................... 37

Table 4-2 Functional tools that supports integrated Product/Process/Facility

development ..................................................................................... 38

Table 4-3 Standard-formats in common CAD systems...................................... 45

Table 4-4 CAD representations and some associated file formats .................... 47

Table 4-5 Functionality needed after translation and the associated CAD

representations................................................................................. 47

Table 4-6 Performance measures classification (Adapted from Zachman’s

Framework) ...................................................................................... 53

Table 5-1 Legend for Methodology implementation in CeEE developments ..... 59

Table 5-2 Computer applications for the PHP-Environment Integration ............ 63

Table 5-3 CeEE based on Freeware tools......................................................... 68

Table 5-4 General activities in the Broker business opportunities classification 71

Table 5-5 European Standard for case study RST profiles and their equivalences

......................................................................................................... 79

Table 5-6 Case study Material and their equivalences ...................................... 79

Table 5-7 CeEE based on WebSphere toolsTM .................................................. 84

viii


Chapter 1. Introduction 1.1 Background

The age of information era and globalization has created a situation of increased international competition which has put manufacturing companies under augmented pressure in order to sustain and improve their market share. This has lead to more international collaboration within large companies or among different companies. Under this scenario the tasks of design and manufacturing of products are being executed by different facilities within a large company or by several different companies, usually at different geographically locations.

An example of this situation is happening between Latin America and the

United States/European Union, where the design groups are in USA/EU and manufacturing facilities are located in Latin America. One of these cases is the automotive industry where systems and parts are distributed among 1st Tier and 2nd Tier suppliers. For example a part is designed in USA and then the manufacture is transferred to Mexican companies [Aca, et. al., 2003]. 1.2 Research justification

The special case of the North American Free Trade Agreement (NAFTA) has closed the relation between USA and Mexico, especially commercial and industry relations. Today, Northern Mexican Region has been seen the installation of a large number of US manufacturing facilities looking for advantages in low cost labor, close to border localization and Mexican manufacturing expertise. The sectors with higher grow in the border are Electronic, Automotive and Power Industry [SECOFI 1999]. However, these facilities require transferring products in a more efficient and effective manner in order to reduce time to market.

ITESM, Campus Monterrey

1


Problems faced between US and Mexican companies are lack of collaboration during early stages of life cycle product development, miscommunication between design and manufacturing engineers, poor access to information manufacturing technological capacities and deficient knowledge of manufacturing process capabilities.

In order to support the manufacturing community of Small and Medium Enterprises (SMEs), the strategic programs as Virtual Industry Clusters [VIC, 2000] and Virtual Enterprise Broker [VEB, 2001] have been implemented. These programs support the development of SMEs through the use of information technology and the creation of value added networks. Within these programs as well, groundbreaking work has been done in manufacturing, especially in life cycle engineering, collaborative product development, and SME clustering and brokerage, where the integration of these areas, are the challenge for the next generation engineering work. Likewise, the world wide engineering requirements are demanding more than parts/components outsourcing and also engineering knowledge sharing with their partners and allies, through an Integrated Product Development.

The concept of “Integrated Product Development” means the integration of all the activities, methods, information and technologies to conceive the complete Product Life Cycle” [Tipnis 1999]. Nowadays, several Computer based information systems have been introduced to support Integrated Product Development; however, there are two major technical challenges in computer supported group work:

• The applications have to enable the product development team to share, discuss and realize ideas.

• The environment and the collaborative applications integrated in these

environments. The environment has to provide some services and to take care about the consistency and availability of data.

Based on these statements, a methodology to implement Collaborative e-

Engineering Environments (CeEE) will be proposed, providing a model to transfer the e-engineering concepts to the industry. A taxonomy of supporting technologies for Collaborative Engineering is also proposed, and used as a tool for the applications integration into the environments design.


2


1.3 Objective and relevance of the research

Define a methodology to design and integrate CeEE, in order to transfer the concepts of collaboration in engineering to the industry. The environment should integrate computer applications which will support engineering activities for design and manufacturing in global product development.

Demonstrate the environments with improved scenarios based on the “Action Research” approach, in order test the methodology and improve it through reflections from cycling process improvement. 1.4 Scope of the research

There are five integrated e-Services (as shown in Figure 1-1) that an engineering e-HUB1 should offer as center for on-demand e-services for value added industrial networks: e-Marketing, e-Brokerage, e-Engineering, e-Supply and e-Productivity. The conjunction of these e-Services will improve the competitive position of Latin American SMEs based on the Virtual Enterprise concept.

EmpresaProveedor Cliente

e-Factorye-Factory

e- Supplye- Supply

e-Marketinge-Marketing

e- Engineeringe- Engineering

e-Brokeragee-Brokerage

e- Productivitye- Productivity

Figure 1-1 Integrated e-Services offered by e-HUBs [Molina, 2003]

1 An e-Hub is a Broker entity which act as an integrated engineering service provider through virtual capabilities of engineering and manufacturing ITESM, Campus Monterrey

3


Brief descriptions of the mentioned e-Services are: • e-Marketing to support the development of intelligent Web-portals for

promotion of products and services of SMEs.

• e-Brokerage to underpin the exploitation of business opportunities for the creation of supply chains, integrated networks of micro-enterprises and Virtual Enterprises based on SMEs.

• e-Engineering to establish environments that foster collaboration among engineering groups to support integrated product development

• e-Supply integrates services related to e-factory, e-logistics for importing/exporting materials and products, supplier and customer relation management.

• e-Productivity integrates technologies for the diagnosis, planning, evaluation and monitoring of SMEs.

The present research is focused on the e-Engineering services, defining a

methodology for the design and integration of CeEE. 1.5 Thesis organization

The present research work is organized in six chapters. Chapter 2 reports relevant literature review of the state of the art in Collaborative Engineering. It starts presenting the tendencies on simultaneous and remote engineering, and finally brief descriptions of collaborative environments from worldwide research groups are analyzed.

Chapter 3 describes the research methodology, which is based on “action research”. A definition of this type of methodology is described, and analyzed in order to clarify the way the results were achieved, through the experiences developing CeEE.

The Chapter 4 presents the proposed methodology for design and integration of CeEE in order to transfer e-Engineering practices to Industrial projects. The methodology is an improved set of steps resulting from the evaluation cycles from action research.


4


On Chapter 5, a description of the experiences developing CeEE with different technologies is presented. The progress and evolution is shown from one scenario to the next one, thorough the use of the proposed methodology in these scenarios.

The Chapter 6 summarizes the results and conclusions of the experiences in developing CeEE, through action research improving cycles.

Finally at the end of this thesis a group of appendixes are presented, where Appendix A presents the detail of the reviewed “Collaborative Environments” analyzed in the Literature Review. Appendix B explains each of the categories proposed in the taxonomy of Computer applications and tools to the integration of applications in CeEE. Appendix C is the a description of the most common exchange formats on engineering design, followed by the Appendix D which presents detailed information from the Process domain from Landing Gear case study. Finally the Appendix E contains the explanation of the IBM – WebSphereTM technologies.


5


Chapter 2. Literature Review 2.1 Introduction

Engineering design can be defined as the systematic, intelligent generation and evaluation of specifications for artifacts whose form and function achieve stated objectives and satisfy specified constraints [Dym and Little, 2000], these artifacts are most often “physical”, like airplanes, wheelchairs, ladders, and carburetors. But they can also be “paper” products, such as drawings, plans, computer software, articles, and books. The form or the artifact is its shape, its geometry. By function we mean those things the artifact is supposed to do. The specifications of artifacts are precise descriptions of the properties of the object being designed. Typically they are numerical values of performance parameters (e.g., constants or variables that serve as indicators of the artifact’s behavior) or of attributes (e.g., properties or characteristics of the artifact). As a matter of terminology, we will refer to design specifications as that set of values that articulates what a design is intended to do. Design specifications, then, also, provide a basis for evaluating proposed design, as they become the “targets” of the design process against which we can measure success in achieving them.

For hundred of years, the way of doing things was trough physical labor, in which a person with hand tools used craft skills to make objects. Since the industrial revolution, machinery has played an increasing role, but In more recent decades, the technologies have become more end more important, like computer aided design and manufacturing (CAD/CAM) and new concepts in quality assurance (QA). It is expected that the 21st century will bring even better process models, more exacting control, and increased integration, through computer technologies and virtual integrations as shown in Figure 2-1:


6


Systemwidenetworks and informationRobust processes and intelligent controlGlobal enterprises and virtual manufacturing corporations

Computer aided design, planning, and manufacturingLimited process models using closed loop controlIncreased factory automation

Steam-powered machineryImproved understanding of processFactory conditions in cities

A person with an anvil and a hammerPoorly understood processCraftspeopleCottage industry

21th Century20th Century19th CenturyEarly 18th

Century

Past, Present and Future

Systemwidenetworks and informationRobust processes and intelligent controlGlobal enterprises and virtual manufacturing corporations

Computer aided design, planning, and manufacturingLimited process models using closed loop controlIncreased factory automation

Steam-powered machineryImproved understanding of processFactory conditions in cities

A person with an anvil and a hammerPoorly understood processCraftspeopleCottage industry

21th Century20th Century19th CenturyEarly 18th

Century

Past, Present and Future

Figure 2-1 Tendencies to 21st Century engineering and manufacturing

[Wright, 2001]

The present trends created by the Internet have now set the stage for an

even larger scale or global approach to manufacturing. We can expect to see global networks of information and distributed engineering and manufacturing enterprises. The Internet is certainly providing the infrastructure for these more flexible and informal ways of creating new enterprises that respond to people with a naturally entrepreneurial spirit.

Another important issue is that a successful design is not something that just

happens. Rather, it is the result of careful thought about what customers demand, and the specification of ways to realize those requirements. There are various tools and techniques that assist the engineers in this design process. A particularly important element of successful design is managing the design project. Just as thinking about design in a rigorous way doesn’t imply any loss in creativity, using formal (and informal) tools to manage the process doesn’t mean that we give up either technical competency or inventiveness. [Dym and Little, 2000] On the contrary, we can see many examples of organizations that foster imaginative engineering design as an integral part or their management style.


7



8

2.2 Market analysis

The manufacturing tendencies reflect the changes on the customer demands over the years. Nowadays, the market is constantly requiring more customized products, moving from mass production, through mass customization until “one-of-a-kind production” in less time with lower costs. These changes imply more flexibility, giving more importance to reconfigurable systems (on-demand)

A new competitive environment for industrial products and services is emerging and is forcing a change in the way manufacturing enterprises are managed. Competitive advantages in the new global economy will belong to manufacturing enterprises, capable of responding rapidly to the demand of high quality and highly customized products [Molina; 1998].

Operating new competitive firms is becoming more difficult as product variety and options increase, product complexity increases, product life cycles shrink, and profit margins decrease. In addition, the capital costs of manufacturing technologies are extremely high. These factors impose high productivity levels for manufacturing facilities. There is also the need to create the next generation manufacturing systems with higher levels of flexibility, allowing these systems to respond to very dynamic markets demands [Iacocca Institute; 1991].

Those market needs, have been driving the manufacturing technologies through different concepts as customization, flexibility and business strategy. As a consequence, the term Next Generation Manufacturing (NGM) refers to the application of new concepts, models, methodologies and information technologies, with the goal of preparing companies to become more competitive in a global and networked environment [Molina and Bell, 2002]. 2.2.1 From traditional engineering, to Collaborative Engineering

The product design in industry is an activity where collaboration is fundamental. Indeed, many actors collaborate to achieve a common goal: The definition of a product that can be used and may be sold [Riboulet et. al., 2002]. At the same time the globalization of the industrial activity and decentralization of many manufacturing processes leads companies to work in relation to very distant collaborators as shown in Figure 2-2.


Project Management

Assembly

Design

Supplier

Supplier

Analysis

Figure 2-2 Global product development [Molina, 2003].

In this context collaboration must be organized to allow a better

communication between actors. Concurrent engineering methodologies are developed in order to involve the different points of view on the product, all along its life cycle. This trend is pushed by the product’s evolution: design of complex artifacts and systems requires the cooperation of multidisciplinary design teams providing optimization from any point of view.

Organizations are constantly seeking better methods for improving productivity and effectiveness in task accomplishment, primarily through the use of technology management. Examples include the need to reduce the cost of designing new products and to significantly shrink overall development life cycles [Bochenek and Ragusa, 2001]. The most common use of Collaborative e-Engineering Environments (CeEE) is currently in collaborative design, education and training.

2.2.2 Industry background In industrial cases, specially in large projects, physically co-located meetings

are often expensive, impossible to manage and may be of poor efficiency. So the expansion of Internet-based tools has opened new opportunities for collaborative


9


work improvement. This can explain the development of a new generation of tools designed to support this kind of activity: Internet/Web and CSCW (Computer Supported Cooperative Work) in design. [Riboulet et. al., 2002]

An ever-increasing number of organizations are beginning to use virtual

environment tools for product development. These systems are characteristically 3-D computer graphic systems with real-time user interactive control and viewer centered perspectives. However, the use of virtual environments technologies raises several virtual CeEE operational and research issues that need identification and investigation.

For example [Keller, 1998] the Boeing Corporation used Computer-Aided

Three-dimensional Interactive Application (CATIA) software to reduce by 60 to 90 percent design rework for its 777 aircraft. Various auto manufactures have also experienced substantial improvements and acceleration in vehicle styling and design made possible through the use of CeEE.

Another example, Daimler-Chrysler Corporation’s Dodge Intrepid product line

was developed using what the company calls “cyber synthesis” that resulted in five new vehicles and three new V-6 engines. As a result of the use of Virtual Environment technologies and digital models, the company has reported cost savings of $75 million and a 20 % reduction in its intrepid model development time. [Bochenek and Ragusa, 2001]..

2.3 Collaborative Engineering Environments

A Collaborative e-Engineering Environment (CeEE) is an automated environment that enables people (including sales, designers, engineers, managers, and customers) to collaborate and interact on the development of a new project regardless of their geographic locations and interaction means [Shen, 2003]. With the advances in information and communication technologies, particularly Internet and Web-based technologies, Collaborative Engineering has been recognized as a promising medium for complex engineering design projects.


10


CeEE establishes and manages a collection of virtual workspaces, each of which incorporates people, information, and engineering tools appropriate to a design activity. In a CeEE users can participate in several workspaces, discover collaboration opportunities, provide knowledge or services, seek information or assistance, and perform their design activities. In this kind of environment, knowledge sharing among people as well as software tools is imperative to support collaborative design activities efficiently and effectively

Knowledge in a CeEE must be well organized and should be flexibly applied

to different kinds of design problems. Integrated knowledge bases may suffer from the lack of uniform knowledge representation. There are many different views of a design (e.g. function, performance, and manufacturing), each with a different language, and various perspectives, typically overlap, necessitating the sharing of information if a design is going to be executed concurrently and cooperatively. Some research in this area is related to various areas and technologies including AI/DAI, knowledge engineering, databases, Computer Supported Cooperative Work (CSCW) and groupware, as well as Internet/Web-based technologies.

The compelling story of the development of engineering HUBs then becomes

the delivery of a new service (filling a gap in existing collaboration technologies whose focus is primarily on operation collaboration support). The core service of the system will be largely a web hosted Integrated product development space, augmented by the right mix of technologies and additional services and offering a back-end connection to a set of operational collaboration platforms.

2.3.1 Context

A conceptual virtual collaborative design environment model, shown in Figure

2-3 illustrates the interrelationships between people, work, and technology within the broader context of organizational social, and technical environments [Bochenek and Ragusa, 2001]. Selecting an appropriate tool or integrating advanced technologies to support the process of team product design evaluation or the overall organizational goal to reorganize the design, development and acquisition process, requires that all conceptual model elements be considered individually and together. The model helps to consider how these elements affect and influences organizational Virtual Collaborative Design Environments operational and research issues for new product and system design analysis.


11


Work

Technical Environment

OrganizationalEnvironment

SocialEnvironment

People Technology

Figure 2-3 A Virtual Collaborative Design Environment conceptual model [Bochenek and Ragusa, 2001]

A. Organizational, Social, and Technical Environments: The

organizational environment is primarily defined by the goals and objectives of the organization, (e.g. whether profit seeking or not). The social environment is determined by how the organization functions with regard to the degree of individual and team interaction cohesiveness and motivation that exists to accomplish work. The structure of the organizations, e.g., functional, project, or matrix affects the social context of activities performed. The technical environment is driven by the degree to which the organization is dependent on and supports technology.

These environments, individually and collectively, influence a set of factors

that directly affect the environment design considerations. Within these factors the important relationships are between people and the work tasks they perform, and between people and the technology they use to accomplish work.

B. Work: Product Design, Development, and Simulation-based Acquisition C. People: Integrated Product and Process Teams D. Technology: Immersive, Interactive Virtual Environment (VE) Tools

The dramatic growth in the World Wide Web has also seen a rapid increase

in the range of distributed cooperative applications. Many of these move beyond the existing client-server model of interaction that underpins World Wide Web, to support much richer patterns of user interaction and activity [Tian and Taylor, 2001]. While often exploiting their own distributed infrastructure, these environments seek to build upon the accessibility and coverage of the World Wide Web to promote and support a number of geographically remote users working together. ITESM, Campus Monterrey

12


2.3.2 Related research During the last years, many researches have focused on the technologies or

the infrastructure that can assist product designers in the distributed design environment. Some examples are CAD conferences, work process modeling and management, product data sharing, agent-based knowledge sharing and conflict management. These ongoing research efforts aim the ways in which a diverse group of product designers and computer-based design tools or systems can work together in a network-oriented environment. A few examples of these efforts would be explained as follows [Chung and Lee, 2002]:

• CAD conferencing: enables synchronous collaborative work due to its geometry models exchanging capabilities and the teleconferencing system. The research is focused on application sharing, co-authoring, 3D visualization and desktop conferencing.

• Work process modeling: supports asynchronous collaboration among workgroups by modeling and managing design workflow to enable complex design procedure to be handled efficiently.

• Product data sharing: for collaborative design, the efficient exchange and sharing of product data through the product lifecycle is important.

• Agent-based knowledge: focused on enabling collaboration among software agents for supporting design teams in sharing their understanding of the design process.

• Conflict management: enables to coordinate information for collaborative design. Some coordination strategies to avoid conflict between design participants have been proposed.

Therefore, an analysis of the state of the art in Collaborative Engineering

Environments was carried out, in order to compare and find convergence among different approaches from several research groups. Due to this, some specific research projects in simultaneous and collaborative engineering will be briefly described in the Appendix - A from this thesis, and simplified in the Table 2-1 from this chapter, in order to understand the basis for the development of this kind of environments in collaborative engineering. The projects Domain will be mapped according to the taxonomy proposed on the Section 4.3.2 of this thesis for the classification of computer applications to support product development (See also Appendix B).


13


The categories from the Taxonomy are:

• F: Functional tools • Cd: Coordination tools • Cl: Collaboration tools • KM: Information/Knowledge management tools

This will guide the analysis to determine the main area where researchers

are focusing on, or to determine the kind of tools that researched environments integrates. Table 2-1 Collaborative Engineering Environments Review

Domain Group System Description F Cd Cl IM Molina, et. al., 1995

MOSES A source of product and manufacturing information, with an Engineering Moderator

X X

Hanneghan, 1998

CONCERT Allows virtual team members to access these middleware services via the Internet through cross-platform applications

X X X X

Huang, 2002 CyberReview A central portal for supporting collaborative product design review

X

Qina, et. al., 2003

Web-based conceptual design

2D and 3D geometries sketching, manipulation and simulation (not standard CAD systems)

X

Tay and Roy, 2003

CyberCAD Web-interactive CAD software X

Heckel, et. al., 1997

VWS Provides a service for sharing state for asynchronous collaborating engineering applications

X X

Chlebus, et. al., 1998

PDM-Tech Support every organization of data management and process structure

X

Oliveira, 2003 Epistheme The exchange, share and dissemination of knowledge

X

dVISE, 1999 dVISE Product data visualization and simulation. Allows real time visualization to interact and redline 3D models

X X

Wanga, 2003 WebBlow Share product information and knowledge, and to ensure the system security

X

Mitschang, 2003

TOGA and CHAMPAGNE

Exploits common work and information spaces X X

PIVOTAL, 1999 PIVOTAL 3D models manipulation, discussion and collaboration facilitated

X X

Tamine and Dillmann, 2003

KaViDo Record and document development processes X

Harrison, 1996 Deneb Enables real-time, interactive collaboration X Huang and Mak, 2002

CyberCO They are agents and workflows X X

Qian and Shensheng, 2002

P_PROCE Product development process management system that integrates WFMS with PDMs

X X


14


Based on the performed review about Collaborative Engineering, The author has noticed:

• That most of the collaborative environments or tools are functional oriented applications, trying to support specific activities within the Product life cycle. Likewise, the major emphasis in the collaboration research lines is the CAD/CAM/CAE.

• The research efforts are mainly software-driven. That means the researchers are more concerned with the technical issues, more than evaluating the overall Engineering Environments.

• Researches are more focused on the development of their own technologies, developing new software tools more than integrating existing ones.

• A remaining open issue is to cover the whole life cycle, trying to integrate standard tools combining the different need from the actual globalized markets.

It is important to consider that the impact of design decision is initially very

high, and declines steeply as the design matures. Great opportunity exists at the preliminary design stage, and the literature review has shown more research interests in advanced stages of product development, where the amount of technologies is bigger than the available tools for early stages. Therefore, directing the efforts to an integrated product development, considering as well the early stages, will have considerable impact on the decision making.

As shown in Figure 2-4 the opportunities in collaborative Engineering will be leaded by the integration of tools, not only form advanced stages, but also from early stages in order to have an increased impact and a major coverage of the product life cycle. However, the tools from advanced stages may not be forgotten.


15


Conceptual Design

Design Production

Detailed Design

Impa

ct o

f dec

isio

ns

Availability of tools

ImpactTools

Figure 2-4 Opportunity in early design stage [Wang, et. al., 2002]

Finally, the collaborative coordination tools seems not to be widely spread

into the Collaborative Engineering approaches, and this is an important issue to be tackled. There are just a few environments which consider the management issues. Thus, another opportunity can be the coordinating automation in Collaborative Engineering Environments.

As a result, this research work intends to tackle the major issues already mentioned in this analysis. It can be achieved designing integrated environments, where workflow and methodologies formalize engineering lifecycle activities, balancing the methods and tools, and also considering if there are needs to design Products / process / Facilities. The integration of computers applications leads collaboration and interaction among different partners, and finally, the use of standard tools will be pursued, in order to focus the efforts more in the integrated definition, than specific detailed software problems. The idea is to generate integrated solutions for the industry, more than creating software applications and tools for the market.


16


Chapter 3. Research methodology 3.1 Introduction

The development of the current research work was carried out using learning cycles, where lessons learned from previous iterations (based on experiences) allowed the improvement and changes to the current work execution in e-Engineering. This kind of research concurs with an already defined research methodology called: Action Research.

Action research consists of a family of research methodologies which pursue

action and research outcomes at the same time (See Figure 3-1). Under this approach, the author of this research work was able to propose an improved methodology for the design and integration of CeEE which will be detailed in the next Chapter. The current Chapter will give an introduction and explanation of the general concepts of Action Research in order to understand how it works and to clarify the results achievement of this work.

Action Research

Problem-solving that is not designed, executed, and assessed as an integral part of a research effort

Research that does not include design, execution, and assessment of a problem-solving effort

Action research, i.e. research that includes and is mainly based on practical problem-solving

Figure 3-1 Understand action research [Iversen, et. al., 2002]


17


As an introduction, several definitions for action research exist. Some of them are presented:

Action research…”aims to contribute both to the practical concerns

of people in an immediate problematic situation and to the goals of social science by joint collaboration within a mutually acceptable framework.” [Rapoport, 1970].

“Action Research is a process by which change and

understanding can be pursued at the one time. It is usually described as cyclic, with action and critical reflection taking place in turn. The reflection is used to review the previous action and plan the next one.” [Dick, 2000].

“Action research is undertaken by participants in social situations

to improve their practices and their understanding of them.” [Bowling, 1997]

“Action research is collaborative, critical and self-critical inquiry by

practitioners (e.g.: teachers, managers) into a major problem or issue or concern in their own practice. They own the problem and feel responsible and accountable for solving it through team work and through following a cyclical practice” [Zuber-Skerrit, 1996].

Conventional experimental research has developed certain principles to

guide its execution. These principles are appropriate for certain types of research, but they can actually inhibit effective change in some cases. Action research has had to develop a different set of principles. It also has some characteristic differences from most other qualitative methods [Dick, 2000]. Action research tends to be:

• Cyclic: Similar steps tend to recur, in a similar sequence; • Participative: The clients and informants are involved as partners, or at

least active participants, in the research process; • Qualitative: It deals more often with language than with numbers; and • Reflective: Critical reflection upon the process and outcomes are important

parts of each cycle.


18


3.2 What is action research?

Action research is a flexible spiral process which allows action (change,

improvement) and research (understanding, knowledge) to be achieved at the same time [Dick, 2002]. In most of its forms it does this by

• Using a cyclic or spiral process which alternates between action and critical reflection and

• In the later cycles, continuously refining methods, data and interpretation

in the light of the understanding developed in the earlier cycles.

In most of its forms it is also participative (among other reasons, change is usually easier to achieve when those affected by the change are involved) and qualitative. It is thus an emergent process which takes shape as understanding increases; it is an iterative process which converges towards a better understanding of what happens. The understanding allows more informed change and at the same time is informed by that change. People affected by the change are usually involved in the action research. This allows the understanding to be widely shared and the change to be pursued with commitment.

Action research commonly proceeds like this: The researcher plans the first or next step and is then carried out. Researchers meet to recollect and critique their experience. In the light of this, they decide what to do for the next step (what information do they need or what outcome to pursue, and what method to use). In short, action research alternates between action and critical reflection. The reflection consists first of analyzing what has already happened in previous steps, and then of planning what next step to take.

Action research aims to contribute both to the practical concerns of people in

an immediate problematic situation and to the goals of social science by joint collaboration within a mutually acceptable framework. In most of its forms it is also participative (among other reasons, change is usually easier to achieve when those affected by the change are involved) and qualitative. It is thus an emergent process which takes shape as understanding increases; it is an iterative process which converges towards a better understanding of what happens. (Dick, 1999)


19


It is true that action research and some forms of practice are in some ways similar. Both are often directed towards the achievement of change. Both are qualitative and often participative. Both tend to be flexible and cyclic. In both instances, there is a desire to base planned changes in the situation on understanding, and to derive that understanding from evidence.

3.3 Action research cycles With the exception of well-practiced tasks there is a natural rhythm to the way

most of humans behave. They do something, and then they check if it worked as expected. If it did not, is analyzed what happened and what they might do differently. If necessary the process is repeated (act -> review -> act -> review and so on)

Most writers on the topic state or assume that action research is cyclic, or at

least spiral in structure. One crucial step in each cycle consists of critical reflection. The researcher and others involved first recollect and then critique what has already happened. The increased understanding which emerges from the critical reflection is then put to good use in designing the later steps.

The well known cycle is that of Stephen Kemmis [Kemmis and McTaggart,

1992]. According to them, action research occurs through a dynamic and complementary process, which consists of four essential “moments”: of Planning, Action, Observation and Reflection. These moments are the fundamental steps in spiraling process through which participants in an action research group undertake to:

• Develop a plan of critically informed action to improve what is already

happening, • Act to implement the plan, • Observe the effects of the critically informed action in the context in which it

occurs, and • Reflect on these effects as the basis for further planning, subsequent

critically informed action and so on, through a succession of stages Kemmis and McTaggart’s concept of action research is set out in figure 3-2:


20


Figure 3-2 Concept of action research [Kemmis and McTaggart, 1992]

The reflection leads on to the next stage of planning. The "planning" isn't a

separate and prior step; it is embedded in the action and reflection. As change is intended to result, effective action research depends upon the agreement and commitment of those affected by it. This is usually generated by involving them directly in the research process. In many instances, researchers try to involve them as equal partners.

Cycles provide a useful way of thinking and describing an Action Research

process. Researching a particular issue usually involves going through a number of cycles. This allows practices and understandings to be refined or changed over time. It may mean also that the analyzed issues needs refinement or change.


21


The diagram on Figure 3-3 shows the way Action Research evolves through cycles of planning, action, observation and reflection. The rising base line represents the goal of continuous improvement. Successive cycles become larger and represent the way that the process may change over time.

Plan

Reflect

Observe

Act

Plan

Reflect

Observe

Act

Plan

Reflect

Observe

Act

Figure 3-3 Action Research evolution through cycles [Crane and Richardson, 2000]

The author of this thesis proposes a methodology for the design and

integration of Collaborative e-Engineering Environments. The basis approach to the design of the methodology was to use action research as a mean of ensuring the success of the methodology, through an evaluated set of steps, and with the required technologies to allow its implementation. In Chapter 5 of this thesis, an explanation of the evolution in the experiences developing Collaborative Environments is shown, noticing the cycles proposed by the action research approach. However, the action research as a research methodology was not fully applied. Only the overall concept and the main steps were mapped to the current thesis development. The next Chapters explain in detail, the refined methodology, achieved by the enrichment during the experiences cycles.


22


Chapter 4. Methodology for design and integration of Collaborative e-Engineering Environments

There are several technical challenges in Collaborative Engineering: 1) Definition of a collaborative Integrated Product Development process among the different companies participating in Product Life Cycle activities; 2) Establishment of environments that foster the coordination and cooperation among engineering groups and, 3) Integration of applications and tools that allows the exchange of information and knowledge among engineers in an effective and efficient manner.

Therefore Collaborative e-Engineering Environments, with an underlying methodology, must be designed and developed to train and cultivate “Communities of e-Engineering Practice”. These integrated environments must enforce four dimensions of e-Engineering:

• Process: how engineering (design, manufacturing, supply, procurement and service) is realized in a global environment using e-technologies.

• Information: how information have to be structured and shared between all the engineering teams in a global e-Engineering environment.

• Organizational: how cultural diversity and behavior affects global engineering activities and how teams can be organized based on core competencies to achieve global e-Engineering.

• Technology: how different e-technologies and e-applications can be integrated to achieve global e-Engineering.

Likewise, the proposed methodology intends to overcome the major issues

mentioned in the literature review analysis, as a lack of the nowadays research efforts. The proposed methodology in this thesis foster collaborative environments integrating tools not only functional oriented but also platforms to achieve coordination, collaboration and information management capabilities. ITESM, Campus Monterrey

23


The integration of standard tools is the main focus, more than developing own technologies. The integrated vision of collaborative concepts enforces collaborative support to cover the whole engineering life cycle, from early stages, to advanced ones, where a large number of computer tools exist.

Consequently, a methodology has to be followed for the integration of Collaborative e-Engineering Environments in order to be transferred to the industry to support cooperative groupwork in engineering services. Hence, the next sequence of activities is proposed, as shown in Figure 4-1, as the e-Engineering Transfer Model to the industry:

Design and Integration of

Environment and applications

Modeling Methods

- IDEF0- UML- EXPRESS-G

TO-BE Model

AS-IS Model

ModelExecution

ModelImplementation

ModelRevision

Model Assessment

Model Evaluation

Start

End

I

II

III

IV

Assessment of the AS- IS, and model

the TO-BE

Execute and manage the CeEE

Determine the Company process

requirements

Figure 4-1 e-Engineering Transfer Model to the industry

The model starts with the identification of the current Industry’s development

process. It can be determined based on reference models2 for the type of process development definition. This process is considered AS-IS. 2 The Chair in Mechatronics from the Integrated Manufacturing Systems research Center, from the Monterrey Institute of Technology (CSIM-ITESM), is currently working on the development of reference a model for reconfigurable Product, Process and Manufacturing systems development processes. ITESM, Campus Monterrey

24


A graphical representation of an AS-IS model can be done and from this base, it is possible to propose a TO-BE process model. The flexibility of using a graphical representation helps identifying duplicated information, parallel activities and information sent to other departments in order to become more efficiently. This TO-BE process model will be the base to define the environment Workflow. Sometimes the AS-IS does not exists, or it can be directly the TO-BE. This can happen when improvements are already considered in the current process, or when new work methods are proposed to be implemented in Industry.

A Workflow Model of Integrated Process Development is then built, based on the identified activities, which are required for a specific design process (particular model). In order to generate a complete and reliable workflow it is necessary to have a specific understanding and environment identification from each activity based on the input process model.

The Figure 4-2 shows the steps defined in the e-Engineering Transfer Model, which will be detailed in the following sections:

� I. Determine the Company process requirements (AS-IS)� Product

� Process

� Manufacturing system

� II. Assessment of the AS- IS, and model the TO-BE � Process and information flow

� Human resources / Teamwork

� Data – Information – Knowledge

� Technology / Methods and techniques

� III. Design and integration of environment and applications� Model (Modeling the workflow)

� Integrate (Selection and Integration of e-Engineering applications )

� Connect (Connect environment and applications)

� Monitor (Definition of performance measures)

� IV. Execute and manage the CeEE

Figure 4-2 Methodology for Technology Transfer


25


4.1 Step I: Define the company requirements and model the AS-

IS of the development process

In order to understand the context of process development, an engineering project can be divided into activities and sub-activities. According to [Mejía and Molina, 2002], a project is carried out going through four core processes: Market requirements, Project planning, Project execution and Customer follow-up. In the project execution stage, it has been considered important to follow the model of Integrated Product Development where the Broker has to carry out four main activities [Cooper, 1993]: Ideation, Basic Development, Advanced Development and Launching.

Even though, the activities from project execution may vary depending on the

type of development process. A reconfigurable methodology for product, process and manufacturing systems development has been developed [Molina, 2003], allowing the project planners to know in advance, what stages has to be performed by the project team. Into the methodology, information technologies and resources are identified and considered, as well as several methods and techniques and their corresponding inputs and outputs.

The Figure 4-3 depicts the integration of the project core processes, with the possible project execution configurations. When a project is going to start, at the project planning stage the methodology is then configured with the corresponding stages and the necessary activities, in order to fulfill all the project requirements to accomplish a successful project execution with high quality results and with less time of development.

Analyzing the AS-IS business process model provides the knowledge and

foundation upon which all process design, improvement, and redesign decisions are based and allows the design team to represent graphically how a process is executed, so that the process is understood and agreed upon by all involved. The AS-IS business process model is then, the representation of the current processes, prior to any improvement ideas.


26


Market requirements

Market requirements Project

planningProject

planning

Customer follow-up

Customer follow-up

Project executionProject executionIdeationBasic development

Advance developmentLaunching



IdeationBasic development


ProductDesign

Manu-facturingSystem Design

ProcessDesign

Project Definition

Basic Development

Advanced Development Launching

Manufacture partner orSupplier Selection

Manufacturing &Quality Control Components

Product IdeaConceptual Design

&Target Specifications

Detailed Design

Individual Component Specifications Process Selection Operation Planning Ramp up Production

Prototype

Product Transfer

Technology Transfer

Facility Design

Indi

vidu

al

Com

pone

nt

Spec

ifica

tions

Equipment Selection Manufacturing Layout Design Set-up Equipment

Concept Design & Target Specifications Detailed Design Facility construction &

Set-up

ProductDesignProductDesign



ProcessDesignProcessDesign

Project DefinitionProject

DefinitionBasic

DevelopmentBasic

DevelopmentAdvanced

DevelopmentAdvanced

Development LaunchingLaunching

Manufacture partner orSupplier Selection

Manufacturing &Quality Control Components

Product IdeaConceptual Design

&Target Specifications

Detailed Design

Individual Component Specifications Process Selection Operation Planning Ramp up Production

Prototype

Product Transfer

Technology Transfer

Facility Design

Indi

vidu

al

Com

pone

nt

Spec

ifica

tions

Equipment Selection Manufacturing Layout Design Set-up Equipment

Concept Design & Target Specifications Detailed Design Facility construction &

Set-up

Figure 4-3 Generic project core process, activities and configurable sub-activities

4.2 Step II: Assess the AS- IS, and model the TO-BE

As mentioned before, an AS-IS model is defined; However it can be no AS-IS model depending on the company’s requirements. Afterwards, the TO-BE process is modeled capturing the process-redesign team’s analysis or it can be a proposed methodology, when there is no current process in execution.

The product life cycle under an Integrated Product Development requires a process model which must be integrated with an efficient information/knowledge management (not only the physical product features, but also the information/knowledge flow from the different departments and the integration among them), as well as the human resources involved (also with the hierarchy and responsibilities for specified tasks), and finally the Technology that will be used (application/tools for required methods and techniques) where the computers applications has priority in the identification, in order to analyze their integration in the collaborative environment. ITESM, Campus Monterrey

27


Hence, there are four domains in the identification of the integrated product development environment: process, information/knowledge, organization and resources; which are defined in the following sections, and depicted in Figure 4-4, adapted from [Al-Ashaab, et. al., 2000]:

1

2

3

4

5

6

1

2

3

4

5

6

Evaluation

Activities Flow

Analysis

Organizational Structure

Identification of key people

Product Information

Manufacturing information

Information/KnowledgeProcess

Organization Technology� Technological

Resources

� Methods

� Techniques

Human resources

SynthesisAnalysis

Data

Information

Knowledge

Data

Information

Knowledge

Knowledge / Information

ManagementCollaborationCoordinationFunctional

APPLICATIONS & TOOLSKnowledge / Information

ManagementCollaborationCoordinationFunctional

APPLICATIONS & TOOLS

Figure 4-4 AS-IS / TO-BE process development assessment

4.2.1 Process Domain

By modeling the product development activities by the process domain view, it is possible to:

• Describe the activities of the Integrated Product Development • Identify the flow of information through the product life cycle • Recognize the resources, controls inputs and outputs incorporated in each

activity • Select the core processes and activities of a company

The process modeling is one of the basic ways to understand how a project

is carried out. The integration of a company (or group of companies) among ITESM, Campus Monterrey

28


different activities and areas is also represented in this process domain. By analyzing the project process, it is possible to understand the relations between partners, departments, areas, information, resources and materials. Commonly these relations are not identified by the companies, reason why a graphical representation (based on the reconfigurable methodology) will help. The Process Domain will establish:

• The structure of the activity modeling • The resources used in each activity (Human and Technological) • The teams that support specific activities • The controls based on the current company’s tools

4.2.2 Information /Knowledge Domain

The Information/Knowledge Domain allows the detailed description of data, information and knowledge required in the integrated product development, making possible to:

• Segment the available information into: Data, Information and Knowledge • Structure the product information • Structure the Manufacturing information • Identify the engineering relation between product and Manufacturing

elements. • Identify the sources of Data/Information/Knowledge

The evolution of information modeling methodologies has reached an

important level up today. These methodologies had been oriented to aspects related with the product’s life cycle [Molina and Bell. 1999]. The information required throughout the life cycle of a product can be described, structured, stored without redundancy and standardized if the relevant data concerning a company, its products and manufacturing facilities is defined in information models [Weck et. al. 1991].

In this Information domain, the data/information/knowledge structure must be considered, in order to define the starting specifications for a PDM structuring. This is the way that information will be stored in a specific database for further consultation and also to track the information generation.


29


In order to represent the information domain, it is necessary to specify which information of the models would be necessary and which structure will be required based on the general structure of information models:

• The Product Modeling: Representing all the information related with the products and components at all the stages of the product’s life cycle.

• The Manufacturing Modeling: Representing information modeling from the

manufacturing processes, resources and strategies in a company.

Both Models are considered in the information domain in order to cover the complete product information (product – process – production facility) and to establish the framework for information structuring. Likewise the Information Domain uses data and information from the technological resources as a reference, to establish the level of integration and connectivity required in the future CeEE integration. 4.2.3 Organization Domain

The identification of the human resources and how they are organized is defined within the Organizational domain. It must establish the relations among the areas/departments/partners involved in a simultaneous engineering (concurrent engineering) environment. The organization structure is important, in order to identify the key players in the engineering activities, not only for execution, but also for reviewing, supervising and monitoring. A flat organization helps the integration with suppliers and customers, following the extended enterprise concept.

In the organization domain, is important to consider the partners roles, in order to specify the possible interactions, as well as the knowledge and information sharing, which will be critical for some design activities. For these considerations, the knowledge and skills from the people is a key issue for the resources assignment to specific tasks and activities.

About the human organization is preferred to have a flat organizational enterprise structure, in which a less authority levels organization is proposed. This type of organizations forced the companies become more agile and tends to centralize more responsibilities in working teams as well as reduces bureaucracy,


30


in order to have time effective activities execution. Based on this, the synergy and teamwork concepts appear both of them as the bases for a Concurrent and Simultaneous Engineering approach. The Organization domain will provide:

• The enterprise structures • The key people in the company • The actual working teams • The level of knowledge management • Key people experiences • Key people skills

4.2.4 Technology Domain

In this domain, the technologies used to support the Product development will be divided according to their main functionality into the four main categories according to the taxonomy proposed on the Section 4.3.2 of this thesis for the classification of computer applications to support product development (See Table 4-1 and its details on Appendix B).

The introduction of these technologies must be carefully decided and validated considering return value, scalability, integration capability, maintenance, etc. Moreover, the integration of these systems must meet the requirements not only of specific departments (e.g. design departments), but also the complete company (or industrial network) with different approaches according to each partner, by delivering specific tools oriented to their requirements. This domain will provide information about:

• The type of systems used in the company • The level of automation in the different departments • The actual integration between the existing systems of the company • The application limits of such information systems

Finally, a successful Integrated Product/Process/Facility design strategies

are thorough, well planned where the company and partners must be open to change their design practices in order to reach both cultural and technical transformations.


31


4.3 Step III: Design and integration of environment and

applications

After the model is identified, and the AS-IS model is understood (or TO-BE model, if it is the case) four main steps must be followed in order to integrate Collaborative e-Engineering Environments. These steps are graphically shown in Figure 4-5:

MAN

AGE

MAN

AGE

Supplier

Customer

InternalInternal

DataInformationKnowledge

Teamwork

Collaboration tools

Functional tools

Data And Information

Management

Coordination tools Teamwork

Collaboration tools

Functional tools


Management

Coordination tools

AnalyzeDevelopment

Process

Technologiesidentification

Workflow definition

AutomatedBusiness Processes

Feedback

AnalyzeDevelopment

Process

Technologiesidentification

Workflow definition

AutomatedBusiness Processes

Feedback

Figure 4-5 Design and integration of environment and applications

4.3.1 MODEL: Modeling the workflow

With a workflow modeling, is possible to analyze the whole process development and visualize how it works. The model also helps identifying possible information flow problems, duplicated activities and unnecessary activities, as well as showing which are the core activities and core resources in the Broker entity, or even in its value added network.


32



33

4.3.1.1 Create and model the Workflow

Based on the four domains (explained in the Section 4.2 from this Chapter to asses the AS-IS model), the workflow is defined, in order to use a Workflow Management System (WFMS) using the identified information in the particular model previously defined with the Product/Process/Facility design methodology (generic model), as shown in Figure 4-6.

1

2

3

4

5

6

1

2

3

4

5

6

Information/KnowledgeInformation/Knowledge

ResourcesResourcesOrganization Organization

Input Output

Information/Control

Resources/Mechanisms

Com

pute

r ap

plic

atio

ns

Functional

Collaboration

Coordination

Information Management

Com

pute

r ap

plic

atio

ns

Functional

Collaboration

Coordination


Human Resources

TechnologicalResources

I / O:-Data-Information-KnowledgeExecuteM

onito

r

ProcessProcess

WorkflowActivity

Figure 4-6 Workflow based on the four domains of the Particular model for an

instance of Product/Process/Facility design

Today’s business environments make indispensable for a company to deal

with complex business processes, where a workflow management system is a system able to support an automatic, efficient execution of the business processes.

A business process is the execution of a series of activities which leads to the achievement of a measurable business result (undertaken in pursuit of a common goal, and aligned with corporate objectives). The result may be the creation of a product or service, or an intermediate component which contributes to the creation and delivery of products or services, either directly or indirectly.


[www, UOP] Value chains and large-scale business processes produce outputs that are valued by customers. Other processes generate outputs that are valued by other processes.

Typical business processes include receiving orders, marketing services, selling products, delivering services, distributing products, invoicing for services, accounting for money received. A business process usually depends upon several business functions for support, e.g. IT, personnel, accommodation. A business process rarely operates in isolation, e.g. other business processes will depend on it and it will depend on other processes. There are some ready made general business processes technologies for some of the most commonly used business processes, like: Customer Relationship Management (CRM), Enterprise Resource Planning (ERP), Supply Chain Management (SCM), Straight-Through Processing (STP) and Mergers and Acquisitions (M&A).

The author of this thesis claims the consideration of Product Life Cycle Management (PLM) as a business processes. Activities as the ideas generation, parametric analysis, mathematical formulation, product model information, 3D models, and other information related to the product itself, are information/activities that have to be identified and formalized in order to allow the workflow automation for an efficient project execution, through a WFMS.

A WFMS in general is a software system that defines, creates, and manages automated business processes. The WFMS helps users involved in a business process to carry out their tasks following certain business logic [Hyerim and Yeongho, 2002]. This means that the WFMS should have a process model representing the business logic. A process model consists of a number of activities and their precedence relations. Once a process model is set up, the WFMS automatically assigns activities to individual users based on the model. By logging in the system, a user can identify a task list that the user has to carry out. The system assists the user by delivering task related information including due date, process name, priority and status of task, input and output files, and methods and techniques (software based tools and human processes). These are presented on a user interface for WFMS clients. On completing the task assigned, the user notifies the WFMS of the results. Then, the WFMS proceeds to the remained part of the process by assigning the subsequent task to the other relevant users.


34


4.3.1.2 Define the people involved in modeling

Always in the early stages of a determined project, there is a project leader or a workgroup in charge of the project planning. At his stage, the people involved for the workflow planning must be selected, and a role is assigned, due to the different tasks and skills that modeling workflow involves. Several users can be responsible for the different tasks, or the same user can perform several tasks: Project leader (administrator): A system administrator exists in a Workflow system as the first person. This person is responsible for the initial definition of other staff members. As soon as the workflow model is in place, the system administrator is responsible for maintaining workflow models and monitoring running processes. Users who define staff: The project leader can authorize users to create and change the definitions of staff members. Users who model processes: Users can have the authorization to build and verify the process models. These process models define how to run the processes at run time. Users authorized for IT tasks: Users can have the authorization to design and define programs to use with the Workflow system.

Therefore, an organizational structure must be defined, in order to determine the roles of the human resources involved, not only in modeling issues (Project planning) , but also for the project execution. 4.3.1.3 Follow the modeling steps

The steps in the modeling process are dependent on one another. If these steps are completed in the order that is shown, the prerequisites for each step will be fulfilled.

1. Define the organization of staff members (according to the last point of people involved), including roles and levels need for the organization.

2. Define the data structures that the process needs, the activities in a process, and in programs.

3. Register the application programs or tools, needed for the activities in a process.


35


4. Draw a diagram of a process that shows each activity and block with all the connectors that determine the flow of control and data. Specify the properties for the process.

5. Define, in detail, the logic behind the process diagram: • For each activity, specify its start conditions and its end conditions, the

persons, data structures, and programs that are required to perform the activity.

• For each control connector in the diagram, optionally specify a transition condition that is important for the control to flow that way.

• For each data connector in the diagram, specify how the data in the output container of one activity is mapped to the input container of another.

4.3.2 INTEGRATE: Selection and Integration of e-Engineering applications

This is the technological stage of the CeEE methodology. The available technologies in the market, allow companies to use specific systems for some determined activities within the product life cycle. There are also supporting technologies which allow the collaboration and knowledge sharing among the engineering teams. Even though, the target is to have into an integrated environment, all the activities that a user has to perform, with the methods and techniques that he is supposed to use. At the same time, the user should have in the same environment, the required technologies to interact with his engineering partners, regardless their geographical location. On this basis, the author proposes a Taxonomy for Computer Applications Classification that supports integrated Product/Process/Facility development.

In this step of the methodology, the integration of computer applications to feed the workflow is carried out based on the proposed Taxonomy, which is an important issue due to the introduction of several Computer based applications to support Integrated Product/Process/Facility Development (IPPFD). This concept of IPPFD integrates all the activities, methods, information and technologies to conceive the complete Product Life Cycle. Each activity into core processes executed in product development requires specific applications as well as there are generic applications which are used throughout the entire process or sub-process. Table 4-1 integrates the concepts and commonly used tools in integrated product design process under the Concurrent and Simultaneous


36


Engineering approach. For each type of product or process, these tools may change, but in general these categories include the necessary tools in order to enable the integrated product development supported by information technologies.

Table 4-1 Computer applications Classification that supports integrated product development

APPLICATIONS AND TOOLS

Functional Coordination Collaboration Knowledge / Information

Management

To carry out and support specific

functions

To manage and control tasks

To Interact and Communicate

To share and manage Information

and knowledge

Definition

Function oriented systems that support engineers in specific tasks.

Coordination systems to support sequencing of activities and flow of information.

Collaboration systems to foster cooperation among engineer e.g. CSCW - Computer Supported Cooperative Working

Product information and Knowledge management systems to enable the exchange of product and manufacturing information and knowledge

Available tools

• CAD/CAM/CAE • ICAD • Knowledge

Based Engineering Systems (KBES)

• MAS / SPEED • Rapid

prototyping • QFD / AMEF /

IDEF0 • DFM / DFA

• Project management systems

• Workflow • Groupware • e-management • e-project

• Net meeting • Forums • Chat • Multicasting • e-mail • Groupware • CSCW • Applications

sharing

• PDM – Product Data Management

• Product Model • Manufacturing

Model • PLM – Product

Life Cycle Management

It is important to mention that tendencies in commercial computer

applications, is the integration of tools from the same category (vertical Integration in Taxonomy table), or with a different one (horizontal integration in Taxonomy table). An example may be functional tools such as CAD systems which are being integrating CAM modules, or even light CAE functionalities. Likewise, some Functional tools now are able to include some knowledge storage, or even their PDM systems. ITESM, Campus Monterrey

37


4.3.2.1 Identification of Functional tools

The Table 4-2 shows some methods and techniques that will support the Product/Process/Facility design process. It is important to define all the methods and techniques that will support the integrated design process, as well as the technological tools that will enable the execution of those processes. The applications used can vary depending on the organization and it is not fixed.

It is also important to improve the use of Information Technologies to support the design activities. That means, this table will grow with the continuous improvement carried out with the experience of implementing this kind of projects through the advanced services offered to industrial networks in the globalized market. Table 4-2 Functional tools that supports integrated Product/Process/Facility development

Techniques Tools

Prod

uct

Proc

ess

Faci

lity

Competitive Intelligence Internet search O O

Pugh Charts Worksheet O O

Gant Diagram MS Project O O O

BOM SmartLister O

Con

cept

ualiz

atio

n

Brainstorming Smartdraw or WWW : Sylvia (http://www.jpb.com/creative/brainstorming.php) O

Parametric Analysis Internet search O

Interview Word processing, Web Templates O

QFD QualiSoft O

Patent Analysis WWW : Patent databases (e.g.: www.uspto.gov) O O O

Functional Decomposition Power Point or Smartdraw O O

Bas

ic D

evel

opm

ent

Morphological Matrix WWW : e.g. CREAX (http://function.creax.com/default.asp) O O


38



39

Table 4-2 Functional tools that supports integrated Product/Process/Facility development (Continue)

Pugh Charts (Selection Process) Worksheet O O

Process Selection Defined Worksheet O

Sketch, Checklist Whiteboard O

Scale Drawing CAD (e.g.: Solidworks, AutoCAD) O O O

Checklist TO-DO List O

FMEA-D WWW : e.g. www.fmeca.com O

FMEA-P WWW : e.g. www.fmeca.com O Bas

ic D

evel

opm

ent (

Cont

.)

Partners selection ECCD, ECBM, BCPT O

Parametric Modeling 3D parametric CAD (e.g. Mechanical Desktop, CATIA, Pro/E) O O O

TRIZ Tech optimizer, Innovation workbench, or WWW : CREAX O

DFA, DFM Boothroyd tables O

VE (Value Engineering), Pugh Charts, Axiomatic Design Worksheets O

CAE CAE (e.g. Patran/Nastran, CATIA, CAD-Mold) O

Tolerance Analysis Excel, Minitab, Mechanical Desktop O

BOM SmartLister O O

NC Coding CAM O

Process Planning CAPP O

Line balancing, Simulation Arena, ProModel O O

Simulation Delmia O

Adv

ance

d D

evel

opm

ent

Cost analysis ABC cost model O O O

Rapid Prototyping Techniques STL export files, 3D Printing O

Laun

-ch

ing

Inspection and quality control e-Inspection O


At this point, the identification of Human process and Automated (or semi-automated processes) is a key issue. Furthermore, it is also important to consider how easy the integration of the selected tools is. This means, if the software tools are Stand-Alone applications, Web-based tools or if they are in-house developments (were there is complete access to the software codes). This classification will let the environment designer to identify the potential tools to be fully integrated to a Global collaborative Engineering environment. In some cases, there are tools that can not be integrated because of licensing problems, or simply because not all the partners have access to it. In these cases, the functional tools are planned to be combined with some collaboration tools to allow the partners working in the same task interacting over a common application (functional).

4.3.2.2 Definition of Coordination, Collaboration and Information/Knowledge

Management tools

The reason for dividing the taxonomy into two categories, at the moment of the design, is based on the statement from the author of this thesis, that functional tools are more specific and diverse. Their selection is based mainly on the type of project development, as well as the stages where a specific activity is located. Therefore, functional tools are selected by experts, and it is made for each activity into the project life cycle, while the Coordination, Collaboration and Information/Knowledge Management tools can be selected for the whole process.

Probably the Collaboration tools can also have a level of selection between project and knowledge management tools. The collaboration tools are selected also by activities, but depending on the level of interaction required by the partners in each activity. For these tools there is not a great variability, and the same tool can be used in several activities, joining the execution process allowing the collaboration among the partners. With these tools, a workplace or groupware can be defined, and the functional tools, as well as the workflow can be integrated into it. But the main structure of the environment will be defined by these tools.

Group communication and groupware are important features of sophisticated distributed systems. The term ‘‘groupware’’ was defined by [Ellis et al. 1991] as ‘‘computer based systems that support groups of people engaged in a common ITESM, Campus Monterrey

40


task (or goal) and that provide an interface to shared environment’’. Conceptually, groupware is just computer software that functions as a means for human collaborations. It is often considered synonymous with Computer-Supported Collaborative Work as groupware provides collaborative functionality and redefines the collaborative concept by computer-supported communication. In contrast to single-user and single-location application of traditional CAD systems, the current trend is towards multi-point multi-user collaboration, which is facilitated by the ‘‘groupware’’ concept that allows the sharing of system applications, or files across computer platforms and from different locations [Lococo and Yen, 1998].

Advances in processor and computing technology have led to a common practice of CAD/CAM groupware collaboration being assisted by collaborative tools to establish a computer-supported cooperative working environment. Examples of these tools are: text base messages such as text e-mail, text talk and facsimile; audio-based messages such as voicemail, telephone and Internet phone, two-dimensional drawing such as blue print drawings by facsimile and mail (by express delivery), asynchronous computer support such as multimedia e-mail, file transfer (FTP), and World Wide Web services, and synchronous computer support which include shared applications, multimedia audio, whiteboard and video, three-dimensional geometry viewers and desktop conferencing. 4.3.3 CONNECT: Connect environment and applications using standard

and web protocols

At this stage, an evaluation of the partners involved in a project is carried out. It is important to consider (under the extended enterprise concept) that integration with suppliers and customers is an important issue in order to improve the product development, allowing better efficiencies, reduction of time.-to-market, and high quality through the cooperative working of partners involved.

According to [Gott, 1996], the extended enterprise can be regarded as a kind of enterprise which represented by all those organizations or parts of organizations, customers, suppliers and sub-contractors, is engaged collaboratively in the design, development, production and delivery of a product to the end user.


41


The main focus in the extended enterprise are: the creation of a network, the integration between the partners in the network or resulting value chain, and the sharing of information through the use of information and communication technology within the network [Vesterager et al, 1999]. Thus, among other things, the general extended enterprise concept seeks to meet the challenges or opportunities within the following areas:

• Globalization of markets and products. • Use of information and communication technologies as a means of

integration and communication. • Change from delivering standard products to delivering more customized

products (e.g. mass customization). • Increased product life cycle coverage.

The generic model for the extended enterprise has been defined in terms of

business process [Browne, 1998] described by a vertical and a horizontal axis. The vertical axis represents the function view of a manufacturing system (design, manufacturing and control issues), and the horizontal axis represents the integration of the supplier, distributor and customer, it also represents the flow of materials/products from the supplier through to the customer. This model defined five macro-business processes: Customer Order Fulfillment, Supply Chain Management, Manufacturing, Customer Driven Design, And Co-Engineering.

Within the approach of this thesis, the important Macro-business processes regarding the integration of customer and suppliers are:

• Customer Driven Design: joints all the necessary activities to work together in the design and development of a product.

• Co-engineering: includes all the activities directly involved with the

coordination of supplier capabilities into the product design process, so new materials, technologies and process can be incorporated in the enterprise.

Therefore, special attention in the information flow among partners is

necessary to be paid. At this stage is important to identify the required information from the partners involved in the product life cycle, and the connection with their technologies.


42


4.3.3.1 Identify required information from partners involved

Due to this, two groups of connections can be identified. First group includes marketing information exchange (e.g. Web pages, e-catalogues) or interconnection of Manufacturing / Production information (e.g. e-RFQ, ERP, on-line Capacities), and the second group includes the information exchange between partner’s functional tools (e.g. CAD/CAM/CAE files).

From the first group and more related to inter-enterprise collaboration [Lancioni, et. al., 2002], several Internet-specific opportunities for (vertical) collaboration between companies can be:

• Online vendor catalogues, from which buyers can select and procure items from suppliers.

• The tracking of shipments of the various modes of transportation, including truck, rail and air.

• The use of the Internet in processing customer queries, complaints and handling technical issues.

• The timely receipt of orders from international customers. • Communicating with suppliers regarding deliveries, stock availability, etc.

However, under the scope of this thesis over the Engineering Stages from

Product Life Cycle, the connection among functional tools is then a critical issue. Within this approach, the connectivity of functional tools throughout the Product life cycle is included, as well as the connection with information from Functional tools from the partners involved (e.g. Customers and suppliers). The Figure 4-7 depicts the information connection in CeEE, in order to support the Co-engineering and the Customer Driven Design:

Moreover, the connectivity of different functions (different domain of functional tools) will require extra activities to be done, in order to interpret the output information from an specific activity, into usable information for the next activity. As an example of this, can be the “QFD – How’s” which are the result of the use of the QFD technique in the activity of “understand customer requirements”. In this case A QFD Software is used, but its output is a graphical result, which is not possible to be used as a direct input in subsequent activities.


43


However, an activity of interpretation of those needs can be executed before introducing that information in the next activity, which can be the “functional decomposition”. Between this two stages, the outputs from the QFD (the How’s) are used as functions to be analyzed and deployed in the “functional decomposition” stage, but the “Type” of information used differs in format, and it is used in a different way in each activity.

QFDQFD AMEFAMEF CADCAD CAMCAM CAECAE SimulationSimulation

CAx

Integration environment

Knowledge / Information

Management:-Product Model

-Manufacturing Model

Supplier Customer

e-engineering environment information integrationData

InformationKnowledge

• CSM• Catalogues• M-Model

• CRM• Auctions• EDI

SCM CRM

ERP

Co-engineering Co-Design

SCMSCM CRMCRM

ERPERP

Co-engineeringCo-engineering Co-Design Co-Design


Co-Engineering Co-Design• IGES• STEP• DXF

• IGES• STEP• DXF

Figure 4-7 Connect applications of Customers and Suppliers

From the other side, we can have the same information, which will be used in the same activity, but where the supporting tool is different from one partner to the other. The most typical case is in the advanced stages from the design, where several CAD/CAM/CAE/ICAD systems can be found in the Market. This means that the transferring of this information from one partner to the other must be standardized in a specific format, allowing partners to work in the same stage, with the same product but with computer different platforms. In the Appendix C from this thesis, a detailed description of the three most important exchange formats is presented (STEP, IGES and DXF). ITESM, Campus Monterrey

44


4.3.3.2 Define connectivity solution through exchange formats

Due to the engineering focus of this thesis, more than production and manufacturing approach, the connectivity solutions presented in this section are focused in the information exchange between partner’s functional tools

To such an exchange problem, three possible solutions exist:

1. All use the same CAD/CAM/CAE/ICAD package. 2. Use special translator applications to change data from one format to

specific one needed. 3. Use a neutral format for data exchange.

If a data exchange format is required, the Table 4-3 shows which interfaces

are integrated as standard into common CAD systems: Table 4-3 Standard-formats in common CAD systems

Standard-format

CAD-System

IGES

STEP

STL

DXF

DW

G

VDA-

FS

SAT

VRM

L

PAR

ASO

LID

Autodesk AutoCAD O O O O O

Autodesk MDT O O O O O

CADKEY Corp. O O O O O O O

Bentley MicroStation O O O O O O O

CoCreate Designer O O O O O

Dassault Catia O O O O O O

IronCAD O O O O O O

PTC Pro/Desktop O O O O O O

PTC Pro/E O O O O O O O

SDRC I-Deas O O O O

SolidWorks O O O O O O O O O

Think 3 O O O O O O O

UGS Unigraphics O O O O O O

UGS SolidEdge O O O O O O


45


However, before generating any type of interchange data, the following items

must be addressed [Clough, 1999]:

1. What is the current representation of the data being transferred? Examples:

o solid model o surface model o Wireframe o 2D o multiple views o dimensional

2. Can the receiving system handle the current data representation? o If not, what type of data can it handle? o What type of "filtering" must be performed for a successful

translation? 3. What functionality is needed after translation?

Examples: o Geometric Data o Mass Properties o 3D Shaded Images o Clearances

4. What information actually needs to be transferred? Examples:

o Solid Model Only o Detailed Drawing o Wireframe Only

Another very important thing to remember is that this type of translation does

not provide bi-directional integration of applications. The translations can be performed in both directions, but in most cases data is lost or filtered during each translation.

For example, at this time there is no file format supported to transfer

parametric data contained in a parametric solid. This means, if a parametric solid model is translated into a STEP file and then read directly back into the Parametric CAD Solid Modeler, all parametric information is lost


46


It should also be noted, that any translation of geometry between two CAD

systems, whether using STEP, IGES, etc., requires testing to develop the right combination of parameters for each translator. A STEP file suitable for importing into CAD Vendor A may not import properly into CAD Vendor B.

The following two tables (Table 4-4 and Table 4-5, adapted from [Clough, 1999]) shows a list of CAD representations with some associated file formats and also a list of common functionality needed after translation and the associated CAD representations which support them: Table 4-4 CAD representations and some associated file formats

Representation File Formats Supporting It

Parametric Solid Models Not supported at this time Solid Models STEP (Some IGES translators) Surface Models STEP, IGES Wireframe Models STEP, IGES, DXF Tessellated Models VRML, STL

Table 4-5 Functionality needed after translation and the associated CAD representations

Functionality Needed Representations Supporting It

Mass Properties Solid Models Detail Design Solid Models, Surface Models, Wireframe Models Manufacturing Solid Models, Surface Models, Wireframe Models Assembly Integration Solid and Surface Models Meshing Solid and Surface Models 3D Shaded images Solid, Surface and Tessellated Models Dimension Query Solid, Surface, Wireframe and Tessellated Models WEB Access Tessellated Models, Raster images, Vector images

The best way to share data is by using the same CAD application. If this is not possible, solid models via STEP provide the most functionality after translation of CAD data.


47


Understanding what the data will be used for, the capabilities of the CAD systems and the limitations introduced from the data translation are key issues for a successful transfer. Consideration must be placed on what functionality is required with the imported data and the amount of rework that is necessary to support it. 4.3.4 MONITOR: Definition of performance measures and monitoring

techniques

In this monitoring phase, the definitions of “what” to monitor are defined but it is not monitored yet. The measurable parameters are defined in order to allow managers to coordinate, track and control the process in a further execution phase.

The notion of monitoring business processes has initiated numerous efforts to better manage business processes to obtain customer satisfaction, improve operational efficiency, lower operating cost, and maintain competitive advantage. Recently, workflow management has been adopted as a major information technology for managing business processes. It aims at automating business processes by delivering necessary documents, information, and processes according to predefined rules [Hollingsworth, 1994].

In the nowadays rapidly changing environment, companies need to design, evaluate, and optimize the entire process chains including demand forecasting, ordering, research & development, designing, engineering, production and service. That is, business processes are increasingly recognized as important corporate assets that need to be managed throughout their lifecycles

After a successful implementation of an automated Workflow system, the loop for continuous process management is closed by the use of Monitoring techniques. It provides external visibility into what is occurring when the business process is being executed. The Monitor stage intends to track events and data from the Workflow environment execution and provides both real-time and historical tracking of what is occurring in the workflow engine.

At this stage, the resources planning arise in order to consider all the parameters that will be involved in the execution of a process. In this monitoring


48


phase, the definition of the measurable parameters is then carried out, in order to allow managers to coordinate, track and control the process execution. As shown in figure 4-8 it has to be considered the project plan (or the workflow model), in order to have a guide for associating all the measurable data.

For example the resources involved in each activity (human and

technological), which are important for cost estimations (important measurable parameter) and also for workload analysis. Furthermore, assigned dates and time are analyzed, in order to control delays or precedence problems based on unfinished activities. Similarly, the Input and Outputs from the activities are parameters to be controlled, in order to manage the information flow as well as availability for further activities, being an important issue to avoid delays or lack of information to perform the business process activities.

Company 1Company 1

Coordination

Fn Fn

Fn Fn Fn

Fn Fn

Fn Fn

Fn Fn Fn

Fn Fn

MarketRequirements

Project planning

Project Execution Closing andFollow-up( C BD AD L )

MarketRequirements

Project planning

Project Execution Closing andFollow-up( C BD AD L )

Mul

tidis

cipl

inar

yTe

amM

ultid

isci

plin

ary

Team

Info

rmat

ion

and

Kno

wle

dge

man

agem

ent

Time

Milestones&

Deliverables

Performancemeasurements

Resources

M O

N I

T O

R

Figure 4-8 Performance Measures definition

All these variables and parameters are critical for the definition of the

Performance measures, which will be essential to understand how the process really works. Performance measures help to minimize the gap between how a process is supposed to work and the way it actually works. Those measures help to understand: ITESM, Campus Monterrey

49


• How a process works by representing what happens in the process. • What factors affect process performance. • How a process will behave if something in the process changes. • What the process limits are.

According to [Deborin, et. al., 2002], a Business Process Monitoring has two

distinct targets:

• An operational view of what is occurring at the Workflow execution, allowing the perform of administrative actions as well as providing an enhanced alarm/alert system that can pinpoint problems and bottlenecks in an executing process.

• A management interface into the actual performance of the business process. The information contained here provides important decision-making data from a cost, time, and even utilization perspective. The metrics that are generated from the Monitoring activities can be imported back as feedback to the continued analysis of the process.

Finally, the performance measures will allow managers to collect and analyze

information (helped with statistical techniques) to evaluate performances as well as create statements to judge projects performance and have enough information for continuous process improvement (which is an important issue to tackle in process monitoring). 4.3.4.1 Identify the types of measures (default from WFMS and user-defined)

The Measures that allow users to evaluate the performance of a business process as it is running is known as Business measures. As workflow modeling is proposed to manage the Process domain, in common WFMS there are two types of measures: those predefined by the WFMS used, such as cost and duration, and user-defined ones. Some examples of default measures can be:

• State: Shows the current state of Process Instance, Activity Instance, or work item in the Workflow system. The states can be: o Ready - When an instance is created. o Running - When an instance is started. o Completed - When an instance is completed. o Terminated - When an instance is terminated.


50


• Starting Time: Specifies the start date and time of the Process Instance. • Elapsed Duration: The elapsed duration is calculated by the current time

minus the time the Process Instance was started. • Working Duration: Shows the total working duration for the Process

Instance. This field is the aggregation of the total working time spent by resources in the Process Instance.

• Due date: This field shows the date when a Process Instance has to be ready.

• Cost: It specify the total cost accumulated since the process start.

From the other side, an evaluation of the process and the goals is carried out, in order to determine the user defined performance measures. A performance measure is a variable that describes the behavior of a particular action that an employee, a process, or a business unit performs. A measurement system is a system that allows the collection and distribution of a number of useful performance measures, taking care of identifying the right variables.

Managers can use this data to lead their organizations and make informed decisions based on the information provided by the measurement system. It is also important to learn how to use these measures to drive performance improvements. A measurement system only provides data and it has value only if the data can be used to make good decisions and to drive improvement efforts that translate into appropriate actions and performance plans.

An appropriate business measurement system can aid an organization in achieving a higher level of process visibility. Process visibility allows the business to identify issues as they occur, rather than indirect reporting, which may not have an accurate picture of what is occurring. A measurement system can also provide critical performance-related information as the process is executing to ensure that customers are receiving the highest quality products and/or services possible [Deborin, et. al., 2002]. 4.3.4.2 Define customized performance measures

A performance measure is the evaluation of a defined metric at a specific location in a process under a specific condition. This business measure definition contains three elements: metric, location, and condition:


51


• Metric: A metric is what users would like to evaluate. It may be simple, such as process cycle time, process cost, or activity working duration. Alternatively, it may be complex and represented by a specific expression or formula that contains a number of metrics.

• Location: A location is the specified point within a process at which we wish to evaluate a metric. For example, a location can be before a specific activity, at the end of a process, etc.

• Condition: A condition is the specified set of circumstances for which the metric value is valid. For example, A metric value is needed to be evaluated when Task A or Task B have completed, but Task C has not yet started. This Condition can be defined by using a Boolean expression. If a condition is not defined to a business measure, then the metric will be evaluated under all available conditions.

In the following paragraphs a set of important issues will be described, in

order to take into account at the moment of defining the business measures that will later be used in the workflow monitoring. Identify strategy and objectives:

The key to having a good measurement system is to have a good strategy. Performance measures are derived from strategy and from analysis of the key business factors that are needed to be concentrated on to ensure that the vision is achieved. Identify goal measures:

Goals need to be set at each level in the organization, so that achievement of lower-level goals leads to achievement of higher-level goals. Lower level goals tend to become more concrete and measurable. Lower-level goals are based more on the outcomes of specific projects and activities that support the higher-level goals. (See also Table 4-6) Determine categories and required measures:

Create measures categories (for example, Productivity, Quality, Timeliness, Resource Utilization, Cycle Time, and Costs). Expressions that evaluate the relevant business measures within the process have to be defined. ITESM, Campus Monterrey

52


Determine available data required for business measures: Review the list of possible measures and outline what elements must be

contained within an automatically monitoring data container and will be accessible to the system. If the required data is outside of the process scope, then determine if measures can be gathered by another means. 4.3.4.3 Determine the monitoring level

It is important to define the monitoring level for the process management. That means, a hierarchical monitoring definition must be determined, in order to filter the performance indicators to the right person (e.g., the relevant indicators for directives may differ from those important indicators concerning to the project managers or project executors).

A table for the measures classification is shown in Table 4-6 which is based on the Zachman framework [Zachman, 2000], counting with hierarchical levels on one axis, and the important issues in a system definition (what, how, where, who, when and why). For our approach, the hierarchy will be reduced to three levels: Directive, coordinators or project managers, and the operation level. However, for this thesis, the important monitoring level will be focused on the Project management performance measures. They are not strategically measures as directives needs, neither floor measures, which are specific for activities execution. Table 4-6 Performance measures classification (Adapted from Zachman’s Framework)

What (Information)

How (Function)

Where (Network)

Who (People)

When (Time)

Why (motivation)

Directive

Management

Operation

As an example the measures from the “Who“ (People, resources) in the

upper (Directive) perspective is mainly related to the human aspects, therefore using measures concepts such as organizational units, mission, organizational chart, etc. However, moving down to the managers perspectives, the focus gradually shifts towards the human-machine interaction and subsequently (operational) to interface specifications (away from the human aspect).


53


4.4 Step IV: Execute and manage the CeEE

For the design and integration of the Collaborative Engineering Environment, it is necessary to cover a set of activities that will allow the implementation of this concept in the industries. To achieve this, it is required the support of reference models, architectures and methodologies that enable the performance of the Model, Integrate, Connect and Monitor activities.

At this stage, the designed environment is supposed to be implemented. The technology selection is carried out (based on pre-selected applications), or an assessment of the better option can be performed. 4.4.1.1 Configure the generic environment settings

The technologies to be used for the implementation of the environment are configured at this step, based on the design requirements previously defined and company requirements. As shown in Figure 4-9, the environment design steps must be covered, in order to determine the kind of process development, and the applications and supporting tools that will be integrated, as well as the information sharing requirements based on the connectivity definitions. The management system to be used is also considered, based on the performance measures that will be controlled.

This stage is very important for the Internet connections and uploading the

required services which will allow the Web hosting of the environment applications. At this stage, the hardware and middleware configuration play a critical role, in order to determine the physical installation of the hosted services from the CeEE. This step aims the set-up and configuration of the technological platform where the CeEE will run.


54


Model Integrate Connect Monitor

Management

Model Assessment

ModelRevision

ModelImplemen-

tation

ModelExecution

ModelEvaluation

Supplier

Customer

Internal

Supplier

Customer

InternalInternal


Teamwork 1(or Company A)

Collaboration tools

Collaboration tools

Functional tools


Management

Coordination tools Teamwork 1

(or Company A)

Collaboration tools

Collaboration tools

Functional tools


Management

Coordination tools

Iden

tify

tool

s & te

chni

ques Human processes

Com

pute

r ap

plic

atio

ns

Functional

Collaboration

Coordination


Identify external Partners

Info

rmat

ion

requ

ired

Data

Information

Knowledge

I/O analysis

Start

End

Indicators definition

Control system definition

Performance measurement

Management andProcess improvement

Co-engineering

Co-design

Figure 4-9 Executed steps from Collaborative Environments Design

4.4.1.2 Release the workflow model

When the modeling process is finished, and all the stages from the environment design methodology where covered, the model should represent the ’real’ processes of the company (or Industry networks) having defined:

• Work items in the process and the order in which they occur • Staff assigned to manage and perform each work item • Process-relevant data used in each work item and passed to subsequent

ones • Programs needed to perform work items • Conditions for starting and ending each work item • Maximum duration of each work item and process

When the model is finished, now it is ready to be automated and executed,.

At this stage, the selection of the WFMS is carried out. ITESM, Campus Monterrey

55


The workflow model is created (In a “Buildtime” package) and afterwards it can be converted in an operational process. It is then called a process template. In “Runtime” (workflow in execution), for every instance of a process, the Workflow server navigate through the process. It uses the process model information to move the work to the right person in the right sequence, as well as starts the defined programs, keeps process execution history, and provides recovery and restart procedures. Activities that need to be performed appear on worklists of the users of the assigned staff members. When a staff member selects, for example, a program activity, the program starts with the information already defined in the process model. 4.4.1.3 Execute the Workflow Runtime

The workflow execution is only carried out when all the stages from the Collaborative Engineering Environments Methodology were covered, due to the necessity of identification of all the domains related to the engineering environment.

In order to execute an automated Workflow Management System, the Workflow Management Coalition (WfMC), an international standard organization on WFMS, has proposed a Workflow Reference Model (WRM). Figure 4-10 represents the general architecture of WRM, which is adopted by most existing WFMSs. This architecture shows a good fit with the proposed methodology of this thesis, according to the integration of applications, coordination and process definition, Making the use of Workflow as a key tool in developing CeEE.

WRM consist of five components: workflow engine, process definition tools, monitoring tools, workflow clients and invoked applications. The central part of the system is the engine that interprets process definitions controls process execution, and manages work items in users work lists. It also interacts with workflow participants, and invokes some required applications. The process definition tools create process models and store them in a proper format. There are two types of workflow clients: workflow client applications and invoked applications. While both perform workflow activities, the former are controlled by human clients and the latter are software programs that perform the activities automatically. The administration and monitoring tools provide a user interface for administration and supervision of workflow management. ITESM, Campus Monterrey

56


Other Workflow enactment services

Workflow API and interchanges formats

Workflow enactment services

Workflow Client

applications

Invoquedapplications

Process definition tools

Administration and

monitoring tools

Workflow engines

Workflow engines

Interface 2

Interface 5

Interface 3

Interface 4

Interface 1

Figure 4-10 Workflow Reference Model [Hollingsworth, 1994]

The benefits of a Workflow are many and diverse, depending on the

organization’s goals. Following are some examples:

• Faster work completion If a process has a lot of paper-based activities, Workflow can reduce the time it takes to accomplish tasks. Automating processes and moving documents electronically virtually eliminates the time required to move paper around partners.

• Gains in productivity For Workflow participants, a WFMS saves valuable time by helping work organization and set priorities (based on priority, due date, or most time-sensitive tasks). Work arrives with all the supporting information, and the required indications to execute a task.

• Improvements in process control Workflow is a powerful knowledge management tool for standardizing the organization’s processes (consistency and quality) while providing great flexibility for modifying and improving them.

• More effective collaboration Over time, the process definitions can become for the organization or the industrial networks, a storehouse of “best practices”, which can be shared across the extended enterprise.


57


Chapter 5. Case study

In this chapter, the experiences in developing Collaborative e-Engineering Environments will be described. The research methodology facilitated the improvements of the CeEE design Methodology definition. Based on this, three improvement cycles based on the action research approach, will be explained in order to evaluate the experiences. The scenarios presented, will lead to understand and demonstrate the need of Collaborative Engineering Environments in globalized industrial networks, through the integration of automated processes and Technology.

The Figure 5-1 depicts a general overview of the spiral sequencing followed

in the development of the presented scenarios.

WebSphereStudio

IntelliStation Power 9114-275 AIX 5L IBM IntelliStation M Pro Windows XP

Computer and Network

CATIA P3

DELM

IALotus SameTimeInstant Messaging

Lotus QuickPlaceTeam WorkPlace

Lotus SameTimeInstant Messaging


Lotus Collaborative Center Lotus Domino Server

WebSphereMQ Series

WebSphere Portal Extends

Foundation & ToolsWebSphere Application

Server

MQ

WorkFlow

MQ

Integrator

Integrator

DatabaseDB2

SmarTeam

Other Applications

TCP/IP, HTTP, SSL

CeEE design methodology

Plan

Observe

Ref

lect

ActCycle 1

Plan

Observe

Ref

lect

ActCycle 1

Plan

Observe

Ref

lect

ActCycle 2

Plan

Observe

Ref

lect

ActCycle 2

Plan

Observe

Ref

lect

ActCycle 3

Plan

Observe

Ref

lect

ActCycle 3

Environment execution

Feedback(Technology)

Environment execution

Feedback(Methodology)

I. AS-ISII. TO-BEIII. Environment

– Model– Integrate– Connect– Monitor

IV. Execute

Php Groupware Freeware applications IBM - WebSphereTM

Figure 5-1 Case studies: Performed Action Research Spiral


58


In the following sections the experiences developing CeEE with different technologies and methodology will be explained, in order to identify those key issues at the moment of implementing the Engineering Environments. The first cycle intended to establish a shared space to allow interaction among partners. The web-space provide access to some collaboration tools (chat and forums), and web storage was able, as well as publishing (html) procedures. After this first cycle, a need for more collaboration tools, and the need to demonstrate that public domain applications were also an alternative to collaborate in technical projects. This cycle can be considered as an informal Environment, due to the use of freeware applications, which offers the necessary tools to foster collaboration among remote partners in a collaborative project. Afterwards, the look for a more stable platform has guided to a selection of tools for a third cycle, where a more robust technology provided by IBMTM will be explained, in order to detail the platform capable to support the creation of a Collaborative e-Engineering Environments.

The methodology proposed in Chapter 4 was implemented in each cycle, as the planning stage for the Environments Integration. The methodology will be summarized in the scenarios description based on the shortcuts specified on table 5-1: Table 5-1 Legend for Methodology implementation in CeEE developments

Steps Methodology steps description Shortcut Step I Define the company requirements and model the AS –

IS of the development process Step I. AS-IS

Step II Assess the AS- IS, and model the TO-BE Step II. TO-BE

Step III Design and integration of environment and applications Step III. Environment

Modeling the workflow III.1 - Model

Selection and Integration of e-Engineering applications III.2 - Integrate

Connect environment and application using standard and web protocols III.3 - Connect

Definition of performance measures and monitoring techniques III.4 - Monitor

Step IV Execute and manage the CeEE Step IV. Execute


59


5.1 Cycle 1: Php groupware Technologies

The purpose of this cycle, was to design and integrate a Collaborative e-Engineering Environment to be used in a project with the University of California at Berkeley called: Global Collaborative Engineering Environment for Integrated Product Development using Internet 2 (Global e-Engineering).3 The project was intended to support the remote development of High Tech Products, as well as education cooperation. 5.1.1 Step I. AS-IS

In this scenario, there was no current process under execution. The idea was to introduce a new methodology for High-Tech products development. Consequently, an original model or a current process to be analyzed (in order to be improved) does not exist. 5.1.2 Step II. TO-BE

For this project, a structured way of doing the design stages was proposed, in order to concurrently design electronic products, integrating electronic and Mechanical knowledge. The proposed model is shown in Figure 5-2 and it is directly considered the TO-BE model, due to no existing process was previously implemented. These stages were followed to assist students and engineers to design and collaborate with a determined set of specific methods and tools, allowing the collaborative product development within US and Mexican students.

The model is assessed based on the four domains. The Process Domain is clearly identified, and the activities sequencing was clearly defined. The information domain includes the procedures, instructive and formats which leads the documentation of the process development. Each stage from the methodology has a defined set of documents which allow the partners to execute the activities. A lack of human resources assignment was identified (Organization domain); there are no responsible nor coordinator roles. The Technology Domain is defined through the identification of required methods and tools, to support Integrated Product development Process.

3 UC MEXUS-CONACyT Advanced Networks Services Applications. Collaborative Grants in Research, Education & Technology 2001 ITESM, Campus Monterrey

60


Phases Activities Toollgates Record

Idea

tion

Basi

c D

evel

opm

ent

Laun

chin

g

1 Competitive Intelligence

2 Project Definition

3 Parametric Analysis

4 Market requirements

5 Functional Decomposition

6 Concept Generation

8 Physic Decomposition

10 Manufacturing Model

11 DFM&A

7 Parametric Model

9 Activity Base Cost

12 FMEA - Process

13 Installation Instructions

14 Operation Instructions

15 Maintenance Instructions

16 Retirement instructions

2 Project Plan

1 Inventory of ideas

4 Target Specifications

8 FMEA - Design

7 Drawings

9 Prototype

12 Process Planning forFabrication and Assembly

16 User’s Manual

Det

ail D

esig

n

IDA-01 , IDT01

IDA-02 , IDT02

BDA-03

BDA-04 , BDT-04

BDA-05

BDA-06, BDA06

DDA-07 , DDT-07

DDA-11

DDA-10

DDA-09 , DDT-09

DDA-12 , DDT-12

LAA-17 , LAT-16

LAA-13

LAA-14

LAA-15

6 Select Concept

DDA-08 , DDT-08

Information

TechnologyOrganization

Process

Legend:Information


Process

Legend:

Figure 5-2 Integrated High-Tech Product Development Process

5.1.3 Step III. Environment

The technology to be considered in this scenario was evaluated. In the early stages of the project, a complete development of a prototype environment was carried out. The selected technologies for the first software were Hypertext Preprocessor (PHP), MySQL and Apache Web Server. The system was finished, but some issues about the testing period showed that the developed software was not the best option for this application. Among the limitations founded were the difficulty to do maintenance, it was not standard and it was not easily modifiable. In this way, a Webmaster must be constantly coordinating and maintaining the system, increasing costs, and reducing efficiency and autonomy for the Software users.

As a consequence, a new research about collaborative applications was done and some standard applications were analyzed. The chosen application was PHPgroupware (http://phpgroupware.org/) because it offers a standard


61


groupware, which can be personalized, that is, it can be reprogrammed to be adjusted to an specific application.

After the domains are identified, the sub-steps from this stage of the methodology were executed: 5.1.3.1 Step III.1 - MODEL

Based on the TO-BE model assessed on the previous stages, now the work assignment to the CeEE users will be defined. Due to the platform specifications, a lack of processes management or workflow tools obliged a different form to represent the Process Sequencing. Due to this a set of HTML pages were developed in order to integrate them into the environment. This is the way groupware systems are configured in order to personalize the environments to the purposed application.

For this scenario, the Integrated Product Development Process was divided in its main four stages, specifying the sequence of activities to be performed by the users, and the required information that each step requires to be performed and the information generated as a result. In order to access to the Environment the users must introduce a username, password and select actual project stage. The stages are available as the project advance; if information from pervious stages is not complete next stages are unavailable (See Figure 5-3):

Figure 5-3 Stages of Product Development process in the PHP CeEE


62



63

5.1.3.2 Step III.2 - INTEGRATE

For this case, the technology needs Server configuration in order to allow the Internet access to the Environment. The storage space limited is depending on the hardware from the server where the installation will be installed.

For the UC-MEXUS project, several Web based tools were developed for

supporting the Integrated Product Development Process. Some examples are: A) The Manufacturing Advisory Service (MAS)4, which is a tool for finding a good fabrication method for a part while still at the conceptual level of design, B) SMT-Advisor5, helps users to analyze the manufacturability of any Printed Circuit Board (PCB) according to the capabilities from the SMT line at ITESM, and C) Ducade6, fro supporting the electronic and mechanical components assemblies design.

Therefore, the technologies used in this case are summarized on Table 5-2.

Table 5-2 Computer applications for the PHP-Environment Integration

Functional Knowledge / Information

Management Collaboration Coordination

PHP-

Gro

upw

are

tool

s

Web Based Applications used: • MAS • SMT-Advisor • Ducade

Engineering stand-alone applications used: • Pro-Engineer • Electronic

Workbench

• Files uploads Tools available are: • Mail • Chat • Forums • Shared spaces • News • User index

Design stages are conformed by a sequence of activities in order to assure the information flow along product development process The defined structure in the environment allow process flows and control of Instructive, Formats, Methods and Tools

4 http://cybercut.berkeley.edu/mas2/ 5 http://csim.mty.itesm.mx/grupos/smt 6 http://spiderman.me.berkeley.edu/ducade/


The Information management tools and the collaboration tools are capabilities of PHP technology. From the other side, the Functional tools are the methods and tools recommended for use by the Integrated Product Development Process. 5.1.3.3 Step III.3 - CONNECT

For this scenario, no marketing information exchange was required due to the partners were Universities (UC-Berkeley & ITESM), using their own capabilities for design and manufacture. The only need of information exchange may be the information exchange between partner’s functional tools as CAD software and DUCADE system. 5.1.3.4 Step III.4 - MONITOR

For this scenario, and due to the lack of a coordination system, no performance measures were defined. The automated monitoring was not possible, and conventional managing tools were used. 5.1.4 Step IV. Execute

After executing the previous activities, and with the identified technology, the Integration and implementation of the CeEE is carried out. The architecture of the system is explained on Figure 5-4.

Navigator

HTML Result

PHP Processing

Data Base ServerPHP Page

Internet Server

Page request

Navigator

HTML Result

PHP Processing

Data Base ServerPHP Page

Internet Server

Page request

Figure 5-4 Php groupware architecture


64


A Current version of Collaborative e-Engineering Environment prototype is located at http://csim.mty.itesm.mx/grupos/e-engineering as shown in Figure 5-5. All the identified technologies are referenced from the process model, and the application can be linked (if it is a web based functional tool) or simply referenced or recommended by the process model (in this case, embedded information html pages)

Web-based

Productdevelopmentstage

Detailedmethodology(Instructivesand formats)

Working area

Bookmarks:Links tofunctionaltools andotherinterestingsites

Collaborationtools, as:Links toChat, Forum, calendar, news, userdirectory, etc

Figure 5-5 PHP-Groupware characteristics

To fulfill all of the above issues, the developed system offers different applications on each stage and activities of the project. The members can access these methodological sections in different geographical locations and the environment allows them to: Organize their project activities (Time and resources), Participate in creative ideas across distances and contribute as they please, Establish coordinated actions for specific task in order to take decisions in critical points during the product design process and finally, Keep up-to-date and share project information as records of every activity, product models and simulation reports. 5.2 Cycle 2: Free-ware applications

The Manufacturing Systems Center (CSIM-ITESM); has been largely working with computer applications that support Integrated Product Development, from early stages (i.e. Brainstorming or QFD) to advanced engineering tools (i.e.


65


CAD/CAM/CAE or simulation tools). But the globalization has been driving companies and research efforts to allow “collaboration” and “integration” of the processes across the product life cycle.

This cycle was executed, trying to explore a broader range on collaboration tools, because technological feedback from the last cycle (Php-groupware scenario) has shown that collaboration tools already integrated in groupwares are limited. Due to this, several tools were tested, and this scenario summarized the concepts of “what” commercial public domain tools may offer. Within these categories, it can be included MSNTM, YahooTM, NetMeetingTM, which provides a high variety collaboration tools. For this specific scenario, the MSN applications were selected in order to demonstrate the concepts. Then, the CeEE methodology was used to design an environment with free-ware tools. 5.2.1 Step I. AS-IS

In this scenario, as well as the previous one, there was no current process under execution, so an AS-IS process does not exist. 5.2.2 Step II. TO-BE

Due to the main objective of this scenario was to test the variety of accessible collaboration tools, the same Integrated Product Development Process was intended to be included in this scenario (The proposed model was already shown in Figure 5-2). This model is also directly considered TO-BE model, due to there were no existing process previously implemented. 5.2.3 Step III. Environment

Considering the availability of these tools, some of the next steps were carried out in order to design an integrated environment. 5.2.3.1 Step III.1 – MODEL

In this scenario, it was necessary to create a shared space, using MSN groups. With this space, now it was possible to include the defined methodology, which in this case was made similarly as the same scenario. This time the use of images was done, due to the less configurability of the frames from the virtual group. However, simple text-based or html based frames can be configured.


66


In this kind of environments, there is a lack of workflow tools, so Figure 5-6 shows the way the environment was configured to have a flow of activities, and the methods and tools required for each activity, through the use of images (as a demonstrating way to show that the frame can be configured in such a way that advanced Web programming can be develop improved ways to show the process flow).

Figure 5-6 Stages of Product Development process in freeware based CeEE

A workflow was not carried out, but instead, a Web structure related to the

project activities was generated into the MSN group. A menu was created, with the Integrated product development stages, according to the pre-defined methodology. As well, links to the documentation (Procedures, Instructive and Formats) were generated. The documents were uploaded, and instances o the delivered documents (Registers) were able to be uploaded in a pre-defined files structure. 5.2.3.2 Step III.2 – INTEGRATE

In this case, freeware applications were used to configure an e-engineering environment, which integrates space to upload information, configure methodological steps, calendar, e-mailing, and chat, among other services (See Table 5-3). Some specific tools (functional tools) were shared through “applications sharing” and allowing control and interacting through video/audio conferencing as well as drafting with a common whiteboard.


67



68

Table 5-3 CeEE based on Freeware tools



MSN

col

labo

rativ

e to

ols

In this case, engineering stand-alone applications were used: • Mechanical

Desktop • Design explorer • Electronic

Workbench Some CAD tools allow collaboration (e.g. CATIA, AML)

MSN groups: • Files uploads • Pictures

publishing • Customized html

frames (with the project information)

MSN group: • Chat • Calendar • Forums

MSN Messenger: • Instant messaging • Applications

sharing • Audio / Video • Whiteboard

For this environment, a lack of a formal coordination tool is a disadvantage. Stand alone applications as MS Project were used. An approach is the defined structure in the environment created: MSN groups: • Calendar • Customized html

frames (with the project information)

This kind of scenarios can be an example of the execution of one activity into

the product life cycle. Here the users need some input information (i.e. electronic CAD design, specifications, etc), and they must deliver a specific output (CAD model reviewed or engineering change proposed). It is supposed that a upper level from here, the management and monitor tools are supposed to be controlling the execution of this task, as well as the common information (i.e. uploaded in this shared environment) is centralized. 5.2.3.3 Step III.3 – CONNECT

Once again, the key issue in connecting applications is the exchange formats among functional tools. However, in this kind of environments, the transferring of formats to exchange information between computer applications can be managed through the files uploading from the environment. As a result, this stage was no t executed, due to no need of connectivity efforts are required. 5.2.3.4 Step III.4 – MONITOR

The monitor stage was not executed as well, because there is no a coordination system, able to track and control defined performance measures.



69

5.2.4 Step IV. Execute

In former projects, different tools have been used to foster collaboration, but the problem is that the integration is still a key issue. As shown in the Figure 5-7, a combination of different tools through the internet was used to execute a specific task in an electronic product design.

Figure 5-7 MSNTM collaborative tools (Messenger and groups)

The users of this CeEE (MSN group) http://groups.msn.com/e-engineering

were joined through e-mail accounts (in this specific case, Hotmail.com accounts were created). They were considered four engineers and one Project leader. The point to tackle is then the “integration” of all the required applications into a common “environment”, providing the necessary tools to the project team. The integration platform should allow the coordinated and simultaneous execution of project tasks, providing a “Global Collaborative e-engineering Environment”


5.3 Cycle 3: Industrial Scenario - Case Study

This cycle tries to integrate the experiences gained in the prior two cycles, were technological and methodological feedback has been achieved. The need of more stable and robust platforms has guided to the selection of more complex (commercial) applications 5.3.1 General description of the scenario

This Industrial scenario will be the value added services offered by a Virtual

Enterprise Broker. This business entity in charge of providing brokerage services for the Mexican Virtual Industry Cluster (VIC) has been created at CSIM – ITESM (Centro de Sistemas Integrados de Manufactura) and has been named IECOS (Integration Engineering and Construction Systems). IECOS was created as part of the incubation program for technological based companies from ITESM, Campus Monterrey. IECOS is an engineering firm created to satisfy companies’ requirements for innovative projects through the integration of technological competencies of industry networks (wws.iecos.com.mx). In October of 2001, IECOS was created as a formal firm with the objective of exploring different way of how the creation of new business is possible for the Mexican-Industry Cluster 5.3.1.1 Industry networks management

One of the major benefits of Industry Networks is the partner’s integration and the classification of potential projects able to be performed where the Broker is in charge of the project management and control. This is very important and critical to fulfill the customer’s requirements. It is important to identify what type of project is going to be executed in order to organize better the different stages of development. As explained on section 4.1 from Chapter 4 of this thesis, in the project execution stage, it has been considered important to follow the model of Integrated Product Development where the Broker has to carry out four main activities: Ideation, Basic Development, Advanced Development and Launching. Depending on the kind of market needs, on the complexity and the activities that must be executed, there are different types of projects: Product transfer, Technology transfer and New Product Development (See Table 5-4). The Table shows as well the general activities carried out, depending on the new business opportunity identified (Broker Project Types), in order to compare them and analyze the early stages definition. ITESM, Campus Monterrey

70


Table 5-4 General activities in the Broker business opportunities classification

Stages Sub-stages

Product transfer

Technology transfer

Product development

Market requirements

-

• Technological Requirements Analysis

• Partners evaluation and selection

• Analysis of the part/processes that can be outsourced

• Partners evaluation

• Competitive intelligence

• Market analysis

Project planning

-

• Financial Analysis • Request for Quotation • Terms and conditions

negotiation

• Manufacture analysis • Technologies

evaluation • Manufacturing process

definition

• Resources and time assignation

• Scope definition

Ideation - - • Concept ideation • Feasibility analysis

Basic development

- • Layout • Technology

implementation

• Functional analysis • Morphology • Concept selection

Advance development

• 2D, 3D Drawings • CNC Codes • Manufacturing &

Assembly

• System ramp-up • Pilot production • Tests and adjustments

• Drawings generation • Bill of materials • Providers selection

Project execution

Launching • Quality control • Product storage • Mass production • Prototyping

• Build and construct

Customer follow-up

- • Delivery • Feedback • Payment

• Delivery • Feedback • Payment

• Ramp-up • Guarantee

The Broker business process is divided in four main stages: Market

requirements, Project planning, Project Execution and Customer Follow-Up. The Figure 5-8 shows the generic Brokerage project stages, in order to clarify the interaction between project planning and project execution. The Figure 5-8 (instantiated from Figure 4-3 from this thesis) shows the variable project executions according to the type of project to be executed. 5.3.1.2 Customer Background

A European aerospace maintenance company (with more than 20,000 metal-mechanic parts to be subcontracted), through its office in North America (for American customers), was looking for Mexican suppliers to achieve better quality and lower cost. The aerospace markets rule the characteristic products offered by this company, traducing it into low volumes and high quality and resistance levels. This company is nowadays working with IECOS in its Mexican sourcing network and some Central and South American suppliers.


71


Market requirements

Market requirements Project

planningProject

planning

Customer follow-up

Customer follow-up





IdeationBasic development


Ideation

Basic Development

Advanced Development

Launching

Technology Transfer• Layout• Machinery:

- Specialized- Universal

Technology Transfer• Layout• Machinery:

- Specialized- Universal

ProductTransfer

2D, 3D Drawings3D – 5D CNC CodesManufacturing & Assembly

ProductTransfer

2D, 3D Drawings3D – 5D CNC CodesManufacturing & Assembly

New Product Development• Market analysis• Product specification• Manufacture analysis• Detailed design

New Product Development• Market analysis• Product specification• Manufacture analysis• Detailed design

Production

Figure 5-8 Virtual Enterprise Broker projects

At the beginning, the main problem was: how to integrate the capabilities of

different suppliers in order to satisfy the diversity of parts that this company had (from small parts to complete assemblies). IECOS was proposed as an alternative because of the different SMEs integration, in order to meet the product mixture, by dealing with only a single company that coordinates all Mexican suppliers.

The day-to-day interaction with the customer is carried out via chat. All questions, requirements and conversations are discussed with this tool. However, the technical information provided by both parts is sent using e-mail. Lately, after a long-term relationship, the customer gives IECOS access to an ftp server with the technical information of the project (drawings, materials specifications, etc.)

Among the products that IECOS has provided to the OEM, a special Case was selected to detail: Installation and removal tool for airplanes landing gear maintenance.


72



73

5.3.1.3 Product description

The Installation and removal tool for the maintenance of airplane landing gear is a licensed product from the IECOS client. The product is actually manufactured and assembled in Europe and the OEM´s office in Miami planned to transfer the product to Mexico.

As shown in Figure 5-9, the product is composed by two sub-structures named: (A) Gripper and (B) Pick-up tool.

Figure 5-9 Installation/removal tool for airplane landing gear

5.3.2 Design the Collaborative e-Engineering Environment for Aerospace

Maintenance Tooling 5.3.2.1 Step I. AS-IS

The original process executed for product transfer is based on the Quality Assurance documentation. Based on this model, the AS-IS model is analyzed in order to came up with ideas of improvement.


Then, the workflow carried out for project development in this case study is based on the Quality Assurance Process from the IECOS quality system. The original diagram (in Spanish) is shown on left from Figure 5-10, and at right it is a summary of general activities based on this process.

BOM Definition

Material Selection

Partners Selection

IECOS Quality Control

Control in Process

Manufacturing ProcessDefinition

Packing and Shipping

Storage

Figure 5-10 Generic product transfer process based on the quality documentation

The initial stage is the contact with the client (in this case it was an actual

customer). The Original Equipment Manufacturer (OEM) explains in general the project requirements and gives a target price, which will allow them to exploit new business opportunities (a price they think would open their market). The Technical information and drawings are sent for analysis (now, downloadable from ftp database) and the customer wait for the quotation.

For this case, a complete product design is not carried out, because the product already has an original design. However, it is very important to focus on the set rules for materials, tolerances, etc., because of the standards transitions within Europe and North America (including Mexico). Then some engineering changes must be proposed in order to fulfill the customer requirements.

The analysis of the information is then carried out. It is necessary to identify that all the information is complete, because sometimes not all the required information is totally complete (assemblies, sub-assemblies and detailed components).


74


As a first stage, the Bill of Materials (BOM) is carried out in order to identify

the materials and standard components that must be purchased. Several instructive documents were developed to interpret the OEM drawings for aerospace components (e.g. Boeing, Air Bus, Snegma, etc) because of their information complexity and sometimes its antiquity (hand made drawings). It is important, because the components list must match in dimensioning and quantity with the BOM.

For the material specification, a list of previously used materials by IECOS is consulted. When the material is not founded, the international standards are checked (ANFOR, DIN, AISI-SAE, etc.) to find the corresponding material in commercial standards in Mexico. Sometimes the equivalent specification is not a common standard in Mexico, even in USA. The material can be imported from USA, but it must be avoided because the costs and lead times will increase.

When an equivalent standard for materials specifications is not found in the national market, a chemical and mechanical properties evaluation is carried out. The required product performance is then analyzed against its function and operation (electrical and thermal conditions, work environment, stresses, etc.) in order to allow the suggestion of materials with similar conditions. The new material is then proposed to the customer through a registered document and they can decide if the change is viable or not. Usually the conditions of the new material must be equal in properties or even exceed the characteristics proposed by original design. The acceptance of engineering changes must be documented in formal registers.

The first approach of integration is the strategies used in materials purchase. The material can be bought directly by the manufacture provider, or IECOS can do it directly in order to ensure quality and lead times. At the same time, consolidations of material purchases allow costs reduction by increasing volumes.

The manufacturing process definition is defined, in parallel, with the materials definition. The process chart will help IECOS to identify the required processes in order to integrate the competences of different (one or more) companies for the project development.


75


The Manufacture provider selection is critical in the IECOS projects. A “database” of companies (Virtual Industry Clusters [Flores and Molina, 2000] is used to pre-select the partners that will be part of a determined project. All the information of the companies is stored in a software tool called “Enterprise Core Competence Database” [Mejía and Molina, 2002] where SMEs can be identified depending on the project conditions, and the potential providers competencies. The SMEs are ranked based on an evaluation through the IMMPAC Methodology [Molina and Gonzalez, 1997]. Based on this evaluation the VEB rank the companies and can select correctly those whose competencies are needed to execute a determined project. Additionally, new tools are required to rank the companies not only according to they initial evaluation, but also based on their historic performance in former projects. These experiences are very important for the partners selection.

Before the information goes to the manufacture provider, all the technical information must be very clear to IECOS in order to take care of the provider’s questions. For the IECOS complete understanding of the information, a detailed analysis must be worked out, and virtual meetings with the customer can be carried out, if it is necessary.

An initial set of companies is selected to the initial quoting. Confidentiality agreements are sign, and the providers then analyze the information. After this, new parameters influence the partners selection, like price and quoting time. Reliability of the providers can also determine the selection based on the performance rankings information.

Once the materials are identified (national or international provider) and the company or companies whose will be in charge of the manufacture are also contacted, the quotation to the customer is sent. However, the product already has a detailed analysis in order to save time and costs at the moment of the purchase order. During the manufacturing process IECOS gives support to the suppliers, answering any questions related to the specifications, materials and processes. IECOS is the link between the customer and the suppliers. All the information needed in order to manufacture the parts, is managed through IECOS

When the OEM accepts the quote, IECOS proceed to the agreements with suppliers and control meetings are established in order to check the products advances (at 25%, 50% and 75% of the estimated delivery time). In the case of ITESM, Campus Monterrey

76


non-Mexican providers (from Latin American Industry Clusters [VIC, 2000]) is an area for further research, because the inspection and control is not easy. Some Web-tools and e-services [Mejía, et al. 2002] are also proposed for implementation in order to improve the foreign clusters management.

After the partial controls are carried out, without non-conformities, the product and/or components are delivered to the IECOS facility and finally quality controls are done and documented. The product is packed and delivered (exported) to the customer, in this case in Miami, USA. 5.3.2.2 Step II. TO-BE

Based on the experience and interviewing the experts, a TO-BE model can be defined, in order to generate the workflow, which will be the start-up for the CeEE design. The Figure 5-11 represents the Product transfer TO-BE Model. 5.3.2.3 Step III. Environment

In order to detail the next sub-stages corresponding to the Environment design (Step III), a selection of key Activities will be done. The selected activity to be explained in the following sub-sections is: Engineering changes analysis. The Figure 5-12 depicts the subsequent activities, token from the TO-BE Model already presented in Figure 5-11.

Materials selection and/or engineering

changes

Manufacturing process definition and

Manufacture partners selection

Engineering changes authorization


changes





changes




Figure 5-11 Selected activity to exemplify the Environment design (Step III)


77


Control at 25% of project execution

Commercialisation & Market analysisSourcing strategies

Product(s) identification

Request for quotation (RFQ)

Confidentiality agreement signature

Technical Information analysis & BOM definition

Materials selection and/or engineering changes

Manufacturing process definition and Manufacture

partners selection


Materials Availability and Quoting


Availability analysis and

QuotingQuotation generation

(Bid sending)Bid analysis

Negotiation Alternative analysis

Purchase order Re-design

Materials and/or standard components acquisition

Mtls/Std. Com. delivery

Manufacture

Additional process quoting

Assistance in production and

Quality controls

Product(s) delivery

Final inspection &

Supplier evaluation

Package and storageSpecial

Packaging providing

Final product delivery(Export)

Shipment service

Final product receipt(Import)

Product evaluation Feedback

Payment Financial management

Mtls./comp. Payments

receipt

ManufacturePayment(s)

receipt

process/service payment(s)

receipt

Mar

ket r

equi

rem

ents

Proj

ect p

lann

ing

Proj

ect e

xecu

tion

Cus

tom

er F

ollo

w-u

p

Customer Broker Alliances / ProvidersMaterials/components Manufacture Others

Integration to Broker’s alliances



Control at 50% of project executionControl at 75% of project execution

Control at 25% of project execution

Commercialisation & Market analysisSourcing strategies

Product(s) identification

Request for quotation (RFQ)


Technical Information analysis & BOM definition

Materials selection and/or engineering changes

Manufacturing process definition and Manufacture

partners selection


Materials Availability and Quoting


Availability analysis and

QuotingQuotation generation

(Bid sending)Bid analysis

Negotiation Alternative analysis

Purchase order Re-design

Materials and/or standard components acquisition

Mtls/Std. Com. delivery

Manufacture

Additional process quoting

Assistance in production and

Quality controls

Product(s) delivery

Final inspection &

Supplier evaluation

Package and storageSpecial

Packaging providing

Final product delivery(Export)

Shipment service

Final product receipt(Import)

Product evaluation Feedback

Payment Financial management

Mtls./comp. Payments

receipt

ManufacturePayment(s)

receipt

process/service payment(s)

receipt

Mar

ket r

equi

rem

ents

Proj

ect p

lann

ing

Proj

ect e

xecu

tion

Cus

tom

er F

ollo

w-u

p

Customer Broker Alliances / ProvidersMaterials/components Manufacture Others







Control at 50% of project executionControl at 75% of project execution

Figure 5-12 Product transfer TO-BE Model


78


As initial stage, the customer sent the Request for quotation (RFQ) to IECOS with some other RFQs. This project was high priority, because they wanted to transfer the manufacture to Mexico. An order was placed and the actual provider’s price was far beyond any acceptance. The information was received electronically and the analysis started with geometrical and materials analysis.

The BOM analysis identified three kinds of standard RST profiles (RST: Rectangular Structural Tubes). Table 5-5 specifies the European standards detailed in the drawings for these profiles: Table 5-5 European Standard for case study RST profiles and their equivalences

Original specification (mm) Equivalence in Inches

RST 2 Thk. x 20 x 40 PTR 0.079 Thk. x 0.7874 x 1.5748 RST 3 Thk. x 40 x 60 PTR 0.118 Thk. x 1.5748 x 2.3622 RST 4 Thk. x 40 x 80 PTR 0.157 Thk. x 1.5748 x 3.1496

IECOS foresee a first engineering change, with the selection of a RST

standard profile in the national market. For that reason, a parametric 3D model was drawn in a CAD system, in order to continue with the analysis, and wait for the changes authorization. With the parametric model, the profiles could be easily changed, and the new model and drawings will be automatically modified, reducing time and re-design costs.

About materials, Table 5-6 shows the original design materials and their equivalences: Table 5-6 Case study Material and their equivalences

Original specification Equivalence A65 Al 5556 E24 ASTM A284 Grade C

XC38 AISI-SAE 1040 Z30C13 INOX 420

Some of them were not commercial within the national market. The aluminum

components were the most important parts, which are A65 (regarding original


79


design). However, the equivalence according to the standards was Al5556, which is not commercial in our market. After the analysis it was determined that the corresponding material with slightly exceeding properties was the Al 6061. That aluminum is commercial in North America, but the dimensions of the RST were European standard based.

As a matter of fact, engineering activities where carried out, in order to measure the impact on the potential engineering changes. The change on material and standard profiles won’t impact only in the materials properties, but also in the measures of standard profiles. Thus, a 3D parametric model must be built in order to evaluate jointly with the customer, the geometrical impacts as well. The Figure 5-13 shows the 3D solid model of the Pick-up tool for the engineering changes evaluation, and afterwards, past the information as an improved manufacturing drawing.

Figure 5-13 3D solid model of the Pick-up tool

In parallel, the manufacturing process was analyzed and the suppliers

selection was carried out based on the companies database and the ranking regarding competences and previous performance. The RFQ for the selected suppliers was sent and the materials were quoted in USA.


80


Finally, a very good price for the manufacture was offered (even more competitive than European providers), but the material must be imported and the price increases. For that reason a Virtual meeting with the customer was carried out, and they tried to look for better prices in Europe. In a first iteration, a good agreement was made with the customer; where they get the responsibility to place the material in Mexico. After other iteration they found out that material standard plates where bigger than needed and the scrap will be high (because low volumes wont allow using the complete plate)

The Mexican metal-mechanical industry was set up with American standards.

That means plate dimensions (Thickness) were established in inches, as well as RSTs and other types of bars and tubes. Changing the original design in order to adapt these materials was not an option for the customer. For that reason, they decide to purchase the product in Europe, regardless the extra cost they will incur in, not just due to the high manufacturing costs, but also because of transportation and customs fees.

5.3.2.3.1 Step III.1 – MODEL

Based on the assessment made to the TO-BE model, the identified domains will be very helpful for the Workflow construction. The Figure 5-14 shows the four domains, for the selected activity to be detailed through these steps.

065 Customer sends the purchase order

Re-design (if needed) 066 Generate a parametric 3D model (with parametric

drawings) It is useful especially for the units translation. The model will be adjusted to the new dimensions

067 Validation with the client

068 Authorization signed by the client, to distribute the new drawings to the manufacturing providers

069 Drawings and technical information release

Materials and standard components acquisition

070 Purchase the material(s) or component(s)









































Inputs Outputs• Materials

information• Original

Drawing and BOM

• 3D model• CAD Drawings• Modified BOM• Engineering

changes proposed



Drawing and BOM

• 3D model• CAD Drawings• Modified BOM• Engineering

changes proposed

CEO IECOS

Supply ServicesCoordinator

Technology ServicesCoordinator

Engineering & Const.Coordinator

Project Managers Project Managers Project Managers

CEO IECOS





Support STAFF & AlliesEngineers, Technicians,

Partners, Allied Enterprises & Engineering Companies

Support STAFF & AlliesEngineers, Technicians, Construction Partners

CEO IECOS





CEO IECOS





Support STAFF & AlliesEngineers, Technicians,

Partners, Allied Enterprises & Engineering Companies

Support STAFF & AlliesEngineers, Technicians, Construction Partners

Information


Process

Figure 5-14 TO-BE assessment for the selected activity


81



82

The Process domain is taken from a detailed description of the activities

carried out on the analyzed process. A table with the detailed description of the activities for this case study can be found in the Appendix D. For the selected activity, the information used and resulting must be identified also, as well as they storage specification and future/previous use. The technology domain is analyzed in the next step. Finally the human resources are assigned to the activities, and managers and coordinators are also defined.

The Workflow modeling is carried out, after the identification of the whole set

of activities from the process model, The Figure 5-15 shows the modeled workflow for the Landing Gear product transfer complete process. Each of the activities has assigned responsible, due dates, required computer tools, and some other features.

Figure 5-15 Workflow model for product transfer (in LotusWF TM)

5.3.2.3.2 Step III.2 – INTEGRATE Based on the Technology Domain analysis from the TO-BE model

assessment, the applications and tools to support the Product Transfer Process are now identified. An analysis of the Functional tools has to be carried out in


order to identify those Web-based applications (open source, or linked applications), and Stand alone applications which will support other specific activities into the engineering life cycle of the product Transfer scenario. This analysis is performed in order to evaluate which functional tools are able to be merged in the environment, or if just a reference to its use will be required.

The Figure 5-16, shows the applications used in the specific case of the

“Engineering changes” activity. The technologies usually used for executing this activity are CAD/CAM/CAE applications, but they are generally joined with communication tools with the customer (or another engineering partner) such as chat (or in such a case, video/audio conferencing), file transfer for accessing and sharing information and knowledge. Applications’ sharing (or viewing) is important on engineering activities, when partners must interact on specific problem solving. The conjunction of all these tools can avoid face-to-face meetings or expensive phone calls, unless the situation definitely requires it


changes





changes





changes




(Telephone)Broker

Engineering Team

Customer Engineering Department

ChatVideo/audio

InternetWorkstation

CAD:3D Model

PDMViewingFile

transfer

Broke

r



Drawing and BOM

• 3D model• CAD

Drawings• Modified

BOM• Engineering

changes proposed



Drawing and BOM

• 3D model• CAD

Drawings• Modified

BOM• Engineering

changes proposed

Project leader

t Q

$t Q

$t Q

$t Q

$

t Q

$t Q

$

Figure 5-16 Applications identification in the Product Transfer Engineering

changes activity

In the Appendix E from this thesis, in the section E.3, a set of WebSphere

applications are described, complementing the Table 5-7 which summarizes the applications to be integrated in the Product Transfer CeEE.


83



84

Table 5-7 CeEE based on WebSphereTM tools



IBM

Web

Sphe

reTM

IBM - PLM tools which are stand-alone: CATIA DELMIA Additional stand-alone softwares: (e.g. QFD, IDEF, AMEF) Web-based tools can be included into the WPI-Portal

Database DB2 SmarTeam

Lotus QuickPlace Team WorkPlace Lotus SameTime Instant Messaging Lotus Collaborative Center Lotus Domino Server

MQ Series: - MQ Workflow - MQ Integrator

HOLOSOFX Lotus Domino Server

5.3.2.3.3 Step III.3 – CONNECT In the Product Transfer Process, especially in the Engineering changes

activities, the customer gives to its suppliers the product information (Drawings and BOM) in a image format (*.tiff), as shown in Figure 5-17. That’s why the Engineering changes activity is important, because that information is translated to a 3D model, in order to evaluate the impact of the engineering changes. For that reason the exchange Formats are considered important, because the information is received in a “plain” format and it is converted in a “information format” (3D CAD model). Therefore, the customer and suppliers applications must be considered in order to generate a standard format, and evaluation how subsequent activities will interact with this information. That is because a TIFF format goes in and a CAD format (e.g. STEP, if CAD systems are not compatible) goes out.

Another connectivity issue could be the FTP access for accessing product

information from the customer. This can be considered into the integration functions from Step III.2 in order to evaluate the potential integration of this access into the CeEE. Likewise, the suppliers information is important, for example materials catalogues which are constantly revised in engineering changes activities.


Customer

Specif.

BOM

Supplier

Print-Drawing(*.Tiff)

• Web-databases• Catalogues• Availability


changes





changes





changes




• 3D Modelling• BOM analysis

� Materials� Standards

Figure 5-17 Information exchange in Engineering changes activity from Product transfer process

5.3.2.3.4 Step III.4 – MONITOR In this monitoring phase, the definitions of “what” to monitor is defined but it is

not monitored yet. The measurable parameters are defined in order to allow managers to coordinate, track and control the process in the execution phase of the Product Transfer.

The Figure 5-18 shows how it has to be considered the project plan (or the

workflow model), in order to have a guide for associating all the measurable data. For example the resources involved in each activity (human and technological), which are important for cost estimations (important measurable parameter) and also for workload analysis. Furthermore, assigned dates and time are analyzed, in order to control delays or precedence problems based on unfinished activities. Similarly, the Input and Outputs from the activities are parameters to be controlled, in order to manage the information flow as well as availability for further activities, being an important issue to avoid delays or lack of information to perform the business process activities.


85


Project leaderProject leader t Q

$t Q

$Customer requirements:• Cost• Time• Quality

OI

Milestones

Resources

Deliverables:• BOM• Modified CAD• Drawings• DocumentationEngineerEngineerModelerModeler

Hr/Week = $$

TimeKnowledgeor skills = Quality

Technology = $$Materials selection and/or engineering

changes





changes





changes




Figure 5-18 Performance measures definition in engineering changes activity

In the special case of the engineering change activity from the product

transfer scenario, the customer demands Time, Quality and Costs. That measures must be translated to the execution process, making important to control variables such as: Modeler and engineers time dedicated to the specific project (impacts on Cost, and time), Systems used, like CAD systems (Impacts on Cost), Modeler Years of experience (will impact on the model quality, and less time consumption).

5.3.2.4 Step IV. Execute In order to explore better alternatives and more powerful technologies, The

WebSphereTM family from IBM has been identified. For the “Global Collaborative e-Engineering Environment” the technology architecture and the Application architecture is the IBM WebSphere Software product approach.

In the Appendix E from this Thesis, a description of the IBM-WebSphere

technologies is detailed. The first part describe the Technology and Application Architecture, the second part is very important, because it describes the High-


86


level overview of the WebSphere platform, which will be important to understand the proposed architecture for the Collaborative e-Engineering Environment, and the third part describes the Applications to Implement CeEE Architecture from this case study.

The WebSphere family offers products, tools and technologies with capacities to cover the defined requirements. This shows a high-level overview of the WebSphere platform helping to support and to integrate the Taxonomy of Computer applications. WebSphere is based on infrastructure software (middleware) designed for dynamic e-business, providing solutions for connecting people, systems, and applications with internal and external resources. The Figure 5-19 presents the architecture definition to build the CeEE defined in this scenario.

WebSphereStudio

IntelliStation Power 9114-275 AIX 5L IBM IntelliStation M Pro Windows XP

Computer and Network

CATIA P3

DELM

IALotus SameTimeInstant Messaging


Lotus SameTimeInstant Messaging


Lotus Collaborative Center Lotus Domino Server

WebSphereMQ Series

WebSphere Portal Extends

Foundation & ToolsWebSphere Application

Server

MQ

WorkFlow

MQ

Integrator

Integrator

DatabaseDB2

SmarTeam

FunctionalFunctional

Other Applications

Coordination

Collaboration

Knowledge / Information Management

TCP/IP, HTTP, SSL

LANInternetInternet

Figure 5-19 CeEE architecture with WebSphere Technologies.


87


Due to the specialized knowledge required for the implementation of the

environment on WebSphere, The scope of the thesis will be at the level of the environment design, and the proposed architecture in order to be implemented by a computer systems expert. At the same time, the IBM specific technologies are described in the Appendix E from this Thesis, in order to have defined the functionality of the platform.


88


Chapter 6. Results and Conclusions 6.1 Results After the execution of this research, the next results were achieved:

• A methodology for the design and integration of Collaborative e-Engineering Environments (CeEEs) in order to be transferred to the industry to support collaborative group-work in engineering services.

• A proposed Taxonomy for Computer Applications Classification that supports integrated Product/Process/Facility development, allowing engineers, users and project managers to classify and determine the required computer tools to support their work activities

6.2 Conclusions:

• For the creation of CeEE, the applications taxonomy allows the identification of the necessary tools that engineers needs as a minimal support in their engineering activities execution.

• Not all the activities require collaboration supporting tools, but all of them require the exchange of information and knowledge. The methodology allows the evaluation of all the activities in order to define which are necessary to be automated or supported by collaborative tools

• The functional tools are used for support specific engineering activities, and are selected according to the engineering tasks, while coordination, collaboration and Information management are platforms generalized to the whole engineering lifecycle

• The integration of applications and tools from early engineering life cycle stages will depend on the company requirements model. With the CeEE integrated approach, the use of computer supported tools can be balanced throughout all the stages of the engineering life cycle, where


89


advanced computer tools (from advanced engineering life cycle stages) are more commonly used.

• The experiences in developing CeEE have shown that the technologies may not be an obstacle in the collaboration efforts of the enterprises. Companies can interact with their engineering partners (between employees or company’s partners) without the need of the most advanced and complex technologies. The collaboration can be used only for critical activities within the companies engineering life cycle.

• A CeEE can be designed to cover the complete engineering life cycle (From early to advanced engineering stages), or a light version can be built to support specific activities.

• The engineering activities are usually performed in heterogeneous environments. Therefore, is important to consider the aspect of connectivity through the definition of standard ways of connections to allow information and knowledge share.

• As shown in Figure 6-1, and jointly with the action research cycles, the author was able to notice that scenarios must be defined first, and then a CeEE shall be designed to meet the engineering needs. Not define first the CeEE and the force the scenarios to fit or work efficiently in it.

• A CeEE is not worth to be integrated, without a defined scenario. The industrial requirements will drive the Environments functionality according to the companies needs.

First:

First:

• Freeware tools

• Php groupware

• High-Tech product development

• Educational program

• Product Transfer• Technology transfer• New Product

Development

• IBMTM

WebSphere tools

Figure 6-1 Recommended sequencing for CeEE design


90


• It is necessary to identify the scenario (company requirements), prior to define and configure the CeEE (with pre-evaluated technologies) and not to develop an environment without concerning about the industrial content (or defined methodology), because idle technologies will appear.

• Related to the application of Action Research, it can be concluded that cycling process of execution and reflection, allow identification of improvements for Technologies as well as for the automated process in execution (workflow).

6.3 Further research: After the experiences developing CeEE based on the action research approach, new opportunities for further research were identified. The main field is the technological implementation of CeEE. This is a field which requires specialized knowledge in computer science and Web technologies. The scope of the current research work covers the conceptual level of CeEE design, and the proposed architecture for further implementation, based on experiences in the environments execution. However there is an open research line, in the technical configuration and investigation on technological platforms to improve the CeEE performance. Another important research field that has been identified is the costs and benefit analysis implementing and executing CeEE. This is an important issue to tackle, in order to allow industrial partners to evaluate brake-even point, balancing the CeEE as a supporting tool, against executing the integrated product/process/facility design developments through traditional engineering. This research line should be executed as a fourth action research cycle, where the feedback should be focused on the implementation of CeEEs evaluating performance and costs from the integrated applications, in order to allow the planning of a fifth Cycle if it is necessary. The use of action research as a way of improving the different designs and implementations of CeEE, will allow improvements not only in the Technological field, but also in the content field (Process Improvement).


91



92

References Aca J., Mejía R., Velandia M., García E., Galeano N., Ahuett H., Molina A., Wright P., “Integrated Product Development in Virtual Enterprises Supported by Web-based Applications”, in Process and Foundations for Virtual Organizations, L.M. Camarinha-Matos, H. Afsarmanesh (Eds.), Kluwer Academic Publishers, pp. 361-268. 2003.

Al-Ashaab A., Molina A., Valdepeña T., “Marco de trabajo para la introducción e implementación de ingeniería concurrente”, (Reference framework for the introduction and implementation of Concurrent Engineering), Transferencia, Año 13, Número 51, pp. 23-25, Julio-2000, (in Spanish).

Bacheldor, B. and Kontzer, T. “PLM-more than just ERP or SCM”. Asia Computer Weekly. Singapore: pg. 1, Jul - 2003.

Bly et al., Media spaces: bringing people together in a video, audio and computing environment commune, The Journal of the ACM, vol. 36, Issue 1. p.p. 28–47. 1993.

Bochenek, G.M.; Ragusa, J.M.; "Virtual collaborative design environments: a review, issues, some research, and the future”. International Conference on Management of Engineering and Technology. PICMET '01. Portland, 2001

Bowling, A. “Research Methods in Health”. Buckingham: Open University Press. 1997.

Browne, J., Hunt, I., Zhang, J. The Extended Enterprise. Handbook of Life Cycle Engineering – Concepts, Models and Technologies. Kluwer Academic Publishers, Great Britain, 1998.

Chlebus, E., Cholewa, M., Dudzik, R. And Kozera, M. „Cax application for process oriented concurrent design“. Journal of Materials Processing Technology, Vol 76. p.p. 176-181. 1998

Chung, J. and Lee, K. “A framework of collaborative design environment for injection molding”. Computer in Industry. Vol 47, Issue 3. p.p. 319-337. 2002.

Clough, Gary, “NASA STEP Central: Information for NASA Engineers on the use of STEP (ISO 10303) for CAD/CAM/CAE Data Exchange”, http://step.nasa.gov, 1999.

Cooper G. Robert, “Winning at new products, Accelerating the Process from Idea to Launch”, Addison-Wesley Publishing Company, Second Edition, 1993.

Crane, P. and Richardson, L. “Reconnect action research kit” Reconnect Action Research Committee and Reconnect Services, Canberra: Commonwealth Department of Family and Community Services, Youth and Students Branch. 2000.

Daft R. and Wiginton J., “Language and Organization”, Academy of Management Review. Vol. 4, No. 2, pp. 179-191. 1979.

Deborin, E., Basrai, J., Benedetti, T., Halchin, R., Mahfouz, T., Perera, N., Shamshabad, B., Spory, R. and Turakhia, R. “Continuous Business Process Management with HOLOSOFX BPM Suite and MQSeries Workflow”. IBM-Redbook SG246590, 2002


Dick, Bob “A beginner's guide to action research” [On line]. Available at http://www.uq.net.au/action_research/arp/guide.html, 2000.

Dick, Bob “Action research: action and research” In the seminar: "Doing good action research" held at Southern Cross University, February 18, 2002

dVISE, 1999 - http://www.division.com/products/products.htm

Dym, C. and Little, P. “Engineering Desing: A Project-Based Introduction”. Ed. John Wiley & Sons. 2000.

Ellis, et al., “Groupware: some issues and experiences” The Journal of ACM Transactions on Information Systems, Vol. 34, No.1. p.p. 39–58. 1991

Flores M., Molina A., “Virtual Industry Clusters: Foundation to create Virtual Enterprises”, in Advanced in Networked Enterprises - Virtual Organizations, Balanced Automation and Systems Integration, L.M. Camarinha-Matos, H. Afsarmanesh, Heinz-H. Erbe (Eds.), Kluwer Academic Publishers, pp. 111- 120. 2000.

Gao, J. and Bowland, W. “A Product data management integrated product configuration and assembly process planning environment.” Proceedings of the Institution of Mechanical Engineers; 216, 3; Wilson Applied Science & Technology Abstracts PlusText. p.p. 407. 2002

Gott, B. Empowered Engineering for the Extended Enterprise – A Management Guide, Cambashi ltd., Cambridge, England. 1996.

Hales, Crispin. “Managing Engineering Design”, Longman Scientific & Technical”, First edition, 1993.

Hanneghan, M., Merabti, M. and Colquhoun, G. “CONCERT: a middleware-based support environment for concurrent engineering”, in: I. Horvath, A. Taleb-Bendiab Eds. , Proceedings of 2nd International Symposium on Tools and Methods for Concurrent Engineering TMCE’98 , Manchester Metropolitan University, UK, pp. 446–455. 1998.

Harrison, J.P. “Virtual collaborative simulation environment for integrated product and process development”, IEEE International Symposium on High Performance Distributed Computing, Proceeding 1996, 6-9, pp. 19-22. August-1996.

Haviland, 1998 - The Haviland Consulting Group, http://www.fmeca.com/

Heckel, J., Ganeshan, R., Case, M., and Baskin, A. “The Virtual Workspace System (VWS): An Enabling Technology for Collaborating Engineering Applications” IEEE, 1997

Hollingsworth, D. “Workflow management coalition specification: the workflow referente model”. WfMC specification, 1994

Huang, G. and Mak, L. “Agent-based Collaboration Between Distributed Web Applications: Case Study on Collaborative Design for X, Using CyberCO” Concurrent Engineering: Research and applications, Vol. 10, No. 4. p.p. 279-290. 2002

Huang, George Q. “Web-based support for collaborative product design review” Journal of Computers in Industry. Volume 48, Issue 1. p.p. 71–88 , 2002.

Hyerim Bae, Yeongho Kim. “A document-process association model for workflow management” Journal of Computers in industry. Vol 47, Issue 2. p.p. 139-154, 2002


93


Iacocca Institute, Lehigh University “21st Century Manufacturing Enterprise Strategy An Industry-Led View”, Volume 1 & 2, November 1991.

Iversen, J., Mathiassen, L. and Nielsen, P. A. „Managing Risks in Software Process Improvement: An Action Research Approach”. Submitted to MISQ. 2002.

Kao, Y.C. and Lin, G.C.I. “Development of a collaborative CAD/CAM system”, The Journal of Robotics and Computer-Integrated Manufacturing. Vol. 14, Issue 1. p.p. 55–68. 1998.

Keller. S. P. “Simulation-based acquisition: Real world examples” Army RD&A, pp 25-26, Sep-Oct, 1998.

Kemmis, S. and McTaggart, R. “Como planificar la investigación-acción” translated from “The action research planner”, third edition. Victoria: Deakin University. 1992.

Krause, F.-L., Kimura, F., Kjellberg, T. and Lu, S. C.-Y. “Product Modelling”. Annals of the CIRP, Vol. 42, Issue 2, 1993.

Kydd, C. T. and Ferry, D. L. “Electronic mail and new methods for measuring media richness,” Proc. Assoc. Inform. Syst. (AIS), pp. 246–248, Aug. 1995.

Lancioni, R., Smith, M. and Oliva, t. “The role of the Internet in supply chain management”, Industrial Management. Vol. 29. p.p. 45-56. 2002.

Lococo, A., and Yen, D.C. “Groupware: computer-supported collaboration, The Journal of Telematics and Informatics. Vol. 15, Issue 1-2. p.p. 85–101. 1998.

Machover, Carl. “The CAD/CAM Handbook”, The McGraw-Hill Company, First edition, 1995.

McGee, L. “Communication channels used by technical writers throughout the documentation process,” IEEE Trans. Prof. Commun, vol. 43, no. 1, pp. 35–50, 2000.

Mejia R. and Molina A. "Virtual Enterprise Broker: Process, Methods and Tools", in Collaborative Business Ecosystems and Virtual Enterprises (L.M. Camarinha- Matos Ed)., Kluwer Academic Publishers, pp. 81-90. 2002.

Mejía, R., Aca, J., García, E. and Molina, A. “E-Services for Virtual Enterprise Brokerage”, in Knowledge and Technology Integration in Production and Services, V. Marik, L. Camarinha-Matos, H. Afsarmanesh (Eds.), Kluwer Academic Publishers, pp. 141 – 148. 2002

Mitschang, Bernhard. “Data propagation as an enabling technology for collaboration and cooperative information systems” Computers in Industry, Volume 52, Issue 1, Pages 59-69. Sept- 2003.

Molina A., Acosta J.L., Al-Ashaab A., Rodriguez K., "Web-based information model to support product development in Virtual Enterprises", in Digital Enterprise Challenges – Life Cycle Approach to Management and Production, George L. Kovács, Peter Bertók, Géza Haidegger, (Eds.), Kluwer Academic Publishers, pp. 284-295. 2001.

Molina A., Bell R., “Reference Models for the Computer Aided Support of Simultaneous Engineering”, Int. J. Computer Integrated Manufacturing,Vol. 15, No.3, pp 193-213., 2002.

Molina A., Ellis T.I.A, Young R.I.M, Bell R., "Modelling Manufacturing Capability to Support Concurrent Engineering", Concurrent Engineering: Research and Applications, Volume 3, Number 1, pp. 29-42. March 1995.


94


Molina A., González D., “IMMPAC: A Methodology for the Implementation of Enterprise Integration Programmes in Mexican SMEs”, in Enterprise Engineering and Integration: Building International Consensus, K. Kosanke and James G. Nell (Editors), Springer, pp. 431-438. 1997. Molina, A. “methodology for integrated product, Process and manufacturing system design” in the Seminar of e-Engineering: the future of the Engineering, EGADE, ITESM, Nov – 2003.

Molina, A. and Bell, R. “A manufacturing representation of a flexible manufacturing facility”, Proceedings of mechanicals engineers, Vol. 213, part B. pp. 225-246. 1999.

Molina, A., Ponguta, S., Bremer, C. and Eversheim, W. “Framework for global virtual business” Agility & Global competition, Vol. 2, No. 3, p.p. 56-69. 1998

NIST, 1993 - http://www.idef.com/idef0.html

Oliveira, J., Moreira de Souza, J., Strauch, J. and Marquesa, C. “Epistheme: a scientific knowledge management environment in the SpeCS collaborative framework”, Computers in Industry, Volume 52, Issue 1, Pages 81-93. Sept-2003.

Palady P., “Failure Modes & Effects Analysis”, Pt Pubns, September 1995.

PIVOTAL, 1999 - http://www.centricsoftware.com/html/news/index.html

QFD Institute, 1993 - http://www.qfdi.org/

Qian, F and Shenseng, Z. “Product development process management system based on P_PROCE Model”. Concurrente Engineering: Research and applications. Vol. 10, No. 3. p.p. 203-211. Sept-2002.

Qina, S.F.,. Harrisonb, R., Westb, A.A., Jordanovc, I.N., Wrighta D.K. “A framework of web-based conceptual design”. Computers in Industry Vol 50, Issue 2, p.p.153–164, 2003.

Rahman et al., Application of multimedia technology in manufacturing: a review, The Journal of Computers in Industry, Vol. 38, Issue 1. p.p. 43–52. 1999.

Rapoport, R. “Three dilemmas in action research”. Human Relations. Vol. 23. No. 5. pp.499-513. 1970.

Revelle J. B. Revelle, Moran J.W and Cox C., The QFD Handbook, John Wiley & Sons, January 21, 1998.

Riboulet, V.; Marin, P.; Leon, J.-C.; “Towards a new set of tools for a collaborative design environment” The 7th International Conference on Computer Supported Cooperative Work in Design, 2002.

SECOFI-Sistema de Información Empresarial Mexicano, Estadísticas Sectoriales, Sector Externo, Fracciones arancelarias: 848071, 848041, 848079, 820730 (http://www.secofi-siem.gob.mx/siem1999/). 1999.

Shen, Weiming. “Editorial of the special issue on knowledge sharing in collaborative design environments”, Computers in Industry, Volume 52, Issue 1, Pages 1-3. Sept-2003.

Shu, L. and Flowers, W. “Teledesign: groupware user experiments in three-dimensional computer-aided design”, The Journal of Collaborative Computing 1. p.p. 1–14. 1994.

Tamine, O. and Dillmann, R. “KaViDo—a web-based system for collaborative research and development processes” Computers in Industry, Volume 52, Issue 1, Pages 29-45. Sept-2003


95


Tay, F.E.H and Roy, A. “CyberCAD: a collaborative approach in 3D-CAD technology in a multimedia-supported environment” Computers in Industry Vol. 52, Issue 2. p.p. 127–145. 2003.

Tian, G.Y.; Taylor, D.; "Design and implementation of a Web-based distributed collaborative design environment”. Proceedings, Fifth International Conference on Information Visualisation, 2001.

Tipnis V.A., "Evolving Issues in Product Life Cycle Design: Design for Sustainability", Chapter 13, in Handbook of Life Cycle Engineering: Concepts, models and technologies, Edited by A. Molina, A. Kusiak and J. Sanchez, London, Kluwer Academic Publishers, pp. 399 - 412. 1999.

UOP (The University of Phoenix): www.seanet.com/~daveg/glossary.htm

Van Luxemburg, A. and Ulijn, J. “The contribution of different communication media to an effective design process between a company and its customer: communicative and cultural implications of 5 Dutch cases”. IEEE transactions on professional communication, 2002.

VEB, 2001 - Virtual enterprise Broker - www.iecos.com.mx

Vesterager, Joahn, Bjorn, Lars. Gobbi, Chiara. Architecture and Methodology for Creating Virtual Enterprises – Results from Globeman21. Paper presented at the IMS Globeman21 Open Day, TIME24. Tokyo, Japan. March 1999.

VIC, 2000 - Virtual Industry Clusters - www.Industry-clusters.com

Wang L., Shen W., Xie H., Neelamkavil J. and Pardasani A. “Collaborative conceptual design – State of the art and future trends”. Journal of Computer Aided Design, Volume 34, Issue 13. Pages 981-996.November 2002.

Wanga, Y., Shena, W. and Ghenniwab, H. “WebBlow: a Web/agent-based multidisciplinary design optimization environment” Computers in Industry, Volume 52, Issue 1, Pages 17-28. Sept-2003.

Weck, M., Eversheim, W. , Konig, W. And Pfeifer, T., Production engineering – The competitive edge. Butterworth Heinenmann. 1991.

Wright, Paul Kenneth “21st Century Manufacturing”. Prentice Hall, 1st Edition. New Jersey, 2001

Zachman, J. A. “Enterprise Architecture - A Framework”, ZIFA- Zachman International. www.zifa.com. 2000.

Zuber-Skerritt, O. “New Directions in Action Research”. London: Falmer Press. 1996.


96

Ricardo Mejía Gutiérrez APPENDIXES

Appendix A. Collaborative Environments related research (Description)

MOSES - [Molina, et. al., 1995] MOSES (Model Oriented Simultaneous Engineering System) was a research project carried out by two groups, one at the University of Leeds (in the Department of Mechanical Engineering) and Loughborough University of Technology (in the Department of Manufacturing Engineering). The project was funded by the UK government (in the form of the EPSRC) and several industrial collaborators for a 3 year duration and started in May 1992. The project has a full title of: "Exploiting Product and Manufacturing Models in Simultaneous Engineering". Its concept is a two model CAE concept that supports Concurrent Engineering. It provides a source of product and manufacturing information and so aids data integrity, integration and conflict identification through a Product Model, an Engineering Moderator and Design for Manufacture/Manufacturing Model (as shown in Figure A-1).

Solid Modeller

Relationship Graph

Evaluator

Design for Assembly

Manufacturing strategist

Engineering moderator

Procedural knowledge

Base

Integration environment: Ptech Object-Oriented Conceptual Modelling Tool

Product Data

Model

Manu-facturing

model

Design for function Design for Manufacture Manufacturing Code Generation

Figure A-1 MOSES (Model Oriented Simultaneous Engineering System)


97


CONCERT - [Hanneghan, 1998] The CONCERT (CONCurrent Engineering suppoRT) is a middleware service

(Middleware: is a general-purpose service that sits between heterogeneous computer platforms and applications allowing multiple platforms to interact with a common application); playing an important role in supporting the process of Concurrent Engineering, which invariably requires heterogeneous platforms to interoperate.

The CONCERT architecture allows virtual team members to access these

middleware services via the Internet through cross-platform applications. The architecture consists of four main services: a Distribution Support Service (DSS) , a Collaboration Support Service (CSS) , a Project Support Service (PSS) and a Repository Support Service (RSS); along with a data object repository which is used to store all the data elements produced during the project life-cycle (see Figure A-2)

Wrapper

Platform 1

“Workbench”application

Third-partyapplication

Wrapper

Legacy application

Legacydatabase

OperatingSystem

Hardware

The CONCERT Architecture Middleware Services

Platform 2OperatingSystem

Hardware

Platform n

OperatingSystem

Hardware

Object Request Broker

Appl

icat

ion

Laye

r

Figure A-2 CONCERT (CONCurrent Engineering suppoRT) CyberReview - [Huang, 2002] Developed by the Department of Industrial and Manufacturing Systems Engineering, at the University of Hong Kong, the CyberReview is the development of a web-based framework, which works as a central portal for


98


supporting collaborative product design review between partners in the extended enterprise. This portal was designed under the systematic theory of axiomatic design review (STAR) the design review can be defined as a mapping process between the design objects and the review criteria. The portal provides a number of online facilities over the web to support various decision-making activities for design-review. Supported by the Review Coordinator, the Project Manager established a review team or committee specifying design documents to be included for review and preparing review documents. The design team uses the Design Explorer to upload the desired design documents onto the CyberReview repository. Generally asynchronous, individual members in the review committee use the Comments Explorer to carry out their reviews by submitting comments and suggestions to the CyberReview database. Finally, with the help of the Meeting Explorer, a review meeting is called upon to resolve the comments from individual members. This last step is generally synchronous.

Design Team Cyber Review Review Team

Upload:Design DocsVRML files

Preparation:PersonnelDocumentsProcedure

Download:Design DocsVRML files

CoordinatorExplorer

DesignExplorer

CommentsExplorer

FormsExplorer

MeetingExplorer

View CommentsSubmit Comments

Common FormPrivate Form

DiscussionMale Conclusion

ReviseDesign

orComplete

Design

Design Team Cyber Review Review Team

Upload:Design DocsVRML files

Preparation:PersonnelDocumentsProcedure

Download:Design DocsVRML files

CoordinatorExplorer

DesignExplorer

CommentsExplorer

FormsExplorer

MeetingExplorer

View CommentsSubmit Comments

Common FormPrivate Form

DiscussionMale Conclusion

ReviseDesign

orComplete

Design

Figure A-3 CyberReview Framework Web-based conceptual design - [Qina, et. al., 2003] This system has four processes developed which enable these online sketches interpretation:


99


• 2D and 3D geometry: on-line freehand sketched input is interpreted as 2D

and 3D geometry, which geometrically represents conceptual design. • Extract 3D hierarchical configurations: The system then infers 3D

configuration by analyzing 3D modeling history. The configuration is described by a parent–child hierarchical relationship and relative positions between two geometric components.

• VRML-based behavioral simulations: In order to verify the conceptual design of a product, the behaviors can be specified interactively on different components.

Unfortunately, conventional CAD systems do not readily support this conceptual design processes, due to complete, concrete and precise definition of the geometry usually required, which are only available at the end of the design process. CyberCAD - [Tay and Roy, 2003] CyberCAD can be defined as ‘‘inexpensive, user-friendly and Web-interactive CAD software to allow professionals and laymen alike to develop 3D models to support synchronous collaboration among geographically dispersed users.’’ Developed under JavaTM, CyberCAD became object oriented, simple, robust, portable, multithreaded, platform independent, distributed and dynamic. 2D and 3D modeling operations are empowered by CyberCAD.Math and CyberCAD.Utility packages, which are actually composed of various classes for specific tasks. For example, the SolidModeller.class that is a core class of the utility package, is responsible for 3D modeling operations like extrusion, rotate, revolve and sweep among others. The CAD conferencing part is assisted by the network package that holds the basic structure of RMI, which is subsequently extended for supporting the videoconferencing module. The entire CyberCAD system requires several of packages and each package includes several numbers of JavaTM class files having similar functionality related to the package in which they reside.


100


Virtual Workspace System (VWS) - [Heckel, et. al., 1997] The Virtual Workspace System (VWS) provides a service for sharing state (both data and meta-data or schema) for asynchronous collaborating engineering applications. Key features are: (1) a reliable and platform independent message transport mechanism between client workspaces; (2) an ontological formalism for describing the content of collaborating workspaces, based on the object-oriented model and extending it with notion of constraints; (3) selective sharing based on interest; (4) ability to group events together into transactions; (5) support for conflict detection/resolution support; and, (6) collaboration policies that can be set at the object level (e.g., a user can be notified of changes to object of class C1 immediately, but not so for objects of class C2). The VWS System is being used to develop a collaborative application to support both design of facilities and maintenance management at the U.S. Army’s Fort Gordon. PDM-Tech system - [Chlebus, et. al., 1998] The PDM-Tech is system developed at the Institute of Production Engineering and Automation of the Wroclaw University of Technology. It can support every organization of data management and process structure of a company, for a wide spectrum of products. Information handled by the system (documentation, forms, sheets and instructions) is kept in a relational database, focusing on process oriented concurrent design. The PDM – Tech system links and synchronizes work on design and production engineering tasks and allows for creation and modification of diverse product design structures. The system supports generation of process plans for both conventional/manual and automatic/NC machining or assembly operations. CAD/CAM applications may be integrated with the system and may operate on data handled by a database management system. Epistheme - [Oliveira, 2003] To facilitate the exchange, share and dissemination of knowledge and its management, the Epistheme proposes a scientific knowledge management environment where researchers may share their data, past experiences, ideas


101


and get all the necessary information to execute their tasks, make decisions, collaborate with one another and disseminate knowledge. P_PROCE - [Qian and Shensheng, 2002] It is an integrated product development workflow model called P_PROCE mode. It serves as guidelines and constraint framework for workflow modeling. P_PROCE model is made up of five views. Each view can be considered as a submodel. They are process submodel P), product submodel (P), resource submodel (R), organization submodel (O), and control & evaluation submodel (CE). The process submodel is the core of the P_PROCE model. It is a product development process management system that integrates WFMS with PDMs, In order to manage the whole lifecycle of product development. The system can not only manage the product data, but also deal with the process information resource information, organization information, and control & evaluation information. It supports workflow modeling, workflow enactment and product design. In fact, it acts as an enabling tool of a CE project. dVISE - [dVISE, 1999] Is a product data visualization and simulation software that enables collaborations between designers and the engineers. It allows real time visualization and point of reference synchronization in a live review session so users are able to interact and redline 3D models. Users can create and edit virtual mockups and combine different parts from several CAD systems into a mockup of the product for review. dVISE support not only creation of real-time event based behaviors to simulate product functions, but also testing real time collision and clearance detection. Furthermore, it allows users to make and view virtual notes for design tracking, export mockups to MPEG movies and web-enables format for viewing. dVISE is available on Microsoft Windows NT, HP UNIX and IRIX platforms.


102


WebBlow - [Wanga, 2003] A Web/agent-based multidisciplinary design optimization environment, presents some results on the development of a distributed multidisciplinary design optimization (MDO) environment (called WebBlow) using a number of enabling technologies including software agents, Internet/Web, and XML. The objective is to provide a powerful solution for project managers and designers working on multiple design projects to share product information and knowledge, and to ensure the system security and mitigate the difficulties with firewalls. Software agents encapsulate the functionalities of the system, such as process simulation, performance simulation, and design optimization. XML is used for data management at the server side as well as for message exchanges among software agents. TOGA and CHAMPAGNE - [Mitschang, 2003] Collaboration in cooperative information systems, as occurring in concurrent design and engineering, exploits common work and information spaces, as the Transaction-Oriented Group and Coordination Service for Data-Centric Applications (TOGA) and the DataPropagator CHAMPAGNE which together realize a shared information space that is controlled by a basic collaboration service. Its approach enables the evolution of a set of separate applications to form a cooperative information system, and it can be exploited as a basic service within collaboration frameworks to effectively manage common work and information spaces. Workflow Management Systems realize process coordination and enactment especially for asynchronous work. This approach enacts coordination of synchronous work on shared data objects, but not directly the flow of work activities, since it is not process-oriented. PIVOTAL - [PIVOTAL, 1999] It is another important virtual collaboration solution which offers a collaboration prototyping and knowledge management tool. It focuses an product design so that designers and engineers can manipulate 3D models and own their


103


personalized data views in order to get the information they need. The user can perform model manipulation, real-time behavior test and design process simulations. Group discussion and collaboration are facilitated by real time audio, video and whiteboard conferencing with 3D annotation tools. PIVOTAL also supports model behavior activation, environment simulation and heterogeneous data incorporation. PIVOTAL runs on Microsoft Windows and UNIX platforms. KaViDo - [Tamine and Dillmann, 2003] Is a web-based system called Karlsruhe’s virtual documentation (KaViDo) tool for collaborative research and development. The objectives of KaViDo are to record and document development processes, to manage the competences of distributed experts, to exchange user experiences and to assist product development. It ensures for the fact that product information and construction knowledge are shared between the project collaborators. KaViDo is a browser-based tool. Its implementation is using web services. XML is used to exchange data between KaViDo and other applications. Deneb - [Harrison, 1996] Deneb Robotics Corporation developed a virtual collaborative engineering (VCE). Its system enables real-time, interactive collaboration which facilitates discussion and analysis of simulations over a global network. VCE allows users to interactively evaluate design concepts, manufacturing tooling, processes, and factory layouts in a dynamic simulation environment at geographically remote locations. VCE supports interactive model visualization, revision and manipulation during collaboration. Secure data transmission, simulation synchronization, interactive kinematics and collision detection, and independent machine synchronization are also core capabilities of VCE. VCE runs on Microsoft Windows NT and several UNIX platforms. (Deneb Robotics, Inc. is now Delmia Corp.)


104


CyberCO - [Huang and Mak, 2002] The cyberCO framework is built upon two essential concepts. They are agents and workflows. Agents are web applications with special purpose of representing domain web applications (TeleDSS) during the process of collaboration. The concept of workflow and its management is introduced to address the a type of interactions between the agents. The CyberCO framework has been implemented in a prototype web-based system. It includes two main modules: CyberAgents and CyberWorkflows which are themselves standard web applications with the standard 3-tiered architecture, except for their special purposes for defining and executing agents and workflows respectively. CyberCO has two working modes: definition and execution. Agents and workflows are first properly defined before they can be executed. Some other related research Most efforts in computer-supported cooperative work are concentrated on creating an environment for co-authoring, documentation and messaging. Examples of research and efforts on the transmission of two-dimensional graphics and text include the Media Space project at Xerox PARC [Bly et al, 1993], the Cruiser, Touring machine and projects at Bellcore and the Argo system at DEC [Rahman et al., 1999]. Some manufacturing-related research was also accomplished, such as, “VideoDraw” which was a video-based prototype tool for two-dimensional sketch drawings, ‘‘TOPES’’ which was for exchanging graphics, drawing and text, and “ClearBoard” which was designed to enable dispersed co-workers to draw with color makers or with electronic pens and software tools [Kao and Lin, 1998]. Other efforts resulted in “Teledesign”, explored for examining 3D-CAD groupware issues [Shu and Flowers, 1994] while ‘‘CrystalPad’’ was developed for the creation and revision of documents and ‘‘Shared 3D viewer’’ was developed for discussion on 3D-CAD geometry files [Kao and Lin, 1998].


105


Appendix B. Computer applications Taxonomy B.1) Functional Tools Those tools supporting specific tasks during the product development process are considered as “functional tools”. These tools support and enable the specific execution of a task or a group of tasks allowing the fulfillment of a partial objective within the objectives of the different stages of product development. These kinds of applications are often automations of methodologies or techniques. This means that every sequential and logical process performed to accomplish certain objectives, is able to be automated. In other words, such activity can be executed with a computer, making time and resources demand more efficient, as well as assuring quality in the objectives to be fulfilled.

Functional Tools based on Information

Functional Tools based on Models Use

Engineering life cycle Figure B-1 Functional Tools based on Information and based on Models through

Product engineering life cycle B.1.1 Functional Tools based on Information Most common used Concurrent Engineering tools have been commercially developed to generate computational applications facilitating their specific task execution and implementation. Some examples can be the QFD (Quality Function Deployment) [QFD Institute, 1993] [Revelle, 1998] which enables the transformation of costumers’ requirements into actions and design, allowing engineers to focus in content and activities within the QFD instead of documentation issues. For FMEA (Failure Modes and Effect Analysis)


106


[Haviland, 1998] [Palady, 1995], there are also computational tools to automate the systematical process of potential failure identification in a product design or in a process before these occur. FMEA can be considered as an standardized analytical method to detect and eliminate problems in a systematical and total manner. Same occurs with IDEF-0 (ICAM Definition Method Zero) [NIST, 1993]: There are software applications that automate hierarchical deployment, enabling systems definition at any number of detail levels, through the necessary level for required analysis.

QFD AMEFDFM/A

FunctionalAnalysis

MorphologicMatrix

FunctionsPerformanceBenchmarkingTargetsCorrelations

FunctionsBehaviorComponents

MechanismFunctions vsmechanismsPerformanceOperations

Fault TreeFault ScenariosCause-EffectsControls

Figure B-2 Functional Tools based on Information

These tools are methodologies which enable the accomplishment of specific tasks, and because of the availability of some commercial software tools, are possible to integrate them into an automated processes for project development. B.1.2 Functional Tools based on Models There are work-techniques that do not necessarily follow a sequence of activities, but also, are functional processes that support the product development cycle. The software tools for CAD/CAM/CAE are examples of these. CAD (Computer Aided Design) enables geometry definitions for mechanical parts, architecture


107


structures, electronic circuits, layouts, among others. The information is stored in a database, for later referencing and technical drawing generation. CAM (Computer Aided Design) systems provide information and instruction for automated machines in parts manufacturing, assembling and circuiting, using mainly CAD geometric information as start point. Computer Aided Engineering (CAE) is used to analyze CAD’s geometry, allowing simulation and forecasting product behavior, so the design can be refined and optimized [Manchover, 1995]. Within these engineering supporting systems, the evolution of the technologies have reached the Knowledge Based Engineering Systems (KBES) which allow the optimization, in time and quality, of engineering processes through the engineering knowledge structuring.

AdvancedDevelopment

BasicDevelopment

Launching

Conceptualization 2D Drawing2D Drawing

Solid ModellingSolid Modelling

Surface Modelling

WireframeWireframe

CAE – Computer Aided Engineering

CAM – Computer Aided Manufacturing

KBES – Knowledge Based Engineering Systems

Simulation for Electronic products

Electronic productsmodeling

Manufacturing Systems Simulation

Figure B-3 Functional Tools based on Models

B.2) Coordination Tools Design engineering is a process in which a requirement or idea is

transformed in the necessary information in order to develop a new product or system. Successful management of this process is summarized in the effective handling of three issues [Hales, 1993]: 1.) Activities of the design team (such as:


108


task planning, report revision/elaboration, cost estimation or information recovery), 2.) Outputs from the design team (is the analysis of measurable variables, being the performance measurements of the design team activities) and 3.) Influences on the design team (are those external forces which influence on the project or design team, such as: markets, customers, management changes, motivation and technological developments).

In project management and control, activities have to be guided and

monitored in terms of performance, while design outputs have to be continuously reviewed and assessed in terms of quality. The effect of influenced factors must be forecasted, monitored and controlled where possible. Thus, it is not only necessary to have planning tools, but also control and monitoring tools. Therefore, this kind of coordination applications are not only meant to be used in specific stages of development, but also in continuous monitoring of activities, execution control and effective planning of activities, resources, time and results.

Nowadays, there are many automation of these tools in the market; which

are developed computational tools and are commercially available. It is important to describe the different kinds of project to be managed and the skill levels of Project Management (PM) in order to mention some commercial Project Management related software tools. “The Hampton Group, Inc”, which is a specialized training and consulting corporation in the PM field, has proposed a PM classification for appropriate software selection:

A. Smaller projects largely within one functional area:

In this category the planning is based only in time rather than capacity analysis or budgeting. Project managers prompt plans, occasionally prepare status reports and produces simple GANTT y PERT diagrams. There is a very broad range of choices of software products that meets this capacity level, such as: TurboProject, Milestone Simplicity, Project Vision and Quick Gantt. Without reaching all its potential, Microsoft Project and Primavera's SureTrak may also be god choices.

B. Larger cross-functional projects for executives or clients: Budget is now an important issue in planning and tracking. Consequently project plans are built based on estimated work-hours and predecessor relationships, rather than only start and finish dates. The software builds more precise work plans, in which it budgets and schedules not only


109


internal employees, but also external consultants and vendors as well as budgeting for equipment and travel expenses. At this level, the market is even shared by Microsoft Project and Primavera Products.

C. Multi-project environment: Decision-makers can prioritize projects, allocate resources, schedule and track a set of people working on multiple projects. The software should be able to identify conflicting demands for the same resources as well as allow the executives to set priorities among projects that require the same resource. Detailed project budgets are created and have the software come pretty close to mimicking the company's cost accounting system. In this category, users often want sophisticated risk assessment tools, learning curve and resource loading features as well as detailed performance tracking. At this level, there several software tools, such as Microsoft Project (con Project Central), Primavera Project Planner and other products, Open Plan, Cobra, Enterprise PM, Micro Planner X-Pert.

B.3) Collaboration Tools

Collaboration tools enable the interaction between members of the teamwork

involved in the different stages of integrated products, processes or manufacturing systems development. Through the use of these tools it is possible to develop collaboration environments that facilitate remote activities execution. From these requirements emerged the concept of Collaborative Engineering, far beyond the individual intercommunication tools, integrating other tools such as functional, coordination and/or information management tools (As presented in the proposed Taxonomy, see Table 4-1 from Chapter 4 from this thesis).

The individual collaboration tools are communication engines that enable

interaction between members of a multidisciplinary design team. For this purpose, Web capability to publish information from the concept generation to the product realization and virtual manufacturing, has motivated the adoption of Internet as a collaborative design tool. Currently, it is playing an increasing major role in the systems development for product collaborative development. [Wang, et Al., 2002].


110


Thus, it is important to determine the communication and interaction

requirements through the life cycle of the projects. Visualization and virtual environments are critical for the next generation design and development, as well as to the local and remote collaboration, such as face-to-face meeting, telephone, teleconferences and videoconferences. Choosing of a good media depends on the quantity of explicit information that would be used in the activity, and has developed into an interesting media transference richness classification, as shown in Figure B-4 [Van Luxemburg and Ulijn, 2002]:

Documents FTP Letters E-mail Chat Telephone Face-to-Face

Netcasting Whiteboard/Document sharing Newsgroups Instant

messagingDesktop-

coferencingVideo-

coferencing

LOW HIGH

Documents FTP Letters E-mail Chat Telephone Face-to-Face

Netcasting Whiteboard/Document sharing Newsgroups Instant

messagingDesktop-

coferencingVideo-

coferencing

LOW HIGH

Figure B-4 Media richness in a cualitative escale

Due to this, nowadays collaborative tools are becoming more important for the interaction of work teams during the whole product development process. Thus, the selection of the most suitable media depends on the required interaction level for all activities, in order to efficient communication and collaboration through resources optimization. Table B-1 Traditional and Electronic communication systems

Synchronous Asynchronous

Traditional • Face to face • Telephone

• Letters • Documents • Notes

Electronics

• Video-conference • Desktop-conferencing • Chatting • Whiteboard • Shared files

• Instant messaging • e-mail • FTP (File Transfer

Protocol) • Newsgroup • Net casting


111


For selection, it is important to differentiate the “media richness” degree

offered by the different communication resources, which is determined by this four aspects [Kydd and Ferry, 1995]: 1) Immediacy of feedback, which is expressed as shown in Table B-1: synchrony and asynchrony, 2) Number of social cues, such as facial expressions, corporal language and voice intonation [McGee. 2000], 3) Extent of personalization, which determines the communication customization, and 4) Language Variety, writing or oral symbols associations used to communicate ideas, emotions or experiences, and the variety itself depends on how much information can be communicated [Daft y Wiginton, 1979]. B.4) Tools for information / knowledge Management

Historically, the most successful organizations have been driving their Information technologies investments on data acquisition, storage and processing, and finally their analysis and selective distribution. In the last decades the continuous introduction of new methods and technologies to improve information storage, communication, processing, security and analysis, (as well as the incremental availability of commercial tools and global communication improvements) have change the way of executing tasks, moving from complete manual processes (usually executed for high trusted employees) to the use of technologies known as computer tools for information and knowledge Management

The important base for knowledge management is the product and

manufacturing engineering information. Since these two models begins automated systems that generates computational tools for stocking, control and information distribution; allowing access to engineers and managers, and all related with product and/or processes development.

There are internet applications that are designed to allow product information

can be shared between certain work group in and out the enterprise. This is covered by the OEM’s (Original Equipment Manufacturing), supplier’s network, consulting and partners that involves product life cycle [Molina et. al., 2001]. The key of this context is the product and manufacturing information, as well as engineering knowledge.


112


The challenge is to allow the free access to all process stages of a particular product. The effort in the information modeling to support the product development is based in:

• Product model: The product model has to represent all the necessary

information during the life cycle such as a customers needs, design, fabrication, production, assembly, packaging, distribution and collecting/recycle/re-use [Krause et al. 1993]

• Manufacturing modeling: The manufacturing model must represent the technological and production capabilities. The information entities which define the Manufacturing information modeling are the resources, process, and strategies. The manufacturing and process resource describe the technological capabilities. Other issues are new strategies which represent the real capability of the enterprise. The manufacturing strategies represent the information that is specific for each organization. This information helps to identify resources and certain processes which aid in determining the strategy for the proposed enterprise. [Molina et. al., 1995] [Molina y Bell, 1999]

The evolution of the Information Modeling has lead to a new generation of developmental knowledge and information management technology. The advancement of robust systems has paved the way toward the integration and management of different information models, and others strategic enterprise systems. The most known tools in the actual market of information management are:

• PDM – Product Data Management: PDM Systems are tools that help engineers to manage data and product life cycle processes. These systems keep track of the huge amount of information required for and generated during the product life cycle. They ensure that live data are up-to-date and that old data are archived correctly, provide security measures and allow data to be property tracked and audited. The use of Work-Flow and process management allows an enterprise to define the ways in which changes may be made to product data, providing methods to route data automatically and to audit approval decisions. PDM tools often provide methods by which other software systems may use their resources [Gao and bowland, 2002].


113


• PLM – Product Life Cycle Management Due to automotive industry and others manufacturing companies like Aerospace and Electronics, emerge one of the most recent enterprises applications which is the Product Life Cycle Management, also known as “PLM”. PLM is much more than its predecessors, which had a heavy emphasis on computer-aided design and product data management. Newer PLM software is designed to help a company deliver a product and continually enhance it by helping it manage and automate materials sourcing, design, engineering change orders, product documentation such as test results, product packaging, and post-sales data. It can also help companies to handle through a growing number of local, state, federal, and international regulations. The software typically includes a centralized database that stores all product master records, bills of materials, design-history records, packaging and artwork data, and more. PLM can be integrated with ERP (Enterprise Resource Planning) and SCM (Supply Chain Management) in order to connect the information about the product with human resources, financing and forecasting. This allows a unifying vision and getting a better understanding of how a simple change in the design can affect the overall system. [Bacheldor and Kontzer, 2003]

It is important to have a good manage of the information throughout the process of product development, because is very important for a successful project. The upgraded and available information for the entire work group it is a requirement, facilitating decision making fast and reliable.


114


Appendix C. The IGES, DXF and STEP Exchange Formats

C.1) IGES (Initial Graphics Exchange Specification) IGES was the first specification for CAD data exchange published in 1980 as a NBS (National Bureau of Standards) report in USA. IGES version 1.0 was accepted and released in 1981 as an ANSI standard. All major CAD vendors support IGES and it is currently by far the most widespread standard for CAD data exchange. IGES was originally developed for the exchange of drafting data like 2D/3D wireframe models, text, dimensioning data, and a limited class of surfaces. Due to criticism and bad experience with the data transfer using IGES, the standard has been gradually extended and developed concerning supported entities, syntax, clarity, and consistency. The current version, IGES 5.2, provides the following capabilities:

• Geometry: 2D/3D wireframes, 2D/3D curves and surfaces, CSG (since version 4.0 in 1988), B- Rep (since version 5.1 in 1991);

• Presentation: Drafting entities for technical drawings; • Application dependent elements: Piping and electronic schematics, AEC

elements; • Finite Element Modeling: Elements for FEM systems.

IGES specification defines the format of the file, language format, and the product definition data in these formats. The product definition includes geometric, topological, and non-geometric data. The geometry part defines the geometric entities to be used to define the geometry. The topology part defines the entities to describe the relationships between the geometric entities. The geometric shape of a product is described using these two parts (i.e. geometry


115


and topology). The non-geometric part can be divided into annotation, definition, and organization. The annotation category consists of dimensions, drafting notations, text, etc. The definition category allows users to define specific properties of individual or collections of entities. The organization category defines groupings of geometric, annotation, or property elements. An IGES file consists of six sections: Flag, Start, Global, Directory Entry, Parameter Data, and Terminate. Each entity instance consists of a directory entry and parameter data entry. The directory entry provides an index and includes attributes to describe the data. The parameter data defines the specific entity. Parameter data are defined by fixed length records, according to the corresponding entity. Each entity instance has bi-directional pointers between the directory entry and the parameter data section. The size of IGES files and consequently the processing time are practical problems. IGES files are composed of fixed format records and each entity has to have records in both the directory entry section and the parameter data section with bi-directional pointers. This causes also errors in pre- and post-processor implementations. IGES is under control of the NCGA (National Computer Graphics Association) and is part of the U.S. Product Data Association (USPRO) and the IGES/PDES Organization (IGO). The NCGA administers the National IGES User Group (NIUG), which provides access to information on IGES. C.2) DXF (Data eXchange Format) DXF was originally developed by Autodesk, Inc., the vendor of AutoCAD. It has become a "de-facto" standard among most CAD vendors and is in wide use to exchange 2D/3D wireframe data. All implementations of AutoCAD accept this format and are able to convert it to and from their internal representation. A DXF file is a complete representation of the AutoCAD drawing database thus some features or concepts can't be used by other CAD systems. The DXF version R13 supports wireframe, surface, and solid representations.


116


A DXF file consists of four sections: Header, Table, Block, and Entity section. The header section contains general information about the drawing. Each parameter has a variable name and an associated value. The table section contains definitions of line types, layers, text styles, views, etc. The block section contains entities for block definitions. These entities define the blocks used in the drawing. The format of the entities in the block section is identical to entities in the entity section. The entity section contains the drawing entities, including any block references. Items in the entity section exist also in the block section and the appearance of entities in the two sections is identical. Variables, table entries, and entities are described by a group that introduces the item, giving its type and/or name, followed by multiple groups that supply the values associated with the item. In addition, special groups are used for separators such as markers for the beginning and end of sections, tables, and the file itself. Group codes are used to describe the type of the value, and the general use of the group. C.3) STEP (STandard for the Exchange of Product model data) STEP is a new International Standard (ISO 10303) for representing and exchanging product model information. It includes an object-flavored data specification language, EXPRESS, to describe the representation of the data. STEP defines also implementation methods, for instance, a physical transfer file, and offers different resources, e.g. geometric and topological representation. The development of STEP started in 1984 as a worldwide collaboration. The goal was to define a standard to cover all aspects of a product t (i.e. geometry, topology, tolerances, materials, etc.), during its lifetime. This kind of attempt was not been made before. STEP is a collection of standards to represent and exchange product information. The main parts of STEP are already international standards, while many parts are still under development. The development is performed under the control of the International Standards organization (ISO), Technical Committee 184 (TC184, Industrial Automation Systems), Subcommittee 4 (SC4, Industrial Data and Global Manufacturing Programming Languages).


117


The objective of STEP is to offer system-independent mechanism to describe the product information in computer aided systems throughout its lifetime. It separates the representation of product information from the implementation methods. Implementation methods are used for data exchange. The representation offers a definition of product information to many applications. STEP provides also a basis for archiving product information and a methodology for the conformance testing of implementations. EXPRESS is a formal data specification language used to specify the representation of product information. The use of a formal data specification language facilitates development of implementation. It also enables consistency of representation. STEP specifies the implementation methods used for data exchange that support the representation of product information. STEP does not only define the geometric shape of a product: it also includes topology, features, tolerance specifications, material properties, etc. necessary to completely define a product for the purposes of design, analysis, manufacture, test, inspection and product support. The use of STEP is still very modest but it is growing all the time. The majority of CAD system vendors has implemented or is implementing STEP pre- and postprocessors for their CAD systems. STEP is an evolving standard that will cover the whole product life cycle in terms of data sharing, storage and exchange. It is the most important and largest effort ever established in engineering domain and will replace current CAD exchange standards.


118


Appendix D. Process Domain for Cycle 3: Product Transfer Case Study Continuing with the case study, the workflow must be defined. The next table shows the Workflow definition (for the Step III.1 - MODEL) for product transfer lifecycle from an OEM (aerospace maintenance tooling) Table D-1 Detailed workflow Stage of Life Cycle No. Activities of IECOS Case Comments Market analysis 001 The Broker performs commercialization activities. Business opportunity 002 The customer contacts the Broker. In this special case is the OEM for aerospace

maintenance tooling 003 The customer explains the new project in general

004 The Broker make a general analysis The approach of the project is evaluated by the broker according to its competences and/or capabilities

005 The Broker accepts or deny to quote 006 The customer send a confidential agreement

007 The broker review and sign the confidential agreement

008 The broker send the signed confidential agreement

009 The customer send the project information

Drawings, technical specifications, production volumes, etc It can be by e-mail, fax, prints, or accessible from an ftp server.


119


010 Review the information and check if it is complete

It is important that all the information is transferred, because it will determine (without doubts) the scope and requirements of the product quality In this special case, are important: final assembly, sub-assemblies, detailed drawings, materials requirements Additional information (out of product specifications) are important too, as production volume, packing requirements, delivery time, etc

011 Consult the drawings reading instructive (if it is necessary)

If the person(s) who is(are) reading the information is(are) not familiarized with the information from this client, the instructive document for the client’s drawings interpretation must be consulted

012 Broker make initial questions, or ask if information is not complete or clear

BOM definition 013 Check the internal “commercial raw material master list”

Is a register with general information of the commercial materials (standard dimensions)

014 Develop a BOM for each drawing 015 Al the drawing’s BOM are put together

016 The developed BOM is then compared with the client’s BOM (if it is provided)

017 Track and evaluate inconsistencies with customer’s BOM

018 Contact customer if questions regarding BOM are founded

019 Register and organize the BOM requirements by material type, acquisition mode and dimensions,

020 Update the “commercial raw material master list” If new specifications are founded

Material selection 021 Find the corresponding local standard for the materials specifications (and components)

A format that registers the material requirements from former projects, called “materials standards list”, must be consulted. Check the norms (ANFOR, DIN, AISI-SAE, etc.) in order to translate the requirements into local and/or commercial standards (For Mexico), which usually are AISI-SAE, ASTM, etc


120


022 Check also dimensioning specifications Usually the unit translation causes non-standard dimensions, which can be a problem for raw materials acquisition (e.g. from “mm” to “in.”)

023 Identify the standard dimensions and properties for the required materials

Use catalogues from commercial providers (national or international)

024 Check previous projects in the archive to identify materials providers

Use a format called “materials standards list” from former projects

025 Identify local providers for the required materials Based on material specifications, and geometrical constrains (standard dimensioning)

026 Check availability of the raw materials in the market

027 Search the chemical and mechanical properties of the material specified on design If the material is not available in the local market

028 Identify the main properties, according to the product function

(E.g. Electrical conditions, thermal conditions, working environment, etc.)

029 Choose a material with similar or better functionality Use a format called “materials standards list on the local market” from former projects

030 Internal engineering changes (material selection) are proposed

Propose similar materials, based on the main properties in order to allow local purchases of the materials and components (it will reduce costs and time, without reducing functionality and performance)

031 Check for local availability (or if local provider can obtain it), quality certification and functionality requirements achievement.

032 Check international availability

033 Proposal for engineering changes (material selection) to the customer

It is needed a signed authorization from the client, with a written reason of the change and the responsible.

034 Update registers with materials equivalences

General Manufacturing processes definition

035 Review customer requirements and analyze drawings

The client can demand special process (even if they are not the most convenient ones). Although new process can be proposed and subjected to authorization

036 Manufacturing processes determination

In this special case, the most common manufacturing processes are: Machining, metalworking (plate cutting, rolling, welding, etc.) and assembly. (Other processes are considered like painting, heat treatments, etc.)


121

Ricardo Mejía Gutiérrez APPENDIXES 037 Analysis of required technological competencies Partners selection (Manufacturing Process Supplier Selection)

038 Categorization, evaluation and pre-selection of business partners

Supported by the IMMPAC methodology (for providers evaluation)

039 Search the IECOS database for manufacturing providers from previous projects

Based on IMMPAC results, and performance ranking (from previous projects)

040 Search for new partners if actual alliances are not capable

It can occur when: Full partner’s capacity is occupied, New competencies are required, high prices or if it is no worth to do it for some partners, etc

041 Execute the “Process for clusters growing and strengthening”

A standard process is carried out to find new potential providers

042 Pre-select potential manufacturing providers

043 Send the confidential agreement to the potential manufacturing providers

044 The manufacturing providers review and sign the confidential agreement

045 The manufacturing providers send back the signed confidential agreement

046 Send RFQ (Request for quotation) to potential providers, with all the relevant information

Considering materials acquisition by them or by IECOS

047 IECOS is available for any question that providers can have.

048 IECOS receive and answer or canalize the doubts and questions from the manufacturing providers

049 Manufacturing provider(s) send their Quotations to IECOS

050 Quotations analysis

051 Manufacturing provider(s) pre-selection According to Costs, Quality, lead times and Performance record and ranking (if it exists) from previous projects

Materials supplier selection 052 Decide if IECOS will acquire the materials or if the

manufacture provider will do it directly. It can be performed parallel to the manufacturing partners selection

053 Needs establishment according price and lead time If IECOS decide to purchase directly the material The BOM generated is used for these activities.


122


054 Search for local supplies options and send RFQ Based on the BOM and the purchasing needs described on the previous point.

055 Search for International supplies options and send RFQ If it is necessary

056 Material provider(s) pre-selection Analyzing: Materials specifications, Costs, Quality, lead times and Performance record (if it exists) from previous projects

057 Update registers with materials providers Quotation generation 058 Analyze materials and manufacturing quotations

059 Select the best options

060 Generate a IECOS quotation Integrating all services (materials, components, manufacturing, assembly, package, shipping, etc.)

061 Send the quotation to the customer 062 Customer analyzes the bid 063 Customer accepts or deny the bid 064 Re-negotiation can be performed if it is necessary 065 Customer sends the purchase order Re-design (if needed) 066 Generate a parametric 3D model (with parametric




069 Drawings and technical information release Materials and standard components acquisition


071 Receive the material and fill the “receipt register”

Signed by the IECOS responsible and the Material delivery responsible. Quantity and dimensioning of the received material must be clearly specified.

072 Labeling and storage of the received material

Material Label “to verify” with project and part number to be identified. Update the register “storage master record” with all the individual materials and/or components

073 Update the register “storage master record”


123


074 Materials and/or components inspection Total inspection (Dimensions, Thickness, Hardness, etc.)

075 Re-labeling after inspection Change the label to “accepted” or “rejected” depending on the quality inspection

076 Contact the supplier if the material(s) or component(s) are rejected Fill the format of non-conformity

077 Supplier evaluation Update or generate the supplier performance register

Material and/or components delivery to the manufacture provider

078 Fill the “delivery register”

Signed by the IECOS responsible and the manufacturing responsible. Quantity and dimensioning of the delivered material must be clearly specified. It is important to specify the permissible scrap accepted by IECOS

078 Un-register from storage records 079 Update the register “storage master record”

080 Deliver the material(s) and/or Component(s) to the manufacture provider

Production coordination agreement

081 Internal due date definition

Based on the proposed lead-time to deliver the final product to the client, considering packing and shipping, formalities, time for transporting, and additional processes like Painting, heat treatments, etc.

082 Activities planning for coordination and execution Based on the “Manufacturing processes determination” stage (#036)

083 Scope defined and agreed with the manufacture provider

084 Measures and controls definition

Clear and reachable objectives must be defined with the manufacture provider. Due dates must be established and the way that IECOS will receive feedback from the product manufacture.

085 Manufacture provider can consult IECOS for any inconvenient or question that it can face

Manufacture execution and controls

086 Manufacture provider will report its advances at the 25% of the general advances. A first report must be generated


124


087 Actions are carried out if requirements are not fulfilled.

IECOS will support and assist the manufacture provider for any problem or inconvenient that it can face

088 Manufacture provider will report its advances at the 50% of the general advances. A second report must be generated


090 Manufacture provider will report its advances at the 75% of the general advances. A third report must be generated


092 Final report generation by the manufacture provider A final report must be generated

093 Deliver the final product (or component) to IECOS (together with the final report)

Product receipt 094 Products or components receipt Fill the “receipt register” and sign by IECOS

095 Fill the “receiving register” Signed by the IECOS responsible and the delivery responsible from the Manufacture provider

096 Labeling and storage of the received product(s) and/or component(s)

Labeled “to verify” with project and part number to be identified.

097 Update the register “storage master record” For each product(s) and/or component(s)

Quality control 098 Final inspection Full inspection (Dimensions, Thickness, Hardness, materials, mechanical properties, tolerances –according to standards used -, etc.)

099 Re-labeling after inspection

Change the label to “accepted” or “rejected” depending on the quality inspection. An additional “to detail” label can be added, when a rejected part can be recovered by re-manufacture

100 Contact the manufacture provider for any non-conformity (Rejected or to-detail) Fill the format of non-conformity

101 Actions are carried out 102 Supplier evaluation Update or generate the supplier performance register Packing and storage 103 Check the customer package requirements (if they

exists) Sometimes the client demand some special packages specifications

104 Define package If customer does not specify it. 105 Packaging check list definition Quantity, Invoices, ID metal sheets, etc 106 Product Packing 107 Take a digital photo for documentation


125


108 Transport the final product to the storage area named “product ready to be delivered”

109 Update the register “storage master record” The warehouse must be divided in five areas: 1-To verify, 2-Accepted, 3-To detail, 4-Rejected and 5-Rready to be delivered.

Shipping 110 Prepare all the export documentation 111 Contact the transportation company 112 Agreeing a date for picking up the final product

113 Fill the “Final shipping register”

Signed by the IECOS responsible and the transportation company responsible. Description of the delivered product must be clearly specified for Customs.

114 Un-register from storage records 115 Update the register “storage master record” 116 Deliver the final product to the customer 117 Package tracking Until the customers receive it Customers feedback 118 Receive quality controls feedback from customers

evaluation

119 Evaluate customer’s satisfaction 120 Lessons learned documentation 121 Payment procedures starts 122 Receive the payment

123 Distribute payments over materials, manufacture and other process suppliers


126


Appendix E. IBM - WebSphereTM E.1) Technology Architecture and Application Architecture. An Application Architecture is the architecture of any automated services that support and implement such functional requirements, including the interfaces to the business and other applications. It describes the structure of an application and how that structure implements the functional requirements of the organization. Whilst there should ideally be one application architecture in an organization, in practice there are typically many different application architectures. The operational requirements of a software system define the reliability, manageability, performance, security, and interoperability requirements of the software (to list just a few).

Figure E-1 Technology Architecture and Application Architecture.

A Technology Architecture is the architecture of the hardware and software infrastructure that supports the organization and implements the operational (or


127


non functional) requirements, particularly the application and information architectures of the organization. It describes the structure and inter-relationships of the technologies used, and how those technologies support the operational requirements of the organization. A good technology architecture can provide security, availability, and reliability, and can support a variety of other operational requirements, but if the application is not designed to take advantage of the characteristics of the technology architecture, it can still perform poorly or be difficult to deploy and operate. Similarly, a well-designed application structure that matches business process requirements precisely—and has been constructed from reusable software components using the latest technology—may map poorly to an actual technology configuration, with servers inappropriately configured to support the application components and network hardware settings unable to support information flow. This shows that there is a relationship between the application architecture and the technology architecture: a good technology architecture is built to support the specific applications vital to the organization; a good application architecture leverages the technology architecture to deliver consistent performance across operational requirements E.2) High-level overview of the WebSphere platform

Figure E-2 WebSphere platform


128



129

E.2.1 WebSphere Foundation & Tools Foundation and tools products reduce business risk by relying on a high quality foundation to rapidly build and deploy applications for high-performance e-business on demand. This group contains products that represent the basic functional infrastructure for other products. Some key features of these products are the following: Open services infrastructure: Provides a reliable foundation capable of high volume, secure transactions and is fully enabled to deliver Web services. Using an open services infrastructure allows you to provide an operating environment for disparate platforms. Application development: Allows you to develop new applications to provide rapid and efficient response to business needs. You can quickly build quality applications that deliver new function and integrate with existing applications and assets. Enterprise modernization: Allows you to leverage existing business assets and extend them for e-business. These business assets can include applications and data which provide critical business information and processes. Incorporating these existing applications into new Web-based applications can be the quickest and most cost-effective way to move to an e-business on demand environment. Leveraging your development skills is also a key part of enterprise modernization. E.2.2 WebSphere business portals Business portals strengthen relationships by enhancing customer, partner, employee, and supplier user experiences for optimal satisfaction. In this group we find the products, such as WebSphere Portal that help businesses to extend the range of their applications. IBM WebSphere Portal provides a single point of access to applications, application content, processes, and people in your network. The personalized single point of access to all necessary resources reduces information overload, accelerates productivity, and increases Web site usage. In addition, portals do much more; for example they provide additional valuable functions such as


security, search, collaboration, document management, document viewing, and workflow. A portal delivers integrated content and applications, plus a unified, collaborative workplace. Indeed, portals are the next-generation desktop, delivering e-business applications over the Web to all kinds of client devices. E.2.3 WebSphere Business Integration products Business integration products optimize operations by integrating and automating business processes. WebSphere Business Integration products help customers to interconnect their islands of information and make full use of the message-based architecture. For the case of this proposal, the integration part that interests us is the based one in processes. Process integration is at the highest level of business integration. It implies coordinating and controlling activities that may span multiple systems and involve people in a variety of roles. It structures, implements, automates, and manages business processes while providing runtime measurements that will then assist in optimizing the process models. Process integration can support long-running transactions and roles-based human activities. The flow of a business event through the process can be modified by external input, either by parameters provided when the process is instantiated or by information retrieved from external data sources such as an application database, or by human decisions such as in an approval step. Process integration can also be seen as the business logic layer that determines what needs to be done at a given point in a process, as opposed to how it gets done, which is typically the role of the application. Separating the what from the how allows flexibility since one can be changed without affecting the other. E.3) Applications to Implement CeEE Architecture from Cycle 3:

Landing Gear case study In order to allow the fully functionality required by the Collaborative Engineering Environments, the WebSphere Applications where identified. Some of the applications required are: ITESM, Campus Monterrey

130


IBM WebSphere Application Server WebSphere Application Server is a Web application server that provides J2EE services for the WebSphere Portal environment. It executes the Java portlets, JavaBeans, JavaServer Pages files, and Enterprise JavaBeans used by WebSphere Portal. This component is the platform on which WebSphere Portal runs. IBM WebSphere Studio WebSphere Studio Site Developer is an integrated development environment (IDE) for creating dynamic Web sites quickly and easily. It is for Web developers who need team development support for JSPs, servlets, and XML, plus access to database and Web services wizards. WebSphere Studio Site Developer is based on Eclipse, which is an open source, extensible, IDE platform. Lotus Collaborative Center WebSphere Portal featuring Collaboration Center capabilities offers an integrated framework of e-Wokplace components for finding, connecting, and working with people, such as People Finder portlet, My Lotus Team Workplace (QuickPlace) portlet, Lotus Web Conferencing (Sametime) portlet, Sametime Contact List, and Sametime Who Is Here portlet. These portlets are built on the Lotus Collaborative Components. IBM Lotus Domino Enterprise IBM Lotus Domino Enterprise Server and Notes® is groupware software that provides messaging and collaboration features. Notes is the e-mail, calendaring, group scheduling, Web access, and information management client. Domino is the integrated messaging and Web application server. Lotus Instant Messaging (Sametime) Lotus Instant Messaging provides Instant messaging and online awareness. Using Sametime, portal users can discover if others are available to chat, receive e-mail, share applications and other tools in an e-meeting or Web conference, and, if Lotus Discovery Server is enabled, find documents authored by others and display expertise profiles from the Knowledge Map. Lotus Team Workplace (QuickPlace) Lotus Team Workplace is a Web-based solution for creating team workspaces for collaboration. Portal users can work securely with colleagues, suppliers, partners and customers. It provides teams with workspaces where they can reach consensus through discussions, collaborate on documents, and coordinate plans, tasks, and resources.


131