Niko Ville

Salonen Rolls-Royce

PLM and Classification Society management in Marine manufacturing companies

Introduction

This study was started after 'Systems thinking and systems engineering' program arranged in Finland by group of technical universities and educational learning centre, Edutech, during 2011-2012. The program inspired to think could system modelling techniques give new ways of solving, proving and improving operational strategies and models in conjunction with PLM/ERP systems, Integrated Production Systems (IPS) in combination with more general techniques of UML modelling and other types of use case and data flow map presentation methods, and by using improvement tools such as lean six sigma 'toolbox'.

This study concentrates to identify specific Marine industry specific engineer to order based classification society management requirements and processes, which are known, but create extensive landscape of various certification processes influencing operational management of design, manufacturing, procurement and financial transactions, including invoicing and cost control to manufacturers like Rolls-Royce. This study focuses on modelling of different certification processes for configurable project specific products.

This study illustrated the same need and missing functionality from component manufacturer's point of view as Ehrler et al. (2007) [4] describes for classification society Germanischer Lloyd (GL), that currently these requirements are not sufficiently addressed by state of the art PDM/PLM software tools and solutions.

Classification societies have to manage product oriented structures (as designed, as built), associated analysis and simulation data (FEM, CFD) and manifold relationships to external part catalogues and material databases Additionally, the underlying information model has to be extensible and adaptable during production use in order to satisfy short term requirements from different certification projects.

The outcome of this study is setting a framework of studies carried out currently and in next coming 1-2 years trying to describe specifically manufacturer's business processes to meet the requirements from the classification society's, project management's and engineering change management's process point of view including the engineering to order logistical planning requirements for marine products. All these requirements are generic to all products, which are to be certified.

The key question for PLM from this study is could system modelling of dynamic systems give new ways of solving product lifecycle management system development issues by introducing modelling techniques to enable simulations to prove and select best option from possible technical architectures. The elements identified in this study should be compared with ISE information model AP239, Product Life Cycle Support (PLCS), known officially as ISO10303-239:2012 [START_REF]Industrial automation systems and integration -Product data representation and exchange, Part 239: Application protocol: Product life cycle support[END_REF], is an international standard for the definition and exchange of product data needed for the long-term support of very complex products, such as ships. This model is again linked to various information models, including STEP geometry definition standards.

Approach

The approach used in this study is based on 13 years of experience working in marine manufacturing industry. During this time, first working with classification society processes in engineering at Rolls-Royce, in Finland. Later work has included developing different PDM/PLM solutions in local engineering organisations and during the last 3 years in central Rolls-Royce Marine PLM team enabling new methods and systems to comply with the varying classification society rules from the perspective of Rolls-Royce Marine delivering more than 150 different product types to thousands of customers.

The approach is taking account current ISO standards and commercial PDM/PLM/ERP tool capabilities, and articles and papers written within Marine industry conferences and organisations like ISSC. Statistical information from current IPS systems is supporting the practical knowledge. The conclusions are based on abstraction of true artefacts into concept generalisation.

Classification societies [6]

It is important to understand the relation between product manufacturers using different PLM/IPS systems and marine industry Classification Societies.

A classification society is a non-governmental organization that establishes and maintains technical standards for the construction and operation of ships and offshore structures. The society will also validate that construction is according to these standards and carry out regular surveys in service to ensure compliance with the standards. To avoid liability, they explicitly take no responsibility for the safety, fitness for purpose, or seaworthiness of the ship.

Classification societies set technical rules, confirm that designs and calculations meet these rules, survey ships and structures during the process of construction and commissioning, and periodically survey vessels to ensure that they continue to meet the rules. Classification societies are also responsible for classing oil platforms, other offshore structures, and submarines. This survey process covers diesel engines, important shipboard pumps and other vital machinery.

Classification surveyors inspect ships to make sure that the ship, its components and machinery are built and maintained according to the standards required for their class.

Today there are a number of classification societies, the largest of which are Det Norske Veritas, Lloyd's Register, Germanischer Lloyd, Nippon Kaiji Kyokai, RINA and the American Bureau of Shipping.

Marine vessels and structures are classified according to the soundness of their structure and design for the purpose of the vessel. The classification rules are designed to ensure an acceptable degree of stability, safety, environmental impact, etc.

All nations require that ships and other marine structures flying their flag meet certain standards; in most cases these standards are deemed to be met if the ship has the relevant certificate from a member of the IACS or EMSA. Certificates issued by the classification society on behalf of the flag country are also required for pumps, engines, and other equipment vital to the ship's function. Equipment under certain sizes is usually excluded from these certificate requirements.

In particular, classification societies may be authorised to inspect ships, oil rigs, submarines, and other marine structures and issue certificates on behalf of the state under whose flag the ships are registered.

As well as providing classification and certification services, the larger societies also conduct research at their own research facilities in order to improve the effectiveness of their rules and to investigate the safety of new innovations in shipbuilding.

There are more than 50 marine classification organizations worldwide.

[6]

Principle certification requirements for component manufacturer

The principle certification requirements defined by the IACS include two main requirements that can be extracted and implied how product manufacturers need to comply in general terms against specific classification rules.

Design certification models

Design certification is one part of certification process. The IACS definition A. above describes the final requirement for design to be certified. The most used model as the IACS implies is the project specific "case by case" certificated design certification model.

Unfortunately the review process is not tuned from information flow and process point of view to level that customer delivery time requirement is always met. The demanding addition in ship building industry is the engineer to order process, which in reality means that all requirements are not defined before the design process starts and in many cases even the manufacturing must be started before all requirements are fully known. This means that customer detail requirements are changing during the delivery process. For configurable marine products the definition of "product design plan for new vessel" is even more challenging as the vessel, generally 'application' changes the rules against the product.

Therefore classification societies have various design certification models to support and improve management of delivery time. The next more generic is "product (design) type certification", which is in some classification societies named as "design appraisal" (incl. Lloyd's Register). The next level of approval is "design type certification". Some classification societies also have "special agreements", which two are mentioned below.

Special agreement (DNV) [7]:

In order to support efforts on reduced delivery time and to ensure efficient and correct certification processes, DNV consider it beneficial to establish General Certification Agreements (GCA) between manufacturers and DNV.

In such agreements the daily procedures for efficient processes for design approval and surveys will be laid down. Information and documentation needed and required by the two parties may also be defined and be part of such agreements.

Further, the agreement will also normally include commitments on transfer and sharing of information and experiences that are considered beneficial for the manufacturer and DNV. [7] There are also concepts of certifying the entire PLM/IPS system in cases where products can be fully 'configured to order'. Then the certification is done against the PLM/IPS systems and configuration rules within the system. In these cases the management focuses in the robustness of the system rules and to the change management of these rules. This level of certification is extremely difficult to obtain as the next sections will identify from the fact how much the processes vary. This type of certification is also business risk for the manufacturer as the system management becomes controlled also externally and the entire business knowledge is tight to the systems, and dynamical business changes or business strategy changes can not be easily adapted and systems modified.

Component and materials certification models

Component and materials certification is the second part of certification process. The purpose of this process is to ensure the quality and traceability of used materials and components. This model contains again classification specific variations, but elements are based on international standards like the "standard inspection documents", which is defined from ISO 10474 [8] (previous EN 10204-91) and EN 10204:2004 [10]. Classification societies have own definitions and names for these, but manufacturers refer usually to the ISO standards.

The material certification process starts from the combination of application and product specific rules. Some critical components require certification of material. These are identified from the basis of criticality of operability and safety of the application (vessel). Classification rules define specific inspection document types [7] for each component or functional component category, for example main propulsion shaft line components (including shafts, gears, bearings, clutches, couplings, propellers etc.).

The actual material certification process requires specific "samples" and "test reports" performed and documented by defined authority, which again can vary, and finally including "material inspection", also having element of options which party can perform the inspection.

Certified components and materials can be traced by unique item codes or by item serialization. Serialization has been more used and rational way of managing item data in ERP systems. Materials are serialized "by lot" and components requiring certificate "by unit" or "by lot". By lot means the material is traced to a level of raw material batch. By unit means that the component is traced to level of every unit produced.

Most used component/material certification is "case by case" certification as is for design approval. Manufactures and classification societies are trying to improve the process performance in different ways. One of these methods is by "group certification", which is not fully standardized approach from the fact that sharing the certification is not improving classification society's individual profitability of their business. From customer's, ship builder's and manufacturer's perspective this would be excellent way of improving the process as it increases flexibility to use certified materials and components. This is another topic for the financial management and dynamic systems modelling of the classification society management.

More used classification society specific process model for manufacturing is called "type approved manufacturing process", which is defined as part of "type approval" in some classification societies (incl. Lloyd's Register). In DNV this approval model is called Manufacturing Survey Arrangement (MSA) [7] in Lloyd's Register of Shipping type approval term is used for overall approval of design and manufacturing, and 'design appraisal' is the term used for design certification.

In general classification society type approval requires companies to be certified with ISO 9001. This rule applies to all type approvals.

Product certification process

Product certification is the top level certification that links the product to the actual application, ship, oil rig or submarine. Type approved components or products must always be still documented against the application and classification societies will review that the type approvals are compliant within the application and usage of product in it. However, when configuration management of product is done properly within the limits of the type approvals, manufacturer can process the product certification efficiently by extracting and collecting the documentation from the PLM/IPS system. "Manufacturer's declaration" is the first principle assurance of compliance from the manufacturer, that each installed product will be according the specific classification society rules.

The product certification process usually includes system and assembly level testing. The classification society inspects onsite that the specific serialised manufactured product and certified documentation is according the rules for specific application. When product and documentation is according specific rules the inspector will issue unit certification and product is ready to be installed to the application (vessel etc.).

From manufacturer point of view the product is now ready to be shipped to shipyard to be installed to the specific application. This study does not include the classification processes in the shipyard. This process includes also the sea trials, but this level certification is against the entire application and main aspects of manufacturer classification processes have been performed before this lifecycle phase.

Financial invoicing and costing models

Financial aspects of classification society management are not part of scope of this study, however it is important part of overall evaluation of classification society management and even more important for understanding and improving using dynamic system modelling and simulation methods.

The complexity of classification processes makes recording and managing cost difficult based from two different aspects. As the rules itself are complex and variable, so are the financial transaction models. First point is that invoicing is not standardized among classification societies and there are several agents causing additional variation to the cost collection and invoicing process. This again means that manufacturers can not record accurate classification process cost and often even invoices against specific items in ERP systems. Very often the cost is recorded for the delivery project or even worse on yearly basis. Defining standard costing models and processes for financial invoicing and costing must be part of future study to be able model and simulate the system dynamics.

Current product life cycle standards for marine and classification societies

The standard exchange ship Product Data Model is STEP (ISO 10303). This Application Protocol shares some modules with the AP239 devoted to Product Life Cycle Support (PLCS) that was published on 2005 and latest 2012. AP233 is the standard for Systems Engineering Data Representation. The objective is to provide the functionality defined in the shipbuilding application protocols using a combination of STEP AP239, AP214, and reference data libraries.

DNV has presented a product model specifying a standardized vessel description for class work [START_REF] Vindøy | A Functionally Oriented Vessel Data Model Used as Basis for Classification[END_REF] [START_REF] Vindøy | A Functionally Oriented Vessel Data Model Used as Basis for Classification[END_REF] based on ISO 15926 and DNV's own "ships functional" classification hierarchy.

Classification society approval processes in shipbuilding introduce additional and specific requirements for information management systems to be used in the ship design process. ISO 10474 [8] defines the inspection documentation requirements adopted with modifications to classification societies. ISO 9001 is quality standard that most marine product manufacturers have adopted also to support ways to improve the classification society certification processes. Different engineering change management approaches which form the basis of these functions in PDM systems are listed. The most relevant ones are: Quality management -Guidelines for configuration management (ISO 10007), Institute of Configuration Management (CMII), Workflow Management Coalition (WfMC) and the ISO 10303 Standard for the Exchange of Product Model Data (STEP).

Product lifecycle view of certification processes

Below a simple component based certification process (Figure 1.) is described in SIPOC (Supplier -Input -Process -Output -Customer) process model. The process is also the most often used "case by case" classification (meaning all documentation and process is re-used and each step in the process is performed again and again for each delivery project for specific customer). Any dynamics (including feedbacks, other loops, delays etc.) are not considered in the SIPOC model. The SIPOC does not either consider the original design requirements that have been identified against the product definition.

The SIPOC process figure's key elements are creating design documentation that is reviewed by classification society authority and stamped as approved. Then the manufacturing process is inspected based on rules and against the approved design documentation (the meeting point of design and physical product).

This process is performed to all components defined requiring certification by the specific classification society rules. Final product/system (Unit) inspection is collecting all related approved documents and product certification is given to the equipment.

This process is followed for every product delivered to customers. There are two very specific differences compared to other businesses (car, aero manufacturing): Rules change based on specific classification society (and there is several as mentioned in the chapter Classification Societies) and the other difference is that final inspection is done by specific classification society inspector for every sold unit.

Fig. 1. SIPOC for 'case by case' classification process without any dynamics

When manufacturer is operating by "case by case" basis and using manufacturing suppliers the flow of information, material and people can be illustrated as in figure 2. This figure shows also the 'happy path' without any additional loops, which may occur in the process.

The link from certificate management to the supplier or to internal production is critical flow connection point of documentation information to physical product flow. These connection points and the dynamic flow of information and components/material is causing that "case by case" certification does not work, main reason for dynamics is that both flows contain variations of loops and delays.

There have been situations, where classification societies request the documentation package of the entire product to be sent only when fully complete, which again fights against the ETO process principles. It is fully understandable from classification society point of view, that it would be easier to review the documentation as one fully defined package rather than one evolving package of documentation to obtain the product approval. However the business requirements do not make this easy or practical.

Fig. 2. Information and material flow in 'case by case' delivery process

In comparison for type approved design and certified manufacturing process the flow is presented in figure 3.

The situation of "design type approved" documentation information flow in figure 3 would show in stock flow model differences from "case by case". The difference is, the design certification is already obtained and the data can flow through the purchase order or production order process information flow and not as separate information flow. Obtaining the Product (Unit) level design approval is easier as the package of documentation can be provided early on the process.

Fig. 3. Information and material flow of type approved and manufacturing approved process

Theoretical link between PLM and Classification Society management

The theoretical relation between PLM and Classification Society management can be identified by systems thinking (including many systems engineering principles) and information science levels. Operations management theories could be linked also between PLM and Classification Society, but are out-scoped as systems thinking and information science are deeper principles that this study concentrates.

Using definitions: openness, purposefulness, multidimensionality, emergent properties and counterintuitive from Jamshid Gharajedaghi's, 'Systems thinking, managing chaos and complexity' book [START_REF]Systems thinking: managing chaos and complexity[END_REF], the link between systems definitions and certification process can be achieved.

The certification of component within an application has direct correlation to open systems principles, where the certification requirements can be understood only in the context of the environment, the ship and product located in specific function. The certification changes additionally between classification societies, but these differences can not be reasoned directly, but can be seen as variation or immaturity of understanding systems.

Purposefulness can be seen of understanding why certification is happening. The value-guided system can be identified in this study by challenging the current models, especially the 'case by case' certification process based on understanding the what, how and why of the system, classification society management.

The plurality or multidimensionality of classification society management and certification process can be identified in function, structure and process levels. The system ship-product-component and certification process has several functions, for ship owner it is means to manage the insurance cost, secure the quality of product, for classification society it is means to earn money and improve global safety of sailing ships, and for component manufacturer it can secure easy entry to market and help identifying principle rules that shall be complied when designing and manufacturing products to commercial marine ships. The plurality of structure for certification required components and an entire product structure are closely linked between the PLM and Classification Society certification process. The plurality and 'equifinality': a final state can be reached from same initial conditions by number of routes. Certification processes can be seen from the differentiating from causality by ability to certify the product with various certification methods.

Emergent properties of classification society certification management could be the overall satisfaction of all parties in the certification process, ship owner, shipyard, classification society, manufacturer and others. This satisfaction will evolve the systems behaviour over time.

Counterintuitive behaviour can also be seen part of classification society management. Only taking one example is component manufacturer's overall cost management. The cost structure and behaviour of certified components for many manufacturers can not understand if there is not enough knowledge how the system behaves with various dynamical relations. This can lead to mistakes from 'assuming' that changing one parameter of the system would lead to positive reaction, but actually result can be opposite, negative increase of overall cost.

Systems engineering and it specific area of requirement management is core part of PLM principles and also PLM systems. The classification society rules are requirements and very much structured requirements.

Information and library science's classification, collection, manipulation, storage of information is field, which is basement for researching computer science, database systems and overlaying PLM applications. Turning the conceptual certification process and information principles identified in this study will eventually lead to defining information architectures, information management and information retrieval concepts for the PLM (IPS) systems.

Principle impacts to PLM and entire IPS

Previous classification rules, including design, component/material and product certification creates complex process and data model requirements to manufacturing company, especially when same product is certified to different classification societies and product is used in different applications (ships, oil rigs etc.) or/and having different usage models.

The engineering principle of form, fit and function (FFF) definition can be jeopardized by this if items contain data of classification society specifics. From engineering perspective keeping product definition purely compliant to FFF reduces enormous numbers of variants of items. From engineering point of view and from management point of view isolating the item definition purely into FFF, means that the item (raw material, component, assembly or product) must be maintained as such trough it's whole lifecycle from cradle to grave. To the question how the requirements can be met without jeopardizing true FFF item definition is explained next.

The classification rules for manufacturer can be identified as requirements same way as actual customer requirements are defined. The requirements can be divided to into categories described earlier. The requirements are also assigned to different lifecycle phases of the product. Common requirement and domain is that requirements are including the application domain, which creates need for conditional requirements from manufacturer point of view manufacturer wants to use the product in different applications. For configurable products this creates more complex data model requirement as there can be configurable modular products as the product (unit) level product definition is very generic. As described in earlier study [START_REF]Dynamic product structure configuration of superimposed part structure solutions, Niko Ville Salonen[END_REF] the "unit concept" model can be used as the representative item against the requirements, before actual delivery specific item is created.

Based on statistical study in azimuth thrusters the same component can have different certification models (documentation and process requirements) already in the generic product structure (also called as 150% BOM) definitions. The variation can increase when generic product is configured to physical product structure definition (100% BOM). This fact and the previous application and unit level definition based metadata combined define the abstraction into "conditional occurrence tree based requirements". This means that the specific component occurrence can have conditional requirement against the classification society management process.

The application domain requirements can be identified for design, some for documentation during product design, some specific for application engineering phase, some for actual manufacturing processes (inspection, sampling and testing, certification), which again all can contain documentation needs and keeping records. The requirements can be pointing to different certification types based on application or usage in application. Managing documentation specific for each application (engineer to order delivery project) for specific system/component/material creates own data model requirements.

Example of azimuth thruster's product structure and conditional requirements is shown in figures 4. and 5. In figure 4, azimuth thruster's (unit) structure is having parent application (vessel "Tug") and the azimuth thruster is containing one branch of configurable modular product structure. The parent child structure has deep sub-module structure, which are also configurable and the lowest level components have sub structure of pre-fabrication components and finally raw materials. In figure 5, azimuth thruster (unit) structure and the parent application (vessel "Tug") have extractions of metadata, shown in green arrows. The actual requirements are linked as previously defined not against the components (Shaft and raw materials), but against the occurrence of the components. The conditional rules are illustrated with IF-AND clauses. The red arrows mean positive outcome "Yes" and yellow are negative outcome "No". The black arrows are conclusion links "To Obtain", which can link between requirements, representing the sequencing, or to artefacts (documents), which will be received or created by the manufacturer.

Fig. 5. Example of conditional requirements against the shaft

The requirements (rules) themselves are also moving target for manufacturer. The rules are revised and classification societies identify the effective date for each version. This is specifically the Rules effective dates, which are defined by classification society. The rule is linked to requirement defined by the manufacturing company. One reason for separating the rule and requirement is that many rules are not precise and specific and manufacturer sometimes must take interpretation of the rule. This happens also in real cases, when different inspectors from same classification society interpret rules differently. This type situation can be recovered from, but the delivery process can be impacted by delay and loops of communication between manufacturing company and classification society.

Businesses can not react as fast even classification societies identify the rule change dates early in advance. Manufacturers main focus is bringing value to customers, which means the customer requirements drive the changes in products. The regulations must be complied, but the phasing of design changes do not match.

Marine manufacturers work according the ship building project principles and timelines. The sales phase and contracts are long processes and the commitment to customer requirements need freezing classification society requirements in certain point to be able to deliver product in time according contract. This means that item definition and the class society requirement relation has also effective date.

Linking requirements based on classification rules from top application to low level components and materials need conditional requirements as the rules are not standardized. The product and application relation and application performance characteristics make some requirements not valid or not active. The difference of not valid and not active is quite different by means of data model if the item definition is kept intact. The linking of the requirement can be done to several items and the validity of the requirement is conditional of the combination of characteristics.

In IPS landscape the active requirements and only active (delivery specific product configuration) must be transferred to resource planning system for manufacturing integration to inform supplier or internal manufacturing of the testing and inspection and certification requirements. Again avoiding multiplying actual FFF items creates specific need to manage the information until As Built configuration has been created. There can be several methods how the information of requirements can be transformed to documentation package objects and processes and how the information is transferred to ERP systems. These models are often company specific models not described in this study.

Thinking of dynamic system models

Static modelling as done in this study is not enough to develop integrated production systems (IPS) and select the optimal operations strategies. One of the key questions developing and maintaining these systems is overall IT cost against the achieved business benefit.

The classification society management process has many feedback loops and delays all influenced by different certification models or combination of models used by the business. Understanding the dynamics and simulating the options can first of all improve the decision making of certification strategies, but also what IPS functions should be developed and which order.

Defining the relations of other manufacturers is required for the dynamic business system model. From modelling the dynamics the behaviours and sensitivity analysis could indicate and help PLM and IPS developers to understand what system configurations must be in place to create solution to include flexibilities for business environment changes in short term and in long term.

Conclusions

This study defined the principles of classification society rules for a product or component manufacturer in marine business sector. Different certification processes were identified and described and single component classification certification process and, data and material flow models for 'case by case' and 'type approved' were illustrated.

The classification society rules define conditional requirements against the product definition and production process definition. These requirements are linked from the top level application (vessel) and product (unit or concept unit) through to lowest level of components and materials. The documentation requirements are from the original designs or design templates to the application engineering phase documentation for specific application. The rules vary also in the manufacturing phase, requiring different traceability levels for item to various testing and inspection requirements, including documentation.

The item traceability with related documentation for specific application starts from delivery project. In configure to order and engineering to order type business, highest level structure items can be used to carry documentation for the child items, however this is not optimal solution for learning and lean organization. Adding folder type objects or manufacturer's internal serialized objects having traceability to enabling addition of documentation against the FFF items improves the information capture and use or re-use of existing data improves. Without question various system configurations can be developed to facilitate solutions for the IPS applications to manage classification society data, data flow and processes as explained above. As the classification societies are not working in standard models (requirements nor financial operations) manufacturers must base their PLM and ERP strategies on their own product portfolio and positioning in the market sector creating flexible solutions. Unfortunately this creates more complex unique technical solutions for each manufacturer. This influences selection what operational strategies and system development strategies should be taken to simplify and optimise the operations to improve internal processes and reduce overall cost of classification society management.

Discussion and further work

This study has recognized several improvements what IACS could focus on. Standardizing the rules of classification societies and including rules for standardizing financial management, especially invoicing of the classification certification process. It is understandable that this type of improvements require long time and involvement of international standards like ISO, major insurance companies and entire shipping community, including ship owners, ship operators, shipyards and the logistical chain to raw material producers. Some of topics have been raised already in the European Union organisations.

This study brought up need for studying the financial invoicing and costing models of the classification society certification process based on the fact that the cost of classification society management is business critical parameter. This study has also been completed, but official papers or articles have not been published. More important for manufacturers is to model, analyse and understand the system behaviours and ways to control and optimise the overall performance of the company. The types of dynamics, which have been presented in this study, are also being modelled and later simulated with tools like Vensim [1]. This study is still ongoing.

Fig. 4 .

 4 Fig. 4. Example of Azimuth Thruster product structure, installed in a harbour tug


Iris De Fontaines
email: iris.de-fontaines@eurocopter.com

Didier Lefeuve
email: didier.lefeuve@eurocopter.com

Guy Prudhomme
email: guy.prudhomme@g-scop.inpg.fr

Michel Tollenaere
email: michel.tollenaere@inpg.fr

Improving digital engineering tools in complex product development by means of an adequate monitoring of research projects

Keywords: technology transfer, PLM process improvement, research steering, maturity, TRL, scenarios, proof of usage, BPMN

Complex products development relies on established and tested processes that embed software applications in collaborative PLM systems. Many efforts are performed by companies to improve their development process by means of research projects. However the transfer of research results into industrial processes implies a high level of risk. The maturity assessment and the proof of usage are two criteria that help decreasing the risky transition. Technology Readiness Level (TRL) methodology and usage scenarios are tools which provide evidence associated to those two criteria. In this paper, a methodology is proposed to guide stakeholders in the development of usage scenario in the frame of TRL methodology. Thanks to the proposed methodology, at the end of the research project, the proof of usage and the maturity of engineering technology products are validated and could support their industrialization.

Introduction

PLM provides enhanced tools and methods to perform design and engineering in industry or service activities. Thus PLM is focused on engineering data management, CAD data handling, engineering document management, different natures of bill of materials; it supports the main engineering processes, like authoring, data creation, engineering changes, assessment and approvals between different departments or companies. It is expected from PLM systems to control access rights to the data as read-only, RW, print, via roles of actors within an organization or in an extended enterprise. In the recent decades, improvements in engineering methods have been mainly brought by means of massive introduction of digital engineering [START_REF] Terzi | Product lifecycle management -from its history to its new role[END_REF]. Thus digital engineering is an important part of R&D efforts in large-scale companies, with digital mockup, multi physics simulations, optimization, virtual reality and support to PLM processes (changes, extended enterprising, data exchange…). Aerospace industry develops very complex products, because of the multiple kinds of technology involved (materials, electronics, control…) and the accurate tools in use to assess and optimize the behavior of an aircraft [START_REF] Etienne | Specifications and development of interoperability solution dedicated to multiple expertise collaboration in a design framework[END_REF]. R&D departments from the major aerospace companies are massively involved in the improvements of both the technologies embedded in the products (airplanes, helicopters, launchers, satellites, drones) and also the methods and tools (PLM tools) in use for the development process itself. From a sustainable business perspective, both innovative R&D results are required, the first ones to deliver best in class products to the customers, while the seconds aim at reducing time to market, developing more customized products and optimizing human design resources production. This paper focuses on that latter kind of research results, namely R&D propositions for methods and tools improvements that tend to improve PLM tools seen as a support to digital engineering processes. Managing research and innovation implies managing some kinds off risks. Indeed new technologies produced by research project ought to be developed and deployed inside industrial projects. Therefore, research processes should allow studying and anticipating all related impacts and disturbance that might occur when a new technology is inserted in industrial projects. The technology insertion relies on a multidisciplinary decision that implies discussions, contradictions and arguments. Actors of these multidisciplinary teams are invited to decide on a go/no-go way based on the maturity of the new technologies. But how could a "piece of technology" be defined as mature? How could the research process be steered in order to answer maturity requirements'? In the field of product technology (aircraft system and components), the maturity is assessed thanks to the technology readiness level (TRL) methodology during R&T projects. Let's remind that this paper deals with the field of method and tools (M&T). Using TRL methodology in the field of engineering methods and tools opens the following issues: is this TRL methodology transferable for such kind of products? Methods and Tools have not only to show a high level of efficiency from a scientific and technical point of view, but they also have to be usable by stakeholders. In other words, the proof of usage of such method and tools has to be realized as soon as possible. New resources have to be proposed in order to adapt the TRL methodology to this field and to include and assess the proof of usage in research process. Which resources could been associated to the TRL methodology, and how to better anticipate the proof of usage of new technology product? Finally how to qualify those resources?

The study was realized in Eurocopter Company, the manufacturer of helicopters from EADS Company. An action research methodology was applied in order to propose answers to the research issue. As an actor of the research process but also of the industrial process, the researcher analyzed the as-is situation of the technology transfer. The analysis pointed ways of improvement, solved by the integration of scenario inside the TRL methodology. A scenario methodology was developed, and then evaluated on a case study.

The first part of the article explains the major concepts used as the TRL methodology, the proof of usage and the scenario. The second step presents a new approach for assessing M&T maturity and proof of usage. The third part validates the approach on a Eurocopter case study.

Definition and Concepts 1.Maturity of a technology product

Research projects aim, in one hand, to study new technology products and, on the other hand, to reduce risks and uncertainties associated to their future integration into industrial projects. The Technology Readiness Level (TRL) methodology, developed by the NASA [START_REF]Technology Readiness Assessment ( TRA ) Guidance[END_REF], is the tool presently in use for assessing technology product maturity. A TRL is a key milestone where the transition from each TRL requires a review to ensure that specific criteria have been considered, completed and validated. The methodology is built around nine levels of readiness [START_REF] Mankins | Technology readiness level[END_REF], rapidly described in Figure 1. From our experience, TRL 6 is a critical level. Indeed it represents the first level of applied research. However, the TRL methodology is initially developed for space technical products and our study focuses on engineering technology products (processes, tools and methods dedicated to designers and engineers). Is the NASA TRL methodology and criteria adaptable to engineering technology product? Indeed aircraft and engineering technology products transfer success do not depends on the same criteria. Engineering products need to be adopted by future users. The concept of usage needs to be integrated inside the TRL methodology.

The proof of usage

Engineering technology products are dedicated to designers and are used during aircraft development programs. We distinguish a current way of working, the AS-IS situation where technical and business issues are identified. The integration and use of new engineering technology products in a new way of working, the TO-BE situation [START_REF] Cornu | Vers un guide méthodologique pour la définition, la prise en compte des exigences et de contraintes d'interopérabilité et le déploiement de processus d'ingénierie système dans une entreprise multi-sites[END_REF], reduce and/or solve those issues. Users interact with new technology products and the success of user/technology products interactions depends on the success of technology product integration in their functional environment. Therefore requirements and functionalities of technology products have to be co-studied with final users in order to anticipate their future usage in TO-BE situation. Furthermore the success of user/technology products interactions depends on users. As [START_REF] Pascal | Construire des scénarios d'aide à la conception de solutions TIC : une approche cognitivo-structurationniste. Le cas KMP[END_REF] points out, a prescribe usage is different of a real one. The success of user/engineering technology product interactions is called the proof of usage. It is validated and verified into a TO-BE situation. The Figure 2 illustrates relationships between technology products and AS-IS/TO-BE situations.

Fig. 2. Relationships between Technology Products, AS-IS/TO-BE situations and Proof of usage

Scenarios

Scenarios are used in different scientific communities as human computer interaction (HCI), software engineering, information systems, requirement engineering and as strategic management community. All those communities have different definitions of scenarios and use them with different goals. [START_REF] Rolland | A proposal for a scenario classification framework[END_REF] and [START_REF] Jarke | Scenario Management: An Interdisciplinary Approach[END_REF] have written two complete papers about scenarios in those different communities. Furthermore, [START_REF] Jarke | Scenario Management: An Interdisciplinary Approach[END_REF] proposes a global and shared definition of a scenario: "A scenario is a description of the world, in a context and for a purpose, focusing on task interaction. It is intended as a means of communication among stakeholders, and to contain requirements engineering from one or more viewpoints"

The final aim of a scenario is to explore and anticipate a future usage of a product or system [START_REF] Pascal | Construire des scénarios d'aide à la conception de solutions TIC : une approche cognitivo-structurationniste. Le cas KMP[END_REF]. Therefore scenario is a pertinent tool for assessing the proof of usage. Description, context, task are items that define usage scenario. In the context of requirement engineering, [START_REF] Rolland | A proposal for a scenario classification framework[END_REF] proposes a classification framework based on four views: form, content, purpose and lifecycle; themselves qualified by facets and attributes. Technology products aim to improve a current situation characterized into an AS-IS scenario. The integration of new technology products is realized into a new way of working, the TO-BE scenario.

A new approach for assessing engineering tools maturity during Research projects

The aim is to assess the maturity of engineering technology products during R&T projects in order to anticipate development phases. It has been seen that the TRL methodology contributes to monitor and assess the technology products maturity but seems not sufficient in the case of engineering products. It is proposed to integrate the concept of proof of usage as new criteria of TRL methodology. The proof of usage proves the coherency and validates the user/technology products interactions. Proof of usage is validated thanks to analysis of scenarios. A new approach is proposed in order to associate proof of usage and scenario with technology readiness levels. The methodology, illustrated in Figure 3, is applied between TRL3 and TRL6. The AS-IS scenario is defined when TRL 3 is assessed and it is not modified all along the process.

-Phase 1: Analysis of usage scenarios First Step: Creation and analysis of the AS-IS scenario based on scenario framework [START_REF] Rolland | A proposal for a scenario classification framework[END_REF]: it is a diagnostic step which describes how stakeholders work and collaborate today in order to answer technical and business issues. Based on the AS-IS scenario, ways of improvement are identified Second Step: Description of TO-BE scenario based on scenario framework: it is a picture of an improved AS-IS scenario which implies the use of new technology products. New technology product answers previous ways of improvement. Users have to plan new processes, new ways of working. In particular, they do not have to be afraid of change [START_REF] Bergsjo | Implementing a service-oriented PLM architecture focusing on support for engineering change management[END_REF].

-Phase 2: Technology product requirements and prototypes First Step: Based on TO-BE scenario: actors are able to formalize technology product requirements (characteristics, architecture, performance, integration, interfaces). Second Step: Rapid prototyping of technology products: most of the time technology products are already developed thanks to research project but they have to be adapted to the previous identified requirements.

-Phase 3: Prototypes and requirements validation and TRL assessment First Step: Execution of the TO-BE scenario in the TRL associated environment: At TRL4, critical components are developed and tested with simplified data in a laboratory environment At TRL5, the whole system is developed and tested with simplified data At TRL6, the whole system is tested with real data Second step: Validation of the adequacy and coherency between the TO-BE scenario developed and the initial requirements. If technology products are not validated, iteration is realized on requirements-prototype steps. The maturity is assessed thanks to the TRL questionnaire, based on evidence provided by the TO-BE scenario. Associated to the proof of usage, a work has been done on the TRL questionnaire in order to adapt maturity criteria to engineering technology products. For confidentiality restrictions, the questionnaire and proposed criteria could not be shared.

Validation of the new approach on a Case study

An application of the new approach on engineering technology products in Eurocopter Company is described in this part.

Construction and analysis of AS-IS scenario

Two issues are treated in the scenario:

-A technical issue consisting in the thermal integration of helicopter engine into its compartment. Ventilations have to be designed on the compartment in order to ensure the cooling of the engine. -A business issue consisting in ensuring a collaborative work between involved actors. The actors work with non-interoperable tools in different firms.

The two issues were identified by users during interviews and are described in a narrative text. The case was studied in the frame of a European research project named CRESCENDO [START_REF] Crescendo | CRESCENDO EU Project[END_REF].

The AS-IS scenario describes all activities and data exchanges currently implemented for answering previous issues: the verification and validation of ventilation design of the engine compartment. The scenario was modelled collaboratively between involved actors. A business process model was built by one of the actors, progressively thanks to interviews and reviews with others actors. Because of confidentiality restriction, the business model could not been shared. A high-level process, represented in Figure 4, is rather proposed. Four actors are represented: the engine manufacturer, the CAD designer of the design office, the aerodynamic engineer and the thermal engineer. Ten main information flows leaning on activities, each of them modelled by an arrow, are identified. A narrative text, joined to the process modelling, explains the different steps.

TO-BE scenario: technology products requirements and prototypes validation

Thanks to the AS-IS scenario, ways of improvement are identified:

-new tools for tracing and storing all data and knowledge exchanged -new working method in order to facilitate the meshing step but also in order to reduce the number of model data set up and calculation -new modelling and simulation workflow Those improvements are translated into four technology products, integrated inside a TO-BE scenario, illustrated on Figure 5. Major improvements concern the calculation workflow and data management. It was proposed to realize automated coupling between aerodynamic and thermal disciplines. Table 2 summarizes the four technology products.

TP1 Collaborative calculation workflow

Iterative automate calculation workflow TP2 New tools and methods for A benchmark is realized in order to find the best model set-up and calculation tool for each thermal and aerodynamic discipline with the best interoperability TP3 Surrogate model of the engine Improvement and better precision of the engine behavior TP4 Data management Data management in order to trace and store all knowledge, parameters and data exchange all along the TO-BE process.

The TO-BE scenario illustrates all the interactions between the technology products themselves and with the firm ecosystem. The analysis of this TO-BE scenario contributes to the formalization of technology product requirements and to their development. Then developed technology products that means prototypes, are tested in the TO-BE scenario. Thanks to the execution, two aspects are verified and validated:

-the global result of TO-BE scenario and so the TO-BE scenario -the technology products characteristics and ability to answer to user's expectations

Maturity assessment in a perspective of technology transfer

Final step is to assess the maturity of technology products. A TRL review is organised and all criteria are discussed. The TRL targeted implies conditions of execution of the TO-BE scenario, which means on previous step. For a TRL4, TO-BE scenario is executed with simplified conditions (light CADs, local environment, few users). The success of TO-BE scenario validates the proof of usage. Furthermore, the TO-BE scenario illustrates technology product requirements, environment and interactions. Thus, the scenario is an appropriate tool that allows assessing the technical maturity and the proof of usage of engineering technology product.

Conclusion and Perspectives

This paper focuses on the monitoring of research results, namely R&D propositions for methods and tools improvements that tend to improve PLM tools seen as a support to digital engineering processes. The TRL methodology is used during research project for assessing technology product maturity. Proposition is done to improve this methodology in the case of engineering technology product. A new criterion is defined: the proof of usage. It translates the success of the interaction between users and technology. Associated to the proof of usage, scenarios are developed. Two typologies are defined: AS-IS and TO-BE scenarios. Scenario supports the proof of usage assessment. Scenarios are co-developed with impacted stakeholders and are modeled under Business Process Model Notation (BPMN).

Thanks to models, TRL criteria are assessed and justified: technology requirements, interfaces, performance, and applications. Furthermore stakeholders can forecast usage related technology products. However, several TO-BE scenarios could be proposed. Additional works have to be realized on this issue. How could we choose between several TO-BE scenarios? How to evaluate them? A global approach is proposed in order to monitor research project advancement from TRL3 to TRL6. The validation of TRL6 is the key for technology transfer in development phase. Current approach covers "technologic and business aspects" thanks to the maturity and proof of usage but what about "financial aspects"? Does the proof of usage justify the investment? In practice the multidisciplinary decision at the transition is also based on a business case. Technology products have to prove their added-value. The concept of proof of value [START_REF] Yannou | Which research in design creativity and innovation? Let us not forget the reality of companies[END_REF] has to be defined and integrated in the methodology proposed in part 2.

Fig. 1 .

 1 Fig. 1. TRL scale

Fig. 3 .

 3 Fig. 3. Description of the two interlocked processes: TRL linear process and cycle usage scenario process

Fig. 4 .

 4 Fig. 4. Business model of the AS-IS scenario

Fig. 5 .

 5 Fig. 5. Business model of the TO-BE scenario

Table 2 .

 2 Technology products to develop in the TO-BE process of the usage scenario

	TP	Technology product	Action solved


Vincent Cheutet
email: vincent.cheutet@supmeca.fr

Patrice Leclaire

Tony Da

Silva Botelho

Geneviève Inglebert

Capitalizing Data, Information and Knowledge on Mechanical Experiments through Ontologies

Keywords: Ontology, experimental data and information, knowledge management

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

Introduction

In the current context of digitalization of the product design process and the reduction of physical mock-up usage, having knowledge on properties and behaviors of material components and systems is of prior interest for companies. Even if material science is a well-established one with a large community, material innovation and new usages imply an important turn-over of knowledge and so specific needs in competency and knowledge capitalization. Moreover, the design process is faster if accurate and reliable materials data are made quickly available. Paper reports on such material data and experiments, although tidy and available, are not so efficient if compared with modern data storage techniques, in particular because the data classification is not standardized from one report to the other and these data tend to be considered as "dead" because it is difficult to reuse raw data for new analyses.

If management of digital simulation data and knowledge has been largely explored [START_REF] Kibamba | PLM -digital engineering and numerical simulation for collaborative product development[END_REF] [START_REF] Buda | PDM suitability study for CAE data management[END_REF] and standardized (STEP AP 209 for instance), experimental data did not create the same interests and only standard tools are proposed, like Granta MI1 for material information management or classical content management software tool for experimental data. To overcome this research gap, ontology is a promising approach, allowing both the capitalization of data and information and the capture of certain domain knowledge.

The paper is structured as follows. Section 2 analyzes the domain of material experiments in laboratory, and in particular what has been proposed to structure data and information in this domain. Section 3 focuses on data and information modeling, especially by ontology. Section 4 describes the proposed approaches and how the demonstrator has been tested. Section 5 discusses the results of the experimentation.

Modeling a mechanical experiment

An experiment can be generically defined as a campaign of tests realized on several machines by different operators and with different experimental protocols, in order to validate a certain objective and deliver a set of deliverables.

Several types of mechanical experiments exist, like tensile, torsional or flexural testing, metal fatigue, creep etc. [START_REF] Lemaitre | Using ontology for design information and knowledge management: a critical review[END_REF]. To illustrate our approach, we selected the field of tribology, involving all contact, friction, wear and lubrication phenomena for its multi-physic, multi-domain characteristics, and complexity of situations and experimental data (Fig. 1). This choice is motivated by our laboratory, which is dedicated to engineering of complex systems with teams working on nearly all the fields involved in design and production of complex systems. More than fifty years of parallel development of experimental apparatus and models have enlightened the need to structure experimental data and basic lines to do it. In this context and due to the accumulated experience in the considered laboratory [START_REF] Pieuchot | Méthodologie et classement des essais de frottement et de leurs résultats[END_REF], [START_REF] Gras | Frottement à haute température du titane et de l'alliage TA6V[END_REF][START_REF] Lemaire-Caron | Coatings for Ti6Al4V in cryogenic space engine applications[END_REF], several aspects have to be detailed.

First of all, tribology implies a set of operational variables: local geometry of the contact, external loading, kinematics of the contact, surfaces roughness and environment (including lubrication). On each of our test machines, some of them have been settled, the others varying in a more or less wide range. In this field, experimental scattering is a main feature observed which guided us toward some statistic models (fatigue or roughness influenced evolutions).

Ontology for

In order to model DIK (Data, Information and Knowledge) rently recognised to be a powerful instrument. formal specification of a shared conceptualization of a domain Born from artificial intelligence community, web to model knowledge objects of a certain domain structure of semantic network plus an inference engine. find them in the design community, when databases are too restricted to model linked information, especially in the "PLM 2.0" perspective. Ontologies are used to capture information, to assist on derstanding, dais of communication and knowledge exchanges between different collaborators of a product development process & Kiritsis, 2011).

After a large increase of works in this domain the last years, propose a state-of-art in this domain ( each proving a large diversity of ontology usage in design, like knowledge ma agement systems specialized for a particular point of view interoperability of information systems Moreover, ontology development is known to be a dynamic process and a lite ature exists to ensure a consistent ontology evolution disc under thermo-regulated lubrication test machine with some examples of r Design of each of the test machines was guided by the contact mode and range , kinematics and environment encountered in the industrial applications tained our interest; according to the natural scattering of results, the best knowledge of what happens during the test is a mandatory need:

single contact, with a precise measurement of load, displacements possibly temperatures and accelerations.

Ontology for Data, Information and Knowledge modeling DIK (Data, Information and Knowledge), ontologies are cu rently recognised to be a powerful instrument. An ontology can be defined as a formal specification of a shared conceptualization of a domain [START_REF] Gruber | A translation approach to portable ontology specification[END_REF] Born from artificial intelligence community, ontologies are used in the semantic web to model knowledge objects of a certain domain, by associating to them a structure of semantic network plus an inference engine. Currently, it is possible design community, when databases are too restricted to model information, especially in the "PLM 2.0" perspective. Ontologies are used to capture information, to assist on-line collaboration by proposing a common u dais of communication and knowledge exchanges between different collaborators of a product development process [START_REF] Giménez | PRoduct ONTOlogy: Defining productrelated concepts for logistics planning activities[END_REF], ( MatsokisAfter a large increase of works in this domain the last years, several art in this domain (Liu & Lim, 2010), (Fortineau et al. large diversity of ontology usage in design, like knowledge ma agement systems specialized for a particular point of view [START_REF] Xie | Ontology as a mechanism for application integration and knowledge sharing in collaborative design: a review[END_REF] interoperability of information systems [START_REF] Ishak | Integration of semantic interoperability in a distributed architecture for multi-site planning[END_REF].

Moreover, ontology development is known to be a dynamic process and a lite ature exists to ensure a consistent ontology evolution [START_REF] Sure | State of the art in ontology engineering methodologies[END_REF] 3 hine with some examples of re-Design of each of the test machines was guided by the contact mode and range industrial applications ing of results, having : this imdisplacements and

Information and Knowledge modeling

, ontologies are cur-An ontology can be defined as a [START_REF] Gruber | A translation approach to portable ontology specification[END_REF]. ontologies are used in the semantic , by associating to them a Currently, it is possible to design community, when databases are too restricted to model information, especially in the "PLM 2.0" perspective. Ontologies are used line collaboration by proposing a common undais of communication and knowledge exchanges between different (Matsokis several papers et al., 2011), large diversity of ontology usage in design, like knowledge man- [START_REF] Xie | Ontology as a mechanism for application integration and knowledge sharing in collaborative design: a review[END_REF] to Moreover, ontology development is known to be a dynamic process and a liter- [START_REF] Sure | State of the art in ontology engineering methodologies[END_REF]).

This property is especially interesting here, since the mechanical experiment domain is still evolving. More than the ontology by itself, the methodology to obtain such shared understanding of the domain is of prior interest for the different actors implied in the process. As a matter of fact, providing an effective methodology for creating ontological models is a crucial issue, especially since there is a lack of a general methodology for creating ontologies [START_REF] Nanda | A methodology for product family ontology development using formal concept analysis and web ontology language[END_REF]. In various domains, some methodologies for creating ontologies have been developed, like METHONTOLOGY for chemistry applications [START_REF] Fernandez-Lopez | Building a chemical ontology using METHONTOLOGY and the ontology design environment[END_REF], Toronto Virtual Enterprise (TOVE) with a scenario-based methodology [START_REF] Gruninger | Methodology for the design and evaluation of ontologies[END_REF] or the On-To-Knowledge methodology [START_REF] Pieuchot | Méthodologie et classement des essais de frottement et de leurs résultats[END_REF]. In software engineering, [START_REF] De Nicola | A software engineering approach to ontology building[END_REF] proposes the UPON methodology, as an adaptation of the Unified Software Development Process or Unified Process (UP) for ONtology building.

According to our context and knowledge, we chose the On-To-Knowledge methodology, which includes the identification of goals should be achieved by knowledge management tools and is based on an analysis of usage scenarios [START_REF] Pieuchot | Méthodologie et classement des essais de frottement et de leurs résultats[END_REF]. As a consequence, an ontology developed with such ology does not provide an exhaustive conceptualization, but ensures the consistency between the needs of the domain expert and the ontological model. The steps proposed by the methodology are:

• kick-off, where ontology requirements are captured and specified, Competency Questions (CQs) are identified, potentially reusable ontologies are studied and a first draft version of the ontology is built;

• refinement, where a mature and application-oriented ontology is produced;

• evaluation, where the requirements and competency questions are checked, and the ontology is tested in the application environment;

• and ontology maintenance.

In order to model the ontology, we use the Protégé software2 and the OWL-DL language.

DIK modeling of an experiment

The objectives of the ontology are first to model the crucial data and information related to each experimental projects and secondly to make explicit the specific knowledge of the laboratory on the experiments. A part of such knowledge is used to define the crucial data and information, but the other part allows to model specific restrictions or axioms inside the ontology.

For the kick-off phase, we integrate both experts from the domain, i.e. professors of our laboratory scientifically known for the experience in the tribology do-main, and some "naïve" people that should use such ontology, i.e. young PhD students of the tribology research group. From such phase, we define a set of CQs that lead us to the definition of the ontology in the refinement phase.

Ontology model

The ontology is decomposed in two different facets. We model the generic and common concepts of the domain in the core ontology and we add all specific instances of projects and tests in the instance ontology. The Test class is the central element of the ontology. So an experiment is a project constituted of several tests. Each test is realized on a specific context: machine, experimenter, measurement tools, post-treatment chain, that are each modeled as instances in consistency classes. It is realized on one specimen for material characterization test or two specimens for tribology test, with adequate conditions, either in terms of environment (for example: ambient temperature or cryo-test, atmosphere or under neutral gas) or in terms of load (nature and intensity of force for instance). These conditions are defined by specific values of data properties when being digitally differentiable (like the sliding speed for a tribology test) or by instances when being chosen between a list of predefined concept (like the contact type).

Specific taxonomies have also been defined for the classes Test, Material, TestMachine, MeasureTool and PostTreatment, based on the literature in the domain [START_REF] Gras | Tribologie, Principes et solutions industrielles[END_REF], [START_REF] Ashby | Materials Selection in Mechanical Design[END_REF].

Several object properties are more detailed, always with the idea of fasten and simplify the queries of the ontology:

• the relations between the two classes Project and Test are defined as inverse ones: in the CQs defined, one can ask the ontology either for a project that contains tests with specific conditions or for tests that have been performed for a specific project, without a too complex syntax,

• the relations between the classes Test and Specimen are defined as a taxonomy, with adapted semantics (fig. 3): isPerformedOn, generally linking a Test instance to a Specimen one, is specialized through functional two sub-properties, linking a TribologyTest instance to a Specimen one. Such modeling allows to define that if a test is generally performed on one or several specimens, there are exactly 2 specimens in the case of a tribology test, one considered as the large surface, the other one as the small surface.

Experiments of the model

Once the ontology created and the instances added, two types of experiments have been performed. The first one validates the consistency of the ontology, either at the class level or at the instance one. The second validation considered the match of the ontology to the CQs defined in the On-To-Knowledge process. The ontology is questioned through the DL Query widget of Protégé by using the Manchester OWL syntax3 . In the example (Fig. 5), two queries have been defined:

1. on the left, which are the projects with at least one test that has been realized on a particular machine, 2. on the right, which are the projects with at least one test that has been performed with a load greater than a specific value.

To ease the addition of instances of each tribology project without a complex training on ontology for the experimenters, a specific interface has been developed on Microsoft Excel (Fig. 6). The characteristics of the project is defined and we use the properties of the OWL language (close to XML and interpreted by a parser inside Protégé) to add, at the end of the instance OWL file, the new elements.

Discussion and conclusion

Performing physical and/or digital experiments provide a large amount of data and information that need to be organized, accessible and available for a reuse purpose. In order to capitalize such crucial data and information, and also specific knowledge of the domain, an ontology is developed. Such choice can be explained by the fact that ontologies are able to cope with domains of whose conceptualization is still moving, which is the case of experiments performed in our research laboratory. However, query answering in OWL is known to have scalability issue while the number of data increases, whereas relational databases cope well with it. Thus, as a perspective, a relational database should be created, using the work of (Kupfer et al., 2006), in order to make evolve in parallel the ontological model and the implemented corresponding relational database.

Fig. 1 .

 1 Fig. 1. Pin-on-disc under thermo sults.

  Fig. 2 presents a partial model of the crucial data and information generated and used during an experiment, with the main classes and object properties between classes. In this figure, the plain arrows represent the isA property with the adequate direction (i.e. a tribologyTest is a certain type of Test) whereas the dot arrows represent the other type of semantic object properties (e.g. a Test isRealisedOn a TestMachine).

Fig. 2 .

 2 Fig. 2. Core ontology model of the experiment, with main classes and object properties represented.

Fig. 3 .

 3 Fig. 3. Taxonomy of object property isPerformedOn Fig.4 illustrates an example of Test instance with its connection either with core instances (like the name of the considered TestMachine instance LowSpeedAlternativeTribometer) and specific instances (like the Specimen instance EADS42.11GHL_Disk1).

Fig. 4 .

 4 Fig. 4. Example of instance insertion inside the ontology

Fig. 5 .

 5 Fig. 5. Queries of the ontology

Fig. 6 .

 6 Fig. 6. Excel interface for the experimenter: on the left the project definition interface, on the right the test definition interface The proposed ontological model is presented in terms of generic core model and domain specific taxonomies and tested on real instances of data from tribology and material characterization tests domains. Using the Protégé software allows us to validate this ontology in terms of both model consistency and expert expectation consistency.However, query answering in OWL is known to have scalability issue while the number of data increases, whereas relational databases cope well with it. Thus, as a perspective, a relational database should be created, using the work of(Kupfer et al., 2006), in order to make evolve in parallel the ontological model and the implemented corresponding relational database.

http://www.grantadesign.com/products/mi/

Version 4.1, available at http://protege.stanford.edu/

http://www.co-ode.org/resources/reference/manchester_syntax/


Vincent Cheutet
email: vincent.cheutet@supmeca.fr

Marc Zolghadri

Florent Couffin

Patrice Leclaire

Roberta Costa Affonso

Caroline Bourcier

Challenges in Knowledge Management for Structuring Systems

Keywords: structuring systems, knowledge management, traceability, heritage

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

Introduction

In recent years, companies showed a growing interest in Data, Information and Knowledge Management (DIKM) to ensure their competitiveness. [START_REF] Tsuchiya | Improving Knowledge Creation Ability through Organizational Learning[END_REF] introduces a distinction between datum, information and knowledge: "Although terms "datum", "information" and "knowledge" are often used interchangeably, there exists a clear distinction among them. When datum is sensegiven through interpretative framework, it becomes information, and when information is sense-read through interpretative framework, it becomes knowledge". In companies and research literature, DIKM is classically separated in two main domains: on one hand, data and information management realised by information system, and on the other, knowledge management.

Various papers have contributed to improve comprehension of the specific characteristics of knowledge [START_REF] Bernard | Ontology-based information extraction and integration from heterogeneous data sources[END_REF]. The concept of Knowledge Capitalization appeared since 1990 in an objective of preserving and enhancing the know-how acquired in an organization. It can be described by the model proposed by [START_REF] Grundstein | Three postulates that change knowledge management paradigm[END_REF], composed of five facets (Fig. 1): locate the knowledge, preserve the knowledge, enhance the knowledge, actualize the knowledge, and manage the interactions between the 4 preceding facets. [START_REF] Grundstein | Three postulates that change knowledge management paradigm[END_REF] Knowledge Management (KM) is defined as the management of activities and processes aiming at increasing the creation and usage of knowledge inside an organisation. The valorisation of knowledge satisfies an economic issue at stake for both society (UNESCO, 2005) as well as companies. As a consequence, a large literature exists on different domains. Nevertheless, most of KM works have been developed for companies specialised in design, production and control of industrial products or complex systems. Structuring Systems [START_REF] Zolghadri | Structuring Systems[END_REF], like water systems or transport networks, are systems that currently require a new vision of knowledge management suited to their characteristics.

The article is constructed as follow. After a brief state-of-art in Section 2 on main research contributions in KM, Section 3 defines and characterizes Structuring Systems. Based on these two analyses, Section 4 enlightens the main challenges in KM for Structuring Systems.

Knowledge Management state-of-the-art

To satisfy the issues at stake in the valorisation of knowledge, there are two main approach strategies: approaches focussing on the reification of knowledge and those focussing on individuals as holders of knowledge. [START_REF] Mcmahon | Knowledge management in engineering design: personalization and codification[END_REF] summarises the various terms relative to these approaches as: "commodity view", "codification" and "object view" for the first and "community view", "personalisation" and "process view" for the second.

Personalisation approaches cover the various knowledge transformation mechanisms as applied within an individual or between individuals when they are freely expressed and lead to solutions oriented towards practices communities [START_REF] Amin | Knowing in action: Beyond communities of practice[END_REF] as well as CSCW-type (Computer-Supported Collaborative Work) tools [START_REF] Lewkowicz | Une nouvelle forme de gestion des connaissances basée sur la structuration des intéractions collectives[END_REF].

Codification approaches cover the elicitation of knowledge in a controllable form beyond the actual individual and are, for the most part, based on information and communication technology [START_REF] Chen | Knowledge management fit and its implications for business performance: A profile deviation analysis[END_REF]. This explicit knowledge desynchronised from the interpretative framework of individuals then takes on a dual information/knowledge status. The simple documents, codified in line with the interpretative framework of the individuals who will read them, will be a source of knowledge for them similar to that of the people who wrote these documents. In this case, it becomes possible to consider these documents as knowledge. Otherwise, it will be information source of knowledge. Moreover, the information embedded in expert systems constitutes the intrinsic knowledge of these systems inasmuch as they are able to use it to reason, via their own interpretative patterns.

In his analysis of the literature produced between 1995 and 2002 on the technology and applications covered by knowledge management, [START_REF] Liao | Knowledge management technologies and applications-literature review from 1995 to 2002[END_REF] identified seven technical areas, which [START_REF] Louis-Sidney | A conceptual model for the implementation of IKOES in automotive industry[END_REF] proposes to combine as follows:

• framework(1) and modelling (2),

• artificial intelligence (KBS(3) and expert systems (4)),

• databases (5), data mining(6) and information and communication technology (ICT) (7) (e.g. the Internet, Extranets and wireless web..).

The technical fields covering the tools made directly available to product designers to carry out their redesign activities, supporting the codified knowledge, are those of artificial intelligence for a very formal approach, and databases, data mining and ICT where less formal codification approaches are used. [START_REF] Chandrasegaran | The evolution, challenges, and future of knowledge representation in product design systems[END_REF] reviews current research works in Knowledge representation and capture in product design and concludes by this sentence: "Although much progress has been made as outlined in the current paper, we are yet to see wide spread use of knowledge-aided systems in the industry". [START_REF] Verhagen | A critical review of Knowledge-Based Engineering: An identification of research challenges[END_REF] reviews current research works in Knowledge-Based Engineering, and points out in particular the needs in improving methodologies to support KBE development project, and in developing knowledge traceability.

Moreover none of the research contributions elicited in these two articles tackles the specific context of Structuring Systems.

Structuring Systems

In this paper, Structuring Systems are defined as systems, designed, installed, used and maintained within its operational environment for an extremely long duration, answering to the fundamental needs of the society [START_REF] Zolghadri | Structuring Systems[END_REF].

As a special type of systems, a Structuring System shares with general systems some fundamental properties such as:

• it is composed of subsystems, • these subsystems are interconnected,

• they have dependencies with their environment within which they have various exchanges. This environment is composed not only of other structuring systems but other kind of systems. Moreover, compared with other types of systems, the Structuring Systems have a very long utilization duration, disproportionately higher than the other phases. To take concrete examples of these systems, we can name the water supply systems, energy networks (electricity), transport networks (road, rail, inland waterways), the sites of highly hazardous waste and / or toxic (nuclear, chemical, etc.).

Let us now qualify these services thanks to three criteria: (1) Number of users, (2) Usage frequency, and (3) Usage duration. A product or system provides its services to either one individual customer or a more or less large group of customers. The frequency of usage and also the duration of the service usage by customers could vary from one kind of service to another. These three criteria allow to structure the space of the services offered by a product or a system (Fig. 2).

St r uct uring syst ems

One generation

According to this usage space, we suggest a very first sub-space where the structuring systems are gathered and a very first definition of such systems is the following: "A structuring system is as a complex system which offers its services for a very long period of time covering more than one generation of human being. A structuring system is a heritage of its users".

Other dimensions of the structuring systems' characterisation reveal some properties that allow to understand them in a better way:

• these systems are made of a large number of inter-connected sub-systems forming a complex network, • mainly they correspond to the public utility organizations, and their highestlevel decision-makers are the public authorities that are accountable of their decisions to citizens,

• they are firmly connected to other Structuring Systems but use a myriad of products (computers, cars, etc.),

• their operation phase duration is much longer than any other phase of their lifecycle,

• they are in perpetual evolution and one can hardly define their end-of-life, • they are continuously partially re-designed and refurbished, and continuously maintained.

We can qualify these systems as structuring because they have such deep influences on the society, economy and their eco-systems that they become the main drivers of their evolution (Berion et al., 2007). They play a crucial role in the organisation of actors and their relationships. This is to say that structuring systems structure themselves, eco-systems in which they are implemented but also other systems with which they are connected. The structuring systems express, control and drive the "heavy trends" of the eco-system. These systems are the concretisation of the main political and societal inspiration of a country that goes much further than other kind of design decisions.

From the previous definition, Structuring Systems have several principles that are typical of such systems:

• continuous answer to evolving needs: since consumers' needs evolve not only according to the general evolution of science and technologies but also thanks to the evolution of their own awareness (see [START_REF] Tillman | Stakeholder analysis in water supply systems[END_REF] for the water needs evolution for instance), Structuring Systems have the obligation of service continuity and they are so reconfigured or changed partially to cope with the evolving needs,

• incipience-germination-coalescence: the existing Structuring Systems have been and are still obtained thanks to this iterative threefold process (Fig. 3),

• functional, structural and technological continuity: due to non service break and long-life principles, these systems are inherited and partial evolution of such systems have to ensure continuity with their history, at the three levels,

• durable impacts on and from the environment: some impacts can be tangible in the short term (population movement after the construction of a new bridge) while others may be observed slowly, e.g. the change of the industrial landscape after the construction of transportation infrastructure (Berion et al., 2007). Structuring Systems cover durable needs of users. In this case, the local and national public authorities are the main decision-makers and strategy definers. Nevertheless, private actors are often involved in almost all of the lifecycle's phases. Public and private financing organisations are also those partners that allow a structuring system to be launched, used and maintained. We can model the connections among all these actors by the model represented in Fig. 4.

IGC process

Incipience IGC process time KM approaches have been partially deployed in several Structuring Systems, specifically at each system. The major contributions are related to knowledgebased engineering, with the development of knowledge-based systems to support decision processes associated to these structuring systems, potentially by simulating human expertise during the problem solving process, either for the water domain [START_REF] Wukovits | A knowledge based system to support the process selection during waste water treatment[END_REF], [START_REF] Chau | An ontology-based knowledge management system for flow and water quality modelling[END_REF], [START_REF] Garrido-Baserba | Implementation of a knowledge-based methodology in a decision support system for the design of suitable wastewater treatment process flow diagrams[END_REF], or the urban planning one [START_REF] Rubenstein-Montano | A survey of knowledge-based information systems for urban planning: moving towards knowledge management[END_REF]. In particular, [START_REF] Davis | Agent-based decision-support framework for water supply infrastructure rehabilitation and development[END_REF] details a specification that identifies the types of data, knowledge, and internal and external factors likely to be of relevance in a full decision-support tool (Fig. 5), proving the diversity of partners implied in the decision process and the complexity of knowledge management required to support such process. [START_REF] Davis | Agent-based decision-support framework for water supply infrastructure rehabilitation and development[END_REF].

Challenges in KM for Structuring Systems

The previous sections have enlightened two characteristics of Structuring Systems: they are continuously evolving, and innovation is an important aspect. These two dimensions are deeply connected to the knowledge existing on them.

Nevertheless, several issues attached to Structuring Systems make KM more complex and current approaches in this domain are not suited. If the model in five facets can still be used, each facet should be re-imagined in the context of Structuring Systems.

Locate knowledge for Structuring Systems

Structuring Systems, due to their nature, are inherited from a long history, and their architecture is so the result of past decisions that may be lost at that time. [START_REF] Kujinga | An analysis of stakeholder knowledge about water governance transformation in Zimbabwe[END_REF] illustrates on the example of water governance transformation in Zimbabwe how the knowledge diffusion process is as non-easy and non-intuitive as expected. As a consequence, locate knowledge generated and used during this history is a complex task, with two main dimensions.

The first dimension is related to the large scale of actors that may contribute and/or interact with structuring systems. In this case, specific knowledge capture approaches are needed, for instance by analyzing either knowledge co-production between different partners [START_REF] Hordijk | The role of research and knowledge generation in collective action and urban governance: How can researchers act as catalysts?[END_REF], [START_REF] Edelenbos | Co-producing knowledge: joint knowledge production between experts, bureaucrats and stakeholders in Dutch water management projects[END_REF], or cognitive biases from human expertise in the domain [START_REF] Scholten | Combining expert knowledge and local data for improved service life modeling of water supply networks[END_REF], (Taylor and de Loë, 2012).

The second dimension is more associated to time scale and especially the inheritance of such systems. In this case, knowledge may have disappeared and locate such knowledge is more associated to the archaeology discipline [START_REF] Bernard | Ancient Scientific Sources and Teaching Contexts: Problems and Perspectives[END_REF]. To help this archaeology task, even if a methodology to support such process is still required, several approaches and tools may be of prior interest:

• extraction of information and knowledge from ancient texts, like the approaches proposed by [START_REF] Gomez | Semantic interpretation and knowledge extraction[END_REF] or by [START_REF] Bernard | Ontology-based information extraction and integration from heterogeneous data sources[END_REF],

• Reverse Engineering, where the objective is not only to reconstruct a complete model of a piece, but also to capture the initial design intent [START_REF] Huang | The pre-processing of data points for curve fitting in reverse engineering[END_REF], [START_REF] Durupt | Knowledge Based Reverse Engineering-An Approach for Reverse Engineering of a Mechanical Part[END_REF] and reconstruct knowledge and competencies implemented at the origin.

Preserve knowledge for Structuring Systems

Since their usage time is far from being finished, to preserve such knowledge requires specific preservation techniques, called Long Term Digital Preservation (NLA, 2003), with the mean of keeping digital information so that the same information can be used at some point in the future in spite of obsolescence of everything involved: hardware, software, processes, format, people, etc. Such LTDP approach has contributed to the definition of the OAIS (Open Archival Information System) Standard (ISO 14721:2012).

In the domain of product development (and especially aeronautics), several approaches have been proposed for digital preservation of data and information attached, like the LOTAR project [START_REF] Lotar | LOng Term Archiving and Retrieval[END_REF].

Nevertheless, the main interest of such projects is until now to preserve only data or information attached to the products, like digital geometric data [START_REF] Regli | On the long-term retention of geometry-centric digital engineering artifacts[END_REF]. In our case, preserving technical and organisational knowledge, especially the one attached to any decision process that may be crucial in 150 years for instance, needs further research.

Enhance and actualise knowledge for Structuring Systems

As previously said, Structuring Systems are characterized by a large diversity of stakeholders that are contributing and/or interacting all over the usage time of such systems. Decisions and so knowledge are distributed in organisations that can be considered as short-lived ones compared to the service non-end time of Structuring Systems.

A change of paradigm is so needed for Knowledge Management and the facets "Enhance" and "Actualise" in particular, to attached knowledge not to the organisation that creates knowledge but to the systems by itself.

Fig. 1 .

 1 Fig. 1. The problem of knowledge capitalization in company[START_REF] Grundstein | Three postulates that change knowledge management paradigm[END_REF]

Fig. 2 .

 2 Fig. 2. The usage space of a product or a system

Fig. 3 .

 3 Fig. 3. Iterative process for Structuring Systems: incipience-germination-coalescence

Fig. 4 .

 4 Fig. 4. Influences among stakeholders and a Structuring System

Fig. 5 .

 5 Fig. 5. Influences to be captured in a complete decision-support tool[START_REF] Davis | Agent-based decision-support framework for water supply infrastructure rehabilitation and development[END_REF].