Andreas Lindquist
email: andreas.lindquist@chalmers.se

Fredrik Berglund

Hans Johannesson

CONCURRENT ENGINEERING: Research and Applications Supplier Integration and Communication Strategies in Collaborative Platform Development

Keywords: collaboration, platform development, supply chain, communication, trust, process management, sensitive information

Following the introduction of platform-based products, especially considering that platforms are used for multiple brands, there is certainly a growing need for system engineering processes and techniques. This is further emphasized by the fact that companies faced with collaborative platform development frequently need to harmonize often opposing claims from stakeholders with different backgrounds, beliefs, desires and intentions. A core strategy for using resources (e.g., work-hours, knowledge, and production systems) better and more flexibly is to involve suppliers earlier in the development cycle. From this perspective, well-designed and efficiently managed supplier integration is a huge competitive advantage. Supplier integration may range from component design and manufacture to full responsibility for the design of complex distributed systems. The starting point for this work is the results from a previous study, made by the authors, in which a Swedish automotive company and one of its sub-suppliers were examined in order to identify communication barriers. This revealed several problems regarding supplier interaction and information management in projects where both suppliers and product owners contribute their unique knowledge. Following the previous study, the questions to answer include: How can platforms be represented to suit suppliers as well as orginal equipment manufacturers? How does one guarantee efficient, accurate and secure information exchange between the parties involved? Consequently, this article pinpoints some of the problems that companies involved with collaborative product platform development, together with their suppliers, must face today. To answer these questions, interviews, and document studies were conducted for a Swedish truck manufacturer. The results are oriented to the interfaces between product owners and their suppliers.

Background

Collaboration between buyer and supplier has increased in recent years to become a natural part of the operations of any company that develops complex products. No single company can develop cutting edge systems while also giving attention to peripheral tasks; a company needs to focus on core activities and let other actors complement its shortcomings in selected areas where suppliers build less expensive and better components. The systems developed by suppliers have also grown over time from single components to more complete systems which simply need to be attached to the final product at the buyers' plant. This further enables the company to concentrate on its own core activities and delegate to others specific ways to solve tasks inside separate sub-systems.

Many companies use platforms to enable more variety with a reduced number of unique parts by standardizing certain components within the product. Since the suppliers' systems have become larger, and for this reason have greater influence on the impression and quality of the final product, a need to evaluate how their solutions affect the platform and how this is represented in computer systems is essential. This is needed not only to define the platform but also to represent the platform in the companies' product lifecycle management (PLM) systems. Since the mass customization era of today has generated too much information to handle, due to the representation of systems as separate parts and not as more generic descriptions, there has been an exponential growth of part numbers to describe these systems; new methods and tools are called for to handle these problems.

These new methods and tools need to handle the issue of trust which is important for development in joint ventures; no company would like to risk its intellectual property, but at the same time sharing of information is essential in order to be efficient.

One aim of this study is to capture how platform development is carried out today at an orginal equipment manufacturer (OEM) company in Sweden. Another aim is to capture influential aspects such as security and process management, to compare them with research in these areas, and to use this as a basis for future research about collaborative platforms.

It is easy to make the mistake of simply describing supplier collaboration as the integration of technical systems such as IT support and common platform structures. Although this article deals primarily with the technical part, one must not forget the need for people to meet in order to build the trust essential for joint ventures [START_REF] Mentzer | Fundamentals of Supply Chain Management[END_REF][START_REF] Davenport | Collaborative Research Programmes: Building Trust from Difference[END_REF]. The need to meet in person might be reduced in the future, since contacts between people over the internet have become an increasingly normal way to meet and maintain relationships. Advances in communication and information technologies have however already intensified the collaboration between partners in the supply chain, from smaller islands of internal operations to an interwoven net of operations [START_REF] Prasad | System Integration Techniques of Sharing and Collaboration among Work-groups, Computers and Processes[END_REF]. This evolution enables companies to build up collaborative platforms between customers and suppliers. Rapid change in customer demands actually forces companies to work more closely when developing platforms in order for the supplier to have up-to-date information to work with. In today's methods of collaboration, the integration of suppliers in the platform development process needs to aim at a few core suppliers and to build strong relationships with a small number of major customers over a longer period of time. There can be large benefits, provided the collaboration is realized with mutual respect for the other partner. Unfortunately, strong relationships take time to build; this makes it hard for dynamic organizations with high employee movement to achieve trust and respect for its partners. However, research shows that organizations, which invest in relationspecific assets, engage in knowledge exchange and combine resources through governance, may find large profits for both companies involved in the collaboration [START_REF] Krause | The Relationships Between Supplier Development, Commitment, Social Capital Accumulation and Performance Improvement[END_REF].

Supply chain management is not just about finding the right kind of relationships; it is also about finding what parts to produce in-house and what components and services are more beneficial to outsource. Mentzer [START_REF] Mentzer | Fundamentals of Supply Chain Management[END_REF] states that everything which is not core business, will not be core business in the future or is more expensive to produce in-house should be outsourced. Huang and Mak [START_REF] Huang | WeBid: A web-based framework to Support Early Supplier Involvement in New Product Development[END_REF] describe two kinds of relationships, purchasing and collaboration; even if purchasing can be profitable in a shorter time frame, collaboration usually gives superior benefits in the long run. For companies to get their suppliers to invest in relation-specific equipment, the buyer needs to aim at long term involvement [START_REF] Krause | The Relationships Between Supplier Development, Commitment, Social Capital Accumulation and Performance Improvement[END_REF]. According to Fagerstro¨m [START_REF] Fagerstro¨m | Managing Distributed Product Development. An Information and Knowledge Perspective[END_REF], it is also beneficial to involve suppliers early when working with an interface-based platform structure, as early communication concerning the interfaces can reduce cost originating from adjustment of the products later on. When managing development of new products, it is necessary to develop certain components in-house and others in collaboration with suppliers in order to obtain a product which has a competitive advantage. Typical products developed by the company itself from a platform perspective may be parts with high design content [START_REF] Ogrady | The Age of Modularity[END_REF]. Design of the visual appearance is something that has not yet become a part of supplier collaboration. Although the potential benefits of outsourcing design are not addressed further in this article, it might become an important part of future cooperative platforms, as suppliers become further involved in the development of new products.

Product Platform Development from Both Supplier and Buyer Perspectives

Product platforms and modular product development have grown in importance in recent years. Due to their ability to effectively lower cost in product development [START_REF] Huang | Modularity in Design of Products and Systems[END_REF], for example by carry-over or by using the same unit in several products, and by having clear interfaces, the platforms enable companies to rapidly produce follow-on products or new variants [START_REF] Meyer | Metrics for Managing Research and Development in the Context of the Product Family[END_REF][START_REF] Halman | Platform-driven Development of Product Families: Linking Theory with Practice[END_REF], and to respond to market changes, which facilitates more customer oriented offers. Other advantages are the ability of platforms to enable economy of scale benefits in production, and to utilize the resources of an enterprise more efficiently. Especially important from a supplier perspective is the possibility to let these suppliers take care of their systems by testing, upgrading and recycle them. This way the knowledge of the supplier can be used to the fullest without too much adjustment needed at the buying company.

PLATFORMS

There is not one unified way of describing what a platform is, since researchers often have their own definitions of how a platform relates to adjacent concepts such as product families, modules and brands [START_REF] Halman | Platform-driven Development of Product Families: Linking Theory with Practice[END_REF]. Simpson et al. [START_REF] Simpson | Product Platform Design[END_REF] define a product platform to be a set of parameters features, and components which remain constant from product to product, within a given product family. Product families are defined as groups of related products that share common features, components, and sub-systems; they satisfy a variety of market niches. Some parts are constant such as platform components, and some vary in order to configure variants. Although this description of platforms is suitable for much of the platform development found in industry, it describes traditional, part-based platforms, which has shortcomings in describing platforms that refer to manufacturing assets sharing, as well as organizational and computer support platforms. The restriction of limiting a product platform to a single family is certainly true for many industries, however, this needs some refinement, since much platform development, for example in the automotive industry, includes several brands, as shown in Figure 1. Robertsson and Ulrich [START_REF] Robertson | Platform Product Development[END_REF] give a wider definition of the concept, describing platforms as a collection of assets, components, processes, knowledge and people and their relationships, which are shared by a set of products. This describes our idea of platforms in a better way; involving people in the platform description might, however, be difficult. They may influence the product in a way similar to the way assets do, but because it is not a controllable parameter, it should not be a part of a company's platform structure. Here we considered two other ways to see a platform.

. A platform is an architecture which can support more than one product characterised by common structures, scaled variables and variable structures, controlled by design [START_REF] Gersenson | A Research Roadmap for Robust Product Family Design[END_REF]. This description expresses the need to exchange parts or components and also to scale products to suit specific customer segments. . A basic architecture comprises of sub-systems or modules and the interfaces between them [START_REF] Meyer | Metrics for Managing Research and Development in the Context of the Product Family[END_REF]. This description of platforms addresses the need for interfaces between interacting systems. Interfaces do not necessarily refer to physical interfaces; they can also refer to data exchange, heat transfer or various other factors influencing surrounding systems.

Platform development, according to Jiao et al. [START_REF] Jiao | Product Family Design and Platform-based Product Development: A-state-of-the-Art Review[END_REF], can be achieved in two ways, design for functional variety and for technical variety. The first aims to satisfy diverse customer needs, while the second aims at reducing the in-house variety. The two approaches, which require different strategies, describe the two advantages searched for in platform development, i.e., variety and the reduction of unique parts. There is also a difference between platforms for industrial products and those for consumer products. Industrial buyers often have superior knowledge of the product; they focus more on aspects such as performance and cost instead of the more vague criteria such as aesthetics or the status owning a product of a certain brand. It is also easier to identify the market needs, since the target group is much smaller in industry [START_REF] Jiao | A Methodology of Developing Product Family Architecture for Mass Customization[END_REF]. Industrial customers are the most common ones in supplier collaboration, however, an understanding of the OEM's customers is also important, since the user is not the other company but a third person from one of the OEM's customer segments. Building a platform can be seen as an evolutionary process needed because companies continuously have to renew their product families and eventually their platforms to adapt to changing market needs [START_REF] Meyer | Metrics for Managing Research and Development in the Context of the Product Family[END_REF].

MODULES

Modularity is closely connected to the traditional component-based way of looking at platforms [START_REF] Gershenson | Product Modularity: Definitions and Benefits[END_REF]. The definition of a module varies but it often relates to Suh's independence axioms stating that the solution of a functional requirement should not affect the solution of other functional requirements [START_REF] Suh | The Principles of Design[END_REF]. Huang et al. [START_REF] Huang | The Power of Product Platforms in Mass Customisation[END_REF] sees product architectures as either modular or integral. Modular product architecture has a one-to-one or one-to-many relationship between functional elements and physical structure, which follows Suh's independence axioms, while the integral product architecture is a complex coupled mapping of the two. Both architectures are currently widely used in industry. The present authors' opinion is that a modular design without the complex couplings is preferable, especially for complex products, not necessarily because modular products perform better but because they are more controllable, which makes development work easier. Huang and Kusiak connect the modules to the product architecture and discuss three types of modularity: component swapping, component sharing, and bus modularity with reference to changing components to get new functionality within the module. Components shared between several modules and the interfaces between these modules allow several combinations of products to be made [START_REF] Huang | Modularity in Design of Products and Systems[END_REF].

Gershenson et al. [START_REF] Gershenson | Product Modularity: Definitions and Benefits[END_REF] describes the Sosale and Hashemian view on modular design as an enabler for concurrent engineering, but to do this the overall design task has to be divided into smaller sub-tasks and the interfaces between them must be properly defined. Modular design can also offer benefits in the maintenance phase of a product, by allowing identification and replacement of separate modules. This description represents a product by using a platform of interfaces as specified in the platform section: it highlights interfaces and a holistic product view as a necessity to be efficient in modular design. According to Gershenson et al. [START_REF] Gersenson | A Research Roadmap for Robust Product Family Design[END_REF], interfaces have received little attention in recent years despite great interest in early modular research. Methods of defining interfaces are still not satisfactory, which is why further research on this is called for. The present authors believe that these interfaces must be better defined to more efficiently manage platform development.

COMMONALITY VERSUS VARIETY

There are not only benefits in building platforms: standardizing can sometimes lower the performance of individual products, since the platform is optimized from a holistic view of all the company's products, rather than each separate product [START_REF] Halman | Platform-driven Development of Product Families: Linking Theory with Practice[END_REF][START_REF] Simpson | Product Platform Design[END_REF]. Separate modules can be optimized for any given prerequisites but these does not always align with what is sought for in all variants of the final product. Building platforms can be seen as a balance between commonality and variety; too much commonality lowers cost but reduces the distinctiveness of each brand built on the platform. This statement refers to the common view of looking at platforms as a set of combined modules, which is not necessarily the case when a platform refers to a given production line or to development processes. Many platforms found in industry, however, are built on a modular exchangeable part concept, and there are many benefits to using this platform description. This makes the commonality versus variety balance important to address, to reach a broad customer segment with products that are experienced as unique ones. Berglund et al. [START_REF] Berglund | Utilising the concept of Design's Bandwidth to achieve Product Platform Effectiveness[END_REF] states that this does not necessarily need to be a linear relation. Figure 2 shows the possible design choices which show that a certain level of variety can have different levels of commonality depending on standardization level, use of unique parts and such factors that influence this correlation. Some sort of trade-off is, however, still necessary. Understanding potential changes in technology and market factors and how these affect the platform can improve the robustness of the platform, making it possible to meet future needs [START_REF] Gersenson | A Research Roadmap for Robust Product Family Design[END_REF].

PRODUCT VARIANCE AND PLATFORM CONFIGURABILITY

The main driving force for platform-based development and manufacturing is the possibility to combine customization with economy of scale, at least to a certain extent. The means to achieve this is reuse of common resources in multiple customized product variants. This is in practice described today in terms of 'carry over' or 'commonality' and means utilization of common parts in different customized variants. By doing this it is possible to generate new product variants without having to develop all of the parts contained, just the ones that are variant specific. The rest can be 'carried over' from existing products or from a common core of parts in a product family or from families involved with other brands, in the product platform. Configuration of product variants is thus achieved by combining the parts in the platform with variant-specific parts. Although much has been gained by this strategy, it has its limitations; it needs to be refined to prevent the number of parts from becoming to large.

Claesson [START_REF] Claesson | A Configurable Component Framework Supporting Platform-Based Product Development[END_REF] describes in his doctoral thesis an alternative strategy for coping with the increased demand for customized variants without increasing the number of parts to manage to the same extent as using a part-based platform definition. The proposed strategy is based on a more abstract and knowledge-based platform definition consisting of linked structures of 'configurable components (CCs)', see Figure 3. Each CC is a configurable system that is related to other CCs, and it can be instantiated by assigning values to its variant parameters (VPs) through a 'variant parameter interface (VPI)'. The result of an instantiation, the 'configuration request definition (CRD)', is transferred to other used CCs or to external applications such as PDM and CAD systems. An instance of a product or a sub-system that shall be manufactured is specified by its variant defining parameters. With this input the system of CCs involved then automatically generates the variant defining information (i.e., part numbers, instantiated CAD models, material specifications, and valid reference documents) needed for preparation of production.

COMMONALITY (%) VARIETY ∞ 0 100 Figure 2.
The correlation between commonality and variety is not necessarily linear but covers a field depending on different platform strategies [START_REF] Berglund | Utilising the concept of Design's Bandwidth to achieve Product Platform Effectiveness[END_REF].

To function as stated, each CC must carry three kinds of knowledge about itself:

1. Knowledge about its origin, i.e., what it should do and be, how this is realized and the reason for the solution chosen; 2. Knowledge about its interactions with the external environment; and 3. Rules specifying the composition, functionality and external interactions of the instantiated CC Knowledge item 1 is realized by using an enhanced function-means tree [START_REF] Andersson | Computer Based Requirements and Concept Modelling -Information Gathering and Classification[END_REF] which reflects the functional requirements and constraints, stated in the product specification, and shows the design solutions chosen to fulfill these design criteria. Knowledge item 2 is realized with special interface design solutions for handling the external interactions. Finally, the knowledge item 3 is realized with a configuration rule set (CRS) containing programmed procedural and/or inferential rules linked to the CC object and its interactions. A platform definition based on this kind of knowledge carrying CCs provides much more configuration flexibility than a part-based defined platform. A CC-based platform is, furthermore, much more robust, as the reuse of CCs instead of reuse of parts makes it possible to have the complete CC knowledge contents available for redesign to meet new demands.

Computer Support in Collaborative Development Networks

Computer support has become a vital part of most developing companies' tools. There is also much need for computer support between companies to facilitate efficient and work as one unit. Product lifecycle management tools have grown in importance due to their capacity to handle information sharing [START_REF] Stark | Product Lifecycle Management, 21st Century Paradigm for Product Realisation[END_REF][START_REF] Xu | A Web-enabled PDM System in a Collaborative Design Environment[END_REF].

Sub-contractors can be integrated very effectively by combining processes and, by opening up the PLM system, better control over all parts of a product lifecycle can be achieved. Using neutral data exchange formats such as STEP and XML, or more geometry related standards such as IGES, is intended to reduce the differences between dissimilar kinds of software used at the companies throughout the supply chain [START_REF] Saaksvuori | Product Lifecycle Management[END_REF]. Even if close involvement by sharing data is possible, it is not yet an alternative for all companies. Just because something can be done does not mean it should be done. Intellectual property rights, PLM systems that are not the same at different companies, and problems with keeping all information while transforming files are some of the difficulties that still need to be solved to make integration of databases work efficiently.

Supplier integration can, however, be done in two ways. Either files can be transferred separately or files can be shared between the OEM and supplier through integrated databases. Both choices have their benefits and disadvantages. To transfer files is easier in the start-up phase and it is easy to make changes. The advantages of the database integration, on the other hand, are that it works in real time and is automatically updated, which reduces the risk of engineers working with old data [START_REF] Saaksvuori | Product Lifecycle Management[END_REF]. In computer support for collaborative development, more attention has been given to tools for data transfer using systems such as Net-meeting and e-mail than information sharing tools that can create more effective collaborations. Much information is still sent between different parties information sharing will probably not replace information transfer but it will be more of a support to it.

Secrecy Issues in Collaborative Development

Security is often considered important in collaborative projects but, unfortunately, this matter is often given lower priority when compared with usability [START_REF] Saaksvuori | Product Lifecycle Management[END_REF][START_REF] Shimeall | Software Security in an Internet World: An Executive Summary[END_REF]. The security measures are often adopted later, when the risks of a new system have been evaluated through use. Much of the security in modern companies is oriented to firewalls, which are intended to block access, thus reducing the possibility to collaborate in real-time projects. Firewalls are also difficult to configure, a problem which is hard to solve, especially for smaller companies [START_REF] Gong | Enclaves: Enabling Secure Collaboration Over the Internet[END_REF]. Once the firewall is configured, access rights have to be distributed which can be given to for example specific persons, or to roles in the company [START_REF] Wang | Intellectual Property Protection in Collaborative Design Through Lean Information Modelling and Sharing[END_REF]. Having access connected to certain rolls needs to be used in larger companies where project group members constantly change. Mitrovi'c [START_REF] Mitrovi'c | Handbok i IT-sa¨kerhet[END_REF] gives three factors which affect security: people, processes, and technology. Since people are hard to control, many of the successful methods today are found in access management and file encryption for file transfer [START_REF] Mitrovi'c | Handbok i IT-sa¨kerhet[END_REF][START_REF] Patil | Cross Organizational Workflow Management Systems[END_REF]. This is often a good approach but when sharing data is critical, just locking up information is not without disadvantages. Engineers constantly get into situations where they have to consider what information they can share with suppliers and what information needs to be kept secret. Far from all information is given by shared databases where the access rules apply.

Process Management in Multi-organizational Projects

Many organizations today are giving more effort to supplier development programs to improve supplier performance [START_REF] Modi | Supplier Development: Improving Supplier Performance Through Knowledge Transfer[END_REF]. This improvement is, however, not just about finding tools for collaboration using the same CAD software or using websites to send information. It is also about how thing are done on a process level.

Although there are some differences in research when defining process management, according to Kotzab and Otto [START_REF] Kotzab | General Process-Oriented Management Principles to Manage Supply Chains: Theoretical Identification and Discussion[END_REF], some parts are similar. Process management addresses the whole supply chain and describes constant value-adding steps and deliveries in a uniform direction. Mentzer [START_REF] Mentzer | Fundamentals of Supply Chain Management[END_REF] also involves suppliers when defining process management: as the activity of managing the resources and processes that generate products and services; This also involves suppliers, since no single company does everything by itself, as there are suppliers taking care of parts of the business activities. Clearly, suppliers need to be taken into consideration when planning a company's own development process. Business process management should concentrate on finding a systematic approach to designing, prioritizing, managing, controlling, and monitoring. This can help companies to reach superior competitive standards [START_REF] Zairi | Business Process Management: A boundary less approach to Modern Competitiveness[END_REF]. The relationships between operations are the basis on which exchange of products, services, information and money is conducted. Relationships with suppliers helps to generate a smooth flow between operations and processes [START_REF] Mentzer | Fundamentals of Supply Chain Management[END_REF]. If the organization is to function as one unit, then everyone in it needs to know what the common purpose of the organization is and how their effort contributes to the main goal. This understanding of the goal needs to be communicated as a statement of purpose. When the company and its suppliers are viewed as one system, it is easier to see the interdependencies among people and departments [START_REF] Stamatis | Advanced Quality Planning: A Commonsense Guide to APQ and APQP, Books 24Â7 -ITPro & BusinessPro[END_REF]. The work of a supplier is used by other groups in the company forming a linkage between them. Methods for integrating suppliers in the company's processes are important for any companies that want to be competitive in the diverse organizations of today.

Research Approach

The investigation reported here was made at a multinational Swedish truck manufacturer having several brands that all share the same platform. The company has numerous suppliers, and its core competence is described as their knowledge in handling the demands made on their type of products and putting all systems together. Further, this company works with highly customized products and they rarely produce two trucks that contain exactly the same components. The reason for this is very different customer demands depending on the various areas of use for this type of equipment. The suppliers of this company are naturally quite different in size as well as complexity of their products. Considering this, the suppliers are expected to have very different affect on the platform developed at the OEM. Interviews were conducted with 18 employees, working at several departments. People from management, supply chain collaboration, product, platform, and process development, were purposely selected for interviews. The somewhat heterogeneous group were chosen to study how companies can work together with suppliers to develop efficient platforms.

The main themes for the interviews were how the company investigated works with supplier involvement in platform development today and what issues must be addressed to be more efficient in supplier collaborations in the future. A semi-structured interview, guided by a predefined questionnaire, was used; the participants were allowed to speak freely about the given questions, which included the topics listed here. Supplier collaboration: How is supplier involvement addressed at the company, what kinds of methods are used, and what aspects should be taken into consideration when collaboration becomes joint ventures? Platform development: How are platforms built up and how should they be designed to make supplier collaboration work efficiently, when the development of new products becomes increasingly integrated?

Information exchange: What kinds of tools are used today, what are their benefits and disadvantages, and how could they be improved? Sensitive information: Most joint development ventures are processes which need much communication of sensitive information, but how does the company work in securing the communication flow and intellectual property rights? Process management: Most successful companies have processes to help them obtain the desired products. This is a way to regulate the quality of the products produced. How can process management be extended to function more smoothly with suppliers?

Results

Naturally, the material from this kind of study gives a multi-faceted picture of collaborative platform development. The results presented here are a summary of the most relevant and important results found during the study. They are grouped according to the interview topics and include experience of work procedures and tools in use today and potentials for improvement.

Collaboration and Information Exchange in Practice

Involving suppliers in product development has been found an effective way to utilize knowledge and manufacturing resources and to spread development costs and risks. Involving suppliers platform development has not yet progressed as far because the benefits from this are not as obvious. The OEM wants to be able to choose from several suppliers when selecting a development partner, something that might be difficult when the platform has been developed in cooperation with a certain supplier. The company studied has, however, started to involve a few suppliers in the platform, since they are regarded as very important suppliers that have substantial effect on the efficiency of the final platform.

Several kinds of partnerships have been tried by the company studied, all with their benefits as well as their limitations. One alternative is to let a representative of the supplier work as a resident engineer, sitting physically at the OEM, and being allowed to see the same information as the team members employed by the OEM, see Figure 4. However, this type of collaboration does bind the company closer to the supplier, which makes it more difficult to replace that supplier, if other suppliers can offer better products in the future. It is also hard to control access rights, due to the constant flow of personnel moving in and out of the company on a daily basis. A second method of collaboration is satellite offices, where the suppliers are placed at their own sites, but they work through secure lines inside the OEM's PLM solution. This is used only for consultants' services, since it could endanger the competition between suppliers of the same parts in purchasing situations. Another problem with this type of collaboration, for suppliers of physical components, is the OEM's reluctance to let the supplier handle the forwarding of information, to its own suppliers, directly from the OEM's PLM solution. A third approach is to work at separate locations and transfer information by common mean of exchange (e.g., e-mail), which makes it easier to secure the exchange but harder to keep all information up to date.

Much collaboration today is based on traditional face to face contacts. Although new tools can facilitate the communication and collaboration with suppliers and help overcome geographical distances, this is still considered to lack effectiveness when building trust between people. Collaborative work requires interpersonal trust and involves many agreements, meaning that participants need to meet face-to-face to really have a constructive dialogue. Furthermore, as argued in other case studies [START_REF] Moenaert | Communication Flows in International Product Innovation Teams[END_REF][START_REF] Almefelt | Requirements Management in Practice -Findings from an empirical study in the automotive industry[END_REF], personal relationships and trust between individuals are prerequisites for electronic communication to be efficient. There are concerns regarding the security of the information flow and the risk of sharing sensitive information about the companies' core competences. This is especially significant, since many suppliers in these networks view each other as competitors; suppliers which also collaborate with competitors to the OEM and can use gained information in other partnerships. For example, a resident engineer often access information about adjacent systems from other suppliers and obtain information that might be useful in future collaborations with other companies; this is especially important in the early stages of development when new technology has been developed

but not yet used. This dilemma is a barrier to efficient information sharing, although all involved understand the need to collaborate. Sharing information and securing the flow effectively has often been difficult and time consuming.

Let us distinguish between existing collaboration and what the company investigated is trying to achieve. Today, different suppliers affect the platform in different ways, meaning that some suppliers, that deliver critical systems or technology, are able to dictate the surrounding interfaces of their product and the OEM has to use them since there are no alternatives. Most of the time, however, the supplier gives input, using current and up-coming solutions as aspects to consider, and the buyer later develops the platform to suit its current and next product portfolio. The design environment is later delivered to the suppliers as interfaces built up by surrounding parts. The aim is, however, to develop an interface description of the platform, which allows the supplier to see only what the requirements are on their product regarding interfaces and requirements, to reduce the risk of letting suppliers see each others' solutions. The interfaces between suppliers are also expected to be managed by the OEM, since it needs to handle all of the interfaces in order to have a complete structure and to negotiate conflicting requirements on interfaces. Today much information is shared by e-mail, phone calls and, sometimes on secured lines when handling sensitive information such as CAD files. The information does, however, tend to be too comprehensive because no one wants to be responsible for sending too little information and, by doing so, become responsible for expensive delays. Instead too much information is sent; that can be hard for the supplier to interpret.

In recent years, more effort has been put into building a shared database between an OEM and its suppliers, which allows some chosen development suppliers to change and save parts directly in a system connected to the OEM's product description. The system shows a smaller section of the entire product for the supplier; a section that is continuously being updated by the OEM. This way the supplier never works with old data. However, this method of conducting collaboration requires very effective mechanisms to retain intellectual property rights to different partners in the supply chain; this applies especially to the suppliers, since they cannot delimit a smaller design environment in the same way as the OEM can because suppliers' whole products needs to go in to the OEM product model but the OEM only need to show the supplier the part of the final product that affects its development work, thereby reducing the risk of showing to much data to their suppliers. It has, however, been found difficult let a supplier take over its part of a product, without observation and verification by the OEM, which would force suppliers to show their data. Even though the company does their best to achieve complete requirement specifications and give suppliers enough information, sometimes this is simply not enough. New situations can appear during the work on the project and change the prerequisites, forcing the partners to find new solutions through constant contact and discussion with suppliers.

Platform Development at the Company

Interfaces form the starting point when the company defines the platform. The specified interfaces are broken down from an all-embracing level all the way to specified assemblies and modules. Even if the platform is described as the interfaces between the modules, not the modules themselves, it is hard to separate the two since the advantage of a platform often lies in selling higher quantities of the same products.

The company implements its platform gradually since this puts less stress on the organization before release. It is also considered less risky since the investments on the projects get reduced. Quick change from one platform to another is also considered more suitable for companies with large series of products with less variety, since it is easier to define a specified platform than a more generic one that must cover a wider range of variants. Platform development at the company is usually carried out by letting different departments and organizations give input about what they expect from the platform to meet their requirements and wishes. Since the basis of this work resembles putting assemblies together, the need to involve suppliers has grown because they are expected to take greater responsibility and act more as system integrators, by designing, manufacturing and delivering larger modules than previously. However, they are not yet directly involved in the platform work today but only by influencing the OEM. There are a few larger suppliers that dictate how their part should fit into a product but, most of the time; the supplier has to work with predefined requirements given by the company. The interface approach has not yet come very far in the everyday activities of the company. They wish to work with platforms in a way similar to that used with parts and build interface structures that can be viewed in digital mock-ups (DMU) the same way as parts can. It is considered desirable if aspects other than geometry could be integrated in the platform, such as temperature, light resistance and other factors that gives the conditions in which the suppliers systems has to work. This kind of platform description, however, is far from realized at the company.

Platform development usually follows a curve over time towards more and more unique parts. The platform is built for flexibility but it is hard to anticipate every possible future solution: over time a growing number of specialized solutions emerge. After awhile, the company needs to spend time protecting the platform, when the demand for variants increases due to new technology that the platform cannot incorporate. At this point a new platform is needed; it is time to start the next generation. When designing platforms for several brands, it is also important not to let the commonality of the platform harm the separate brand identities. Different core values can often make this balance hard.

Computer Support for Collaborative Projects

Nowadays, all communication with suppliers is carried out using different kinds of electronic data exchange. Preferably the same CAD software is to be used, but neutral formats are acceptable if the supplier can guarantee the quality of the model. It is problematic, however, to get suppliers to adapt to the company CAD system, especially when small series are called for, since the time and investment to get new CAD software up and running might be too costly. Handling suppliers' products through organizing files, which is the basic function of PDM, would not necessitate the same CAD software, but continuous work with the models and organization of the DMU's do. It is difficult with diverse CAD support in the supply chain since the information about how the model has been built often gets lost when changing file formats on CAD files. This makes it harder to break the model down into subsystems. The more comprehensive a delivery unit from a supplier is the larger are the number of variant combinations that need to be managed to describe it. If the structure of the subsystem is lost or not shared and the systems supplied gets larger and larger then the units cannot in practice be represented by article numbers as usual PLM systems intend them to be. At present, the difficulty in managing this causes much problem for the company.

To help suppliers and securing information it is possible to make a wrap around sensitive parts so that they don't show when the supplier views his design environment, but this is time-consuming work given that it is a part by part operation which is not suitable for widespread systems like for example electronics.

Further information exchange by e-mail is suitable for some types of collaborations such as the traditional kind in which the supplier develops smaller components with low variation inside the products supplied, or a collaboration in which the supplier simply gives feedback on given solutions. In short, e-mail exchange is considered more suitable for work with smaller parts then it is for entire system solutions. The reason for this is that it is difficult for the PLM-systems to handle the suppliers' structures, since suppliers are not interested in giving the OEM more information than it needs; this means that the product structure at the OEM might have information shortage in it, given by the systems supplied. In other words, supply chain management is often not carried out as efficiently as the used PLM system intends. Good understanding of how to build up the product is also needed when designing the separate systems, in order to let the OEM strip the modules of irrelevant information when testing the product by different sorts of virtual verification and validation.

Product lifecycle management is used to gather all information about companies' products under one roof. For this reason the company in this study has tried to integrate all departments in one single PLM system. However, changing systems is not without problems: many systems address different fields in the lifecycle of the product, see Figure 5. It is hard, if not even impossible, with today's systems to get a common view of a preferred system, even within the company studied. With this in mind, it is important, when developing new computer support intended to work in collaborative networks, not to build it around a specific system, since most companies have their own systems that address their specific needs. Even if a supplier could be persuaded to change systems, it is considered to be at the cost of lower efficiency at that specific company; however, these suppliers still have to collaborate with other companies using different systems, thus losing much of the benefits of changing the system in the first place.

To address the upcoming need to let suppliers take care of their own parts of the product model with reduced information sending from the OEM, new tools were introduced at the company studied. Using a common database, the information will first go to a place where the OEM can review models before some or all data goes forward to the OEM's PLM system if approved. The intention of the OEM is to establish graphical boxes where the suppliers can work by using updated input information from the OEM, and at the same time have access rights only to the relevant box or boxes of the structure. the company's process, but managing the security often goes in the opposite direction and aims to secure intellectual property by restricting access to various information considered sensitive. This issue has become increasingly important due to emerging markets with economies that have grown faster than the legal structure and company culture needed to support collaboration with partners. It has been found difficult to address the appropriate user privileges in the extended enterprises between several companies. This is mainly due to the complex situation of having several types of suppliers, all with different access rights and with new partners and employees constantly moving in and out of the business.

The most difficult task to manage often involves other companies' intellectual property. This may seem like very arrogant behavior from the OEM, but it is actually quite natural. This company as well as many other OEMs does not perform cutting edge technology development. Their ambition is to be great at putting sub-systems together and to handle possible problems related to that. The cutting edge technology is developed by the OEM's suppliers who are experts within their specified fields. When competing companies work together in a project supporting the OEM with different components for a given product, they hear and have access to information, about each other's products, which could be used in other concurrent projects with other suppliers if not carefully managed. A need for trust has arisen not just between the OEM and its suppliers but also between suppliers, which are sometimes competitors, working together with the OEM, see Figure 6. The company finds it hard to expect this trust from its suppliers, but have not found any way to solve it with the IT support offered today.

The company participating in this study divides security into two types, internal and external security. Internal security focuses on the integrity, stability and performance of the computer system. External security concentrates on confidentiality and handles access rights and protection of data. To handle access rights, four types of information are connected to each personal user ID. First of all the user has a project connected to the ID used. This defines what the person is allowed to see. Secondly, a role is given to the person; this defines what the person is allowed to do in the system. Thirdly, a mask is set to define what the person is allowed to see on the screen. Finally, an organization which defines what a person is allowed to change in the system. However, it is very difficult to make proper restrictions. People come and go all the time at the company, and it is hard to know what other projects the suppliers work with, since they do not always mention this if it is not beneficial to them. Another way to secure data is to classify it in multiple layers of confidentiality. If information has to be shared anyway, then a wrap can be made to hide secret information by making the picture fuzzy, so the supplier can work only with the outer conditions. The company is working on a system by which the supplier is supposed to allow user access to its own parts, as a way to involve suppliers in these difficult decisions. However, many companies find it hard to divide their information enough, making it hard for the OEM to give the right access rights to suppliers affected by these systems.

Process Management: Not a Single Company Issue

Large companies such as the one in this study usually follow a procedure to describe how work is intended to be performed in their projects. However, these procedures, which are often optimized for the company's own work, are not coordinated very well with its suppliers. The company participating in this study has seen the need to coordinate at least some releases with their suppliers, but in a longer perspective they see benefits in changing to a more standardized process such as Advanced Product Quality Planning (APQP), which is a general process for automotive companies. The trade-off is, however, difficult since the process is often considered one of the advantages that a company has over their competitors. For the moment the company uses some checkpoints but the process of the supplier is intended to be affected as little as possible. To coordinate checkpoints are sometimes very difficult. Smaller companies can be controlled and told what to do, but larger suppliers that are not dependent on the investigated company might not be as willing to change process; this makes sewing a process together for the whole supply chain difficult. The process for collaboration currently developed at the company is advancing in small steps in order to get the suppliers to follow them. It should be noted that even small implementations become quite complex due to the large network of suppliers who are affected by such a process change.

Competitors in some areas

Joint venture at the OEM Figure 6. Trust is not just an issue between two companies but often a multi company issue in joint ventures.

Conclusions

Given the five areas of interest in this study, some conclusions can be drawn to understand how collaborative platform development needs to be conducted. The company studied has tried several strategies for supplier collaboration; all of them present various problems of sharing the right information with the right person. The problems are mainly due to the size of the company and the amount of suppliers, sometimes with hidden agendas, that collaborates with the company. The part-based paradigm used in the automotive industry does not support collaboration very well, both since it is difficult to understand what information affects different suppliers products and due to the difficulty of sharing information when the information is connected to the very private CAD files. A carefully developed interface-based platform could, however, enable better and more open communication and even out the strong grip the OEM has over its suppliers' products from an information sharing perspective. In this model the OEM still must have total control over the interfaces since it is responsible for the total solution but a constructive dialogue with suppliers will remain an important contribution to the platform even in the future.

Platform development at the company has started to orient collaboration to interfaces, an approach that has been confirmed by previous research [START_REF] Fagerstro¨m | Managing Distributed Product Development. An Information and Knowledge Perspective[END_REF][START_REF] Gersenson | A Research Roadmap for Robust Product Family Design[END_REF] as a beneficial way of developing platforms. There are, however, little or no support for doing this with today's computer support since it is mainly supporting development of numerous single products and not the more generic concerns regarding platforms. Having a CAD-based platform description only supports the geometric parts of platforms, even though this is an important concern, other aspect such as how a product interacts with its surroundings concerning heat transfer, sending and receiving of signals and electricity, and other aspects of the systems interface to its surroundings has to be treated with other systems. This makes the interface platform scattered and difficult to overview.

Considering the platform from an information exchange perspective, new methods are also required to handle product structures in PLM systems. Many products provided by suppliers, which have historically been represented by article numbers, have now become complete systems with hundreds of variants. Designating these products with traditional article numbers actually moves the development of multiple variant structures backwards, since each variant of a product structure needs to be represented by a complete product structure for every variant developed by the supplier. This sometimes makes the management of the data almost too much to overcome for the OEM; this calls for product structures where the traditional hierarchal tree structure is replaced by a structure where the features are handled separately and not hierarchal [START_REF] Claesson | A Configurable Component Framework Supporting Platform-Based Product Development[END_REF].

Companies may risk loosing sensitive information when sharing product models with other companies. This is one of the major concerns when collaborating in complex networks of suppliers. Even if tried to be controlled through access rights information leaks on meetings and in the daily project work. Today, trust is considered as a necessity for collaboration but the trust between suppliers within a project that are competitors outside the project can not be expected to trust each other. Once again this problem might be solved by implementing an interface-based platform description. This way; discussions can revolve around the interfaces or conditions the different suppliers put on surrounding suppliers and not the private and sensitive information contained in the CAD assemblies, CAD files shows how problems has been solved within a module, which is often redundant information for the competitor to solve its tasks.

During collaborations it is also desirable to optimize the process as well. When doing this the whole supply chain must be considered to make the projects go forward efficiently. Managing the process does, however, force the company to balance the benefits with having the same process against the risk of lowering performance of individual suppliers if forcing them to use an un-optimized process. Today the company studied synchronizes some checkpoints with its suppliers and but does not control the process in any other way. If this is suitable or not depends on how the company intends to work and if this wish fits a standardized process. This must be considered in each single case, no results from the study showed that a certain approach is better than another. It only showed that they have to be synchronized.

Interfaces as a way to describe platforms have been adopted in the studied company; a description also advocated by researchers in the field. However, even though the acceptance for this platform description is high, there is not yet good support to address these issues in a satisfying way with modern PLM tools. This work gives some areas that from a supply chain perspective would greatly benefit from the development of this type of platform tool.

Future Work

A product model, which is under development at Chalmers University of Technology, aims to support platform development using 'configurable components' as stand-alone parameterized modules. This way, suppliers can take care of their own parts and assets, while still being connected to the complete model upheld by the OEM. By this means, the problem of companies showing sensitive information to a third party is reduced. The model is intended to provide a description much like the black boxes found in programming, which solve a problem but do not tell the outside user how. With a more generic product description, the work of reducing the number of parts, while still maintaining a wide range of variants with a smaller number of component descriptions, can be achieved.

Figure 1 .

 1 Figure 1. Global organisations can use platforms that include several brands, each with their own families.

Figure 3 .

 3 Figure 3. The configurable component concept.

Figure 4 .

 4 Figure 4. Different collaborations tried at the OEM.

4. 4 Figure 5 .

 45 Figure 5. Different PLM-systems address different stages of the lifecycle.

A. LINDQUIST ET AL.


Davide Di Domizio

Paolo Gaudenzi
email: paolo.gaudenzi@uniroma1.it

CONCURRENT ENGINEERING: Research and Applications A Model for Preliminary Design Procedures of Satellite Systems

Keywords: Space systems, space sub-systems, concurrent design, system engineering, design procedures

The article describes a model for satellite systems preliminary design based on European Space Agency concurrent design approach. Space systems preliminary design aspects based on a concurrent engineering methodology are first briefly illustrated. A general description of a typical space system and its subsystems is provided and sizing criteria are provided for each subsystem. The design procedure is formalized according to Unified Modeling Language formalism. A description of the implementation of the model and some conclusive remarks are then included.

Introduction

Since 1998, the European Space Agency (ESA) has been developing preliminary studies for new space missions using the Concurrent Design Facility (CDF) as described in Bandecchi et al. [1, p. 1,2; 2, p. [START_REF] Bandecchi | Concurrent Engineering Applied to Space Mission Assessment and Design[END_REF][START_REF] Bandecchi | The ESA/ ESTEC Concurrent Design Facility[END_REF][START_REF] Bacchetti | Spacecraft Electrical Power Subsystem Design Utilising the ESA-ESTEC Concurrent Design Facility[END_REF]. Concurrent Design (CD) is a methodology that allows the parallel design of several subsystems, managing their mutual interactions, which are then assembled to form an engineering system. The use of this methodology is particularly useful in aerospace engineering, where the design is challenged by the presence of very complex engineering systems. ESA has adopted this methodology for the early stage of the design of space systems, following the example of other space agencies, like NASA, and aims to promote the use of this approach, also for more advanced design phases, in the frame of the European Space Industry.

The success of this approach is witnessed by the great reduction of the time needed to produce reports for preliminary analyses of very complex missions -like science or exploration missions -keeping or improving the high level of design and the quality of studies and even facilitating the communications between designers and customers. In ESA, the duration of a pre-Phase A analysis is now between 3 and 6 weeks against 6-9 months about 10 years ago.

In the context of space engineering the adoption of CD approaches generated a series of advantages: time savings, reduced errors in sizing, better cost prediction, and a better compliance to mission requirements; however, the performances of the CDF are the most interesting aspect. The success of CDF approach dwells in the cutback of the time to produce a pre-Phase A study. The space system is divided into several subsystems assigned to specialized engineering units which manage the design of each part; obviously the design of each subsystem is strictly correlated with the others: an information flux is necessary. In these preliminary phases, each subsystem can be characterized by a series of 'design parameter', which describe its most relevant physical and technical properties. Design parameters are the information exchanged during CDF session among engineering units.

This design approach requires hardware and software resources, as implemented by ESA in the CDF releases in the European Space Research and Technology Centre, but before that a clear description of the system and of the sizing and dimensioning criteria has to be adopted for the overall system, for the payload, and for each bus subsystem. Since the design develops in a concurrent framework, all the interactions among subsystems are required to be well documented too. An effective data modeling will produce clear interactions during the design phases and an easier and more efficient exchange of information [3, p. 2000], solving the problems encountered in data transfer among different areas, as already discussed in [START_REF] Vergeest | Design Model Sharing in Concurrent Engineering: Theory and Practice[END_REF]. In addition, it furnishes a successful and tested answer to meta-data description as requested in [START_REF] Prasad | Information Management for Concurrent Engineering: Research Issues[END_REF], improving team coordination in contexts where a different framework is already applied [START_REF] Gary) Chen | An Integrated Methodological Framework for Project Task Coordination and Team Organization in Concurrent Engineering[END_REF].

The aim of the present article is to describe the model for satellite systems preliminary design developed at Universita´di Roma La Sapienza in the frame of the professional Master Course in satellites and based on ESA concurrent design approach. The study is focused on radar Earth Observation missions. In fact there is the need to focus on a certain class of satellite systems with well-defined requirements to obtain a formal complete description of the model for preliminary design. However, this has not to be considered as a limitation to the generality of the present work illustrated which is focused on the procedure followed during the design. Therefore, a general description of the design and of the design variables is provided along with their mutual interactions in the dimensioning and sizing schemes provided for each subsystem and implemented according to Unified Modeling Language (UML) formalism.

In the following paragraphs all the steps followed to accomplish the design are described. First of all, the common approach to space systems design is briefly illustrated, followed by a slight description of the case study use as reference in this work. A concise explanation of the instruments used to document the design procedure is then provided. The section entitled 'Modelling the design procedure with UML diagrams' represents the core of the present effort: each diagram produced in the design phase is shown and described. A description of the implementation of the model and some conclusive remarks are then included.

The Pre-Phase A Design Process of a Satellite System

A space mission can be described in terms of space, ground and launch segment [START_REF] Larson | Space Mission Analysis and Design[END_REF]. The space segment (the spacecraft) consists of a payload and a bus, composed by several subsystems. Payload is the set of instruments used to meet the objective of the mission: observing the Earth, broadcasting communications, or analyze the atmosphere. The bus has several aims concerning with the functionality, operating survival, and the efficiency of the payload in the space environmental conditions.

Ground segment must interact from ground with the spacecraft both for the payload and for the bus purposes and is responsible of actions like:

. Receiving and analyzing the telemetries of the spacecraft to monitor its operating status . Send commands to the spacecraft when needed . Receive payload data transmitted from the spacecraft or, conversely, transmit data to the spacecraft payload.

The ground segment also operates during the launch phase, a very critical phase of the spacecraft life.

The activities of the launch segment are related to the phases of a space mission that safely takes the spacecraft from the earth surface to the final orbit. The space transportation system is very complex and comprehends both the launch vehicle and the launch basis, connected with the ground segment.

The procedure proposed in this work is focused on the preliminary design of the space segment.

During the first stage of the process of spacecraft design, mission team analyzes mission requirements and produces system and payload constraints for system and payload specialists. These requirements regard the choice of orbit properties, the lifetime, operations, and the main features of the instruments (e.g., resolution or revisiting time in earth observation or link budget in communication). Clearly, this first step establishes a series of requirements and goals to be met for the payload and also sets the operational conditions to be performed by the bus, to allow the mission to be performed in an effective way.

A very synthetic description for the classes of functions to be performed by the bus can be illustrated as follows:

. Support the payload mass and all the masses onboard the spacecraft . Provide the propulsion needed for orbital manoeuvres and corrections . Provide attitude control to the spacecraft and point the payload correctly . Keep the payload (and the entire spacecraft) at the proper temperature conditions . Provide electric power . Provide on board data storage and elaboration . Establish a link to ground for transmitting telemetry and receiving commands It is usual in space system engineering to associate these functions to one subsystem of the spacecraft [START_REF] Larson | Space Mission Analysis and Design[END_REF]. A typical list of subsystems can be defined as follows: payload, Attitude and Orbital control (AOCS), structure, propulsion, data handling, thermal, power, Telemetry Tracking and Command (TT&C). In general, each subsystem is designed by an engineering unit composed by skilled staffs. A system engineering unit should also be considered with the aim of coordinating all the others, managing the system budgets (e.g., mass, power, link) and respecting the constraints that derive both directly from the requirements or from the mission analysis.

Each engineering unit, corresponding to a subsystem, the payload, or the system itself, has to follow simple sizing rules relevant to a specific discipline. In this effort, optimal values for the design parameter are obtained thanks to basic trade off criteria that most of the time optimize the required performance with respect to weight, power, and link budget.

All the engineering units of the list proposed abovealso including one Mission unit that is responsible for the characteristics of the mission to be realized -are the main players of the design phases. Each unit aims to design a subsystem, characterizing it by a series of design parameters: factors describing a specific feature of the unit. At the end of the design process a specific value will be assigned to all design parameters. Examples for design parameters are the following.

. System: Dry mass of the spacecraft, Mass of each subsystem, etc. . Payload: Band of the Synthetic Aperture Radar (SAR) Antenna, Digital data rate of acquired data, etc. . Structure: Structural mass, Body height, etc. Some parameters belong entirely to a single subsystem and are used only for internal evaluations of subsystem design; other design parameters, since a concurrent logic is assumed, are typically exchanged among subsystems: the computations of one subsystem are the input for the analysis of features of another one. (e.g., The design parameter digital data rate produced by payload is an input for data handling which has the aim to store data coming from payload).

The present model of satellite design aims to describe the interaction among the design units and allows a contextual evaluation of the effects that a change of a parameter adopted in a single subsystem could produce in another one. As an example, if the number or locations of batteries are modified, then the structural system needs to update its structural loading requirements while AOCS has to verify the new centre of gravity position and the new inertial rigid body characteristics. Moreover, for both units, a new value for the design parameters (and relevant geometries, material, component) could be necessary. The number of the design parameters, limited at a preliminary phase of the project, is assumed to grow along with the level of detail of the project.

As stated in ECSS publications 1 [START_REF]ECSS-M-30A[END_REF], from the Mission analysis (Phase 0) to Feasibility (Phase A) there are different aims to be satisfied, therefore there is a requirement for more details that is directly translated in a higher number of design parameters. The increasing need for more detail is also characteristic in the next two phases (B and C): preliminary definition and detailed definition. In the present article the application of the CD approach is limited to the first two phases (pre-Phase A study); however, the procedure described in this article could be valid to describe the relations among the components of a single subsystem when the design has entered more specific stages.

In the present work, the design procedure described before is implemented for to the pre-Phase A design of a spacecraft and applied to the specific space mission proposed in the next paragraph. At this preliminary design level it is important to choose the set of design parameters that, at the same time, are limited in number but effective in describing the system at the level of detail needed.

In the modeling effort, a special role is to be assigned to a database of components, where the information collected are the basis for giving a precise value to many design parameters. The efforts in design strategies developed by subsystem designer can have a real confirmation only from the support coming from the properties of existing components. Each designer has access to a database of components relevant for the topics that his subsystem deals with. Each of these databases is based on the following information: company, component type, performance, dimensions, and operational constraints.

Modeling Assumptions and Criteria

Case of Study and Design Strategy

Although the logic and the modeling procedure could be made very general, in this article an application is presented nearby the design procedure itself. The general method has been applied to the design of an Earth Observation Radar satellite. This system is a suitable architecture for a SAR remote sensing satellite mission, to be operated in a Sun synchronous orbit. The orbit requested was Sun Synchronous at 619 km and 97.878.

Table 1 [9, p. iii] summarizes the main requirements of the mission -the focus of design example. The design methodology takes advantage of teamwork activities performed during the editions of Master Course in Satellites of the Universita`di Roma La Sapienza.

Although the choices made during this example are very specific and lead to a precise design output, the logic and the modeling procedure could be considered as very general. Specifically, the Earth Observation (EO) space system has the aim to retrieve images and send them to the users following the requirements stated above, but while the design phase of each subsystem is oriented to achieve this aim, the design procedure is quite independent from the actual system, and could be generalized to other type of missions.

As described previously, the satellite in the example is divided in to several units and a specific engineering unit is assumed to be present. The complete list of units is: mission, system, payload, structure and configuration, power, AOCS, propulsion, thermal, TT&C, data handling, payload-data handling, and transmission. The strategy that is followed during the various phases of the preliminary design is managed by the 1 ECSS (European Cooperation for Space Standardization) Standards documents are intended to be applied together for the management, engineering and product assurance in space projects and applications. ECSS is a cooperative effort of the European Space Agency, National Space Agencies, and European industry associations for the purpose of developing and maintaining common standards.

system designer that has the principal aim to respect the requirement on the driving budgets. 2 Therefore, budgets are the summary descriptors of the entire system and usually can consist of mass, power, telemetry, propellant, pointing, or reliability budget. Mass budget is the most effective driving budget, because it directly influences the mission costs and is the one that influenced the example presented in this article. During the steps of the analysis, the system designer controls the mass values and the mass evolution of the entire system and of each subsystem. The design is assumed to be compliant with the requirements on mass budget when system and subsystems mass are stable and further iteration steps will not modify their values. In the case study, a name was assigned to a possible satellite complying with mission requirements: FINGERSAT (First Idea of a New Generation Earth observation Remote sensing Satellite).

UML Methodology and Diagrams

The documentation of the design procedure is a necessary support to the analysis describing the interactions between subsystems and the activities performed by designer during the design sessions. This documentation uses UML formalism, implementing static, collaboration and activity diagrams [START_REF] Fowler | UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3rd edn[END_REF][START_REF] Rumbaugh | The Unified Modelling Language Reference Manual[END_REF]. In this article, UML diagrams are then used to describe the Concurrent Design approach to the preliminary analysis of a spacecraft.

A class diagram describes the types of objects 3 in the system and the various kinds of static relationships that exist among them. Class diagrams typically show the properties (attributes) and operations (methods) of a class and the constraints that apply to the way objects are connected (associations). The relationships among classes may be of several types: generalization, aggregation, composition and generic associations.

In the next paragraph, each subsystem is documented by a specific class diagram and occasionally some functions are detailed by activity diagrams, while the interactions among subsystems are depicted in collaboration diagrams. The structure of class diagrams is fixed in this work. The central part of the diagram contains a class representing the subsystem that is intended to be described (payload in Figure 3). This is the general part of the subsystem; it may have some attributes and methods. Below this main class there are several other classes that are linked to it with associations one-to-one. These classes, named with the stereotype 'data exchange' 4 represent the part of the subsystem that exchanges values with other subsystems -the interface to other subsystems. Each main class may have several 'data exchange' classes, one for each subsystem that has to exchange data with (I.E. 'Payload_Power' interface class contains attributes that payload shares with power subsystem and methods that permits payload to evaluate these attributes -Figure 3).

A collaboration diagram (Figure 6) is a special class diagram that shows what happens to the objects when they are instantiated. 5 The links between entities represent messages, data, or actions exchanged among them.

Activity diagrams are a technique to describe procedural logic, business process, and work flow. In many ways, they play a role similar to flowcharts, but the principal difference between them and flowchart notation is that they support parallel actions.

Modeling the Design Procedure with UML Diagrams

In this paragraph, the most relevant diagrams of the design procedure are shown: their structure and organization are a feature of the procedure while the data contained depends on the example mission considered in this work.

All class diagrams are presented: one for each subsystem. This set gives a complete description of the 2 'A budget is a numerical list of the components of any overall system parameter. Thus, the total spacecraft weight budget would consist of the weights assigned to the payload instruments, the various subsystems, the propellant required, and typically some margin for growth' (4, paragraph 10.3).

3

Objects and classes are part of the common idiom used in OO-design, it can be easily translated to other fields of applications: in the Figure 1 the class 'Payload Component' is though as the classifier for all the components of the payload (objects): antennas, RF components, cables, etc.

4

A stereotype is a further description of a particular set of classes.

5

In the present case, the instantiation of a class occurs during the CDF session when the data are really exchanged among subsystems. A collaboration diagram describes the sequence of the activities and the involved subsystem of the data handling engineering unit. An activity diagram depicts the detailed procedure used by payload data handling and transmission for mass memory sizing.

The dynamic diagrams presented work at a different level: the collaboration one is an inter -subsystem document diagram, while the activity diagram is an intrasubsystem diagram.

Mission

The mission analysis engineering unit represents the part of the system that make the first analysis and translates the system requirements, shown in Table 1, in specific requirements for each subsystems. Therefore, in this diagram (Figure 1) there are not input labels because Missions generates only outputs and basically is not receiving inputs from other units.

System

The diagram that describes the activities of system designer is quite composite as it has to show the interactions with all the other subsystems (Figure 2). Therefore, the principal feature of this diagram is the presence of interfaces with all other subsystems. The common data that all subsystems exchange with the system designer is the mass budget. The system designer gives a mass budget to each subsystem, the latter has to develop the design respecting this constraint, and at the end of each CD step, gives the results to system designer in terms of mass budget and eventually mass margin. Another common datum that system engineering unit receives from all subsystems is estimated the estimated power need.

Besides, there are more specific data that characterize the interaction with other subsystems. In this domain, system gives to payload engineering unit information on pointing accuracy and on the range of power that can be furnished, while it passes to structure basic mass properties; it gives to data handling information on ground station and on the telemetry budget, to TT&C the requirements on error rates, and to propulsion the data on propellant mass. Power engineering unit receives from system the requirements on bus properties while AOCS gets some pointing requirements. Finally, thermal needs specific values of dissipated power on the various operating modes of the spacecraft.

The inputs to system are essentially mass budgets data except for mission that gives some information on the launcher and the chosen ground stations. Other more specific properties are given by other subsystems, as reported in Figure 4.

Payload

The payload engineering unit receives inputs from mission (orbital parameters, requirements on the EO mission) and from system (Budgets and pointing accuracy).

This special kind of subsystem has some characteristics (the name of the apparatus and redundancy Model for Preliminary Design Procedures of Satellite Systems concept) and there are many functions developed to evaluate some instruments features (Figure 3).

Then Payload also outputs many data. To system, as all other subsystems, it gives the payload mass and power budgets; for data handling (DH) it evaluates the data rate needed to collect imagery data, for power it calculates the power supply required by the instruments.

Payload is composed by several components. Each component has some thermal, power, and structural properties: i.e., operational temperatures, dimensions, and masses.

Structure

The structure subsystem unit includes also the configuration aspects, that sometimes are considered as a separate field of expertise for the complexity that the geometry of arrangements and interfaces among all the parts of the spacecraft could reach. This unit receives inputs from all other subsystems. The properties received are in the following category: dimensions, mass, position suggested, and denied during the configuration phase.

Obviously, structure not onley gives information the to system, but also to other subsystems: to AOCS satellite dimensions and its inertia properties, to thermal satellite dimensions and to Power the requirements for the solar wings. Structure is composed by several elements that are designed using the appropriate functions and is described in the corresponding component class (Figure 4).

Data Handling

From the observation of this diagram (Figure 5) it is immediately clear that the data handling subsystem receives the classical data from system engineering unit: mass and power budgets. Besides, some more information is given: the name of the ground station, which data handling will transmit data to, the so-called telemetry budget (that is the number of telecommand and telemetries to be managed by DH subsystem and that will furnish information on the status of all other subsystems during the mission operational phases).

Data handling receives from the mission engineering unit the bus characteristics and the architecture to be used for the processing units. The AOCS features are also essential: frequency and data rate of all sensors drive the choice of processors and buses. In the output area, data handling behaves as other subsystems giving thermal, structural, and power properties of components to the corresponding units (Figure 7).

Data Handling Collaboration Diagram

This diagram (Figure 6) shows the actions when the concurrent design process is in active phase, when the design parameters are exchanged among subsystems, and engineering units make their design choices.

Each arrow indicates a flux of information between objects. The numbers give a possible sequence of the actions. Each action is represented by a function whose complexity is unpredictable, it depends on the design parameter it has to calculate. As an example, the function 'Calculate Processor Frequency()' can be very complex considering many variables: Update rate of the sensors, historical information, availability of existing central process unit (CPU), etc. 'Define CPU Architecture()', instead, could be a simple choice made by an expert designer.

Implementation of the Model

The model described by the set of diagrams presented in the previous paragraph has been used for the whole design of the satellite system, responding to the requirements stated in section 3.1. The design has The MS Excel Workbooks (composed by inputs, outputs, calculation, and presentation sheets) were created by ESA for the design of each subsystem. Some of them are independent from the current project and can potentially be reused for other case studies (propulsion, data handling, system, etc). The choice of correct values for the design parameters is supported by the presence of a database of components in each workbook. Then each engineering unit was able to find the components necessary for the subsystem it was designing. The database presents an amount of several elements with different properties, allowing a definition of the real value of the design parameters, not only a theoretical one.

During the process the diagrams presented in the previous section constituted a roadmap for:

. the system engineering unit managing the interactions among the subsystems; . all other engineering groups giving the complete overview of the interfaces of data exchanges from the subsystem to all the others.

Besides, the presence of activity diagrams explains the logic used during the subsystem design as depicted in the example presented in the previous paragraph.

The results of the design phases are described deeper in the teamwork report presented in partial fulfillment of the requirements for the Master degree in 'Satellites and Orbiting Platforms' of Sapienza, Universita`di Roma, (year 2005/06) [START_REF] Larson | Space Mission Analysis and Design[END_REF].

Conclusions

Spacecraft design is a typical concurrent design activity where quite different disciplines cooperate to achieve a composite final aim. In the present work, based on ESA development in the field, a possible concurrent design procedure for the preliminary design of spacecraft has been developed, implemented and tested, producing results in the following areas:

. Analysis of dimensioning criteria and identification of design parameters for an earth observation SAR satellite (case study) and for all subsystems. . Definition of the relations among subsystems: exchange of design parameters. . Documentation of the static model of the design procedure using a series of UML class diagrams (described in section 4). . Implementation of the criteria in Workbooks, programmed ad hoc for the case study using This article emphasizes the two documentation phases which give a formal description of data exchange, both static and dynamic, put into practice applying the presented UML model.

An entire definition of all the information needed to complete a pre-Phase A study is achieved using the presented UML model. The design phases of a satellite system, from phase A (preliminary) to phase D (detailed) design, are well described in terms of the set of requirements pertaining to each phase. The European space standards (ECSS) documents contain this piece of information. The level of detail required for phase A is compatible with the system description used in the frame of the present study.

One of the most important result of the implementation of concurrent engineering procedure in the real practice is the reduction of time-to-market by means of the reduction of design time. In order to achieve this results in the present case, a key issue is a clear description of the design variables of the space system as a whole and in terms of all its subsystems and the set up of the relevant design procedures used in the design process. In a complex system as an EO satellite, these procedures touch in most cases different areas of expertise, while in some cases the sizing of a component only refers to a specific discipline. The class diagrams illustrated in the article allow to properly describe the attribution of the design variables to the proper areas of expertise, in such a way preparing the way for setting up effective design procedure either among different areas of expertise or in the context of a single competence. The design model set up in this way will shorten the design time by limiting the design iteration and by making evident, since the beginning of the design process, all the conceptual links that are present in the different areas of expertise of the design. This will allow each member of the design team, with a specific skill, to coordinate his effort in a welldefined teamwork design process.

In fact, with a class diagram, a member of a CD team completely knows what data are of interest for his subsystem and whoever is concerned with that. With an activity diagram, as well, he knows what actions to do for exchanging the aforementioned data (an action can be a software procedure, a bibliographical research, a market analysis, a Matlab routine, a meeting with other CD team members, etc.). Finally, a detailed description of these actions is achieved using activity diagrams, one for each action.

Moreover, even if the model presented is tailored to the FINGERSAT case study, the generality of the procedure is assured by the use of: The presented model definitively is able to provide a multidisciplinary and concurrent design environment for spacecraft design, as demonstrated by the diagrams shown in the previous pages which document with the same approach quite heterogeneous subsystems: space mission analysis, satellite structure, SAR payload, data handling subsystem. Its use is then naturally linked with a teamwork effort of design with a widespread scenario of competences well represented in the members of the team and cannot be used as a standalone one-man-only design effort. Moreover, during the practical CDF sessions, the presence of these diagrams gave to team coordinator and to each member of the team a huge capability to solve very rapidly (with only one diagram!) the outcome of inter-teams communication lacks, rapidly identifying which data are to be exchanged. This improves the team management effort and will lead to a reduced timeto-market.

The model is also very useful for educational and training purposes in space system engineering both in the academic and at the industrial environment.

Figure 1 .

 1 Figure 1. Mission class diagram.

Figure 2 .

 2 Figure 2. System class diagram.

Figure 3 .

 3 Figure 3. Payload class diagram.

Figure 4 .

 4 Figure 4. Structure class diagram.

Figure 7

 7 Figure 7 shows the architecture of the ESA software adapted to FINGERSAT design [1, p. 6].The MS Excel Workbooks (composed by inputs, outputs, calculation, and presentation sheets) were created by ESA for the design of each subsystem. Some of them are independent from the current project and can potentially be reused for other case studies (propulsion, data handling, system, etc).

Figure 5 .

 5 Figure 5. Data handling class diagram.

Figure 6 .

 6 Figure 6. Data handling collaboration diagram.

  Microsoft Õ Office Excel (Copyright ß 1985-2003 Microsoft Corporation). . Documentation of the interactions among the Workbooks and description of the principal functions with the use of UML dynamic diagrams (collaboration and activity). . Creation and loading of a database to finalize the design procedure with real components.

Figure 7 .

 7 Figure 7. The architecture of European Space Agency Concurrent Design Facility software.

.

  A set of class diagram giving the static photography of the data exchange giving an answer to the questions: what each subsystem has to share with others and what can receive from the others. . A set of Collaboration diagrams to describe the active interaction among subsystems (what happens during CDF sessions). . An optional set of Activity diagrams which document the actions undertaken to exchange data (in FINGERSAT case these are the functions used in the workbooks).

Table 1 .

 1 Mission Requirements for the required satellite system.

	Description	Values	Description	Values
	Min observation angle	208	Bus voltage min/max	23/38 V
	Max observation angle	508	PDHT downlink frequency	8.1 GHz
	Ground resolution	3 m	Pointing accuracy	0.00288
	Image mode	STRIPMAP	TT&C uplink frequency	2050 MHz
	SAR frequency	9.65 GHz	Downlink data rate	155 Mbps
	Minimum swath	40 Km	SAR duty cycle	10%
	Min no. images per day	450	Operative life	5 years
	Polarization	HH,VV,HV,VH	Revisit time	Day
	CPU architecture	Integrated	Operative autonomy	24 h

Acknowledgments

The authors are indebted to Massimo Bandecchi who is responsible for ESA CDF, for his support during the development of the present study, and for leeing available to the Universita`di Roma La Sapienza for the purposes of research and education, and for some basic kernel models of the procedures developed by ESA. The present study was part of a team effort of all the classses of the fourth edition of the Master in Satelliti of La Sapienza, the members of which are gratefully acknowledged: Rosaria Barca, Alessandro Cricenti, Salvatore D'Addio, Federico Letterio, Daniela Pilotti, Silvia Sabatini, Daniele Scaranari, Claudio Scotognella, Stefano Serva, Manuela Sternativo, Valerio Tarantini. Also the authors are indebted with the members of all the previous classes of the Master, and in particular to Massimiliano Di Pace and Giovanni Falcucci, who formalized the study performed in the third edition of the Master.