Ettore Settanni
email: e.settanni@bath.ac.uk

Nils E Thenent

Linda B Newnes

System Modeling: a Foundation for Costing Through-life Availability Provision

Keywords: Product-Service-System, Availability contracts, Through-life costing, Systems, Input-Output Analysis, Defence aerospace

Under performance-guaranteeing contracts, such as availability-based contracts, the Original Equipment Manufacturers (OEMs) have become increasingly concerned with understanding and managing the cost of their commitment to deliver specific results to customer through-life. However, current approaches to cost estimating hardly offer more than sheer claims of the existence of a link between cost and organizational performance -no matter whether products, services or product-service-systems (PSS) are at stake. This paper presents an intermediate step towards a computational structure explicitly linking cost and performance for PSS. A PSS is represented formally as a system combining assets and activities delivering the results OEMs are committed to through-life. Inter-temporal aspects of PSS provision which typically define the successful delivery of an asset's availability are taken into account. Network formalism and principles derived from Input-Output Analysis are employed to base PSS cost estimation on a representation of a PSS as a 'system'.

Introduction

Availability-based contracts that provide incentives to guarantee the usability of engineering systems are seen as a desirable alternative to purchasing individual items and then supplementing them with support arrangements [START_REF] Meier | Industrial Product-Service Systems-IPS2[END_REF]. An Original Equipment Manufacturer (OEM) -if not a third party service provider -takes responsibility for all or most of the cost of delivering a result to the customer by means of a combination of assets and through-life activities commonly referred to as Product Service Systems (PSS) [START_REF] Tukker | Product-services as a research field: past, present and future[END_REF].

An in-depth analysis of the Through-life Costing (TLC) literature has highlighted the methodological challenges arising from PSSs [START_REF] Settanni | A conceptual model to address the methodological challenges of costing through-life availability[END_REF]. To summarize, the current approaches to estimate the cost of PSS deal with one cost object at a time, i.e. one product or service characterized by a set of features, and assume that all the relevant costs directly relate to it. They fail to recognize that 1) the results delivered by a PSS are not just designed into an individual end-item. Rather, performance is attained through the actions a business undertakes, their effectiveness and efficiency; and 2) in the presence of multiple deliverables within certain organizational boundaries, the consequence of a series of decisions taken independently is not necessarily the sum of the effects of each individual decision, and may not result in an immediately observable change in cash flows.

This research illustrates an intermediate step towards a computational structure for costing PSS concerned with the formalized system representation in TLC. Unlike product-by-product analysis incumbent in TLC, performance is rendered in terms of undertaken actions, their purposes, the output delivered and necessary preconditions. In this way, performance and cost can be linked in the flow of work through an organizational system, and dealt with simultaneously. In the remainder of this paper, the need for a 'system' approach is discussed first. Then, the principles for obtaining a mathematically treatable representation of the system investigated that can be used for PSS costing are detailed. Additional steps from system representation to PSS costing are left to further research.

Need for a 'System' Approach

The concept of PSS embeds that of 'system'. A system is a combination of interacting elements organized to achieve one or more stated purposes. Within a PSS the relevant system is what delivers the results OEMs are committed to as an outcome of a specific combination of assets and through-life activities. Examples include complex engineering services such as providing the availability of aircraft or major aircraft sub-systems [START_REF]Complex engineering service systems. Concepts and research[END_REF].

For the purpose of cost estimation a system -even a PSS -tends to be entirely characterized in terms of the architecture and properties of the physical entities needed to carry out the system's functions. Less attention is paid to another domain, called the 'process' domain, which is essential when trying to understand certain system behaviors. It concerns the actions or operations performed within or by the system and their mutual relationships [START_REF] Bartolomei | Engineering Systems Multiple-Domain Matrix: An organizing framework for modeling large-scale complex systems[END_REF]. System-thinking and process-thinking are indeed intertwined [START_REF] Emblemsvåg | Process thinking -a new paradigm for science and engineering[END_REF]. This is evident especially for service processes [START_REF] Batista | The systemic perspective of service processes: underlying theory, architecture and approach[END_REF], and PSS [START_REF] Kim | Representing product-service systems with product and service elements[END_REF]. Also, a formalized system representation often relies on process representation techniques -including IDEF0, UML and Petri Networks to mention but a few [START_REF] Aguilar-Saven | Business process modelling: Review and framework[END_REF]. Ma et al. [START_REF] Ma | A generic model and design representation technique of service products[END_REF] summarize the advantages and disadvantages for a variety of such representation techniques with a service operations outlook. In the field of cost estimation a system approach is often claimed. However, it is not the case that formal system representation and modeling always play an explicit role in the cost analysis (see [START_REF] Valerdi | Heuristics for Systems Engineering Cost Estimation[END_REF]). In the absence of a formalized system approach, priority is given to chasing accurate cost estimates in the same way as 'goodness of fit' is chased in forecasting uncontrollable external events [START_REF] Makridakis | Forecasting. Methods and applications[END_REF] (see for example [START_REF] Roy | Cost engineering: why, what and how? Decision Engineering Report Series[END_REF]).

Linking system/process-thinking and cost becomes more important if the aim in cost estimation is to improve cost consciousness i.e., consciousness of the cost implications of the actions taken [START_REF] Lindholm | Learning by costing: Sharpening cost image through life cycle costing?[END_REF]. When cost consciousness is at stake, cost is no longer deemed an intrinsic property of e.g., a product or service. Rather, it is an "emergent property" of the context in which products or services are designed and delivered [START_REF] Field | Process cost modeling: Strategic engineering and economic evaluation of materials technologies[END_REF]. Hence, the primary rationale for developing a cost model becomes to translate the interrelated consequences of changes occurring in such a context into cost metrics, through a consistent and transparent representation of that context.

Causal understanding has to precede the estimate of costs. The development of such an understanding rests on the representation of the quantitative flow of goods and services delivered by organizations, whereas money serves as a meta-language merely providing a value representation of that flow [START_REF] Van Der Merwe | Management accounting philosophy II: The cornerstones of restoration[END_REF]. Based on the flow of goods and services the virtual cost flow paths within stated organizational boundaries can be determined [START_REF] Möller | Material and Energy Flow-Based Cost Accounting[END_REF].

Research on system/process-thinking in TLC is rather sparse. Only a few TLC studies conceptually identify a system through means-ends relationships between the operations or activities performed within or by that system [START_REF] Emblemsvåg | Life-cycle costing. Using activity-based costing and Monte Carlo methods to manage future costs and risks[END_REF][START_REF] Mévellec | Whole life-cycle costs: a new approach[END_REF]. Applications include defense aerospace [START_REF] Davis | A framework for documenting and analyzing life-cycle costs using a simple network based representation[END_REF], and PSS [START_REF] Kimita | Cost evaluation method for service design based on Activity Based Costing[END_REF]. In most cases, however, there is lack of published detail on how the links and mutual dependencies between the operations or activities constituting the system affect the computation of cost. To overcome these limitations, TLC can be based on a technological model of the enterprise or supply chain, implemented through the formalism of Input Output Analysis (IOA) [START_REF] Settanni | An Input-Output technological model of Life Cycle Costing: computational aspects and implementation issues in a generalised supply chain perspective[END_REF].

A technological model is a model which relates to the notion of technological knowledge as detailed process understanding [START_REF] Bohn | Measuring and Managing Technological Knowledge[END_REF]. IOA has been originally meant to represent economic systems such as whole national economies. However, IOA can also handle particularly intricate technical-economic systems consisting of mutually interconnected stages, such as production-inventory systems [START_REF] Grubbstrom | An Overview of Input-Output Analysis Applied to Production-Inventory Systems[END_REF], thus making it potentially suitable for modeling such a PSS as the provision of availability. The theory of IOA owes greatly to Nobel Laureate Wassilly Leontief, whose belief that "…partial analysis cannot provide a sufficiently broad basis for fundamental understanding", coexisted with that that uncritical enthusiasm for formidable mathematical formulation is too often prone to concealing lack of substantive content. IOA guarantees a balance between formalization, which is important for general validity to be proved mathematically, and computability, which is important for relevance to be proved empirically [START_REF] Augusztinovics | What Input-Output is about[END_REF].

A System Representation for PSS Cost Estimation

Prior to estimating cost an understanding of the causal relationships has to be developed. This is a matter of formally representing a PSS as a 'system' i.e., identifying the boundaries and scope of the analysis; and within those boundaries the actions taken, their dependencies, the input resources required and the outputs delivered by each action. Inputs and outputs leading to the outcome(s) the system is meant to achieve can be "goods" (products or services) or "bads" (by-products or 'waste') [START_REF] Möller | Material and Energy Flow-Based Cost Accounting[END_REF].

For illustrative purposes, consider a hypothetical PSS delivering the availability of end-items such as military aircraft (A/C) [START_REF] Hollick | Achieving shared accountability for operational availability attainment[END_REF], or A/C LRUs (Line Replaceable Units). As an example, Fig. 1 illustrates a range of outcomes that such a PSS may deliver in the case of a Multi-functional Display (MfD), and where this research stands. Focus is on the sustainment of end-items (the provision of which remains outside the system boundaries), the aim of which is guaranteeing they are in operable and committable state for certain missions (also outside the system boundaries) over a certain time-span. Fig. 2 shows the structure of the main end-item involved in the PSS. Proceeding clockwise, it shows the structure of the sustaining operations delivering the availability of such an item in terms of means-ends -or supply-demandrelationships using IDEF0. At this stage, the aim is to provide a structured representation of the modeled system without committing to a specific modeling language (e.g, SysML etc.).

First, a single-block context diagram defines the boundaries and scope of the system studied. Outside the boundaries are the exogenous factors i.e., those factors the provision of which is not deemed controllable, and hence left outside the analysis. Not only goods and services may be acquired from outside the system boundaries, but also conditions may be externally imposed on the system functioning, and the system's functions may be delivered outside its boundary. Then, the context diagram is detailed progressively through child diagrams. All the items involved, as well as the flows between the activities the PSS consists of, can be expressed in terms of a common, fictitious metric called 'capability units' -c.u. Capability units may be thought of as flyable hours (sorties, cycles etc.) equivalent to a top-level item (whole A/C or LRU) or sub-items. For example, a fleet of two A/C each of which has a life-cycle capability of flying 2 missions worth 25c.u. can be pooled as an initial "stock" of 100c.u. at time "zero". If a mission having duration 1 time unit is called at time 1, and nothing goes wrong the stock is depleted of 25c.u. leaving a residual capability of 75c.u. A failure occurrence (assumed here to be a completely uncontrollable event) when the mission is called again, would deplete the stock of capability of 50c.u. instead (i.e., one grounded A/C and one spare A/C flying the mission). In this sense, a failure acts like an additional (although wasteful) "demand" of capability. Shortage of capability triggers activities generating more capability units -e.g., by restoring the main item or sub-items into an operable and committable stage.

Although each activity has its lead time, activities are not time-phased in an IDEF0 blueprint. The latter can be thought of as a "picture" of a system taken using a conveniently long "exposure time", which corresponds to the system's total active period i.e., the time-span these activities run. In the presence of nonzero lead times, however, activities must be triggered a number of time units in advance of the time a certain demand of flight capabilities occurs. To introduce this dynamics, an Input-Output based production-inventory system for multiindenture items [START_REF] Grubbstrom | An Overview of Input-Output Analysis Applied to Production-Inventory Systems[END_REF] is adapted to the PSS of interest. The model is modified so that 1) it fits a specific framework for IOA known as "supply-use"; and 2) dynamics is induced similarly to the time-distributed systems' activities approach in IOA [START_REF] Ten Raa | The economics of input-output analysis[END_REF]. Only discrete time is of interest here.

Let n be the number of activities the PSS is composed of. Let be the lead time for the j-th activity (

). Let τ be the total active period's length. For each discrete time ( ) the relevant system can be described in terms of the following multi-period balance of quantities:

( ) ( ) ( ) ∑ ( ) ( ) ( ) (1)
where p is the time lag ( , { }), and is the delivery time ( ( ) ). The time-distributed "use" matrix ( ) [ ( ) ]

records for each activity j its direct requirements of input i ( ) supplied by another activity within the system | | time units prior to the delivery time i.e., at time t. The corresponding quantity ( ) is then multiplied by the Kroneker symbol taking values and 0 otherwise. The time-distributed "supply" matrix ( ) [ ( )] records for each activity j its gross output of i delivered at time t. By assumption, an activity's output is entirely delivered time units ahead the fulfillment of the necessary preconditions (e.g., the provision of inputs). These matrices recording supply and use flows can be combined to give the system's net output as follows: the example in Fig. 2. The example features a PSS consisting of four activities (

). Each activity brings either the main-item (A) or the sub-items it is made of (B, C, D) into an operable and committable state. Assuming for simplicity the use matrix remains constant over time [ ( )] [ ] and so does the supply matrix [ ( )] [ ] the following hypothetical numerical values (all expressed in c.u.) are assumed:

[ ] [ ] ; [ ] [ ]
The beginning inventories for each item in terms (all expressed in c.u.) are ( ) [ ] . (Superscript T means matrix or vector transposition). Finally, the hypothetical values for the lead times of each activity (expressed in discrete time units) are [ ] [ ]. Fig. 3 shows the values for activity levels and capability stock levels given the exogenous demand for flight capability (including "bad" one i.e., due to thing going wrong) shown at the bottom (for the main item only), over a discrete time-span ( ).

Conclusion and Need for Future Work

This research lays the foundation of an original, formalized system representation for use as a preliminary step for PSS costing. It draws on principles developed in disciplines like IOA and inventory modeling, which are not taken into account in current approaches to PSS cost estimation. The insights associated with a rigorous and transparent quantitative approach to model PSS as 'systems' are meant to support the improvement of cost consciousness.

The approach developed here requires a distinction between what can, or has to be included within the system's boundaries, and what is deemed exogenous to the system and hence uncontrollable. The focus on the provision of flight capability and the introduction of c.u. as fictitious units represents an assumption. However, it has allowed to show how the principles of inventory modeling which are welldeveloped for products apply to more generic "functional units", suitable for representing the intermediate and final results delivered by a PSS. The approach that has been illustrated here is in generic form, and is taking a deterministic standpoint. Topics of co-production and inefficiencies/waste generation have been left aside. These aspects can be taken into account as the basic model presented here grows into a costing model consistent with the Input-Output technological approach to TLC suggested in the field of sustainability management by [START_REF] Settanni | An Input-Output technological model of Life Cycle Costing: computational aspects and implementation issues in a generalised supply chain perspective[END_REF]. Further work is necessary to address potentials and limitation of the proposed model through its application to an industrial context. Future research must also address what needs to be known about a PSS, for example, in order to link concepts such as technological maturity and obsolescence to changes over time of the technological knowledge about the system's inputs and outputs.

Fig. 1 .

 1 Fig. 1. Example of PSS deliverables for MfD availability.

Fig. 2 .

 2 Fig. 2. From product structure, through an IDEF0 PSS representation, to time dimension.

Fig. 3 .

 3 Fig. 3. Inter-temporal behavior of hypothetical PSS: main aspects.

Acknowledgments

The authors gratefully acknowledge the support provided by the Department of Mechanical Engineering at the University of Bath, the Innovative electronics Manufacturing Research Centre (IeMRC) and the Engineering and Physical Sciences Research Council (EPSRC) for funding the research.

{ ( ) [ ( ) ( )] ( ) [ ( )]

The vectors ( ) and ( ) are, respectively, the beginning and final inventories of each activity's outputs at time t. For the values of the beginning inventory ( ) are known and serve as initial conditions. The vectors (

) and ( ) are the unknown activity levels at each delivery time, and at each time t respectively. Finally, the vector is the demand of system's outcomes imposed exogenously at each time t. In our case it should be further distinguished into 'good' demand of units in operable and committable state, and 'bad' demand due to e.g., failures:

. Equation ( 1) is developed for

. Let be an identity matrix and a null matrix of appropriate dimensions:

]

or, in compact terms:

The problem becomes finding the elements of as the minimum nonnegative integers such that the entries of are non-negative:

where is a unity vector of appropriate dimension. is a matrix of the same size as , which contains a set of constraints. These constraints are such that an activity j cannot deliver its output unless there is time for doing so. For diagonal matrix [ ] is defined such that if and zero otherwise. Hence:

Alternative approaches to the multistage, mixed-integer linear programming used here (e.g. [START_REF] Grubbstrom | An Overview of Input-Output Analysis Applied to Production-Inventory Systems[END_REF]) can be more effective for the mathematically literate, yet less practical to implement e.g., using spreadsheets. The algorithm can be applied to


Tümay Mart
email: tmart@tai.com.tr

Can Cangelir
email: ccangelir@tai.com.tr

LESSONS LEARNED FOR BETTER MANAGEMENT OF MASTER GEOMETRY

Keywords: Master Geometry, Master Geometry Creation, Master Geometry Validation Workflow, Buffer Geometry

When an aircraft is thought as a final product, it has a complex structure with numerous parts to be managed. Complexity requires multifunctional design activities, and multifunctional design needs collaborative way of working for continuous success. This cooperated approach could only be accomplished by the help of concurrent engineering techniques. Currently, several distinctive design activities are performed at digital environment of CAD tools. Position information and interrelations between parts of a product are provided by the help of associative physical CAD links. Requirement of CAD links during design activities paves the way for the usage of Master Geometry models as an official source of aircraft shape and a geometrical reference for all actors involved. Master Geometry models have to be managed in Product Lifecycle Management tools in order to provide effective implementation and usage of models from conception, through design and manufacture, to service and disposal of product. Some improper cases could be observed when a correlation is tried to be generated between Master Geometry models and 3D models of product at CAD environment. In this paper, these cases will be examined and potential solutions, which are the results of lessons learned activities, will be proposed with concrete examples.

Introduction

Concurrent engineering techniques provide collaborative strategies, which are totally focused on cost and time reduction of product development processes in parallel with improving quality level of final products. These improvements have to be seen as the key for success by all companies who want to be a leading force within their own field of industrial expertise [START_REF] Hartley | Concurrent Engineering[END_REF]. It is mainly a question of process and way of working. For conventional method, product development processes are performed sequentially and this type of method does not answer the requirements of being a global player of challenging and competitive worldwide economy [START_REF] Parsei | Concurrent Engineering[END_REF]. Many aerospace companies attain success only with adapting cooperated way of working strategies, due to high level competition resulting from reduced product life cycles, growing product com-plexity, multifunctional design activities and the need for a large number of product variants [START_REF] Parsei | Concurrent Engineering[END_REF].

For aerospace industry, product development processes start with works at aircraft level and iteratively continues through the level of detailed elementary parts. In another words, it could be stated that the aircraft design process is an iterative and topdown activity. When the complexity of an aircraft is taken into consideration, a final product could only be achieved by involvement of several distinctive disciplines. Additionally, there have to be continuous exchanges of information between all interested parties within a protective environment during product lifecycle. The digital environment created and leaded by concurrent engineering provides this type of collaborative work media where all the related departments can communicate with stakeholders. Integrative design environment has been a subject of intense research over the past several years. According to recent studies, NIST Core Product Model (CPM) is described as a product information-modeling framework. In CPM, a product is modeled as a triad of its function (what it is intended to do), its form (what is its shape and material) and its behavior (how it implements its function) [START_REF] Sudarsan | A product information modeling framework for product lifecycle management[END_REF]. Open Assembly Model (OAM) is defined as an extension of CPM, and OAM is used to provide a standard representation and exchange protocol for assembly and system level tolerance information [START_REF] Sudarsan | A Model for Capturing Product Assembly Information[END_REF]. Another method is The Cooperative Design Modeler (CoDeMo). CoDeMo assists the integration and the cooperation of each participant who would be an external or internal actor. It achieves, thereby, a formal network of cooperation based on the shared database, which is manipulated by the design external actors and managed by the internal actor [START_REF] Noel | A product-process-organization integrative model for collaborative design[END_REF][START_REF] Lionel | CoDE: A Cooperative Design Environment-A New Generation of CAD Systems[END_REF].

In this context, Master Geometry models get on the stage as a set of 3D models, which represents a single geometrical reference database of the main aircraft geometry for all interested parties. It has to be noted that management of Master Geometry models and preserving interrelation between product and Master Geometry during product lifecycle period is important.

At following sections of this paper, three different improper incidences, which possibly could be faced with during generation, usage and management processes of Master Geometry models, will be identified and exact solutions to mentioned incidences will be proposed. Additionally, in order to provide background information about main topic, brief descriptions of product structure, product lifecycle and detailed description of creation and management of Master Geometry will be mentioned.

Definitions

Product Lifecycle

Product life cycle is a generic term covering all phases of acquisition, operation, and logistics support of an item, beginning with concept definition and continuing through disposal of the item [7]. As the product development activity of an aircraft proceeds, it passes through a series of reviews of increasing detail. Design reviews evaluate the technical progress toward meeting specification requirements [START_REF]Military Standard Technical Reviews and Audits for Systems[END_REF]. Each review is tailored to ensure that the emerging design is ready to enter the next stage of development.

Product Structure

Product

Master Geometry

As mentioned previously; during product life cycle process of an aircraft, several different groups are involved in design, manufacturing and after sales service support activities. Although those groups have totally different disciplines, there has to be a strong relation between different disciplines for aircraft design. Consider a design group whose main responsibility is structural part design of the aircraft such as designing frames, ribs, spars, stringers etc. On the other, there has to be another group whose main responsibility is system design. System designers individually know the content of what needs to be generated as a system deeply and location of this system on the aircraft roughly. However, geometrical interaction between systems, absolute geometrical installation points and dimensional limitations also need to be known. This information somehow needs to be shared between different disciplines. The same situation would be observed between two different structural design groups working for different sections of the same aircraft with geometrical dependencies. In order to make sure that design activities are performed on right location of aircraft, location information of designed parts or systems on aircraft has to be identified. Designers need design parameters or geometrical indications, which they can use as a reference point from aircraft geometry. Exact locations of all parts on final product could be provided by the help of physical CAD links. Generating links from part to part could be the first technique comes to mind. However, generating links from other parts or geometrical elements are not recommended, because of location information of common parts and geometrical elements on the aircraft could be changed due to dynamic nature of the design activity and they could not be considered as a reference point.

In this context, implementation of Master Geometry models has significant importance for aircraft development process. Master Geometry file is the collection of all primary references necessary for design of aircraft primary structure and system installation. Master Geometry models form the basis for all geometry levels of the aircraft. Thus, it has to be stated that structural parts can only be physically linked to Master Geometry features in CAD environment, since Master Geometry models are definitely controlled references. Generating links from part to part or from other geometrical elements is not recommended.

Content of Master Geometry Models

Master Geometry is a 3D CAD model, which represents the outer geometry and the elements forming the structure of the aircraft all together. This geometrical composition consists of surfaces, planes, lines and points and includes all necessary geometrical dependencies and constraints required for design of the aircraft. Following definitions show the detailed content of Master Geometry; indications e.g. planes, coordinate systems of main structural components e.g. frames, ribs, spars, cut-outs like doors or windows and the positions of main sections [START_REF] Dolezal | Success Factors for DMU in Complex Aerospace Product Development[END_REF]. It has to be noted that Master Geometry is not an actual part or section that is manufactured, but it is only a conceptual part, containing a sketch or general shape of the overall design and important design parameters [START_REF] Dolezal | Success Factors for DMU in Complex Aerospace Product Development[END_REF]. Following Figure 1 shows the examples of Master Geometry content.

Fig. 1. Examples of Master Geometry Content

Creation of Master Geometry Models

Master Geometry creation process has to be started at conceptual design phase and mainly frozen just after the detailed design phase. However, management of the master geometry database continues for the life of the aircraft. Master Geometry models are the structural reference of the whole aircraft that contains all the external shapes of the aircraft and the main geometrical references, which could be used as a solid basis by structural designers, subcontractors, manufacturing engineers, stress engineers and aerodynamic engineers. Master Geometry models include inputs from all related disciplines especially structural design, aerodynamic, structural analysis, tool design, EMI-EMC group and system engineering. External aircraft geometry, which is an output of aerodynamic studies, could be stated as the main source for generation of Master Geometry models.

Management of Master Geometry

Generating Master Geometry models would be not enough for a complex product development process. Master Geometry could be evolved due to the modifications, improvements and change requests through design phases, and this evolution has to be managed within a protective and controlled environment. Thus, a special product structure, a special role and a special workflow have to be defined for Master Geometry models with the help of Product Lifecycle Management tools. Special product structure brings hierarchical breakdown of Master Geometry models in an organizational way. Authorized role provides controlled access of creating and modifying 3D models of Master Geometry. Only the users, who have Master Geometry Specialist role, would be able to perform 3D model creation or modification tasks. Special workflow provides approval and traceability of 3D model modifications of Master Geometry. However, several problems could be observed during the 3D model generation and management periods of Master Geometry models, due to the nature of geometrical attributes of Master Geometry. Each case and potential solution will be separately analyzed at following subtitles.

Reduction of Feature Intensity

System installation and structural design groups have to use Master Geometry models during their 3D modeling activities. When the design activity becomes more detailed, Master Geometry models shall have ability to answer to requirements of all design groups. Sometimes a single Master Geometry model at aircraft level could not be used properly for detailed design activities within a dynamic environment. For a basic trainer aircraft, Master Geometry models at aircraft level includes approximately 14000 features like lines, points, planes, surfaces etc. Following Figure 2 shows the intensity of features just for a significant section of an aircraft.

Fig. 2. Intensity of Features (lines, planes, points et.)

Using one big model for Master Geometry could be a chaos for detailed part design activities. Consider a structural designer which works on wing and totally responsible for structural parts of a definite section of the wing. When this designer tries to use Master Geometry model as a reference, he/she has to refer aircraft level model which includes all detailed geometrical information of fuselage, empennage or other major components which could be classified as out of scope according to his responsibilities. This excessive information kept in single model will causes confusion among design groups and poses as a risk for performed designs. Same situation also would be a problem for a system installation responsible.

Solution 1.

If whole aircraft is being designed, the general Master Geometry shall be broken down into convenient sections, to avoid excessive information in each model and to align the Master Geometry more in line with the design and manufacture task breakdown, instead of using single model. There have to be separate Master Geometry models for structural design group and system installation group. In order to provide better management of details and integration with design teams, Master Geometry models of structural design group shall be broken to major components, sections and ATA (Air Transport Association of America) sections sequentially. Breakdown principle totally depends on requirements of design group. For instance, there could be separate Master Geometry models for wing, fuselage, and empennage in terms of structure. Still, it can be divided into further indices if necessary. Aircraft level Master Geometry model generated for structural design includes approximately 5000 features and it is observed that the number of features included in one Master Geometry model could be reduced to 800 by splitting into further indices.

Master Geometry models of system installation group shall be derived from the Master Geometry models generated for structural design. Additionally, Master Geometry models of system installation have to be physically linked to the ones of structural design. In order to prevent excessive information in each model, system installation Master Geometry models can be split into sub-sections. There has to be a separate Master Geometry model for each system. Aircraft level Master Geometry model of system installation includes approximately 9000 features and it is observed that the number of features included in one Master Geometry model could be reduced to 250, if a separate model is created for each system. Following Figure 3 shows the reduction rates of feature intensity with approximate values of a real splitting case.

Fig. 3. Reduction of Feature Intensity

Using Buffer Geometry

As mentioned previously, all detail parts except some brackets have to be linked to Master Geometry models and Master Geometry models have to be physically linked to external aircraft geometry models at CAD environment, in order to provide association between models. This means if an external geometry model is changed, associated Master Geometry model will give link update warning, so do detail parts due to updating Master Geometry models. For a basic trainer aircraft, there are more than 4000 detail parts. It could be estimated that updating one detail part at CAD environment takes 1 minute. Each external geometry modification causes detail part updating workload, which approximately equals to 4000 minutes for whole aircraft. Every modification of external geometry would not have an impact on detail parts. Thus, there has to be a monitoring interface between external geometry and Master Geometry models in order to prevent unnecessary updates of Master Geometry and to avoid extra workloads at detail part level.

Additionally, sometimes it is possible that external aircraft geometries could be provided by aerodynamic group as a coarse model. Coarse models include draft surfaces, lack of cut out sections of the surface etc. In this case; first of all, some arrangements and fine tunings have to be performed on models which have been directly taken from external aircraft geometry, and then these models shall be transferred to Master Geometry. These arrangements include totally CAD operations. And these all CAD operations have to be performed in order to make Master Geometry models applicable for design specifications. During detailed design phase, there will be excessive information in Master Geometry models such as initial information taken from aerodynamic group, results of CAD operations and final geometrical features intended to use as Master Geometry. When all information is kept within a same model, it would be impossible to use Master Geometry models properly. Solution 2. If CAD operation for fine tuning of data which has been taken from external aircraft geometry is a frequent activity, there has to be a transition medium between external aircraft geometry models and Master Geometry models.

In this context, Buffer Geometry model gets on the stage as a solution. Buffer Geometry functions as a transition and monitoring model between external aircraft geometry and Master Geometry. All elements taken from the external aircraft geometry are transferred to the Master Geometry after being arranged using the Buffer Geometry. If the surfaces taken from aerodynamic engineering group have been provided as a coarse model, the Buffer Geometry shall be used to make these surfaces fine to prevent excessive information in each Master Geometry model. There shall be a Buffer Geometry model for each Master Geometry model. All geometrical elements in the Master Geometry model shall only be linked to the corresponding Buffer Geometry. In this case, Master Geometry will be linked to Buffer Geometry and Buffer Geometry will also be linked to external aircraft geometry sequentially. Changes on external aircraft geometry will directly have impact on Buffer Geometry. With the help of Buffer Geometry, only effective changes could be transferred to Master Geometry models and this way of working prevents unnecessary link updates of detail parts and provides 80% time reduction for link update task at detail part level. Following Figure 4 shows the CAD operations performed on a Buffer Geometry model.

Master Geometry Validation Workflow

The design data of a product has to be approved and released through workflows with revision control in order to make it applicable for stakeholders within a protective and controlled way. Same identification has to be also implemented for Master Geometry models. Consider a final product with high complexity; all parts of the product could be linked to same Master Geometry model. When this Master Geometry model could somehow up issued from Revision-A to Revision-B due to new requirements or change requests, all items which have CAD links to this Master Geometry model also have to be up issued. Otherwise, associative CAD links between parts and Master Geometry model will become broken because associative links keeps track of the file name of Master Geometry models. Updating links and up issuing of all parts will be a heavy work load for design group.

Solution 3. Giving "Released" status and issue tracking for Master Geometry models is not recommended. Because when you release an item through workflows, you have to keep track of the revision control of that item. In case of Master Geometry models; instead of using "Released" status, "Valid" status has to be used with a proper workflow. Consider a change request has been received for an existing Master Geometry model. According to predefined rules of the Master Geometry Workflow; following steps will be performed sequentially: at first step; Master Geometry Specialist role informs and requests to rearrange the Master Geometry model in accordance with the design requirements. This first stage is "Request" step of the workflow and during this phase the data is frozen. At second step; Engineering Leader role confirms that the Master Geometry change is required and acceptable. This second stage is called "Assessment" step and at this step, Engineering Leader role can also reject the request. The data is set free from now on. At third step; Master Geometry Specialist role applies the changes to Master Geometry model. Additionally, Master Geometry Specialist starts validation request. This third stage is called "Request for Validation" step. At fourth step; Engineering Leader role confirms that the corrections and/or improvements are applied correctly. This fourth stage is called "Approval of Validation" step and at this step, Engineering Leader role can reject the corrections and modifications. After the "Approval of Validation" step, the Master Geometry model will be again frozen and has "Valid" status. Please refer Figure 5 for details of Master Geometry Validation Workflow.

Fig. 5. Master Geometry Validation Workflow

Conclusion

This paper is aimed to present the importance of Master Geometry models on multifunctional design activities. Basically, interactions of structural design activity, system design activity and manufacturing process with Master Geometry models have been identified. Generic geometrical content of Master Geometry models has been also defined. In order to provide coherency between Master Geometry and other indications, brief descriptions of product structure and product life cycle are given. Afterwards, three different problems could be faced with during implementation and management period of Master Geometry has been deeply analyzed and presented with supportive convenient examples. These problems could be defined in a nutshell as follows; problem number one was about excessive content of usage single Master Geometry models during whole product development process. Problem number two was about filling out Master Geometry models with unnecessary geometrical information which makes Master Geometry models useless. And finally, problem number three was about unsuitable consequences of released status of Master Geometry models and workloads of link updates. After that, accordance with the results of lessons learned and know how activities potential solution techniques have been proposed.

Future work will concentrate on issues related to the implementation and management of Space Allocation Mock-up which is a digital mock-up made of simplified 3D solid models in CAD formats. The place of Space Allocation Mock-up design within overall aircraft development will be highlighted and the link between Space Allocation Mock-up models and Master Geometry models will be presented in details.

Fig. 4 .

 4 Fig. 4. Buffer Geometry (CAD arrangements and fine tunings)


Gary Ford

Tom Bartley
email: tom.bartley@bristol.ac.uk

Joel Igba

Alison Turner

Chris Mcmahon
email: chris.mcmahon@bristol.ac.uk

Product Life Cycle Data Management: A Cross-Sectoral Review

Keywords: Information management, Lifecycle, Civil, Marine, Wind

The paper explores data management in the product life cycle of three engineering domains -civil/construction, marine and wind energy -each with distinct but potentially common issues. The approach has been to assess issues within each domain against the life cycle stages defined in ISO 15288 "Systems and software engineering -System life cycle processes", i.e., Concept, Development, Utilisation, Support and Retirement. These were then assimilated and comparisons drawn to identify common problems and areas that appear particular to the do-main. The paper presents a position statement, taken from the experience of practitioners in each of the relevant sectors; the purpose is to understand if there may be opportunities for cross-sectoral learning.

Introduction

The management of engineering data for the operation and maintenance of large complex artefacts such as ships, buildings and power generation systems is very challenging owing to the long life spans, multiplicity of stakeholders, diversity of data types and complexity of interactions in the artefacts and supporting systems. This paper explores these challenges and in particular makes a cross-sectoral analysis of issues across three distinct engineering domains: construction and civil engineering, marine (UK Defence) and renewable energy (offshore wind). Initial comparison of the domains would indicate a number of similarities, e.g., complexity, capital investment, but none-the-less significant differences exist, in business/engineering maturity and structure of the supporting industry, which have strong implications for data management approaches in each domain.

The purpose of the paper was to explore opportunities for engineering communities to share good practice with others and identify issues which are still to be resolved across all engineering sectors.

Background

The three sectors under study are construction/civil engineering, marine and wind energy. Each is characterised by large, long-lived artefacts and by distributed operations, but there are differences, especially in the nature of the industries.

Within civil engineering/construction, Egan's [START_REF] Egan | Rethinking Construction: Report of Construction Task Force[END_REF] 1998 report highlights the disjointed and adversarial nature of the industry. Designs are often created by multiple companies, and construction and operation may be performed by entirely different organisations with little input to upstream decision making. To counter this, in the UK the Government (along with major clients worldwide) has adopted a Building Information Modelling (BIM) strategy which mandates a life cycle approach to the production of project information on public projects by 2016 [2]. BIM is the construction industry's response to Product Lifecycle Management (PLM), in which a federated database is developed to serve an asset from "cradle to cradle" [START_REF] Smith | BIM in Construction -Building Information Modelling[END_REF].

Marine engineering/construction within UK Defence currently constitutes 3 of the 4 major Ministry of Defence (MOD) projects, e.g. the Queen Elizabeth class aircraft carrier with capital expenditure in 2012/13 of £9.1 billion. However, the operation and maintenance cost of a warship will typically be twice the cost of acquisition [START_REF] Harris | Total Ownership Cost[END_REF]. Data management within the marine domain experiences issues similar to construction, e.g., ships designed and built by multiple companies and operationally maintained by another set of organisations, but national security, nuclear engineering and weapons systems are important additional factors, creating a complex data management environment.

The wind energy resources will have a large role to play in meeting renewable energy targets but to be competitive the Cost of Energy (COE) produced from them must be competitive. Hence there is need for innovation and improvements in the sector with reliability and COE as the major drivers. In wind power higher than expected costs of Operations & Maintenance (O&M) is a particular issue [START_REF] Musial | Improving wind turbine gearbox reliability[END_REF]. Reducing the cost of O&M triggers the need for a more comprehensive and integrated through-life service and maintenance management approach [START_REF] Igba | A Systems Approach Towards Reliability-Centred Maintenance of Wind Turbines[END_REF]. Data management is an important step towards optimising O&M activities and reducing COE [START_REF] Fischer | Reliability-centered maintenance for wind turbines based on statistical analysis and practical experience[END_REF].

As an example of the challenges involved in the operational support of very longlived artefacts for which much information is pre-digital we have studied the Clifton Suspension Bridge (CSB) in Bristol which first opened in 1864. The bridge is managed by the Clifton Suspension Bridge Trust (CSBT) which finances all maintenance, conservation and operating costs through tolls. The Trust owns a range of information dating from the 1830's including the original bridge design in addition to operations, management and maintenance details for the bridge. There also exist many technical investigations, reports and general interest material that also form part of the CSBT's collection.

Systems Engineering Life Cycle

A number of standards exist that can be used to assist in managing the construction and operation of a system. The selection and adoption of a life cycle will be dependent upon a number of factors, e.g., definition of requirements, anticipated complexity, urgency, proof of concept, etc. Given the size, cost and complexity of a typical civil engineering project/maritime vessel the design and construction will normally adhere to a life cycle typical of ISO 15288 [8] which defines discrete stages to form a system life cycle, i.e., Concept, Development, Production, Utilisation/Support and Retirement. This review selected ISO 15288 as a current Systems Engineering standard recognised by The International Council on Systems Engineering for a structured comparison of the life cycle stages for each of the selected artefacts. Each ISO 15288 stage details a number of deliverables and purpose, e.g., Concept ~ "develop preliminary system requirements and a feasible design solution". The ISO standard, originally intended for Systems Engineering was modified in 2008 to include software engineering. Some major technical projects carried out to maintain or improve an asset may be viewed as having life cycles of their own embedded within the whole system life cycle.

The utilisation/support stage of the life cycle includes both operation and maintenance and these are the activities that typically cost an organisation most out of the entire life cycle. In some cases up to 70% of the total cost of ownership of an asset is consumed at this stage [START_REF] Koronios | Integration Through Standards-An Overview Of International Standards For Engineering Asset Management[END_REF].

Data Management within Each Domain

Civil engineering/construction: BIM has become the accepted term for a new paradigm in the production and management of a built asset's information through design, construction and operations with a view to achieving transformational change [START_REF] Venugopal | Semantics of model views for information exchanges using the industry foundation class schema[END_REF]. Because the industry has traditionally been slow at adopting new technologies the adoption of BIM is mainly a client-led initiative. Whilst there is an established understanding of how BIM will be implemented there are many technical and cultural challenges to overcome and there are few examples of effective life cycle information management. The Institution of Civil Engineers has identified many case studies where BIM processes have been used effectively in distinct sectors or part of the construction life cycle [START_REF]BIM 2012[END_REF].

An important factor for some clients in specifying the use of BIM is that it can enable better Facilities Management [START_REF] Arayici | Building Information Modelling for Facilities Management (FM)[END_REF]. The Construction Operations Building Information Exchange (COBie), a subset of the Industry Foundation Classes (IFC) standard, has been developed to aid handover of as-built in-formation about an asset in human readable format (spreadsheets) [START_REF] Nisbet | COBie-UK-2012[END_REF]. COBie structures information hierarchically describing the facility's objects and systems and includes service schedules and maintenance requirements and can then be used to interface with Computer Aided Facilities Management applications and used throughout the life of the asset. There are issues in having too much data in that it becomes inaccessible and there is complexity in the number of soft-ware packages which need to interact [START_REF] Anderson | Construction to Operations Ex-change: Challenges of Implementing COBie and BIM in a Large Owner Organization[END_REF].

There are many issues to be resolved before BIM is fully functional. The construction industry has large quantities of legacy data. Where data does exist it is often very difficult to find and likely to not to be in a digital format. Model interoperability also remains an issue [START_REF] Grilo | Value Proposition on Interoperability of BIM and Collaborative Working Environments[END_REF]. The buildings sector is very mature at producing 3D models and the IFC standard is becoming mature enough for widespread use. However, as yet for the linear asset sectors (e.g. highways, railways) the standard is not yet comprehensive enough.

Marine: Warships are complex integrated systems, and may be viewed as systems of systems, e.g. a submarine contains in excess of 100 integrated systems which are linked structurally, mechanically, electrically, hydraulically and pneumatically. PLM of a warship/submarine thus requires a comprehensive systems approach from initial concept through to disposal necessitating the integration of numerous complex systems delivering a synergistic, flexible, maintainable, reliable and available cost effective weapon platform. To support such an approach the UK MOD has developed an Acquisitions Operating Framework [16] that decomposes the full acquisition life cycle into 6 distinct stages: Concept, Assessment, Demonstration, Manufacture, In-Service and Disposal (CADMID). Assessment and Demonstration map onto the Development stage of the ISO 15288 life cycle and In-Service maps to Utilisation and Support.

The development of a warship/submarine entails a number of specific engineering tasks that correlate to and overlap with the CADMID life cycle, e.g. design survey, design synthesis, design assessment, system design, etc. [17]. Each stage within the life cycle specifies data or physical outputs, e.g. User Requirements Document and Through Life Management Plan (TLMP) for the Concept stage, System Requirements Document, refined TLMP and detailed plans for Assessment and combination of prototyping and engineering evaluation of the evolving design and its maturity for Demonstration stage.

To aid independent assessment of major defence programmes, a formal gate process is used to assess the maturity of the design. This includes definition of the Support Solution (for in-service) and its data requirements against the Support Solution Envelope and ISO 10303 for PLM. In addition, a warship may receive a number of upgrades to enhance its capability or extend its life. Each will constitute a discrete CADMID life cycle.

The complete lifespan of a naval vessel may be extremely long. The new Fordclass aircraft carriers of the USA are designed for a 50-year lifespan. The data associated with such a lifespan are considerable and issues include multiplicity of formats stored in multiple locations and hardware systems, owned by many organisations and with much of the data security classified in addition to being commercially sensitive. Records maintained by naval vessels are often more complex and onerous than commercial vessels, e.g., quality control: material certification, surveyed material condition, high value/sensitive equipment, and legislative requirements for operation (Lloyds Shipping, Nuclear Inspectorate). This is particularly relevant with respect to nuclear power plant.

The "In-Service" stage of the project will not only encompass capability enhancements of the artefact but also preventive and corrective maintenance. Royal Navy data indicating the "material state" of an artefact is stored in a considerable number of sources, including the Unit Maintenance Management System (a work management scheduling application utilising Reliability Centred Maintenance as the maintenance methodology), Operational Defects system (that records defects that degrade the operational capability of a vessel), engineering logs (paper-based logs detailing defects, fuel usage, engine hours run, equipment temperatures, fire main pressure,…), financial reports (planned and actual expenditure of maintenance undertaken), test/trials specifications and stores usage reports.

The data sources may be combined to formulate a material state assessment; however, the integrity and accuracy of the sources vary. They may exhibit fuzziness, incompleteness and randomness. For example, trials teams' reports lag the operational environment/system condition; financial reports may reflect the hours available rather than the actual work undertaken rather, test specifications reflect what has been achieved rather than a perspective of the system condition/performance. There is also an issue of trust in the data since the management of the data sources may vary between vessels and classes of vessel.

Wind energy: The first wind farms were built in the UK in the 1980's [START_REF] Tavner | Reliability Analysis for Wind Turbines[END_REF] with a typical design life of between 20 to 30 years [START_REF] Musial | Improving wind turbine gearbox reliability[END_REF] which suggests most early turbines are reaching the end of their design life. A number of wind turbines may suffer from early failure, however, this may still be considered acceptable within the overall design of the artefact. The life cycle stages of Concept, Design, Production, Utilisation, Support and Retirement apply equally in the wind energy industry, which has adopted and incorporated computer aided tools for design and data management from its infancy. As noted by Guo [START_REF] Guo | Reliability Analysis for Wind Turbines with Incomplete Failure Data Collected from after the Date of Initial Installation[END_REF] and Hameed [START_REF] Hameed | Challenges In The Reliability And Maintainability Data Collection For Offshore Wind Turbines[END_REF] the main life cycle stage where data management issues persist is during Utilisation/Support. This is because of the gaps that currently exist in the ability to capture, feedback and re-use in-service information of wind power plants.

Product Lifecycle Management Data Issues

Tables 1, 2 and 3 show data management issues at the different life cycle stages for civil/construction, marine and wind sectors respectively.

Concept

With an ageing infrastructure, similar projects may have been undertaken previously; hence, a search of historical information is essential. For ageing assets search/retrieval of legacy data is often difficult and tacit knowledge is used.

Development

Development of design solutions relies on legacy data to understand what has been done in the past or to validate calculations or models. There are issues with finding relevant data and it is not always known whether it even exists.

During the development stage much data can be generated, and in some cases almost all data is kept regardless of value. Data may not be in a digital format and it may be stored in locations that require special provisions.

There are interoperability issues owing to data and organisational diversity. .

Production

Issues arise in capturing details of work undertaken and how. The "as-built" dataset is often incomplete or has errors, without checking every drawing and document this is difficult to manage. There is no formal process for storing configuration data or the required data format. This can result in data that is less useable in the future and may require time to convert or digitise.

Utilisation/ Support

Conversion and interpretation of original data is challenging for example because original drawings are in "imperial" units, modern materials are SI units.

Inspections and regular risk assessment are part of ongoing asset management and may generate substantial quantities of data in various formats. Issues include data capture, format and storage and whether information can be found when needed. In some cases the data that is collected may never be used, conversely data that has not been recorded would be useful.

Data quality is an issue; any data used must be checked first as errors have been found in calculations, drawings and surveys.

Many different people may have worked on the asset over many years which raises issues with respect to retrieval, classification and terminology.

Some data about the asset may be very old and need preservation. Digitisation may be needed to aid access and to prevent excessive handling of originals Retirement A long term storage policy is required for retired assets, especially for culturally significant artefacts.

To enable the safe retirement of infrastructure, information relating to how it was built, the as-built structure and materials used may be required. The process of defining user and system requirements for complex naval systems has resulted in "the addition of costly, and often unneeded, requirements to the Department's most expensive platforms" [21].

Development

The engineering task, Contract Design is the process within this stage; the process will produce a number of detailed specifications the builder can utilise, e.g., Performance specification, System specification, Sub-system specifications, Equipment specifications, Material specifications, Standards, Acceptance criteria and methods, Costs, Build Programme, Delivery date.

Production

The construction of a naval vessel generates a very large volume of design and construction records including "as fitted" documentation of the artefact. It is not uncommon as a consequence of "supplier changes, changing needs and technologies and in-service engineering changes, [that] no two ships are identical when delivered or remain static after delivery." [START_REF] Hall | Organizational Management of Project and Technical Knowledge over Fleet Lifecycles[END_REF]. Configuration management is essential to maintaining a record of the artefact.

Test specifications: a precise record of the design is essential when defining test specifications. They are maintained not only by the builder but also the operators, and there are quality issues in their collection

Utilisation/ Support

Configuration Management (CM) records may be incomplete/inaccurate and as a consequence effective operations and maintenance may be an issue. Failure to maintain satisfactory CM records has the potential for significant impact.

Material state: data to ascertain the material state for maintenance is multifarious and requires fusing and analysis. Furthermore, the management/ administration of the numerous data sources is subject to variations with respect to Nantes, France, 6 th -10 th July 2013 operational commitment, on-board management and data configuration.

Test specifications and results as a consequence of maintenance and upkeep are created and maintained to verify the installation and performance of the numerous onboard systems. Test specifications are maintained not only by the shipyard but also the operating navy.

Retirement

Configuration Management: records may be incomplete/inaccurate because of changes in legislative policy and/or hazards not envisaged at the time of construction raising potential issues regarding the disposal of controlled materials.

Consultation documentation regarding the disposal of nuclear submarines [23] and the handling of radioactive waste is an issue.

Sales literature: a vessel may be sold for further use as a warship, artificial reef, recycling, etc. hence a "detailed" sales brochure may be produced for prospective buyers, e.g., "Commercial sale of Type 22 frigates" [24].

Drawings, documentation, etc., associated with a "retired" vessel will be archived for reference in potential future designs, lessons learnt etc. There are institutional barriers that hinder communication during design of wind turbines [START_REF] Guo | Reliability Analysis for Wind Turbines with Incomplete Failure Data Collected from after the Date of Initial Installation[END_REF] which lead to issues with data access and ownership.

During product development, issues arise with respect to data transparency and availability, whereby components and subsystems are produced by multiple suppliers unwilling to share design information for confidentiality reasons [START_REF] Musial | Improving wind turbine gearbox reliability[END_REF].

There are also issues with ownership of key design information especially when several sub-suppliers are involved in designing and delivering parts of a system while trying to preserve their Intellectual Property.

The use of legacy data for product development purposes may be problematic, because the wind sector is still relatively young with little historical data and because of poor data accumulation during the in-service stage of early turbines.

Utilisation/ Support

Data management issues during utilisation include data capture, access, technological level, data availability, data quality, database management etc. [START_REF] Hameed | Challenges In The Reliability And Maintainability Data Collection For Offshore Wind Turbines[END_REF] discuss in detail the challenges in collecting reliability and maintainability data of offshore wind turbines, and assert the need for a common shared database such as the Offshore Reliability Database used in the oil and gas industry. Some researchers and laboratories have started to capture field data, but in-service data collection may be difficult owing to access issues especially in the case of offshore turbines and onshore turbines erected on harsh terrains.

Technicians may not complete maintenance records within the turbine due to safety concerns, space limitations, etc. thus record keeping may comprise on-site photographs and off-site report completion. Consequently there may be a "time lag" between inspection and reporting, and data may lack definition and quality.

Assessing availability/reliability data is often difficult, exacerbated by confidentiality, data collection methods, e.g., hand-written and computer-written report sheets raising issues with respect to inconsistency of data source format. Some failures of turbines have been gathered without details of the failure mode.

There is inconsistency in file formats and problems with interoperability due to the use of both hand-written and computer based field data collection. Such issues make it difficult for data to be reused for new designs. .

Retirement

Although a number of wind turbines have been decommissioned as a conse-quence of catastrophic failure and early installed turbines are just reaching their end of life there is limited experience or evidence that would support any claims of data management issues during the retirement stage of wind turbines. .

Cross-Sectoral Comparison

Mapping the "information management" issues given in the previous section to these engineering processes the areas of potential concern identified in Table 4.

M W C M W C M W C M W C M W 1 Generate x x x x x Collect x x x x x x x x x x x Transform x x x x x x x x x x x x Retain x x x Retrieve x x x x x x x x x x x x x x Disseminate x x x x x x x x x x Dispose x x x x x
The largest number of issues relate to "Civil", potentially as a consequence of the age of structures, construction techniques, material, legacy data and complexity of the support function. In all domains information management issues are related to the maturity of the technology and the availability, accuracy and volume of data. The Marine domain is assisted by a controlled and defined system engineering environment, and the considerable history and experience of ship design and maintenance, but data dissemination of sensitive data is an issue.

Collecting data is an issue for all domains. This may be due to the availability of data/stakeholders, and volume and accuracy of data. Issues may also arise as a consequence of the physical environment. Data retrieval although an issue in each domain exhibits differences in application, e.g., Civil ~ large volume of legacy data including historical paper records, Marine/Wind ~ numerous locations and data held by multifarious organisations. Utilisation/Support identifies the largest number of issues, i.e., collating, processing, retaining and retrieving data potentially as result of the volume of data, availability of data / stakeholder, time constraints.

Conclusion and Proposals for Future Work

Engineering domains have similar data management issues but it is important to consider the circumstances in each domain to understand the full range of issues that may apply. In particular, very long lived artefacts have special requirements especially artefact such as the CSB which has a distinctive requirement "to pre-serve […] in perpetuity", not simply as a monument but as a fully functioning bridge. The large volume of CSB data which includes historical records exacerbates the data management issues. Special issues may also arise, however, when issues of national security or commercial confidentiality are present, as shown by our study of the marine sector and wind energy respectively. For all of the sectors studied the greatest number of issues, and hence perhaps the greatest potential for improvement, arise in data management for the utilisation/support stage. Technology may ease the burden of data collection by means of remote sensing, hand held devices, etc. allowing data to be more readily transformed. Engineers and management may subsequently utilise/apply data mining techniques to retrieve, interpret and exploit data as a real resource/tool.

Future work should start by clarifying the issues highlighted into specific workflow issues and expanding the study to encompass a larger number of case studies. The stages of the life cycle could be grouped into pre-utilisation (concept, development and production), utilisation/support and retirement. Grouping the stages may provide a clearer understanding of the cross-sectoral nature of issues but suffer from a loss of granularity as a consequence; finally, data/information transfer between stages may also be studied as a potential area of weakness.

Table 1 .

 1 Data Management Issues: Civil/Construction Sector Life cycle stage Issues (especially concerning long-lived assets)

Table 2 .

 2 Data Management Issues: Marine (Defence) Sector

Life cycle stage Issues

Concept

Documenting and agreeing user requirements is challenging given the numerous operational, human factors, safety, environmental, security and other issues identified by stakeholders, e.g. operational capability/ restrictions, potential future changes, constraints on capability such as legislation, policy, timescale.

Table 3 .

 3 Data Management Issues: Wind Energy Sector

	Life cycle stage Issues
	Concept
	Development
	Production

Table 4 .

 4 Analysis of Information Management Issues. Note (1) Owing to limited maturity of wind technology, issues associated with "Retirement" are excluded.

		ISO 15288 Stage. Note C ~ Civil, M ~ Marine (Defence), W ~ Wind
	Data	Concept	Development	Production	Utilisation/ Support	Retirement
	operation	C

Acknowledgments. The work reported was supported by the Bristol/Bath Industrial Doctorate Centre in Systems, funded by EPSRC grant EP/G037353/1.


Idai Mendy Mombeshora

Elies Dekoninck

Web-Based Portal for Sharing Information through CAD/PLM Software during the Eco-product Development Process

de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

With organisations experiencing increased social and regulatory demands to behave in an environmentally conscious manner, environmental impact is fast becoming a factor considered on par with cost, functionality and value during the product development process. Against this back drop, some organisations are enhancing their competitiveness by improving their environmental performance through the mitigation of the environmental impact of their production and service activities [START_REF] Bacallan | Greening the Supply Chain[END_REF]. However, others view these new requirements as mandates or burdens that slow development while ramping up cost, detracting from the main business of the company. As a result, environmental aspects are often considered an afterthought, resulting in delays and added costs as changes are made after the late addition of environmental requirements into the development process [START_REF] Handfield | Integrating Environmental Concerns into the Design Process: The Gap between Theory and Practice[END_REF]. With its roots in concurrent engineering; three dimensional concurrent engineering (3DCE) holds great promise for integrating environmental considerations into the product development process. 3DCE is the notion that the simultaneous design of product, process and supply chain, through links between internal functions and participation with external partners, leads to improved operating performance [START_REF] Fine | Clockspeed: Winning Industry Control in the Age of Temporary Advantage[END_REF]. Although relatively new in practice, as companies are begin to embrace it, 3DCE appears to be a lens for demonstrating that eco-design efforts can support both traditional and environmental product development goals [START_REF] Ellram | Applying 3DCE to Environmentally Responsible Manufacturing Practices[END_REF].

As the environmental performance of a product is the amalgamation of its environmental impact through all the stages of its lifecycle, from the extraction of raw materials to its end of life, it is dependent on the totality of the supply chain in both upstream and downstream directions throughout its lifecycle. During the product development process, it is necessary to have as much information as possible pertaining to the environmental performance of the various supply chain partners and the products and services they provide. With product lifecycle management (PLM) systems gaining acceptance as means for managing information about a product throughout its lifecycle [START_REF] Sudarsan | A Product Information Modelling Framework for PLM[END_REF], they hold the promise of seamlessly integrating and making available all of the information produced throughout all phases of a product's life cycle to everyone in an organisation and through the product network.

Set within the context of the household appliance industry and through the adoption of the 3DCE and PLM approaches, the integrated software platform for Green ENgineering dESIgn and product sustainability (G.EN.ESI) project is a European Union Seventh Framework project that aims to achieve a 30% reduction in lifecycle energy use and a 50% reduction in industrial waste in household appliances produced based on the choices made through its software platform and ecodesign methodology. For the successful integration of the G.EN.ESI platform into CAD/PLM software, it is paramount to ensure that there is an accurate and reliable flow of information from various supply chain partners, including suppliers, product dismantlers and distributors, to the software. This vital flow of information from the supply chain into the design process via the G.EN.ESI platform will be realised through a unique web-based supply chain portal. Since internet communication technologies gained popularity as a means of simplifying business to business communications, supplier portals have been found to promote information sharing and coordination of operational flows [START_REF] Mcivor | Collaborative buyer supplier relations: implications for organization change management[END_REF], support supplier management and create a sense of community among buyers and suppliers; while increasing the stability of relationships and suppliers' loyalty to their customers [START_REF] Roberts | Web Portals pen doors to one-step services[END_REF]. It is this collaborative potential within web portals that the G.EN.ESI project is looking to harness.

In this paper, the G.EN.ESI project will be presented, with particular focus on the initial steps in the development of the web portal which can be viewed as the evolution of the supply chain web portal from its traditional role as an e-procurement tool into an information sharing tool. The web portal's development will be presented after a brief discussion of information sharing and interorganisational systems.

Importance of Inter-Organisational Information Sharing during the Product Development Process

Information sharing can be applied to almost all core domains of corporate operational activities. Ranging from customer chains where information can aid in the formulation of customer experience strategies, to exchanges within the development chain where information is shared within product design and product lifecycle management activities and supply chain information exchanges that lead to greater visibility and responsiveness [START_REF] Yu | Benefits of Information Sharing with Supply Chain Partnerships[END_REF]. Typically, information sharing within the supply chain is associated with maximising responsiveness and efficiency while minimising cost, with the relationships formed handled by the procurement and/or logistics department; while, information sharing within the product development chain is allied with the acquisition of resources and capabilities to improve product offerings, with the collaborative relationships formed more likely to have a research and development focus.

On the one hand, there is Kanter's notion of collaboration advantage, defined as " a significant leg up in a global economy due to a firm's well developed ability to create and sustain fruitful collaborations" [START_REF] Kanter | Collaborative Advantage[END_REF], which is associated with the product development chain; while on the other, there is the resourcebased theory view that one source of differential performance between firms is the way in which they organise exchange activity [START_REF] Conner | A Resource-Based Theory View of the Firm: Knowledge vs Opportunism[END_REF], which is related to the supply chain. Therefore, it would seem logical to then deduce that amalgamation of the two forms of information sharing would result in advantages gained through the unified use of the formed relationships, enriching the depth and quality of information shared via both design and supply chains. With particular focus on design chains and collaborative design, utilising supply chain information sharing relationships and methods within the product development process would offer a means of augmenting the match between product and process, which most companies accomplish through concurrent engineering, with an additional consideration of supply chain configuration.

The G.EN.ESI Project

Through the development of a software design tool (G.EN.ESI platform) and supporting eco-design methodology (G.EN.ESI methodology), the G.EN.ESI project aims to address the lack of easy to use and robust tools for environmental evaluation at the engineering design stage. Currently available tools are either too qualitative/subjective to be used by designers with limited experience, or too quantitative, costly and time consuming for use during the early stages of the product development process [START_REF] Boks | The Soft Side of Eco-design[END_REF]. Moreover; these tools are usually stand alone and do not allow for easy integration with traditional design tools. The shortcomings of current eco-design procedures and tools mean they fail to offer practical solutions for day-to-day use as they only achieve limited industry penetration [START_REF] Lofthouse | Eco-design tools for designers: defining the requirements[END_REF]. The main objective of the project is to supply a platform that can be completely integrated with other main design tools, such as CAD and PLM software, which helps designers make ecological design choices without losing sight of cost and typical practicalities of industry.

The G.EN.ESI platform architecture will be based on the integration of various tools into the same structure, with the tools communicating to support the entire product design process; an example of a tool is the S-LCC analyst tool which will evaluate the whole product lifecycle. Each tool within the platform will examine design choices from a specific point of view while simultaneously possessing the ability to provide information to the designer on environmental issues. This connection between the tools will allow for an immediate check of the congruence of the choices with other key design parameters. Additionally, environmental decisions made by the designer will be supported by a case-based reasoning tool which will utilise knowledge stored from previously successful cases to suggest possible environmental improvements.

How the Supply Chain Portal Supports the G.EN.ESI Platform

A reliable input of accurate data and information is central to the success of the software platform; the platform will manage data through relational databases structured such that they align with the most common databases which support software tools used by the companies. The G.EN.ESI databases will not only inherit data from local company software tools (CAD/PLM) but will also collate data from various members of the supply chain through the use of a web-based portal. Using information that the supply base inputs into the portal, the platform tools assesses the environmental impacts and cost of various options, such as materials, components, processes etc., allowing the designer to select the most convenient in terms of environmental aspects. The use of the web portal will encourage sustainability competitiveness within industry, while stimulating ecoefficiency throughout the whole supply network.

Figure 1 shows the structure of the web portal proposed by the project and how the portal interacts with the software platform. An example of how the portal and platform interact when used by a designer is as follows: a member of the supply chain uploads information into the portal regarding a component, including weight of component, geographical location of the production plant and transport used to ship it. When the designer selects this component during the design process, the 0km tool within the platform automatically downloads all the information regarding the transport scenario from the portal. The 0km tool collates transport information relating to all the chosen components within the design, it is this information that is used as part of the environmental impact (S-LCA) and cost (S-LCC) calculation along with calculations made from other tools such as DFEE and LeanDFD. The results of these calculations are then presented to the designer. To ensure effective deployment of the supply chain portal, it was essential at this early stage in its development to explore possible portal architectures based on the impact that the nature of shared information, who it is shared with, how it is shared and when it will be shared would have. Based on this, the following specific aims were created for this paper:

1. Explore possible portal architectures and resultant strategic scenarios for the web portal -to ensure that the G.EN.ESI web portal's functional requirements align with the strategic implications it would have on users. To ensure that the architectures, scenarios and use cases developed are truly representative of what is likely to transpire in industry, it was necessary that their development was based on information gathered from potential platform users. Due to the dual nature of the collaboration requirements and to ensure that both options are sufficiently researched, a two-phase data collection process was formulated and executed. Firstly, data was collected through an online administered survey aimed at understanding the nature of supplier collaboration in new product development (SCNPD) with particular focus on the perspective of suppliers. The survey garnered 76 responses from individuals involved in SCNPD projects across a number of engineering industries. The second phase, whose aim was to acquire a better understanding of the acceptability of the portal's proposed role, the climate under with it would be used and the profile of a typical platform user, involved an in-depth case study of a G.EN.ESI project industrial partner. Table 1 summarises some key results from the two phases of data collection.

Table 1. Key results from data collection phase

Online Survey -Most cited factors/qualities to consider when selecting a partner were trust and reliability, openness and mutual support, congruence of goals and relationship.

-When asked which was more important, trust or contracts, 50% of the respondents said trust and the other 50% said they were both equally important.

-Most frequently faced challenges when collaborating were relationship management, aligning goals and objectives and financial burden.

-Most difficult challenges faced when collaborating were dealing with failed relationships, relationship management and aligning goals and objective -Effects of failure were relationship breakdown and end of collaborations.

-Most projects only exchange information and knowledge that is essential.

Case Study -Biggest concern with portal is the security of the information that is shared. "I don't know if I can trust sharing information over the internet, how can you be sure that only the people you want to can see the information you upload?" -Cited that the fear that information would get abused, used for anything that has not been agreed upon, is a concern. "It is not like if you are not happy with what they are doing with the information you can take it back".

-"Getting information from our suppliers is hard enough as it is, even information that they possess; they usually refer us to a data sheet on the website." -"If the people we supply to asked us for the information that we would likely have to ask for from our suppliers, we would not be able to provide it."

Developing Portal Architectures and Strategic Scenarios

To determine various strategic scenarios relating to the supply chain web portal, the technique of scenario planning was used. Scenario planning is a futures technique that is used to generate different scenarios that represent possible futures associated with different trends and events to help develop policies and strategies that are robust and flexible [START_REF] Schoemaker | Scenario Planning: A Tool for Strategic Thinking[END_REF]. In this case, scenario planning was undertaken to determine the following: 1) the best way to structure the supplier portal, 2) strategic implications its structure would have on buyers (firms using the G.EN.ESI platform) and suppliers (supply chain firms that upload information into the portal) and 3) how the way the portal is used varies depending on the strategy implemented. The key question, central to the scenario planning, was as follows: "what is the best and most viable way of structuring a web based supply chain portal to facilitate information sharing between firms that use the G.NE.ESI platform and members of their supply chain?" Through the analysis of past and present web portals and insights gained from the data collection, drivers and deterrents were generated and used as the basis of the scenario generation. Some of the key driver and deterrents are listed in Table 2.

Table 2. Drivers and deterrents influencing the adoption of web portals

Drivers and Deterrents Impact on financial performance. Impact on other business processes. Impact on product development process. Ease of data input into portal.

Availability of required

Alignment with strategic focus. Buyer power vs. supplier power. Cost of use. Impact on reputation. Availability of resources. The two axis method, based on one of the approaches employed by Shell (Foresight, 2009), was then used to generate four contrasting scenarios that are related to the use of web portals by placing a major factor influencing the future of the issue on each of two axes that cross to form four quadrants. It was identified that the major factors influencing the use of the portals were related to the number of companies that would use a single portal; with Multiple Suppliers ↔ Single Supplier on one axis and Multiple Buyers ↔ Single Buyer on the other. A four scenarios diagram, with each scenario represented as a series of potential gains and barriers, was then developed; a simplified version is shown in Figure 2.

Following the scenarios development, the main actions that could be taken to manage the risks inherent in each scenario were identified. With so many firms involved with a single portal in Scenario 1, the development of robust ownership rights is a must to ensure that portal is maintained and monitored for misuse. In Scenario 2, as the buyer has access to collated information regarding a number of suppliers, there is scope for misuse, making it is essential to ensure that the buyer does not have sole responsibility of the portal. The portal should also allow suppliers to export information across multiple portals if they have multiple buyers using the G.EN.ESI platform. Scenario 3 requires a function that allows buyers to assign multiple portals to a single software platform and due to the scale of their responsibilities it is paramount to ensure supplier commitment. The main action with Scenario 4 is to ensure that both parties are fully committed and aware of the work involved if they end up associated with multiple portals; additionally, buyers should be able to assign multiple portals to a single platform and suppliers should be able to share information across multiple portals. Regardless of the scenario, it is essential to guarantee the security of information shared through the use of heightened security measures. Guided by the insights gained during the data collection phase, ten possible use cases were developed. These are possible cases that can arise when the various portal architectures, and their resultant strategic scenarios, are implemented. The list of cases was not exhaustive however; it aimed to encompass a variety of ways that the portal could be used. An example of a use case is as follows: various people from the supplying company have access to the portal. For example, designers of the components being supplied manually enter information into the web portal. There is no one that has been specifically assigned the task of regulating the way in which information is uploaded into the portal.

When set within the context of the strategic scenarios, the use cases can provide useful 'reality checks' on the scenarios, helping to consolidate the overall vision of the web portal with the way it is used and highlight potential risks and challenges. As a result, the use cases were tested against the developed scenarios by mapping them against each other in a matrix (wind-tunnelling) (Foresight, 2009). The focus was on how robust each use case is (can it be performed within the scenario) and the ease of implementation and use. Wind-tunnelling offers a way of determining the viability of the scenarios; if all use cases are robust or easy it suggests high viability, only certain use cases are robust or easy suggests medium viability and no robust or easy use cases suggests low versatility.

The results from the wind tunnelling ranked Scenario 1 as highly viable, Scenario 3 as medium-high viability and Scenarios 2 and 4 as medium viability. This suggests that within the context of the G.EN.ESI project, all the scenarios would work, with Scenario 1 being the most favourable as within it all use cases were deemed as at least possible and at most robust and easy. In the kitchen appliance manufacturing industry, which is mainly comprised of SMEs, having one portal as proposed by Scenario 1 offers significant benefits in terms of acquiring supplier buy-in. Through the use of a single portal, multiple buyers and suppliers are consolidated, mitigating any issues that might arise as a result of mismatched bargaining power that is likely to arise between individual buyers and suppliers. As more and more firms within an industry adopt the G.EN.ESI platform, it could provide a consistent method of sharing information resulting in the formation of an industry wide information sharing standard that has a particular focus of eco-design.

7

The Nature of Existing Compliance Supplier Web Portals

To put the G.EN.ESI portal into context in terms of the evolution of supply web portals, research was undertaken into existing web portals to determine their nature and the scenario which their structure would fall into.

It is undisputable that the use of web portals is on the rise as the popularity of advanced procurement increases; however, due to the difference in the nature of information being exchanged, a shift in focus from traditional procurement portals to compliance portals is required. Examples of such portals include BOMcheck (www.bomcheck.net), in the Scenario 1 category; Freescale (www.freescale.com), in the Scenario 2 category and vendors such as Enovia (www.3ds.com) and Supplier Soft (www.suppliersoft.com), who offer self-service portals where suppliers get a single interface to interact with, while the deployed system depends entirely on the user and industry. These portals are generally used to exchange information including environmental compliance, conflict materials and materials compliance, amongst others. The strength of compliance portals lies in their ability to simplify and automate the process of acquiring data from different suppliers. However, their main weakness is that they require commitment from suppliers who might be reluctant to share information if they are not obliged by law to share it.

Conclusions and Moving Forward

The work detailed in this paper focused on the initial steps in the development of a PLM based web portal, specifically exploring possible portal architectures based on their strategic alignment with the goals of firms using it. All the work that was carried out was informed by knowledge and information gained from researching past and existing web portals, a survey into supplier collaboration projects and an in-depth case study potential G.EN.ESI platform user. Four different architectures, based on the number of companies interacting with a single portal, were generated using scenario planning and presented as a series of potential gains and barriers. Ten use cases which provided a range of possible cases that could arise within the four generated scenarios were created allowing for the viability portal architectures to be tested using the technique of wind-tunnelling. The results from the wind tunnelling ranked Scenario 1 as highly viable, Scenario 3 as medium-high viability and Scenarios 2 and 4 as medium viability. In Scenario 1, multiple buyers and multiple suppliers interact with a single web portal. The consolidation in buyers and suppliers mitigates any bargain-power related issues that might arise, while making way for the possible development of an industry wide information sharing standard. Looking in to existing portals, the presence of compliance portals highlighted that web portals are now being used as more than eprocurement tools.

Moving forward, the project aims to gain a better understanding of supplier collaboration in new product development through the use of the portal by exploring the nature of the information being shared, the roles that users of the portal play (those who initiate it vs. those who participate in it) and any competitive conditions associated with the use of the portal.

Fig. 1 .

 1 Fig.1. Structure of the G.EN.ESI platform's web portal 3 Supply Chain Portal Development Objectives

  2. Develop possible use cases for the web portal and use them to test the viability of the architectures and strategic scenario -to gain an understating of how the portals would perform in various situations. 3. Classify existing compliance web portals based on the developed scenarios and architecture -a way of understanding what is already available and how it relates to the proposed G.EN.ESI platform 4 Research Methodology and Results

Fig. 2 .

 2 Fig.2. Simplified four scenarios diagram 6 Strategic Scenario Viability Based on Portal Use Cases