INFORMATION DRIVEN COLLABORATIVE ENGINEERING: ENABLING FUNCTIONAL PRODUCT INNOVATION

Transcription

1 INFORMATION DRIVEN COLLABORATIVE ENGINEERING: ENABLING FUNCTIONAL PRODUCT INNOVATION Karlsson, L., Löfstrand, M., Larsson, A., Törlind, P., Larsson, T. Polhem Laboratory, Luleå University of Technology SE SWEDEN Elfström, B-O., Isaksson, O. Volvo Aero Corporation SE-46181, Trollhättan, SWEDEN Abstract. This paper discusses Information Driven Collaborative Engineering (IDCE) as an enabler of Functional Product Innovation (FPI). It discusses challenges that arise in functional product development and how distributed collaborative work will be affected. Finally the paper proposes bringing the domains of Distributed Collaborative Engineering (DCE) and Knowledge Enabled Engineering (KEE) together to form IDCE, in order to meet these challenges. 1 Introduction This paper discusses the prospect of Information Driven Collaborative Engineering (IDCE) as an enabler of Functional Product Innovation implying that the development of Functional Products will fundamentally change the ways in which global collaboration is carried out and thus also changes the ways in which collaboration technologies and methods should be designed and applied in order to successfully support such collaboration. A Functional Product (FP) is an offer developed by a network of companies and consisting of capitalintensive hardware integrated with accompanying services that are necessary for keeping it operational during the lifecycle [1]. Fundamentally, this means that globalization, in itself and as we know it today, is not the sole driver for change in terms of methods and technologies for global collaboration in engineering. On the contrary, it is the increasingly information-driven approach to engineering combined with the concept of Functional Products that sets the demands for what, how, when and with whom companies need to communicate. Functional Product development, in general, puts new and extended demands on ways of cooperating and collaborating [2], and, in particular, it puts new demands on methods and technologies that support distributed collaborative engineering (DCE). For DCE to succeed there must be some assurance that the right information is available at the right time, to the right persons, regardless of the location of both the information and of the team in need of that information. In an engineering perspective, DCE methods and tools of today might no longer be sufficient to meet the demands of design teams working in cross-functional, cross-cultural, and cross-organizational settings. The traditional approach to DCE has been based on ways of supporting distributed collaboration technically through video conferencing, online workspaces, and through the real-time transmission, storage and retrieval of data. Considerable attention has also been given to developing protocols and standards that enable easy integration of data and information. FP changes this into IDCE, where the prime focus is not on technical solutions (i.e., capacity or performance issues), but rather on enabling virtual enterprises to make use of the right information at the right time (i.e., usefulness issues), in spite of the rapidly growing

2 volume of data and the increasing range of information sources that are available. The information-driven approach entails a contextual view of knowledge, meaning that the crucial transformation from information to knowledge is more likely to occur if the provided information matches what is requested (i.e., relevant information) and if it is made available just when it is needed (i.e., relevant timing). Also, in order for information to be an enabler and a true driver, this approach emphasizes the importance of capturing design rationale as well as tacit and local knowledge, to the greatest extent possible. Making sure that the information, or knowledge, is used in appropriate ways by users and organizations is thus a main driver, since the effectiveness of collaboration is highly dependent on how well the provided information fits the actual purpose. Realizing the impact of product performance failure or success, through simulation early in the concept phase or even in the customer offering phase creates the possibility to play what-if scenarios with the corporate knowhow in terms of products and offers. In this paper, this area is described under the term Knowledge Enabled Engineering (KEE). Hence, the IDCE approach may be said to be a combination of technology (traditional DCE), work methods and procedures that support the highly heterogeneous environments that increasingly exist in industrial settings. Current DCE practices and technologies must be adapted to the new drivers and the outcome will be new methods of work as well as new technologies that fall within the authors label of Information Driven Collaborative Engineering. Our approach of focusing on simulation-driven design, knowledge-enabled engineering, and distributed collaborative engineering in the support of functional product development is schematically introduced in Figure 1 below. The figure illustrates how our research areas (in red circles) contribute to Functional Product Innovation by means of an information-driven approach to collaborative engineering. Secondary, but highly relevant, knowledge domains are illustrated with grey circles. Figure 1: Functional Product Innovation Going from market needs to Functional Products using Information Driven Collaborative Engineering. 2 Functional Product Challenges Functional Products introduce new demands on work processes, tools and methods for collaboration between distributed as well as co-located teams. These new demands originate in five cornerstones: the extended product definition, the design team composition, the business organization, the design process and new economical challenges. Figure 2, below, introduces these cornerstones schematically, with Distributed Collaborative Engineering [3, 4]

3 and Knowledge Enabled Engineering [5] as complementary and enabling methods and technologies. Figure 2: DCE and KEE relations to FP cornerstones. Invariably, there will be several links and interrelationships between these cornerstones, which are mentioned below. This means that design of functional products is certainly a socalled wicked problem [6], as is often the case within Engineering Design and Product Development, in that no certain correct solution exists, that a sufficiently acceptable solution may still be found, and that that the solution differs over time and in different organizations. The research issues in this paper concern IDCE drivers for enabling FP innovation. Here, the main interest is the impact that these emerging issues have on design teams and their development activities. 2.1 The business organization: Extended enterprise The extended enterprise consists of a network of companies that share risks, revenues and access to each others markets, and where, presumably, each partner has the goal of becoming best partner in a partnership, rather than the sole market leader. One of the reasons for such partnerships may be the increasing complexity of the hardware, software and services that make up the functional product in a business-to-business setting. Another reason might be the rate of technology change that must be managed in the FP design process. 2.2 The evolving product definition One traditional engineering definition of product development is, for example, the one provided by Ulrich and Eppinger [7]: " the set of activities beginning with the perception of a market opportunity and ending in the production, sale and delivery of a product. By this definition, the product is finalized, sold and delivered to the customer and its use is, strictly speaking, not very interesting for the seller. On the other hand, the ISO [8] definition of a product is:

4 A product is an output that results from a process. Products can be tangible or intangible, a thing or an idea, hardware or software, information or knowledge, a process or procedure, a service or function, or a concept or creation. Based on the above definitions, in this paper, a functional product is considered to be: A product, not necessarily a physical artifact, consisting of any combination of hardware, software and services, being sold for the purpose of supplying a function, thereby meeting all agreed-upon needs of the partner whose primary role is that of a customer.[2] The point here is that it would be more effective if people in a company talked about the same product perception, rather than engineers talking about the product as the hardware they are making and business people talking about the product as the offer they are making to the customers. 2.3 The design process Current design, engineering design and engineering management literature describe how traditional engineering projects should be carried out and managed. However, team processes and best practices for FP development have not yet been described. The important functionality for the end user has to be defined in each business case, which will probably lead companies in the extended enterprise to focus more and more on their own core knowledge and competence, while at the same time handling the increasingly complex business and product development relationships and strategies. Some change to the design process will also occur because of the new demands on the hardware. Conceivably, this new business concept will include a stronger interest in upgradeability, configuration control, remanufacturing, modularization and customization. The FP Design (FPD) process will be extended compared to the general hardware design process. In the FP design process, more emphasis is needed on needfinding in early stages and on the first offer to the customer, thereby extending the scope of the product development process, additionally this process will continuously evolve and adapt to the customer demands over the lifecycle of the FP [9]. 2.4 New economic challenges The development and sale of functional products also challenges current economic conditions and business models. Performance will not only be demanded in services and hardware but also in the surrounding economic system. For example, financing and insurance may be included in the functional product offer. As a company is selling functional products it is climbing the value chain and running the risk of taking over value from previous customers, which within the extended enterprise has the effect that the roles of the partners within it are no longer static, but dynamic and changing over time. In these dynamic roles, trust between partner companies becomes more important as, for example, large supplies of spare parts are replaced with agreements on service availability. One might say that the Functional Product is one of the drivers of globalization rather than the other way around and that globalization is no longer a choice but a reality. 2.5 The design team Due to the FP design process within the extended enterprise and the new economic challenges at hand, the design team will include people from a variety of disciplines and functions. To

5 name but a few team roles, the FP design team will include: engineers, lawyers, business developers, technical experts and finance specialists. The FP team has (because of its cross-disciplinary character) different goals, purposes and motivations, and therefore includes different understandings, paradigms and world views, even though they may all be part of the same extended enterprise. Importantly, however, they still have to work with the same tools (at least to a limited degree) and with the same information (to a large degree). Also, since actual functional products are assumed to be mostly of interest in the businessto-business (B2B) environment, and that FP drives globalization rather than the other way around, we are likely to see larger and more diverse (i.e., cross-functional and cross-cultural) design teams in the future. New design team compositions raise the question What is a design team?. As noted above, it is most likely that the design team no longer consists predominantly of engineers and other hardware related specialists. Few professionals have more than one academic degree and relatively few educational programs of today teach students to be knowledgeable in both, for example, design and business. Problems within the FP design team concerning professional vocabulary and understanding will arise more commonly than in a traditional, more homogenous team. The environment for distributed communication and collaboration must be able to support the whole team, which places new demands on the design and suggested usage. To an increasing extent, information needs to be displayed differently to team members with different functions and purposes. How (in terms of layout) and when is a question for the definition of a FP design process, and how (technically) is more related to the DCE and KEE domains. 3 Information Driven Collaborative Engineering The change from traditional hardware development to FP development implies a more integrated way of work between disciplines. Rather than having information spread out throughout the company and external enterprise and often a redundancy of information (i.e., the same information exists in duplicate in different standalone applications and at different parts of the extended enterprise), it is essential to make the information usable for all functions within the extended enterprise and available with the right level of transparency. The heterogeneous FP design teams need to have access to all pertinent information regardless of devices, software and work procedures used. They should also be able to communicate any way they choose within the design team, handling changing product design and production methods, resources and facilities, product functionality, lifecycles, legal agreements, distances, time zones, given team members cultures, background, training, goals, purposes, etc. As the domain of engineering design has evolved in order to better relate to the concepts of concurrent engineering (CE) and integrated product development (IPD), it must evolve to better address issues related to Functional Product Innovation. One way to more closely relate to the emerging needs of an FPI approach is to take an increasingly information-driven approach to collaborative engineering. This is not to say that CE and IPD are things of the past; it is just a way of highlighting that a changing business environment calls for changes in the way that we identify and deploy supporting technology and methods. Engineering Design characteristics in a functional product setting include multidisciplinary teams (which implies new challenges concerning culture, language and professional vocabulary), wicked design problems (which implies focus on argumentation, storytelling and discussion) and involves a iterative process including short as well as long design loops. All this, in addition to today s

6 other issues related to design (such as ideation, concept design, detail design, production, documentation, etc.) fundamentally means that the complexity of information availability and use in global organizations will increase. Our approach is to combine the concepts of integrated product development and distributed collaborative engineering, as we know them today, with our division s background in simulation of manufacturing processes, and evolving them into information-driven collaborative engineering in the support of Functional Product Innovation. This approach involves the idea that decisions, at all times, should be based on the latest and most adequate information available at the time, and that these decisions and their rationale should be traceable throughout the design process. The information source should be the product model, so that decisions are made based upon verified information and simulation rather than rules of thumb, tradition and such. In order to achieve Functional Product Innovation, the authors propose the application of a transparent view of the corporation, where business and technology functions are integrated through information-driven design. Current DCE practices and technologies must be adapted to the new drivers, mainly through design studies of product development teams both in academic settings and in actual industrial settings. Also, the approach would include a closer integration of the DCE domain and the KEE domain, thus allowing for a stronger connection between data, information and communication that is used throughout the product lifecycle, and the knowledge workers that locate, access and use this information. 3.1 Distributed Collaborative Engineering The area of Distributed Collaborative Engineering can be divided into three levels: Integration (i.e., data management), Infrastructure (i.e., ICT tools that help create a shared workplace across locations) and Interaction level (i.e., interaction between people, and human-computer interaction). The different levels of collaborative engineering are shown in Figure 3, below. The figure also illustrates the communicative gap that occurs on different levels. Figure 3: Three levels of collaborative engineering.

7 3.1.1 The Integration Level The integration level is focused on the integration of the low-level communication structure, involving the exchange and synchronization of data and information between different software and partners within the extended enterprise. Here, one aim is to support the persistent storage of data, version control of design documents, and to show the current state of the design process. The use of standards for information exchange is important. Tools should be based on, for example, Internet Protocol distribution such as IP multicast, Quality of Service, IPv6 and Peer-to-Peer technologies as well as communication standards from the International Telecom Union (ITU-T) and the Internet Engineering Taskforce (IETF). Product modeling is important, since the product model provides a shared object for multiple participants to store all information about a product throughout its entire lifecycle, i.e., requirements, analyses and geometry. Various techniques for exchanging design data between users exist today, but they are not satisfactory for use in distributed engineering because they are mainly designed for exchange of data and not interaction. Standards like STEP and CORBA provide useful exchange mechanisms for engineering data, but do not solve the problems of conversion. It is impossible to store all information in one place, so technologies for integration and sharing of information must be used. A requirement for collaborative engineering systems is that they must combine relevant data from many sources and present it in a form that is comprehensible to the users. Another important issue is that of security. Information must be exchanged with partners, but not with others outside this partnership. Today, this means that company policies can hinder collaborative work (i.e., company firewalls secure the internal computer systems from threats from the internet while at the same time effectively stopping communication, using standard collaboration tools, from inside the firewall to a partner outside the firewall) The Infrastructure Level This infrastructure level includes the Information and Communication Technologies, ICT (a shared workplace with access to the relevant applications). This level includes collaboration tools for both synchronous and asynchronous activities, and today these modes are commonly separated. Due to the highly heterogeneous environments, the software needs to be highly scalable and adaptive in terms of bandwidth consumption and CPU utilization. It is important to support collaboration between distributed teams of engineers using highly heterogeneous environments, such as the internet and with mobile devices. The infrastructure also includes the physical environments in which the collaboration takes place (i.e., meeting rooms, conferencing studios). The design of physical environments is also of great interest, since creative thinking and collaboration are largely dependent on the flexibility and usefulness of both physical spaces and the tools therein [10]. How do you create a project space that suits local creativity, but also opens up the possibilities for successful global collaboration? The Interaction Level On the interactional level, collaborative engineering is viewed from a people perspective. As such, it focuses on the interaction between individuals and groups using ICT (human-human interaction), and on the interaction between people and ICT (human-computer interaction). The former approach naturally has its base in the area of Computer Supported Cooperative

8 Work (CSCW), while the latter has its origins in Human-Computer Interaction (HCI). Both these approaches deal with the design of computer systems, and are thus closely related to both the Integration level and the Infrastructure level. The Interaction level, however, draws attention to the observation that although the other two levels might be functional from a technical perspective, they might not be usable (easy to use) or even useful (meeting a need) from an end-user perspective. Thus, Interaction is about Infrastructure and Integration in use; observing how these technologies are used in everyday collaboration, and using this understanding as input to the process of designing new methods and technologies that are better tuned to the needs of global engineering design teams New Demands on Distributed Collaboration The distribution of resources within the extended enterprise makes communication and collaboration over distances, which in many cases are very large, a real challenge. It puts additional requirements on the collaboration environment in terms of handling time zones and cultural issues even in a homogeneous engineering-based design team. Such challenges will be even more accentuated in a distributed FP development team where education, training and purposes also differ greatly, as well as languages, culture, religion, ethics and values. Collaboration within the distributed team should not be restricted to communication between project leaders in different teams. Such communication follows the structure of the hierarchical organization, where much information is filtered through the project leader, who may or may not be involved in the detailed design issues. Current DCE seldom supports detailed design in distributed FP development teams [11]. In an ideal world, it should be possible to support IDCE according to what has been described above. The support will consist of suggestions for methods of work and usage which should support all sizes of teams and team complexity. These new demands require research approaches that presuppose close collaboration between academia and industry. Knowledge and different views on the same knowledge must have adequate forms of access control, so that, for example, private information remains private or information not intended for certain people do not reach them by mistake. On the other hand, for optimal product development, everybody needs access to their own relevant information. Here, there is a connection to the team members own preferences, since many people produce at a much higher rate when they have a view of the whole rather than their own part only. The conclusion, here as well as for DCE environments, is that users must be allowed to customize their interfaces with the computer systems in ways that suit them. The design rationale, i.e., why something turned out as it did [12], what motivated that particular design decision, what design possibilities were considered and rejected, etc., we acknowledge as being very important. Especially when it comes to facilitating traceability of decisions over time, methods of work and tools for capturing the design rationale are needed [11]. This area is a good example of challenges that arise from FP development and which affect both the FP design process as well as knowledge management on a technical level. 3.2 Knowledge Enabled Engineering The functional product is knowledge-intensive in a high-risk and high-gain enterprise, which further increases the need for integration and synergy between teams and between computer tools through information modeling. The question, which varies from situation to situation, is: what information needs to be controlled in a knowledge management system?

9 Information needs to be structured and displayed according to the individual team members goals, purposes and training. Knowledge Enabled Engineering (KEE), then, represents a methodology used to capture and reuse knowledge in computer aided design systems [5]. Specific knowledge capture and reuse, like traditional Knowledge Based Engineering (KBE) approaches, of computer simulations where knowledge of properties and behavior of forthcoming products may be predicted is of particular interest. KEE aims to support or perform engineering activities with the help of available and identified techniques and methods. The purpose of KEE is to allow automation of engineering work, as this creates an opportunity to extract knowledge normally found in later (downstream) phases and make this knowledge available already in the conceptual phase of the development process. The emphasis in KBE is on providing informational complete product representations captured in a product model: The product model represents the engineering intent behind the product design, storing the how, why and what of a design. [13] KBE can be defined as: The use of advanced software techniques to capture and re-use product and process knowledge in an integrated way. [14] Together with computerized engineering design tools, used to reduce technical risk and uncertainty along with the number of prototyping cycles needed, e.g., modeling and simulation tools, and the group of tools that enhances communication and facilitates the flow of partial information, e.g., tools based on shared databases, a simulation-driven approach can be taken where the knowledge assets can be used to model and simulate business processes, engineering design processes, products, and ultimately all lifecycle properties of a Functional Product. Combining KEE methods and simulation technologies can improve the design evaluation process, no matter if it concerns the design of a product proposal or the design of the product itself. The knowledge assets can be cost models for business as well as performance models for engineering analysis. Positive effects are the possibility of early standard analysis of design concepts; shorter analysis cycles (i.e., creating the possibility for optimization and more iteration) and the fact that experienced simulation experts can spend less time on routine tasks that are done by the KEE system users instead. Ultimately, the information, or knowledge, can drive the design dynamically rather than being static objects. By having all processes, business and technology, in a company using, and updating, the same knowledge base it is possible to make sure that decisions, or simulations, made are done with the right knowledge asset. Lifecycle simulation of an offer or FP containing all valuable parameters is then possible. 4 Results The research at the Polhem Laboratory have been performed using a three-layered approach [15] to the advancement of global collaboration, combining product development, education and research platforms. 4.1 Product Development Platform Industrial Perspective Due to the close collaboration between the researchers and the partner companies in the Polhem Laboratory [16], researchers can follow real design teams in action at partner companies. The design teams at the companies use a variety of different tools and methods to

10 develop products between company sites in Sweden and in different countries as well as between different companies. Some of the studied companies are Hägglunds Drives AB, Volvo Car Corporation, Land Systems Hägglunds, Sandvik and Volvo Aero Corporation. During the past decade, there has been an intensive development of ICT tools and use of them in industry. First, these tools were used in the detail development phase, but now they are increasingly used together with advanced simulation and KEE tools in the concept development phase. Ten years ago, Volvo Aero Corporation (VAC) joined the Polhem Laboratory and started to develop competencies in the DCE and KEE areas in several Polhem Laboratory projects. The company has successively incorporated the methods and tools in the development process. The most advanced technologies are not yet used, but combining video conferencing and online meetings with ordinary design and simulation tools has presented a new possibility for iterating many more design solutions than before. This enables optimization of the product solutions not only at the Volvo Aero level, but also at the customer and customer s-customer level. The product innovation environment has therefore been enhanced, and ultimately, a product with higher value is produced. This is the case for the Airbus A380 program, where Volvo Aero is partnering with Rolls-Royce to develop the Trent 900 aircraft engine, which provides thrust for the large double-decker. The usage of the methods and tools are studied and further developed together with Volvo Aero and other aircraft industries in VIVACE [17], a 70 MEuro Integrated Project in the EU Sixth Framework Program (FP6). The acronym stands for Value Improvement through a Virtual Aeronautical Collaborative Enterprise and the main project goal is to support the design of a complete aircraft with engines by providing increased simulation capabilities throughout the product engineering lifecycle. The goal is to create a virtual product in a virtual enterprise, thereby aiming to achieve a 5% cost reduction in aircraft development, a 30% lead-time reduction in engine development and a 50% cost reduction in engine development. One of Volvo Aero Corporation s goals in the Virtual Enterprise setting is to study barriers to collaboration in design and how to address them. 4.2 Education platform To disseminate research in industry, a good way is to introduce the research tools and methods into engineering-design education, where new research ideas and technologies can be tested in design projects with industry. During the previous nine years, this approach has been tested in the SIRIUS program [18], a one-year student project, in which students and company development teams work together to develop new concepts for future products. These projects have provided a test platform for research in DCE, KEE and later for IDCE methods and tools. The projects have resulted in possibilities for developing product innovations, about 15 patents and many new products already in production. The students cooperate with the company engineers by using the collaborative systems and methods developed in the research platform at Luleå and communication studios located in Luleå, Gothenburg (Volvo Car Company), Örnsköldsvik (Hägglunds Drives AB) and in Trollhättan (Volvo Aero Corporation). Within these projects students from LTU have also cooperated with other student teams from the Royal Institute of Technology and Chalmers University of Technology.

11 4.3 Research platform Some new ideas may not be possible to implement in industry; therefore, it is also important for the researchers to be able to test and evaluate these issues in experimental forms within academia. The interdisciplinary work within the Polhem Laboratory inspired us to further explore the relationship between the social and technical aspects of collaborative work. By applying concepts from the ethnographic tradition to the context of our research center s understanding of engineering practices has increased, It is shown that the potential to create collaborative environments and technologies better suited to the needs of both co-located and distributed engineering communities has increased. The research team has created several studios for collaboration [19]. The first studio was inaugurated in 2000, see Figure 4 below. Continued research has led to new ideas and concepts that are incorporated in the new experimental studio (see Figure 5), which is flexible enough to accommodate a wide range of co-located and distributed collaborative scenarios, while being rigid enough to also allow for realistic, everyday design-in-action and effortless research observation of those activities. The studio provides a rapid-response environment, in which the significance of issues raised through ethnographic observations of engineering work can be evaluated and solutions offered [20]. Figure 4: The original studio designed at the Polhem Laboratory.

12 Figure 5: The new studio designed at the Polhem Laboratory. It is likely that management and control of the evolution of product development for hardware to product development for Functional Product Innovation can be enabled in several ways. Our suggested way is to enable FPI through the realization of Information Driven Collaborative Engineering. Given the Engineering Design characteristics in a functional product setting as discussed above, Distributed Engineering Design should ideally support all of this with a focus on information and knowledge. IDCE must support local as well as distributed teams with the help of our chosen tools: work methods, technology and demonstrators. Work methods include such things as meeting facilitation, project work methods and distributed design methods. Technology on the other hand includes, for example, videoconferencing, audio conferencing, instant messaging, project portals and shared spaces to name but a few. Whatever sub-solutions to problems (regardless if they are related to technology or work methods) are found in future research, the intention is to demonstrate them in industrial as well as academic settings as a way of spreading results. To identify solutions we must first identify the knowledge gap, which is critical in order to perform relevant research. That includes identifying relevant FP cases and studying design practices at companies with focus on information and collaboration issues related to knowledge acquisition, knowledge retention, knowledge distribution, knowledge backup and knowledge availability. Also, a well grounded knowledge of engineering design and the best practice concerning how distributed engineering design is supported today is critical for reflection on the industrial studies in relation to the existing theoretical framework. To develop more effective solutions (in terms of less time, lower cost, higher quality and higher efficiency), planning and deployment of demonstrators/pilots in industry situations similar to the studied situation is an important consideration. Pilots in an academic environment may then be developed, from which results may be compared to industrial-case results. These academic pilots are to be carried out as single parameter studies in an experimental setting using the new studio. The new studio will also be used to motivate efficiency in large scale by using results from small-scale experiments. After result reflections, new, multi-parameter pilots in industry may be developed, deployed and studied. 5 Discussion - Realization of IDCE The purpose of this article has been to introduce some of the new challenges that arise when trying to develop information-driven collaborative engineering in a functional product innovation setting. The approach is to combine it with research, education and product development, which is expected to lead to functional product innovation. This belief is based on years of research in distributed engineering with several Swedish industrial companies (including Volvo Aero Corporation, Hägglunds Drives AB and Volvo Car Corporation [20]) as well as such research within the senior undergraduate course SIRIUS at Luleå University of Technology. This belief is also based on a genuine interest in research concerning engineering design and product development. So why is it believed that that IDCE (based on DCE and KEE) will lead to functional product innovation? This belief is founded on the outcome of several studies of multi-cultural design teams [15,21], the results of which have been greatly improved and widely acknowledged, thanks to team diversity in terms of language and training. In Europe, VAC and the Division of Computer Aided Design at LTU are participating in the 6th Framework

13 Program VIVACE, where additional tools and methods for this kind of work are under development. Many distributed design cases have been studied [11], including industrial cases with CONEX AB, Hägglunds Drives AB and winter testing of vehicles. These case studies have proven that using distributed design greatly speeds up the creative process. The discussed work concerning Knowledge Enabled Engineering aims at creating tools where routine jobs are automated and simulations speeded up for the benefit of the engineer. Both these activities give the designer more time to be creative and allow for a greater number of design loops with increased internal freedom. In short, this is conducive for creating innovative products. In the SIRIUS course, for example, over a period of nine years, about 15 designs have been patented by the involved companies, and interest from industry partners has never been greater, owing to their interest in innovative design solutions. 5.1 Challenges to reach Information Driven Collaborative Engineering There are some fundamental challenges that relate to both the DCE and KEE aspects of Information Driven Collaborative Engineering. First, there are technically oriented challenges. It is technically possible at an early stage of design to define product models with a high level of detail by making use of existing knowhow. At the same time, it is challenging to gain that know-how at the right level of detail. Secondly, there are methodological challenges. The main shift is that all logical product solutions and their combination must be defined upfront and coded into a computer application. This requires systems development and maintenance work, which is traditionally separated from interactive engineering work. Often, the knowledge models can be developed to be good enough for 80% of the expected preliminary work of a project. Upon entering the product-development phase, an additional 20% of systems development/updating is needed due to additional situation-dependent requirements. A challenge is to define and develop these engineering systems, so that users still have the necessary control and the systems do not become black boxes. It is then crucial to have an efficient updating and redesign methodology, since such work tends to be carried out in a severely restricted time frame. There is a need to develop simulation models adapted to the actual stage of design and available information. By doing this, the combined KEE and simulation environment will become a design support system that drives the design rather than a design verification system that verifies what is already decided. Thirdly, there are cultural and social challenges [22]. The new generation of engineering support systems increasingly integrates techniques, methods and experiences from disciplines that are normally represented among different users, such as CAD, PDM and Simulation users, although it is a technical reality that the systems mergers, new roles and situations appear amongst the users. Challenges appear as new roles are defined, such as Knowledge Engineers. More effort is spent by users on actually defining the design systems than simply using a pre-existing tool from a vendor. The new collaboration tools must be versatile, flexible and easy to use. In particular, in the early concept phase, they must be able to support different types of collaborative interactions: synchronous, asynchronous, point-to-point (engineer-to-engineer as well as between engineers and other company functions), many-to-many, small group interactions, group-togroup, etc. Collaboration tools should include support for session management and control, user presence and awareness, user mobility, and transparent storage of collaborative data and events to facilitate reuse and reprocessability. As examples, informal communication, brainstorming and prototyping are less common between distributed team members than colocated team members. These types of meetings seem much harder to support than meetings

14 later in the design process, where formal product models, requirements, etc., exist and formal decisions are more likely to be documented. Törlind and Larsson [23] showed that informal communication is an important part of the communication between team members. However, this type of communication is difficult to support in a distributed team. Solutions for informal communication, presence and awareness must support rapid communication [24]. The cycle of communication is short; problems are dealt with as they come up, and information is exchanged as a natural, effortless and integral part of everyday work. Therefore, it must be possible to initiate communication systems quickly, since relocating to specially designed conferencing rooms and starting complex systems for short meetings is inconvenient and time-consuming. The tools must be available from the desktop computer. Many of today s tools are technology-focused and force the user to work in a specific way. The technology focus the what can approach becomes the basis of integration and communication technologies, whereas the user focus the what needs approach requires a deeper understanding and analysis of the information and communication processes. A typical example is video conferencing that supports communication between team members, but forces the user to work in a specific way (e.g., side conversation is not possible, eye contact is difficult to achieve, and users should preferably sit in one place and not walk around in the room). New communication tools must support effortless communication, whereby the user can see if collaboration partners are available and initiate communication in a couple of seconds regardless of the partners location. The communication is automatically adapted to the bandwidth of the connection and the hardware. The users have several communication modules that can be used if needed; e.g., start with instant messaging, then switch to video conferencing and use application sharing. All communication events can easily be stored and retrieved later on if necessary. The challenge for global product development is to support true collaboration within global design teams, where the diversity and competencies of the whole team can be utilized and where team members can think together rather then merely exchange information, opinions and divide work [11]. Additionally, the collaboration environment should have the desired levels of security, availability and reliability over time. The challenge, as in the case with the knowledge management above, is to identify the process (using for example the design rationale) needed information and how it will be used and displayed in a system for distributed collaborative engineering of functional product innovation. 6 Conclusions This paper discusses the challenge of designing intuitive and useful methods and technologies for a wide variety of contexts and needs, for an extremely heterogeneous and diverse user population. Also, this paper proposes that future research programs in collaborative engineering take an increased interest in understanding not only what can be communicated, but also what needs to be communicated. The former approach assumes its starting point in integration and communication technologies, whereas the latter approach requires a deeper understanding and analysis of the information processes needed to conduct global product development essentially redefining the scope of supporting methods and technologies for collaborative engineering. First, we need to identify and thoroughly understand what information is needed for collaboration. Second, we need to understand how best to make this information available and useful for each partner and individual in the virtual enterprise.

15 Given that development of functional products affect many areas work in product development, many new demands are placed on today s methods and work environments for distributed product development. Methods of work, technology development, differing user needs because of different educational backgrounds, training, languages, culture, religion, ethics and values must all be considered. Design of functional products certainly constitutes a wicked problem [6] and is as such possible to tackle in many different ways. Therefore, the solutions to whatever problem was originally identified will be context-dependant; that is as it should be, as one is aiming for a customized functional product for the customer, all within the limits of organizational flexibility in terms of design, production, assembly and so on. The area of Information Driven Collaborative Engineering is based on the following argument: 1. Functional Product Innovation demands cross-cultural, cross-functional and crossorganizational collaboration in globally distributed teams. 2. As the organizational complexity increases, it is crucial to provide teams with methods and tools that enable them to effectively locate, access, understand, and make use of the information and knowledge that is now increasingly dispersed throughout often temporary organizations (i.e. Virtual Enterprises). 3. Research in the KEE domain is well equipped to handle issues of making explicit knowledge (i.e. "knowledge as content") available to members of an organization throughout the development process. For example, applications for Knowledge Based Engineering and Simulation Driven Design enables engineers to make wellinformed decisions based on information derived from other domains in which they are not experts. 4. Research in the DCE domain has its primary benefits in promoting the sharing of tacit knowledge (i.e. "knowledge as process"). For instance, applications for Virtual Meetings make it possible to engage in a collective sense making process with other people (thinking together) something which is particularly useful when dealing with highly contextual information or ill-defined (i.e. wicked) problems. 5. Bringing the domains of KEE and DCE closer together will provide opportunities for cross-fertilization, for example by exploring how to better contextualize explicit knowledge, or how to better capture and codify tacit knowledge - issues which the separate research domains cannot adequately handle on independently. By capturing and using the design rationale from previous projects it should be possible to decide what should be communicated through DCE practices and tools rather than what can be modeled, and by doing so, define both what is important and the order of importance. References [1] Alonso-Rasgado, T., Thompson, G., Elfström, B-O.: The Design of Functional (Total Care) Products, Journal of. Engineering Design, vol. 15, No. 6, 2004, pp [2] Löfstrand, M., Larsson, T., Karlsson, L.: Demands on Engineering Design Culture for Implementing Functional Products, Proceedings of the15 th the International Conference on Engineering Design, Melbourne, Australia, August, [3] MacGregor, S. P.: Towards a Prescriptive Design Process for Distributed Design Teams. PhD Thesis, Design Manufacture and Engineering Management (DMEM). University of Strathclyde, Glasgow, UK 2002.

16 [4] Sriram, R. D.: Distributed & Integrated Collaborative Engineering Design. Glenwood, MD: Sarven Publishers (USA) [5] Bylund, N.., Isaksson, O., Kalhori, V., Larsson, T.: Enhanced Engineering Design Practice using Knowledge Enabled Engineering with Simulation Method, Proceedings of Design 2004, Dubrovnik, Croatia, May 18-20, [6] Rittel, H., Webber, M.: Dilemmas in a General Theory of Planning, Journal of Policy Sciences, vol.4, Elsevier Scientific Publishing Company Inc., Amsterdam, pp [7] Ulrich, K. T., Eppinger, S. D.: Product Design and Development. Boston (USA), McGraw-Hill [8] [9] Brännström, O.: A Market Offer Development Process, Proceedings of the 11 th International Product Development Management Conference, Dublin, Ireland, [10] Fernando, T. et al.: Future Workspaces - A Strategic Roadmap for Defining Distributed Engineering Workspaces of the Future, IST , Accessed March , [11] Törlind, P., Larsson, A., Löfstrand, M., Karlsson, L.: Towards True Collaboration In Global Design Teams?, Proceedings of the 15 th International Conference on Engineering Design, Melbourne, August 15 18, [12] Moran, T. P., Carroll, J. M.: (Eds.). Design rationale: Concepts, techniques and use. Mahwah, NJ: Lawrence Erlbaum Associates [13] Chapman, C.B., Pinfold, M.: (2001). The application of a knowledge-based engineering approach to the rapid design and analysis of an automotive structure. Advances in Engineering Software, vol.32, pp [14] Stokes, M.(Ed): MOKA Consortium:. Managing Engineering Knowledge. MOKA: Methodology for Knowledge Based Engineering Applications. Professional Engineering Publishing Limited, London [15] Larsson, A., Törlind, P., Karlsson, L., Mabogunje, A., Leifer, L., Larsson, T. and Elfström, B-O.: Distributed Team Innovation: A Framework for Distributed Product Development, Proceedings of the 14 th International Conference on Engineering Design, August 19-21, Stockholm, Sweden, [16] [17] [18] [19] Törlind, P.: Distributed Engineering - Tools and Methods for Collaborative Product Development, Doctoral Thesis, Luleå University of Technology, ISSN: , ISRN: LTU/DT 02/32 SE, [20] Larsson, A., Törlind, P., Bergström, M., Löfstrand, M., Karlsson, L.: Design For Versatility: The Changing Face of Workspaces for Collaborative Design, Proceedings of 15 th International Conference on Engineering Design, Melbourne, August 15 18, 2005 [21] Lewis R.,D.: When Cultures Collide: Managing Successfully Across Cultures, Nicholas Brealy Publishing, London, 2000, pp [22] Olson, G., M., Olson, J., S.: Distance Matters. Human-Computer Interaction, vol.15 no.2/3, 2000, pp [23] Törlind P., Larsson A.: Supporting Informal Communication in Distributed Engineering Design Teams, Annals of the International CIRP Design Seminar, Hong Kong, [24] Whittaker, S., Frohlich, D., Daly-Jones, O.: Informal Workplace Communication: What Is It Like and How Might We Support It? Proceedings of the 11th ACM Conference on Human Factors in Computing Systems (CHI) 1993, pp