Matthieu Bricogne
email: matthieu.bricogne@utc.fr

Nadège Troussier
email: nadege.troussier@utt.fr

Louis Rivest
email: louis.rivest@etsmtl.ca

Benoît Eynard
email: benoit.eynard@utc.fr

Agile design methods for mechatronics system integration

Keywords: Mechatronics system design, multi-domain system integration, agile design methods, design-decision-integration model, Engineering action's management system, collaboration workspaces

The multi-disciplinary nature of mechatronics product significantly increases complexity of the development process. In this paper, the benefits of agile design methods are presented for multi-disciplinary system integration. After describing a model illustrating the relation between design state, decision making and multi-domain system integration, the conventional mechatronics system design process is illustrated. The weakness of "project planned" [1] management methods and their consequences on system integration are then pointed out. Finally, a framework to provide the necessary design and decision information is proposed to make agile design methods usage possible in this context.

Introduction

Products are becoming increasingly complex, integrating technologies from several fields, such as mechanical engineering, electronic or electrical engineering and software engineering. Mechanical systems developed since the 80's have thus evolved from electro-mechanical systems with discrete electrical and mechanical parts to inte-grated electronic-mechanical systems with sensors, actuators, and digital microelectronics. These integrated systems are called mechatronics systems [START_REF] Isermann | Mechatronics design approach[END_REF].

The multi-disciplinary nature of mechatronics "not only increases the complexity of products but also makes the product development process significantly more difficult" [START_REF] Tomiyama | Complexity of Multi-Disciplinary Design[END_REF]. Engineers and designers use to be educated and to work discipline-wise. Some of them could have multidisciplinary skills but "cross-functional teams consisting of experts in several domains are mandatory to develop multi-disciplinary products" [START_REF] Tomiyama | Complexity of Multi-Disciplinary Design[END_REF]. Several collaboration issues appear in such teams. One of them is the fact that multi-disciplinary product development leads to inter-disciplinary problems and integration issues. They are generally difficult to anticipate, hard to detect and even more hard to solve [START_REF] Tomiyama | Complexity of Multi-Disciplinary Design[END_REF]. This paper aims to present some agile design methods and to propose a framework providing the design and decision information necessary for the implementation of these methods. This paper is divided in two main parts. The first one proposes a model to illustrate the relation between design state, decision making and multi-domain system integration. This illustrating model is used to point out the weakness of "project planned" [START_REF] Sommerville | Software Engineering. Addison Wesley[END_REF] project management, generally used to support mechatronics system design process. Its consequences in term of multi-disciplines system integration are then pointed out.

The second part proposes a framework to provide the necessary design and decision information to make "agile design methods" [START_REF] Matthews | Foundations of an agile design methodology[END_REF] usage possible. These agile design methods are presented as a multi-disciplines integration enabler.

Mechatronics system multi-disciplines integration

Multi-disciplinary mechatronics system design could lead to integration issues. In order to explain what is the impact of multi-disciplines integration on the product, the different levels of mechatronics system' integration are presented below. Penas et al [START_REF] Matthews | Foundations of an agile design methodology[END_REF] describe four different mechatronics system' integration levels (Fig. 1).

The first kind of integration is called "separated components". In this case, components are designed separately and are just incorporated in the same system thanks to cables. The second level of integration corresponds to the concept of "joined components". The mechanical component will be designed in order to place the electrical and/or the electronic components in juxtaposition with each other. Distances between components have been reduced. The third kind of integration is called "inserted": electronic components are spread out into the whole system. There is no real integration. Finally, the ultimate integration level is the "merged" components: electronic is integrated as close as possible to the mechanical and electrical components. Parts are gathered in a coherent and functional manner and mechanical parts can also be used as signal transmitter. The contributions of this integration are various:

─ Physical integration: spatial and weight optimizations are provided, ─ Functional integration: detection, communication, control/information processing allow the system to provide new functionalities and to be reliable.

Fig. 1.

The different integration levels in mechatronics system design [START_REF] Penas | The different complexity levels in mechatronics design process[END_REF] Multi-disciplines integration is a key objective in a mechatronics system design perspective; to point out such objective, an illustrating model is proposed in the next section. This model is used to highlight the weakness of process-planned project management, generally used to support mechatronics system design process.

Decision -Design -Integration illustrating model

Decision -Design for "single discipline" product design

During product design projects, decisions are made and design information is created. Noël et al [START_REF] Noël | The PPO design model with respect to digital enterprise technologies among product life cycle[END_REF] describe the product-process-organization model (PPO) model where both type of information (Decision and Design) are linked. For example, the project objectives, part of the "decision framework" [START_REF] Noël | The PPO design model with respect to digital enterprise technologies among product life cycle[END_REF] have a great influence on the "design framework" [START_REF] Noël | The PPO design model with respect to digital enterprise technologies among product life cycle[END_REF]. On the other hand, technical constraints have to be taken into consideration by project leaders, which are parts of decision framework.

Fig. 2 illustrates the kind of interdependence that could traditionally exist between design framework and decision framework. It is composed of two axes. On the "Decision" axis, several design reviews are considered as the main steps during the design project decision process. On the "Design" axis, the main steps are based on various product deliverables resulting from the different stages of design process proposed by Beitz et al [START_REF] Beitz | Engineering design: a systematic approach[END_REF]. The polyline illustrates the "macro" evolution of a design project and the relation that can exist between the decision and the design information. During the design reviews, the overall progress is measured. Information about the project overall progress is usually seen as limited between project reviews, due to the lack of consolidated information. This idea is represented on the graph by the dashed line between points.

Decision -Design -Integration for multidisciplinary product design: application to mechatronics system design

In the previous section, a model illustrating the relation between decision and design information during product design involving only one discipline has been presented. In this, section, this model will be enriched to take into consideration the multidisciplines integration objective in the mechatronics system design context.

Project planned mechatronics system design process.

Mechatronics system design is usually presented as a linear process [START_REF] Shetty | Mechatronics System Design[END_REF]. Integration is then proposed as a specific step, in particular when the hardware part and the software part have to be integrated. Aca et al. present Product Lifecycle Management (PLM) system key benefit as its ability to facilitate the coordination of the activities among geographically distributed team members [START_REF] Aca | Concurrent Engineering of Mechatronics Products in Virtual Enterprises: Selection and Deployment of a PLM System for the Machine Tool Industry[END_REF]. Fig. 3 illustrates how the client request is divided among the different teams (software team, electrical/electronic team and mechanical team) and how the project manager organizes the different activities. This division is often presented as a necessary method to cope with design complexity [START_REF] Aca | Concurrent Engineering of Mechatronics Products in Virtual Enterprises: Selection and Deployment of a PLM System for the Machine Tool Industry[END_REF]. Due to this division, only few people involved on the project have a general overview on the design problems faced by the different teams. The different interfaces between the different domains are defined and ratified in the early phases. To ensure a proper integration of the different modules, these interfaces have to remain stable. That is why if a design problem occurs in a specific discipline, this problem is generally treated directly by the team concerned, even if a global solution, i.e. implicating several disciplines, could be more efficient or provides a more integrated product. This way of organising the mechatronics system design process is called in this paper "project planned" process in contrast with agile design methods which will be presented later in this paper. To illustrate the lack of this process in term of product integration, the Decision -Design -Integration model will be used in the next section.

Fig. 3. Project planned mechatronics system design process [9]

Decision -Design -Integration illustrating project planned mechatronics system design process.

As described in the previous section, project planned mechatronics system design process leads to product integration weakness. Fig. 4 illustrates the lack of this process thanks to the Decision -Design -Integration model. It points out the fact that the different teams are performing their activities independently, sharing information mainly during the different design reviews. Some of these design reviews are dedicated to system integration, generating the steps on the graph. Between these design reviews, neither precise nor consolidated information about the system to design is available. This idea is represented on the plot by the dashed straight lines. The red (mechanical domain), the green (electrical/electronic domain) and the blue (software domain) dashed lines are independent. Every discipline is managing its own modules' design according to the requirements defined in the early phases of the project and is trying to respect the interfaces specified. As a result, the elevation on the graph is low, meaning that resulting integration is relatively poor.

In order to face this multi-discipline integration issue, agile design methods are proposed: in the next section, the general spirit of these methods is shortly described and some of their fundamental principles are presented as a key for multi-discipline integration. The Decision -Design -Integration model is finally used to illustrate the benefits of these methods in the mechatronics system design context.

Fig. 4. Decision -Design -Integration model illustrating project planned mechatronics system design

Agile methods for mechatronics system design.

Agile methods are well documented for software design [START_REF] Sommerville | Software Engineering. Addison Wesley[END_REF] and product manufacturing purposes [START_REF] Matthews | Foundations of an agile design methodology[END_REF]. However the relevance of these methods for concurrent design methods has not been so much studied. Matthews et al summarize agility benefits as "the ability to react rapidly to changes in the environment, whether expected or not" [START_REF] Matthews | Foundations of an agile design methodology[END_REF]. They also insist on the fact that concurrent design methods lack the ability to respond to unpredicted changes like a late customer request, a designer failure, or some other external environmental impact.

Agile design methods can be valuable for such problems, but also to support multidisciplinary system integration. With the multidisciplinary design problems that can occur, the different cross disciplines activities etc., more exchange between designers, but also a unified, up-to-date and dynamic referential to collaborate [START_REF] Bricogne | PLM perspectives in mechatronics systems design[END_REF] are required. In this section, three agile methods concepts are considered for mechatronics system design among the twelve principles of the "Agile Manifesto"1 which is at the base of all the agile software methods:

─ The first one is related to the early, frequent and continuous deliveries. At any time, all the data concerning the mechatronics system to design have to be available for design reviews. ─ The second one concerns the fact that all the requirements do not have to be frozen at the beginning of the project. Requirements can be modified or added even late in development. ─ The third one relates to the fact that managers, designers, developers have to work together daily on the project. A good overview has to be shared among project team members.

The choice made by the authors about these three concepts is mainly guided by literature reviews and by the mechatronics systems design characteristics. For example, the fact that mechatronics system design generally involves a great number of designers makes that it is necessary to cope with the need to adapt the agile methods to largescale organization [11] [12]. Geographically distributed teams, or extended enterprise characteristics also implies that some of the principles are no more applicable [13] [14].

After the brief description of the three agile methods concepts considered in this paper, the expected benefits linked to their usage will be presented in the next section.

To do this, the Decision -Design -Integration illustrating model is used.

Decision -Design -Integration illustrating agile design methods for mechatronics system design.

In order to be able to contribute to effective integration during the mechatronics system design, the experts coming from the different disciplines have to frequently share information: information about the design, information about the activities, information about the design problems, etc. Fig. 5 assumes the role of continuous information sharing for multi-disciplinary system integration. On the plot, each point corresponds to a quick review that can be performed daily by the project leaders based on the consolidated information provided to them. If inter-disciplinary problems or integration issues are detected, global solutions are provided. This ongoing project management can assist multi-discipline integration, leading to a better resulting integration. This result is illustrated on the graph by the height of the final curves' points. In summary, this graph illustrates the need for a unique repository for all the mechatronics system data. This does not mean that no specific teams have to be created, but they have to continuously share design data into the same repository. The graph also illustrates the influence of regular project leaders' decisions, based on consolidated and dynamic indicators. In the next section, a framework to provide such repository, in order to facilitate the multi-discipline integration, and such indicators, in order to dynamically manage the project, is presented. This framework is presented as the anchor to support agile methods for mechatronics system design.

Fig. 5. Decision -Design -Integration model illustrating agile methods for mechatronics system design

A framework to support agile methods for mechatronics system design

As presented in the previous sections, agile methods are based on constant project reconfigurations. These reconfigurations are human decisions, but they are based on up-to-date indicators provided by the different systems supporting mechatronics system design. In this section, two main systems are presented as a framework to support agile design methods. The first one is dedicated to engineering actions management and the second one is focused on collaboration based on data exchange. The link between these two systems is finally presented.

Engineering actions management system

Engineering action's description

During a design project, the client requests are translated into technical requirements, driving the different design activities [START_REF] Aca | Concurrent Engineering of Mechatronics Products in Virtual Enterprises: Selection and Deployment of a PLM System for the Machine Tool Industry[END_REF]. But other reasons influence and drive the design of a system. For example, design problems that occur are also generating specific demands and activities that are, depending on their severity, not formalized. These requests are generally informal and are considered as "daily work". The last type of activities influencing the design a system is the engineering change request/order or bug correction for software engineering. Although they have own singularities, these prescriptive and reactive activities can be managed the same way, and in the same decision support management system. Indeed, they are all called in this paper "Engineering Actions" (EA).

Engineering actions contain different information. First of all, the EA's creator has to describe the context of the demand, the system concerned, the expected result and eventually a description of the problem encountered. He also has to state on the severity of the demand. The severity can in fact be evaluated on a scale, for example from 1 to 4, thanks to the question "how will operate the system if this engineering action is not performed?". To customize this engineering actions management system to specific companies' needs, the EA can also be flagged by the creator, according to the flags available to him. When this definition stage is performed, the creator assigns the created EA to a specific person or to a domain leader if he does not know who will be in charge of it. The domain leader reads the description and, again, assigns the EA to a member of his team. During all this time, the EA's status is "Opened -Under analysis". When an engineer or a designer considers that he can play a role in the EA resolution, he changes the EA's status to "Opened -Under treatment". With the same principle, the designer will change the EA's status according to the job performed: "Opened -Solution found", "Opened -Solution in progress", "Opened -Test in progress". If he is the only actor concerned by the work to be performed, he will then deliver his modifications into the data management system and change the EA's status to "Closed -corrected". Otherwise, he could also assign the EA to another designer to perform other tasks on the same EA. This kind of scenario could be really helpful for multi-discipline integration purpose. For example, if a mechanical part has to be modified to thermally insulate a new electronic device, a unique EA can be created. This EA is first assigned to the mechanical designer who defines a bounding box for the electronic card before transferring the EA to the electronic designer. This one design the card and transfer back the EA to the mechanical designer, specifying during the transfer the maximum temperature to respect. Finally, the mechanical designer modifies the part accordingly and closes the EA.

As showed above, this engineering actions management system differs from Product Data Management (PDM) project management modules in particular because activities are much more dynamic. When, in PDM, an activity is assigned to a person manually or because a workflow has been triggered, an EA is created by a specific person, assigned to a designer that can decide to work on the EA or to transfer it. In this section, the EA has been described and briefly compared to traditional PDM activities management system. In the next section, the EA management system benefits for agile design methods will be presented.

Engineering action's management system to support agile design methods

Beyond the fact that EA allow to manage trans-disciplines activities, it also provides useful indicators on the project progress, the project maturity, the burden of the teams, etc. Project progress can be measured thanks to the number of EA representing the required functionalities still opened. For the project maturity, the EA representing the unsolved problems can be sumed up in order to determine whether the system is converging, e.g. the number of EA flagged "regression" decreases, or not. The burden of a team can be calculated thanks to the backlog of each team members, i.e. the opened EA affected to each team member. All these calculated indicators, based on the raw indicators coming from the EA management system, are considered as a great support to decision makings. Quick review, daily meeting, executive review, standup meetings are the different terms used in the agile methods community to speak about these meetings where new priorities are defined, problems are shared, and information about one project or about the different running projects is exchanged.

In this section, the benefits of EA management system for agile design methods usage have been pointed out. This system mainly provides indicators to support decisions makings in a multi-disciplines integration purpose. In the next section, this multidisciplines integration will still be focused thanks to simplified data exchange.

Data exchange and collaboration through workspaces

The interest of a multi-disciplinary data management system has often been underlined [START_REF] El-Khoury | A tool integration platform for multi-disciplinary development[END_REF]. But most of the authors continue to imagine a platform with a common interface addressing specific domain data management system, especially for hardware and software parts. Some other initiatives present the perspectives a full integrated platform [10] [17]. Whatever the solution, the workspace (WS) concept is a way of collaborating in a global environment. A WS is a set of Configuration Items (CI) with a specific version associated to each CI. A CI can be a document, an article depending on the domain involved and on the solution adopted. The only prerequisite on the nature of the CI is just that the CI has to be manageable in a version control system. For example, in the software engineering domain, a CI can be a source code file, a portion of this source code, an object class of this source code, etc. In the mechanical domain, a CI can be a parameter, a feature, a part, a product, an assembly or a set of these data.

The need for WS is linked to the fact that the design of a system generates a huge amount of data. In fact, engineers/designers are focused and interested by a subset of these data. WS allow them to be temporally insulated to be able to work on one or several engineering actions in a specific context. Insulation does not mean that they are not working under the control of the data management system. They are just not affected by the changes that can occur due to other engineering actions. One of the major characteristic of the WS is that they have a tree structure (Fig. 6) and a "son WS" can only be composed of CI that are parts of the "parent WS". Only workspaces located at the ends of branches are owned by the designers. The other workspaces are integration workspaces. In software engineering, in which automating testing is possible, automated or manual tests are performed in such integration workspaces.

The modifications performed by designers into their workspaces to realize an engineering action remain private until he decides to promote his modification to the parent workspace. In contrary, the fact of taking into consideration the modification performed by others from the parent workspace is called synchronization. So, the normal data exchange between two child workspaces is series of promotions followed by series synchronizations. For example, on Fig. 6 a specific version delivered in WS 1.1.1 will reach WS 1.3.2 after passing through WS 1.1, WS 1 and WS 1.3. Some other direct exchange mechanisms could also be used.

There are multiple advantages to the usage of this system in a mechatronics system design context. First, the same workspace can be composed of CI coming from different domains. For example, if a change is required on an electronic card due to a supplier change, an engineering action is created by the project leader. The electronic designer changes the layout of the device and writes a note directly in the source code to modify before transferring the engineering action to the developer. Impacts are then easier to manage. Another advantage is the fact that the same CI in different versions can exist at the same time, allowing the designers to be focused on their engineering action and to be able to delay the merging action [START_REF] Bricogne | Towards PLM for mechatronics system design using concurrent software versioning principles[END_REF].

Engineering actions and workspaces: a way to link design and decision information

In the two previous sections, engineering actions management system and collaboration workspaces have been presented. They have been respectively pointed out as decision support system and data integration enabler. In order to provide a fully integrated framework, a link has to be provided between both functionalities. This connection is described in this section.

In fact, when a designer promotes his modification to the parent workspace, it is for a specific reason, described by one or several engineering actions. This means that during the promotion, the engineering action identifier has to be provided. With this information, it is possible to track from the engineering actions management system the impacted CI and their versions. In contrary, from a CI, it is possible to track which engineering actions contribute to the evolution of the CI.

Coming back to the Decision -Design -Integration illustrating model, engineering actions can also be seen as links between decision makings and design data. By giving higher priority to specific engineering actions during short design reviews, the project managers can influence the design of the mechatronics system. By analysing engineering actions exchange and tickets closure information, they also can control the way integration problem are continuously solved by designers and developers. Fig. 7 illustrates how engineering actions can influence the curvature of the graph. On this figure, the points correspond to short design reviews, e.g. daily reviews, and engineering actions are represented thanks to labels. In this section, a framework based on engineering actions management system and collaboration workspaces has been proposed as a support to apply agile design methods in the mechatronics system design context. This framework shall provide a great number of indicators to project leaders, but also to share more information about systems data, especially in order to improve multi-disciplinary for mechatronics system design.

Conclusion

To design mechatronics systems, a unified, up-to-date and dynamic referential has to be provided to the project actors. The main role of this system, which could be a PLM system, is to federate design data and to assist multiple-disciplinary integration. But it could also be a support for new managing methods like agility design methods.

In this paper, a model to illustrate the benefits of agile design methods in term of multi-disciplinary integration has been suggested. A framework based on engineering actions management and collaborative workspaces to support decision processes has also been envisioned. This framework has been shortly described and future work will be focused on further framework description, its implementation and illustration on a case study in order to evaluate this proposition.

Fig. 2 .

 2 Fig. 2. Decision -Design model for "single discipline" product design

Fig. 6 . 1 WS

 61 Fig. 6. Workspaces organized with a tree structure

Fig. 7 .

 7 Fig. 7. Decision -Design -Integration model illustrating the tickets' role on mechatronics system integration

http://agilemanifesto.org/


Perrine De Pinel
email: p.depinel@gmail.com

Nicolas Maranzana

Frédéric Segonds

Sylvain Leroux

Vincent Frerebeau

Proposition of Ergonomic guidelines to improve usability of PLM systems interfaces

Keywords: Ergonomic, PLM, usability, user experience, agile method

Evolutions of PLM systems are mainly directed towards the integration of more lifecycles stages to offer more PLM functions and information systems. At first, PLM were developed and intended only for engineers in detailed design phases. As engineers are familiar with complex and sparse interfaces, PLM software are not really ergonomic. The emerging problem in the past few years is the lack of evolution of PLM software, decreasing significantly its efficiency and utilization. But now, PLM integrate entire lifecycle of the product, so interfaces should be readjusted so that every actor, other than engineers, can easily use it.

In this paper, we assume that simplify and dynamize PLM software interfaces, by meeting usability features and user experience, make the system more interactive and coherent. In a first time, two states of art are realized. The first is about PLM evolution and web interfaces, the second about user experience and usability. A combination between agile method and user-centred design method are applied to these states of art in order to generate PLM software prototypes. Finally, user tests will be conducted on these prototypes in an incrementally and iterative way to correct and to validate them. The final target is to propose some ergonomic guidelines in order to create a generic interface adapted to several kinds of PLM software.

Introduction PLM and challenge

In the earlier 2000s, PLM emerged as a solution to adapt industrial design to the demands of globalization. Indeed, as PLM addresses the entire lifecycle of the product, it has a cross-functional nature and deals closely with the way a company runs [START_REF] Garetti | Organisational change and knowledge management in PLM implementation[END_REF]. For Amann (2002), over the past several years, PLM has emerged as a term to describe a business approach for the creation, management and use of product-associated intellectual capital and information throughout the product lifecycle. According to [START_REF] Pernelle | Modélisation intégrée et pérennisation des connaissances dans une approche PLM, Ingénierie de la conception et cycle de vie des produits, Traité IC2 -série Productique[END_REF], with the increasing concentration of editors and the obsession of lowering information technology costs, too few companies are aware that PLM system design has to evolve to follow user's expectations. Indeed, generic PLM methods are not adapted to the actual PDM platforms configuration causing some heterogeneity issues in the system. Other difficulties found in the PLM system design phase are the complexity and the lack of flexibility in the product models. [START_REF] Pernelle | Modélisation intégrée et pérennisation des connaissances dans une approche PLM, Ingénierie de la conception et cycle de vie des produits, Traité IC2 -série Productique[END_REF]. This can be linked to the level of details of some standards (ISO 10303-1, 1994), which affects the data flowing fluidity.

These different points show the need to act on the PLM design and on its evolution through time. We intend to act along three main lines of PLM: product, processes and organization. We attempt to prove that adding innovation in PLM software design by including ergonomic and usability features can enhance user satisfaction.

Introduction of concurrent engineering and ergonomic approach

Introduction of concurrent engineering implies modifying design habits and requires changes in the project structure. This methodology involves different dimensions such as organizational, social, technical and economic [START_REF] Bossard | Origines et définition de l'ingénierie concourante[END_REF]. In this context, it is possible to think that ergonomics can take place in this process at several levels [START_REF] Fadier | L'intégration des facteurs humains à la conception[END_REF][START_REF] Sagot | Ergonomie et Conception anthropocentrée[END_REF].

The design process is complex and includes different cultures, actors and methods. Also, collaboration can be difficult and tensions may appear [START_REF] Gronier | Coopération à distance en conception de produits : analyse de l'usage d'un collecticiel[END_REF]. A good collaboration environment requires some infrastructures such as databases, processes, and applications. This leads the company towards a common model oriented in an intuitive way that can be consulted by PLM users. With this kind of process, decisions can become more affordable and more understandable. Ergonomic approach can be considered as part of resource information and so assists the development process.

According to [START_REF] Kim | XML-based concurrent and integrated ergonomic analysis in PLM[END_REF], ergonomic analyses are not well managed in PLM. Indeed, they notice that the effective management of human information, along with concurrent ergonomic analysis is very important for each cycle of the product engineering in PLM. As stated [START_REF] Segonds | Contribution to the integration of a collaborative design environment in the early stages of design[END_REF] and Maranzana et al. (2011), PLM software evolution is still developed with a lack of maturity, of consistency, of relationship between modules. According to [START_REF] Sagot | Ergonomie et Conception anthropocentrée[END_REF], integrating human factors in the design product today is an important point. Developing a multidisciplinary approach with engineering and social sciences, as ergonomics, is a huge challenge and a new way of thinking and collaborating. Nowadays, innovating in product design, it is important to meet users' needs and expectations through ergonomics. The aim of ergonomics is to understand interactions between people and systems, define constraints of the user activities and determine the list of tasks PLM users will have to manage. Analyze the users' needs is an important first part of the approach aiming at reducing the problem scope. Therefore requirements depend on use and esteem needs. In fact, changing only one demand can have a significant impact on the system. Recommendations will help to define some guidelines to redefine the systems. They are active on the visible aspect of the interface and contribute to improve the content of the dialogue between the user and the system.

Ergonomics standards

Standards are a set of rules to design and develop systems by ensuring a high level of comfort, performance, satisfaction and security when using a system. Two types exist: management process standards and standards specific to the product. The first type contains one of the most famous standards of the user-centered part design cycle, (ISO 13407, 1999). It's a guide with source information and user-centered organization principles such as: planning and management of design methods, technical aspects of human factors, usability features and general ergonomic principles. In the second type, designers can find some recommendations and the different manners of interacting when designing interfaces. For example, ISO 9241-10 (1993), the dialogue (adaptation to the task, ease of use, error tolerance…); ISO9241-13 (1998): the guidance system, etc. Usability features is an important part of the ergonomic approach and a reference in an expert evaluation of interfaces.

Human Computer Interaction and usability features

As stated by [START_REF] Juristo | Analysing the impact of usability on software design[END_REF], the field of human computer interaction is often related to the usability of software systems. The authors developed a state of art in order to provide some recommendations on how to improve software system usability. Several authors refer to such recommendations named differently: design heuristics [START_REF] Nielsen | Usability Engineering[END_REF], usability rules [START_REF] Shneiderman | Designing the User Interface: Strategies for Effective Human-Computer Interaction[END_REF], usability principles [START_REF] Preece | Human-Computer Interaction[END_REF]Constantine and Lockwood, 1999), ergonomics principles [START_REF] Scapin | Ergonomic criteria for evaluating the ergonomic quality of interactive systems[END_REF], usability patterns [START_REF] Tidwell | Designing Interfaces. Patterns for Effective Interaction Design[END_REF][START_REF] Welie | Amsterdam Collection of Patterns in User Interface Design[END_REF], etc.

According to [START_REF] Juristo | Analysing the impact of usability on software design[END_REF], software usability is a quality attribute listed in a number of classifications (ISO 9126, 2001;Boehm, 1978). [START_REF] Nielsen | Usability Engineering[END_REF] clarifies a standard definition of usability as learnability and memorability of software system, its efficiency of use, ability to avoid and manage user errors and user satisfaction. ISO 9241-11 (1998) defines usability as ''the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specific context of use''. In short, usability is also generally referred to as ''quality in use'' (ISO 14598, 1999). Many studies extol the virtues and benefits of usability [START_REF] Trenner | The Politics of Usability[END_REF]Battey, 1999;[START_REF] Donahue | Usability and the bottom line[END_REF][START_REF] Griffith | Online transactions rise after bank redesigns for usability[END_REF]Black, 2002): it improves productivity and raises team moral, reduces training and documentation costs, improves user productivity, increases e-commerce potential, etc. [START_REF] Juristo | Analysing the impact of usability on software design[END_REF]. Usability is still insufficiently considered in most software systems [START_REF] Seffah | The obstacles and myths of usability and software engineering[END_REF].

Since 1990, usability inspection is the new way to evaluate user interface. According to [START_REF] Nielsen | Usability Engineering[END_REF], there are four basic ways of evaluating it: automatically (usability measured by running interface test programs), empirically (tests the interface with real users), formally (use precise models to calculate usability) and informally (based on experience of the evaluators). This kind of inspection leads us to have a large vision on the different aspects of PLM software evaluation. Software usability is defined as an approach related to design, evaluation and use of human computer interaction, in order to optimize the compatibility between user, activity and software interfaces. Usability allows avoiding issues that could happen and tend to ensure a high performance and an ease of use. To resume, the aim is to design, correct and transform devices and software, by adapting them to human capabilities. It is important to preserve physic, mental and social aspects, preventing negative consequences during the user activities.

According to Brangier et al., (2009), scientific input of software usability can be defined in three types. Firstly, software usability defines some recommendations about style and content presented during interaction. The goal is to guide how to design, organize and specify user's activities, taking into account human factors within the technology. Establish some rules based on experiments, methods and practices whose efficiency and effectiveness are verified. Secondly, software usability tries to specify some models of human computer interaction. It defines ways how the end users should interact with the machine and tries to identify cognitive process developed by them. It elaborates a cognitive and interactive functioning model of the user linked to the machine. Thirdly, software usability takes part of the process and methods development ensuring sensorial and cognitive compatibility and user acceptance optimizing usability features. The aim of these three approaches is to reduce the distance between user and interfaces and to promote the user acceptance.

User's acceptability of the system

Technological acceptability defines how users find a way to take control of a given system. It is based on how he deals and reacts to issues linked to the new technologies.

To check compatibility between technical and psycho-physiologic features of the user can be interesting. For example, [START_REF] Shneiderman | Software Psychology: Human Factors in Computer and Information Systems[END_REF] worked on compatibility between software features with the user operating mode regarding the ease of use and usability features. According to [START_REF] Nielsen | Usability Engineering[END_REF], acceptability is decomposed in many levels (Fig. 1).

Fig 1. System acceptability model adapted from Nielsen (1993)

To design and evaluate interfaces, it can be useful to apply knowledge on cognitive, operational and social functioning. These different ergonomic rules can be adapted to PLM software. In order to apply these recommendations in this kind of interfaces, we can use an agile software development since this approach is widely used in design engineering environments. It involves and takes into consideration the user and the client so as to adapt the development process.

3 Proposition of PLM software interfaces improvement through user centered method and agile development [START_REF] Losada | A guide to agile development of interactive software with a "User Objectives"-driven methodology[END_REF] propose a guide to agile development of interactive software with a user centered driven methodology. They propose to improve the product usability by applying the maximum ergonomic recommendations and standards as possible. Even if they are different way of interaction, combining agile method with user-centered design could be a compelling approach to improve the efficiency of a PLM system. The aim is to understand the needs and tasks in order to adapt development principles by fostering individuals and interaction over process and tools and customer collaboration over contract negotiation. Agile method objective is used to develop software in an incremental and iterative way. The main advantage is its flexibility during the development. This method is oriented on code development and ensures an adapted implementation of the functionalities. It tends to improve how software and process are developed. On the other hand, user centered design method is focused on the interaction in which the user will participate and to register the user's opinion about the application. User experience identify the expectations and cognitive brakes; study the expectations and needs; analyze user perception and analyze performance (Garett, 2002). It improve productivity and efficiency of the company by saving time, simplifying actions, and adding specific features. Both methods allow matching the users' requirement and their satisfaction while using the software. [START_REF] Segonds | Contribution to the integration of a collaborative design environment in the early stages of design[END_REF], developed a generic model based on a collaborative environment by integrating an agile development method. We base our approach on the same process by proposing a new model which describe how integrate user experience at each stage of the PLM development on the agile method. (Fig. 2).We can propose the following hypothesis: Integrating User Experience and some Best Practices ergonomic during project development, facilitates the acceptance of users in the use of PLM in the company.

Experimental plan

This protocol is a proposition; our hypothesis are not tested yet. Protocols below are the process we will used to answer them.

Integration of best practices ergonomic user centred

The integration of user experience in the agile model is represented by 5 steps. In order to validate our hypothesis, we establish a user test.

User analysis

User test

According to Nielsen and Laundauer (1993), 5 users can detect 75% of usability problems on an interface (Fig 4 .). Each of the five users made two scenarios, one without ergonomic requirements and one with them. At the end, we compare the objective and subjective measures in order to check the productivity gain achieved with the ergonomic requirements. (Table 1).

Conclusion

This article proposes to integrate an ergonomic approach to improve the usability of PLM interfaces by integrating user experience through the PLM development on the agile method. The state of art demonstrates that many problems found by PLM software users as complexity or the lack of flexibility of the system could be clearly solved by including usability features. Today, PLM systems are under-utilized and too many actors of companies do not feel concerned with this kind of software. To reduce cost, improve efficiency and delays of production were the main reasons of the creation of PLM, but current software do not meet these expectations. [START_REF] Pernelle | Modélisation intégrée et pérennisation des connaissances dans une approche PLM, Ingénierie de la conception et cycle de vie des produits, Traité IC2 -série Productique[END_REF]. Our model based on the agile method integrate user experience during a project development. We suppose it is improving productivity and effectiveness by improving usability. To validate our hypothesis, we establish a user tests to validate the reliability of this model and show that involving usability features and user experience tends to promote the user acceptance on the PLM interfaces. This proposition could be beneficial to increase user's satisfaction and efficiency of the companies' production.

Fig 2 .

 2 Fig 2. PLM interface model design using a user centred method combined with agile development, adapted from Segonds and NextIS, (2011)

-

  To get acquainted with the project, to take account vision and objectives of the Product Owner -Analyze the current situation, user behavior -Define the target users and their characteristics (representative sample) -Ensure user awareness to usability -Identification requirements = Interview 2. Defining the sprint backlog -Build Personas from the characteristics of users (Grudin & al. 2002) -Write scenarios -Design a navigation scheme based on scenarios -Write detailed uses cases -Prioritize uses cases with the Product Owner (P.O) 3. Implementation -Describe the guidelines and standards for interface design -For each use case, design a Digital Mock-Up -Validate the mock-up developed, with users (Feedback) -Achieve the development of the mock-up for the iteration (developers) 4. User Validation and Test -Submit to the P.O the work during the iteration -Validate the software developed with users 5. Follow-up -Follow-up audit -Change management

Fig. 4 .

 4 Fig. 4.Graphical representation adapted from Nielsen and Laundauer (1993)

Table 1 .

 1 Tableallowingto compare a scenario before and after the integration of ergonomic requirements in order to obtain objective and subjective measures.

	Time

to complete the scenario The number of mouse clicks The number of mistakes The number of abandoned scenario Satisfaction scale 1 to 7 Before ergonomic requirements After ergonomic requirements


Benjamin Hervy
email: benjamin.hervy@irccyn.ec-nantes.fr

Florent Laroche

Alain Bernard

Jean-Louis Kerouanton

Co-working for knowledge management in cultural heritage: towards a PLM for museum

Keywords: Knowledge management, Cultural Heritage, PLM, Museum, DHRM

Dealing with historical knowledge implies specific approaches. Then, modeling it and the different know-hows involved is a complex task. Indeed, patrimonial objects are historical witnesses whose life cycle is hard to handle. In this paper, we discuss possibilities of managing such heterogeneous content through a PLM system dedicated to historical knowledge and museum. Based on previous research in the field of ancient advanced archaeology, we demonstrate our process through an industrial research and development project with a history museum.

Introduction

Museum is filled with knowledge treasures and specific, specialised know-how. Many professional domains are involved. Either they are heterogeneous, they work together for a common goal: preserve and promote cultural heritage. In this paper, we propose a dualistic approach in order to capitalise available knowledge related to patrimonial objects. Thanks to systemic analysis methods and tools, we try to identify the lacks of such approaches when dealing with heritage objects as a product knowledge management. In addition, we discuss the importance of human-centered approach for historical comprehension of non-explicit phenomena (political influences, historical sources contexts). To demonstrate our methodology, we present a research and development project done thanks to the collaboration between Nantes history museum, a research center in history of sciences and techniques (Centre François Viète) and IRCCyN laboratory. This project tends to promote an historical wooden model of Nantes harbour in 1900 with historical knowledge and virtual engineering tools.

First, we discuss on usability of engineering tools and methods for heritage knowledge capitalisation. Enterprise modeling such as PLM operating system provides efficient ways to capture information for co-working (FBS, ISO standards). But we identify a significant lack about long-term evolution of objects: patrimonial objects are concerned by this issue. As we cannot imagine what promoting system will be used in the future, we have to identify and to link significant data and knowledge provided by experts (historians, museum curators, etc.). This will allow museum to challenge the huge amount of knowledge they host for a better collection management. It will also improve cultural promotion and innovation thanks to digital projects. Indeed, if we look at the number of such projects all over the world, it is significantly increasing.

Then we demonstrate our scientific proposition with the results of a 5-years research and development project. It is led by Nantes history museum (France) and concerns two of their collection objects: wooden models of two parts of Nantes city in early 1900's. Many professional domains were involved such as historians, engineers (computers, mechanics, automatics), and museum professionals. They worked together in order to gather information, link it and design the final museography application. The result leads into a virtual augmented reality system based on the real object. The system is web-connected and allows the knowledge database to be enriched both by experts and general public. The content includes geographical, semantic information and historical links between points of interest. We capitalise both geographical areas (buildings, streets), for which we can store evolution during time and heterogeneous semantic information like people, historical events and so on.

Finally we discuss on challenges that can be handle by our method, especially the way that it can be extended to the whole museum through all the objects' collection. The way the system was designed allows us to connect other museum objects together, through historical links, and also to add know-how knowledge from museum activities. Thus, we imagine designing a PLM for museum that would store the whole processes of object acquisition, protection and promotion.

Industrial knowledge management for cultural heritage

Models and methods for knowledge management in industry offer many advantages but present lacks when dealing with historical information. MKSM/MASK, REX, KOD, KALAM are mainly related to industrial knowledge (nuclear, factory), but give significant clues for effective knowledge management. This would give advices when taking into account communities of practice. In addition, product-process oriented models, implemented for product design management [START_REF] Labrousse | FBS-PPRE, an enterprise knowledge lifecycle model[END_REF] also give interesting trails as a systemic and functional approach. As far as digital documents are concerned, we also have to explore such approach for effective document and archive management [START_REF] Keraron | Annotations to improve the using and the updating of digital technical publications[END_REF]. Yet, we need to confront these approaches to historical and cultural heritage needs.

Singularities in cultural heritage come from temporal characteristics (long-time span analysis) and retro-analysis. Usually, knowledge management methods focus on existing knowledge in enterprise modeling.

Yet, a tool for historical knowledge management can take benefit from industrial knowledge management methods. Simply because industrials methods are in most cases reproducible, these should be considered useful. Some tools are already used in the field of history sciences such as archaeology, but they are related to specific knowledge (e.g. GIS). What we aim to do is to gather historical knowledge from different experts' fields as it would be in enterprise models.

New ways of knowledge management yet appear to place humans as a critical factor when dealing with knowledge management [START_REF] Zobrist | La belle histoire de Favi : l'entreprise qui croit que l'homme est bon[END_REF]. In cultural industry, such approach is more common, and lead to interesting results [START_REF] Laroche | Le paradigme de l'ingénieur dans un imaginaire ubiquitaire[END_REF]. We then aim to provide a methodology, inspired by historians' research approach, very close to these methods. That means we have to deal with heterogeneous information and develop an approach mainly based on people's knowledge.

The Digital Heritage Reference Model [START_REF] Laroche | Advanced Industrial Archaeology: A new reverseengineering process for contextualizing and digitizing ancient technical objects[END_REF] (DHRM: methodology based on Product-Process approach but dedicated to historical knowledge) has been designed to answer this problematic. The main idea is to combine different "schemes", capitalising heterogeneous knowledge, allowing us to understand and to model one idea under different points of view (internal, external, technical, socio-economic, political aspects).

According to this approach, we now explore ways to implement and to validate DHRM on practical use cases. This brings new problematic, especially about knowledge extraction modes and historical information visualisation [START_REF] Hervy | Advanced virtual reality visualisation system based on a meta-model dedicated to historical knowledge[END_REF].

Industrial use-case of an interactive knowledge-based system: augmented historical mock-up

Context of the project

In 2008, Nantes history museum started a research and development project about a wooden model, exposed inside the museum. This mock-up, designed in 1899 for the "Exposition Universelle of 1900" (world's fair held in Paris) by Paul Duchesne, represents Nantes harbour in the very end of nineteenth century. It is a great historical object, due to its size -9.20 meters long and 1.85 meters wide, but also due to the geographical area it represents (approximately 7 square kilometers). As for now, museum visitors cannot interact with the mock-up, nor get any historical information about it (except those provided by the museum label).

The goal of the project is to design an interactive system, connected to a database in order to provide information to visitors. Database would host both experts' contributions and general public material: photographs, postcards, etc.

An historical information system

We then designed an information system, according to what we discuss in section 2. This would allow us to manage heterogeneous historical contents, and other materials coming from the process of "advanced industrial archaeology" described in [START_REF] Laroche | Advanced Industrial Archaeology: A new reverseengineering process for contextualizing and digitizing ancient technical objects[END_REF].

Fig. 1. Glimpse of the historical data structure

A glimpse of the data structure is given on Fig. 1. The information system can store both semantic and geometric data. We can therefore store the whole structure of an object (for example a factory) from a macroscopic to a microscopic point of view (Fig. 2). The system also provides links, or relationships that represent historians' knowledge. Visualisation of such knowledge is somehow a complex task, both from ergonomics and computer programming points of view. At this point of the paper, it is important to notice that many skills are involved when dealing with cultural heritage capitalisation.

Fig. 2. Example of multi-dimensional levels of old industrial objects

Based on this concept-knowledge space, we now want to identify historians' knowledge-mining modes. That means identifying ways the system will interact with historians whether they want to consult or to fill information.

Knowledge visualisation

The proposed system (Fig. 3) is composed of a knowledge database, the historical object, and some visualisation devices: touch-screens and video-projectors. In fact, due to the process we applied in the project, we can now imagine any other interactive application: virtual worlds, augmented reality, web application, or any other future fruit of imagination… The system is scalable, and free from technology evolution, contrary to most of museum promoting systems. Scalability is provided by semiautomatic processes, whether it concerns 3D model acquisition and treatment (automatic semantic recognition algorithms) or content updates of visualisation applications.

In addition to this visualisation application, the system can be enriched (currently through web-client software) by experts and general public. This is a significant aspect because we cannot ensure that the whole knowledge related to the object was capitalised in the first iteration. We thus allow the system to capitalise future knowledge. The use of such promotion applications would generate new knowledge for example that the system has to take into account for its new knowledge reference basis. We also have in mind to improve the system in a way that it can assist researchers in their work. For example, it may be able to provide decision help while doing some research on particular historical subject. According to the results of our demonstrating system, we can imagine reproducing the process on other patrimonial objects and extending the process to the whole museum collection. Indeed, as done in contemporary industry, patrimonial objects are concerned by PLM paradigm. From preservation to promotion, many actors are involved, and so is the related knowledge. During these steps -museum lifecycleseveral processes and resources are engaged. The challenge now is to introduce this methodology in a PLM system for museum, allowing the different business areas to work together for better management of historical knowledge (Fig. 4).

Historical knowledge management and museography issues

As discussed before, when capitalising historical knowledge, we need to involve working areas that do not usually communicate. That leads to new processes of cooperation in the design of products and services [START_REF] Boujut | Les entités de coopération dans les nouvelles organisations de la conception[END_REF]: -Products as implementation of cultural mediation devices, which in turn may become heritage objects.

-Services when creating new heritage preservation processes: 3D scanning, structuring documentary corpus…

Fig. 4. Co-working on patrimonial objects

Interdisciplinary Aspects. An overview of the skills needed has been given in the preceding sections of this document. However, let's detail it a bit further:  Expertise on contemporary engineering tools. These tools will be used for the capitalisation phase external data, but also for structuring information. Indeed, the concepts involved may be different depending on the scope (archives, museums, libraries, industry, etc.). This kind of expertise includes mostly engineering skills: experts in modeling and 3D scanning, and IT engineers.  Expertise on the manipulated objects (mostly conservatives)  Expertise in object's contemporary period that leads to an understanding of the object's environment. Mostly historians, historians of science and technology, and archivists for the corpus of documents. These skills are also required for translation of object's contemporary semantics in a current comprehensible language (contemporary to heritage capitalisation stage). Here we see the importance of communication among businesses that usually do not communicate. In fact, each business adopts a vocabulary related to its field of activity. From this point of view, we can assert that different occupations as historians, engineers, conservators, computer are able, under the banner of the common concern of preserving heritage to communicate and work together. This can probably be explained by the common goal, but also by a shared passion that is a community's heritage. Indeed, and this is easily conceivable, heritage and history of a group (in the ethnological sense of the term) is a common root. This can also be seen through the craze that is observed among students working on a subject of their history, yet coming from all sides (engineering schools, universities, etc.).  Expertise on the development and dissemination of information. This includes occupations related to cultural mediation, ergonomists, psychologists, cognitive scientists, or all occupations related to science communication, and data visualisation. This field is therefore also involved in automation or computer programming.

Management of museum collections and associated knowledge

The museum management complexity is as important as for any business. The main difference comes from the nature of manipulated objects. Indeed, the life cycle of products is remarkably different from those in the contemporary design process: the accumulation of knowledge is made retrospectively. It should be used to understand the object's life, influence he has had in a given space-time, and influence of the space-time evolution of the object, described by J.L Ermine in [START_REF] Ermine | Histoire et ingénierie des connaissances[END_REF]. Therefore, the goal is not related to manufacturing process optimisation. However, the tools developed in the field of engineering are designed to be reproducibles. Then, a reproducible method for capitalisation and modeling of historical knowledge would be an answer to many problems. As an example, it would allow the establishment of a reading grid for cultural heritage preservation as recommended by UNESCO [START_REF]UNESCO: Operational Guidelines for the Implementation of the World Heritage Convention[END_REF].

Another significant difference comes from the multi-dimensionality of the concerned knowledge. The phenomenon of reverse capitalisation requires a crossing of objects' life cycles and links between multi-dimensional information. This is why the implementation of DHRM introduces a slightly different definition of the product life cycle as the one usually used in a current industry. Involved concepts and knowledge capitalisation contexts are differents.

Currently, the management of museum collection is provided by dedicated software (usually a specific Database Management System for museum) associated with a thesaurus. These DBMS are often under proprietary license, which prevent from efficient interoperability and implies specific skills. However, only people related to the administration of collections (museum curators, conservators, system administrator, research associates) work on the museum collection database. Indeed, cultural mediators, although the first link between visitors and museum collection objects exposed cannot interact with the collection management system. The information contained in the database is also often codified in a well specified and structured thesaurus. Knowledge of technical teams involved in the maintenance of cultural promotion systems are not taken into account in the system except for some characteristics such as illuminance maximum rate.

In the case of temporary exhibitions, whose aim is to expose heritage objects related to a particular theme, some objects are provided by donors. However, some of these objects are merely loaned and other data are permanently leaved to the museum. It also frequently happens that many museums work together and proceed to exchanges from their own collections to meet the general discourse of the exhibition. However, only objects definitely bequeathed to the museum are then being digitised and loaded into the collections management system (through an historical sheet). Even if the exhibition is stored in the database as an event and linked to exhibited objects, the whole process of the exhibit design and discourse is not capitalised.

Thus, accumulation of knowledge in the sense we have explained in this paper would move towards a knowledge management tool museum, both for collections but also for people working in museum. Moreover, interaction and multi-disciplinarity is evident in the museum world where skills are extremely varied and heterogeneous. Yet, they work toward a common goal: preservation and promotion of cultural heritage. It is therefore a source of knowledge that just waits to be transmitted from generation to generation.

Conclusion

Trying to handle historical knowledge with industrial knowledge management methods is a great challenge. Both researchers and museum experts would take benefit from a global information system dedicated to cultural heritage. Yet, such methods are still incompatible when dealing with ancient objects. Moreover, the way of thinking usually used in industry and enterprise research is very new to history. The approach detailed in this paper may allow researchers in history fields (archaeologists, historians, historians of science…) to develop new issues that would be underlined by the system (e.g. comparison of historical sources or intuitions analysis). To do so, we now have to identify which ways the system would use to communicate with semantically different working areas.

Another challenge we point out is the management of knowledge inside museum. Most of the knowledge from cultural heritage is hosted by such institutions (like libraries or archives). Designing museographic discourses involve many professional skills (designers, curators, and technical staff) and need accurate vision of knowledge provided by museum collection. In fact, many of exhibited heritage objects are linked through this discourse. Specific information system being able to host incremental knowledge related to museum collection would support museum activities, heritage preservation and cultural promotion.

Finally, what we aim to do is to make every community of practice involved in this heritage capitalisation process to take benefit on from each other. Industrial knowledge management should take inspiration from these works in order to improve innovation and design processes.

Fig. 3 .

 3 Fig. 3. Augmented historical mock-up


J Dolz

H A Kirişli

T Fechter

S Karnitzki

U Nestle

M Vermandel

Preliminary clinical study to evaluate an interactive system to segment organs at risk in thoracic oncology on CT

published or not. The documents may come

Preliminary clinical study to evaluate an interactive system to segment organs at risk in thoracic oncology on CT

OARs is required for radiation treatment planning (RTP). In thoracic oncology, delineation of some OARs remains manual, making the task time consuming and prone to inter observer variability. Various (semi-) automatic approaches have been proposed to segment OARs on CT but the task still remains challenging. Here, a system to interactively segment OARs in thoracic oncology on CT images is presented and its clinical acceptability evaluated.

20

Methods: The proposed framework has been implemented using MITK platform. User interaction lies in the easy definition of few manual seeds for the OARs and background using a 'paintbrush' tool, which can be interactively added in any view (axial, sagittal or coronal), and is subsequently propagated within the whole volume. Once the user is content with the seeds placement, the system automatically performs the segmentation. If the outcome is not satisfying, the user can modify the seeds, which involves adding and/or removing existing seeds, and perform again the automatic segmentation. Number of tries has been limited to five in the current study. If after the five modifications the segmentation result is not sufficient to be usable in the RTP, the user shall reject it; otherwise, he shall accept it. A hybrid approach based on our previous work [START_REF] Dolz | Combining watershed and graph cuts methods to 45 segment organs at risk in radiotherapy[END_REF][START_REF] Dolz | Interactive approach to segment organs at risk in radiotherapy treatment planning[END_REF] which combines watershed transformation and graph cuts [START_REF] Yuri | Interactive graph cuts for optimal boundary & region segmentation of objects in nd images[END_REF] is used for the segmentation task.

Results:

The system was evaluated on multivendor CT datasets of 10 patients presenting from early stage to locally advanced NSCLC or pulmonary metastases. OARs taken into consideration in this study were: heart, lungs, oesophagus, proximal bronchus tree, spinal canal and trachea. Interactive contours were generated by a physician using the proposed system. Delineation of the OARs obtained with the presented system was approved to be usable for RTP in more than 90% of the cases, excluding the oesophagus, which segmentation was never approved (Fig 1). On the accepted reported cases, more than 90% of the interactive contours reached a Dice Similarity Coefficient higher than 0.7 with respect to manual segmentations (Fig 2). Therefore, our interactive delineation approach allows users to generate contours of sufficient quality to be used in RTP up to three times faster than manually.

Conclusions: An interactive, accurate and easy-to-use computer-assisted system for OARs segmentation in thoracic oncology was presented and clinically evaluated. The introduction of the proposed approach in clinical routine might offer a valuable new option to radiation therapists (RTTs) in performing OARs delineation task. Consequently, further experiments have been conducted on larger databases and with the participation of additional RTTs to investigate its potential use in daily clinical practice [START_REF] Dolz | Interactive contour delineation of organs at risk in radiotherapy: Clinical evaluation on nsclc patients[END_REF].

Figure. 1 .

 1 Figure. 1. Dice Similarity Coefficients (DSC) of semi-automatic OARs segmentation.

* jose.dolz.upv@gmail.com

2016.