Besoins

Méthodologies « Orientées

Produit » Méthodologies

VUE « ENVIRONNEME NTALE» • Gestion de la relation client • Expérience • Processus d'apprentissage • Outils d'ingénierie • Méthodologies systématiques de conception

Keywords: Système Produit-Service, conception intégrée, modélisation multi-vues, éco-conception, évaluation environnementale English Product-Service System, integrated design, multi-views modelling, eco-design, environmental evaluation VUE bénéfices, attentes Collaboration industrielle Compréhension

A Conceptual Framework for Integrated Product-Service Systems Eco-Design Classical business economy is based on the sale of products. However, during the last decades, the increasing competition in the globalized economy and the resources rarefaction has led manufacturing companies in developed countries to re-orient their business towards integration of services in their product offers. The Product-Service System (PSS) concept is used to depict the resulting marketable set of products and services capable of jointly fulfilling a user's need. PSS raise many interests for the reduction of the environmental pressure because they evolve the classical paradigm of mass production and consumption towards new mechanisms of value creation. In the PSS research field, a strong emphasis is put on their "potential" for decreasing the environmental impacts and on the necessity to design PSS as "integrated" sets of products and services. However, there is an important lack of effective support for PSS design and eco-design. This thesis aims at filling this gap by proposing a conceptual framework for PSS integrated eco-design. Its role is to support integration of products and services during PSS design until the most detailed phases by allowing communication between product engineers and service designers. A framework for PSS integrated design is proposed based on a system-based approach and allowing multi-views system modelling. An environmental evaluation framework is coupled to evaluate during design the environmental impacts generated over the PSS life cycle. The applicability of the conceptual framework is tested on an industrial case of a pneumatic energy delivery PSS.

REMERCIEMENTS / ACNOWLEGEMENTS

To the Jury I would like to thank the jury for this thesis examination and for the interesting exchange we had during the defence. I thank the two reporters, Pr. Nadège Troussier and Pr. Tim McAloone who kindly accepted to read and comment this long manuscript and provided me their valuable tips and remarks. I thank Pr. Tomohiko Sakao for his examination and for kindly accepting to be the jury president. I thank Pr. Améziane Aoussat for his examination despite some difficult conditions at the last moment. Finally, many thanks to Pr. Daniel Brissaud for his supervision, his valuable tips during the entire thesis, his management well adapted to my personality, the attention he paid for my manuscript and his careful support for preparing the defence. I was very pleased to work with him as well as to present the results of this collaboration to the other jury members and to discuss them.

A tous les autres

Je voudrais remercier vivement toutes les personnes qui ont, de près ou de loin, contribué à m'aider et m'ont soutenu pour amener ce travail de thèse à son terme.

Je remercie d'abord Alan Lelah, qui m'a beaucoup aidée et a co-encadré mon travail durant la première année et une bonne partie de la seconde. Ses conseils m'ont permis d'avancer, mais il m'a également beaucoup épaulé et nos échanges m'ont souvent permis d'appréhender les choses différemment et plus facilement. Il m'a communiqué sa bonne humeur et son enthousiasme et je l'en remercie.

Je remercie aussi très vivement Antoine Cros, dirigeant des Ets André Cros, ainsi que toute son équipe, pour l'accueil qui m'a été fait dans l'entreprise et notre collaboration très intéressante. L'entreprise, par le biais de M. Cros est porteuse de fortes valeurs humaines et sociales, puisque l'entreprise est familiale et entend véhiculer des principes de solidarité entre les employés, mais aussi d'un profond engagement environnemental, et accorde une réelle importance au développement de solutions nouvelles génératrices de moins d'impacts. L'entreprise m'a ouvert grand ses portes et beaucoup de temps a été consacré à notre collaboration, et je tiens à remercier pour cela toutes les personnes qui se sont investies dans ce projet, et en particulier Nathalie Candé et Jean-Yves Mahier. Ils m'ont tous deux consacré de longues heures de travail et nos échanges ont toujours été extrêmement enrichissants. Je suis fière d'avoir pu travailler avec une entreprise aussi ouverte et impliquée vers le développement durable.

Je remercie toutes les personnes du laboratoire G-SCOP, et de l'équipe CPP en particulier, qui m'ont apporté leur aide à différents moments de la thèse.

Je remercie les permanents, en particulier Peggy et Guillaume, qui m'ont souvent aidée, qui ont relu beaucoup de mes travaux, et qui m'ont beaucoup conseillé pour préparer la soutenance. Leur soutien et leurs conseils m'ont été précieux. Un grand merci aussi à Guy Prudhomme, qui s'est toujours montré très intéressé par mon travail et disponible, qui a relu une grande partie du manuscrit et m'a beaucoup aidé à mieux le structurer, et qui m'a apporté un regard très intéressant sur cette thèse.

Et surtout, merci (mille fois) à Lucie, qui a été un appui indéfectible durant l'ensemble de la thèse, sur le plan professionnel et surtout personnel. Cette thèse, c'est un peu la sienne aussi. Merci d'avoir été là sur tous les plans et à tous les moments.

Merci à tous les copains qui m'ont aidée à terminer et venir à bout de ce long chemin. Merci à Yacine de m'avoir bien aidée pour la mise en page, tu m'as fait gagner un temps précieux. Merci à tous ceux qui ont assisté à mes pré-soutenances et aussi à ceux qui m'ont apporté leur aide pour préparer ce grand jour, Julien, Natalia, Camille, Tom, et les autres… Et à ceux qui ont exprès fait le déplacement, merci Romain, et un énorme merci pour cette magnifique boîte à musique que tu m'as faite! Rien que pour elle, ça valait le coup ! Merci aussi Egor d'avoir trouvé le temps de venir entre deux déplacements pour nous raconter les dernières nouvelles de Russie… Un grand merci aux copains, à ceux du labo et aux autres, pour m'avoir soutenu ou changé les idées quand j'en avais besoin. Merci à Lucie donc, d'avoir d'abord partagé ton bureau avec moi, puis un peu de ta vie. Merci à ceux qui sont partis depuis des lustres mais qui ont beaucoup compté, Ingwild, Ben, Gab et Chloé, Julie, Romain, j'ai passé des super moments grâce à vous, et je vous dois beaucoup. Le moral, c'est vous. Et merci à ceux qui sont encore là et avec qui j'ai partagé de très bons moments : Julien, Hugo, Natalia, Olga, Yacine, Clément… Merci les copains, on a bien rigolé, on a bien coinché, on a bien dansé, et ça m'a bien aidée.

Merci à ma famille, et surtout à ma maman qui a toujours été là dans les moments difficiles. La fin a été un peu laborieuse mais, grâce à toi, j'ai réussi à ne pas craquer (enfin, pas tous les jours…).

Et un grand merci à toi, Geoffrey, parce que tu étais là, parce que tu sais, parce que tu m'as aimée et toujours épaulée. Je n'étais pas seule parce que nous étions deux, un pilier qui m'a empêché de sombrer. Merci du fond du coeur.

« Le monde ne sera pas détruit par ceux qui font le mal, mais par ceux qui le regardent sans rien faire. » Albert Einstein

Résumé / Abstract

Français Cadre Conceptuel pour l'Eco-Conception de Systèmes Produit-Service L'économie de marché est classiquement basée sur la vente de produits. Pourtant, au cours des dernières décennies, la compétitivité accrue dans une économie mondialisée et la raréfaction des ressources a conduit les entreprises industrielles des pays développés à réorienter leurs offres de produits par l'intégration de services. Le concept de Système Produit-Service (SPS) fait référence à cet ensemble commercialisable de produits et services, capables de répondre ensemble à un besoin utilisateur. Les SPS soulèvent beaucoup d'intérêt pour la réduction des pressions environnementales parce qu'ils font évoluer le paradigme classique de production et consommation de masse vers de nouveaux mécanismes de création de valeur. La recherche sur les SPS accorde beaucoup d'importance à leur « potentiel » pour la réduction des impacts environnementaux ainsi qu'à la nécessité de concevoir les SPS comme des ensembles « intégrés » de produits et services. Néanmoins, un important manque de réel support à la conception et à l'éco-conception de SPS est à noter. Cette thèse cherche à combler ce manque en proposant un cadre conceptuel pour la conception intégrée de SPS. Son rôle est d'assister l'intégration de produits et de services durant la conception de SPS jusqu'aux phases les plus détaillées en permettant la communication entre les ingénieurs produits et les concepteurs de services. Un cadre pour la conception intégrée de SPS est proposé, basé sur une approche système et permettant sa modélisation multi-vues. Un cadre d'évaluation environnemental lui est couplé pour évaluer, au cours de la conception, les impacts environnementaux générés durant le cycle de vie du SPS. L'applicabilité du cadre conceptuel est testée sur un cas industriel de SPS pour la fourniture d'énergie pneumatique.

Résumé de la thèse 1. Introduction 1.1. Contexte et objectif de la recherche

L'économie de marché est classiquement basée sur la vente de produits. Pourtant, au cours des dernières décennies, la compétitivité accrue dans une économie mondialisée et la raréfaction des ressources a conduit les entreprises industrielles des pays développés à réorienter leurs offres de produits par l'intégration de services.

Le concept de Système Produit-Service (SPS) fait référence à cet ensemble commercialisable de produits et services, capables de répondre ensemble à un besoin utilisateur [START_REF] Goedkoop | Product Services Systems, Ecological and Economic Basics[END_REF]. Les SPS soulèvent beaucoup d'intérêt pour la réduction des pressions environnementales parce qu'ils font évoluer le paradigme classique de production et consommation de masse vers de nouveaux mécanismes de création de valeur. La recherche sur les SPS accorde beaucoup d'importance à leur « potentiel » pour la réduction des impacts environnementaux ainsi qu'à la nécessité de concevoir les SPS comme des ensembles « intégrés » de produits et services. Néanmoins, un important manque de réel support à la conception et à l'écoconception de SPS est à noter. Cette thèse cherche à combler ce manque en proposant un cadre conceptuel pour la conception intégrée de SPS. Ce chapitre introduit le sujet de recherche en définissant les fondamentaux des SPS, leurs enjeux pour le développement durable, et détaille les manques initialement identifiés pour la formulation de la question de recherche préliminaire à ces travaux de thèse.

L'émergence des SPS comme réponse à des enjeux de développement durable

Nécessité de changement de modèle de développement

Des besoins et des produits

Historiquement, le paradigme de production et consommation de masse a guidé les entreprises industrielles vers la production de produits toujours plus nombreux pour inonder les marchés, donc vers la réduction maximale des coûts et délais de production, parfois au détriment de la qualité, et vers des stratégies de maximisation du renouvellement des produits, notamment par le biais d' « obsolescence programmée » visant à réduire leur fiabilité ou leur durée de vie. Mais avec ce modèle, les entreprises industrielles des pays développés d'Europe de l'ouest et des Etats-Unis sont aujourd'hui confrontées à la délocalisation des systèmes productifs vers des pays à bas coûts de main d'oeuvre, ainsi qu'à des enjeux et pressions règlementaires croissantes en matière d'environnement, liée à la raréfaction des ressources naturelles et à l'accumulation de pollutions et déchets liés aux produits. La nécessité de maintenir la développement économique dans un état permettant la viabilité de l'humanité a été définie par les Nations Unies comme le « développement durable », correspondant à un « développement qui réponde aux besoins du présent sans compromettre la capacité des générations futures à satisfaire les leurs » [START_REF] Brundtland | Our Common Future[END_REF]. La responsabilité industrielle pour l'évolution vers le développement durable s'est historiquement accrue au fil des années, jusqu'au développement de stratégies d'écoconception pour permettre l'intégration des impacts environnementaux générés tout au long du cycle de vie des produits (ISO/TR 14062 2003) dès la phase de conception . Si ces stratégies sont importantes pour réduire l'impact des produits, dans une économie basée sur la consommation de masse, la réponse au besoin est toujours fonction de la quantité de ressources utilisées.

Le modèle de Systèmes Produit-Service (SPS)

Le concept de SPS s'est développé à la fin des années 1970, avec le concept de « l'économie de service » censé remplacer « l'économie industrielle » basée sur l'utilisation intensive de ressources [START_REF] Stahel | Jobs for Tomorrow: The Potential for Substituting Manpower for Energy[END_REF]. L'idée de l'économie du service est basée sur l'idée que les échanges commerciaux ne soient plus basés sur les produits physiques mais sur le « service rendu » pour répondre aux besoins.

Les termes « d'économie fonctionnelle » [START_REF] Stahel | The Functional Economy: Cultural & Organizational Change[END_REF]) ou « d'économie de fonctionnalité » [START_REF] Grenelle | Rapport Final Au Ministre d'Etat[END_REF]) sont également utilisés pour décrire le fait que les services ou les « fonctions » rendu(e)s par les produits sont le socle de la réponse aux besoins, et non les produits pour eux-mêmes. Avec les SPS, le concept de « valeur d'échange » évolue ainsi vers la « valeur d'usage ».

Les SPS ont de nombreuses définitions selon les auteurs, qui y associent différents concepts et idées, mais les éléments clés suivants y sont généralement associés [START_REF] Goedkoop | Product Services Systems, Ecological and Economic Basics[END_REF]) : les produits ; les services, correspondant à des activités réalisées sans nécessairement de support physique associé ; et leur combinaisons et relations.

Plusieurs typologies de SPS existent, généralement basées sur un continuum allant du produit au service, la plus connue étant celle de Tukker (2004), décrite en Figure 1. Certaines typologies intègrent la notion de « droits de propriété » des produits, qui tient aussi une place importante dans le « potentiel » des SPS pour la réduction des impacts. Dans cette thèse, les SPS considérés sont ceux dont la propriété des produits est maintenue par le fournisseur. En particulier, les SPS orientés « résultat » dans la typologie de Tukker sont ceux étudiés dans ces travaux.

Figure 1 Les principales sous-catégories de SPS selon [START_REF] Tukker | Eight Types of Product-service System: Eight Ways to Sustainability? Experiences from SusProNet[END_REF] Le « potentiel » des SPS pour l'émergence d'une société « durable »

Les SPS sont généralement considérés dans la littérature comme des sources de possible évolution vers des modèles de développement durable.

Bénéfices économiques et stratégiques

Les SPS correspondent en général à une évolution du modèle d'affaires de la vente de produits à la vente de services, soit à un processus nommé « servicisation » (Morelli 2003[START_REF] Baines | State-ofthe-Art in Product-Service Systems[END_REF]). Ce processus de transition de l'entreprise est adopté par l'industrie car il permet de générer des bénéfices à la fois pour le fournisseur et pour le client. En effet, les intérêts des fournisseurs et des clients convergent pour la maximisation de la création de valeur à travers la relation de service : -Le client est mieux compris, son besoin plus clairement identifié et la relation de service permet d'améliorer continuellement la réponse apportée par le fournisseur -Le fournisseur peut se positionner stratégiquement sur des marchés de plus en plus compétitifs, et maintenir des relations de confiance avec les clients pour les fidéliser.

Les SPS permettent au fournisseur de donner à l'ancrage territorial des industries un avantage stratégique, et font évoluer la place des ressources physiques dans la relation de création de valeur financière. L'intérêt du fournisseur est de maximiser ou de prolonger l'utilisation des produits, désormais supports de la valeur d'usage pour le client. Le produit devient un « capital » à faire perdurer.

Bénéfices environnementaux

Les bénéfices environnementaux sont perçus dans cette évolution de la place des produits dans la relation d'offre / demande du développement économique.

Le premier intérêt est le fait que la réponse au besoin ne réside plus dans le produit physique, les SPS sont donc vus comme des leviers d'innovation, où le degré de liberté pour trouver les solutions appropriées est plus grand. Il devient donc possible de trouver de nouvelles réponses aux besoins réduisant radicalement les impacts environnementaux [START_REF] Tukker | New Business for Old Europe. Product-Service Development as a Means to Enhance Competitivness and Eco-Efficiency[END_REF].

Le second intérêt est que les produits étant des « capitaux » à faire perdurer, les leviers d'actions des fournisseurs sur l'ensemble de leurs cycles de vie sont plus nombreux. La « responsabilité élargie » des fournisseurs à l'ensemble du cycle de vie des produits permet l'implémentation de stratégies d' « optimisation » de ces cycles par :

-La maximisation et l'optimisation de leur usage : usage partagé, multiples phases d'usage, upgrades, utilisation facilitée, guidée ou surveillée (par l'addition de systèmes d'information notamment), l'amélioration continue de l'usage. -L'optimisation de la « fin de vie » : mise en oeuvre de processus de réutilisation, upgrade, remanufacturing, recyclage, tous facilités par la possibilité offerte (avec le maintien de la propriété) de récupérer les produits après usage et de mettre en place des canaux de logistique inverse. -L'extension de la durée de vie des matériaux, des produits et du recyclage par la conception -La minimisation des ressources physiques utilisées puisqu'elles font augmenter les coûts des SPS.

Quelques cas emblématiques

Les SPS les plus connus sont brièvement présentés dans cette partie. Le cas Xerox : passé de la vente de photocopieurs à la vente de « photocopie » payée à l'impression. La conception a été revue pour le SPS et un programme de remanufacturing a permis la réutilisation de 90% des équipements et la réduction de déchets de 24000 tonnes [START_REF] Bourg | Changer La Consommation Dans Le Sens Du Développement Durable : La Voie de L'économie de Fonctionnalité[END_REF].

Les cas du vélo partagé (plusieurs villes) : Vélo'V à Lyon propose un service de paiement à l'utilisation du vélo, qui diffère du système de location classique puisque les points de retrait et dépôt sont différents. Les vélos sont mutualisés et leur conception est très différente de celle d'un vélo individuel. Ce cas est également emblématique car il intègre aussi différents produits : les bornes de retrait / dépôt incluant des systèmes de télécommunication, des services de réapprovisionnement, de remise en état, et la création ou l'utilisation de différentes infrastructures (pistes cyclables, télécoms, routes, etc.) Le cas Elis : Elis propose un service de location et nettoyage de vêtements de travail, ou de « vêtement de travail continuellement propre ». Les vêtements sont mutualisés entre plusieurs salariés de différentes sociétés clientes d'Elis qui fournit et récupère régulièrement les vêtements pour les nettoyer. La conception des vêtements a été modifiée par rapport à celle des vêtements de travail classique, des matériaux synthétiques plus robustes que le coton sont utilisés et leur durée de vie est multipliée par deux. Des techniques et process de nettoyage professionnels sont utilisés pour faciliter et accélérer le lavage, le séchage et le repassage des vêtements compte tenu du matériau. Comparé à la vente et utilisation individuelle de vêtements de travail, le SPS d'Elis permet une réduction de 50% de consommation d'énergie et des émissions de CO2 ainsi qu'une consommation d'eau divisée par 10 [START_REF] Grenelle | Rapport Final Au Ministre d'Etat[END_REF]. Le cas Michelin : Michelin est passé de la vente de pneus à la vente de « km parcourus » par les pneus.

Les clients sont des transporteurs ayant un parc poids lourd et ils paient au km parcouru par les pneus. La conception des pneus a permis de réduire l'utilisation de carburant de 5 à 11% avec ces pneus, ce qui bénéficie au client de l'offre. Michelin assure l'installation et l'équilibrage, et garantit un entretien continu du pneu (notamment pression adaptée). Un service d'assistance est mis en place en cas de crevaison ou dégonflage. Les pneus sont rechapés et recreusés au cours du contrat, ce qui permet de prolonger leur durée de vie. Michelin assure aussi des formations aux chauffeurs à l'éco-conduite. Comparé à un achat de pneu traditionnel, le coût des pneus Michelin au km parcouru est plus bas et les coûts de carburant diminués [START_REF] Grenelle | Rapport Final Au Ministre d'Etat[END_REF].

Difficultés et manques pour la conception de SPS durables

Malgré l'intérêt porté aux SPS, à la fois par le monde industriel des pays développés pour gagner en compétitivité, et par les environnementalistes pour le « potentiel » qu'ils représentent, de nombreuses difficultés et questionnements pour leur développement effectif peuvent être soulevées.

Les questionnements autour de l'éco-efficience

Les bénéfices environnementaux des SPS ne sont pas systématiques [START_REF] Tukker | Eight Types of Product-service System: Eight Ways to Sustainability? Experiences from SusProNet[END_REF]) (Vezzoli, Kohtala, and Srinivasan 2014) et sont rarement étudiés de manière quantitative.

Des « effets rebond » peuvent survenir [START_REF] Tukker | New Business for Old Europe. Product-Service Development as a Means to Enhance Competitivness and Eco-Efficiency[END_REF]) (Vezzoli, Kohtala, and Srinivasan 2014) qui correspondent à des réponses comportementales ou systémiques à une action mise en oeuvre pour la réduction des impacts et qui contrebalancent négativement les effets de cette action. [START_REF] Vezzoli | New Design Challenges to Widely Implement 'Sustainable Product-Service Systems[END_REF] font référence aux effets sur les comportements des consommateurs dans le cas du leasing, où, comparativement à l'achat, ceux-ci peuvent être « moins impliqués » et donc « moins écologiques ». D'autre part, certains types de SPS, comme les SPS orientés produit ou orientés usage pour [START_REF] Tukker | Eight Types of Product-service System: Eight Ways to Sustainability? Experiences from SusProNet[END_REF] (voir Erreur ! Source du renvoi introuvable.), peuvent conduire à des réductions d'impacts on significative, ou même à davantage d'impacts que pour les SPS (en référence ici encore au cas du leasing). [START_REF] Vezzoli | New Design Challenges to Widely Implement 'Sustainable Product-Service Systems[END_REF] ajoutent que dans les cas où les produits sont prêtés et retournés, les coûts et impacts associés au transport peuvent être augmentés.

Pour [START_REF] Tukker | Eight Types of Product-service System: Eight Ways to Sustainability? Experiences from SusProNet[END_REF], les SPS orientés produit et usage ne sont donc pas par définition moins consommateurs de ressources que les business models classiques basés sur la vente de produit. Il encourage à s'orienter vers des approches plus innovantes au travers des SPS orientés résultat (voir Erreur ! Source du renvoi introuvable.) pour permettre une réduction substantielle des impacts. D'autre part, très peu d'études quantitatives ont été menées sur les impacts environnementaux des SPS, en particulier pour déterminer leur réduction effective via les SPS comparativement à la vente de produits. Les travaux de Tukker (2004) ont contribué à montrer comment les SPS pouvaient permettre la réduction d'impacts, mais ces travaux sont basés sur des méthodes semi-quantitatives. Quelques cas PSS ont été étudiés via des évaluations quantitatives et comparés à des offres produit pour la conférence environnementale organisée en France lors du Grenelle de l'environnement [START_REF] Grenelle | Rapport Final Au Ministre d'Etat[END_REF]. Mais la plupart des études sont qualitatives et génériques [START_REF] Lindahl | Environmental and Economic Benefits of Integrated Product Service Offerings Quantified with Real Business Cases[END_REF]. La contribution de Lindahl, Sundin, and Sakao (2014) est l'une des rares études quantitatives de SPS qui mesurent leurs bénéfices économiques et environnementaux comparés à la vente de produits. Les résultats montrent que les SPS sont préférables de ces deux points de vue (économique et environnemental) pour les trois cas étudiés.

Les questionnements de la conception

La conception et le développement des SPS appartient à un questionnement plus général du monde industriel pour le développement d'innovations ou d' « éco-innovations » [START_REF] Laperche | Environmental Constraints, Product-Service Systems Development and Impacts on Innovation Management: Learning from Manufacturing Firms in the French Context[END_REF] qui impliquent des changements organisationnels ou structurels au niveau de l'entreprise. La conception de SPS est davantage relative à un projet de transition du business model associé à un nouveau positionnement stratégique qu'à une tâche systématique du processus classique de l'entreprise. [START_REF] Ceschin | Sustainable Product-Service Systems -Between Strategic Design and Transition Studies[END_REF] souligne l'importance d'associer en conception de SPS les approches stratégiques avec les études pour la transition. Quelques méthodologies ont été proposées pour soutenir les entreprises dans cette transition. Les plus répandues sont le manuel de 'Design for Sustainability' développé par l'UNEP [START_REF] Crul | Design for Sustainability -A Step by Step Approach[END_REF], le guide pratique pour les entreprises développé par Tukker and van Halen (2003), ou le guide méthodologique 'Methodology for Product Service Systems Innovation' (MEPSS) [START_REF] Van Halen | Methodology for Product Service System Innovation. How to Implement Clean, Clever and Competitive Strategies in European Industries[END_REF]. Ces méthodologies contiennent principalement des boîtes à outils et des 'guidelines' pour aider le développement des SPS comme « innovations » à un niveau stratégique de l'entreprise.

Pourtant, si ces quelques méthodes sont utiles pour faire émerger de nouveaux concepts et positionner de nouveaux types d'offres sur les marchés, la manière de gérer la conception effective de ces offres manque fortement de support dans la littérature SPS. Cette absence de support méthodologique constitue une forte barrière pour l'adoption effective de SPS dans les entreprises industrielles [START_REF] Beuren | Product-Service Systems: A Literature Review on Integrated Products and Services[END_REF] (Vezzoli, Kohtala, and Srinivasan 2014). La conception de SPS soulève des difficultés dans la mesure où les produits et services doivent être conçus de manière intégrée dans un « système » créateur de valeur. Les produits et services sont généralement conçus par différentes équipes ayant différentes cultures. Cette question de l'intégration des produits et services est souvent soulevée dans la littérature associée comme constituant l'un des challenges majeurs (par exemple [START_REF] Mcaloone | Boundary Conditions for a New Type of Design Task: Understanding Product/Service-Systems[END_REF][START_REF] Isaksson | Development of Product-Service Systems: Challenges and Opportunities for the Manufacturing Firm[END_REF][START_REF] Tan | Strategies for Designing and Developing Services for Manufacturing Firms[END_REF][START_REF] Baines | State-ofthe-Art in Product-Service Systems[END_REF][START_REF] Vasantha | A Review of Product-service Systems Design Methodologies[END_REF][START_REF] Tran | Development of Integrated Design Methodology for Various Types of Product -Service Systems[END_REF]. Cette absence d'outils et méthodes pour la conception de SPS conduit à une absence de support pour leur écoconception, soit la conception de ces systèmes avec une prise en compte de leur dimension environnementale. Les méthodologies existantes pour aider la conception à un niveau stratégique intègrent généralement une évaluation environnementale. Mais ces évaluations sont qualitatives, puisque les informations nécessaires à la quantification ne sont pas disponibles. Ces évaluations servent à orienter la prise de décision à un niveau très conceptuel, mais ne permettent pas d'être « raffinées » au fil de la progression vers les phases plus détaillées, puisque ces phases manquent d'outils pour la conception elle-même.

Les évaluations quantitatives sont donc largement manquantes dans le domaine des SPS et les quelques-unes disponibles ont été menées à posteriori de la conception. Ainsi, pour permettre l'émergence de SPS qui réalisent pleinement leur « potentiel » pour l'écoefficience, des supports méthodologiques pour l'écoconception de SPS doivent être développés.

Question de recherche initiale et orientation de l'action

Après une brève revue de littérature initiale, les conclusions qui peuvent être tirées sont les suivantes : Les Systèmes Produit-Service (SPS) correspondent à une tendance émergente de l'économie industrielle ainsi qu'à un nouveau champ de recherche dans la littérature. Le développement de SPS a été initié par les entreprises industrielles pour maintenir leur compétitivité dans les pays développés. Le remplacement de la vente de produits par des offres intégrées de produits et services est perçu comme prometteur pour permettre de créer de la valeur supplémentaire pour les bénéficiaires et pour les entreprises. Au-delà des bénéfices économiques et stratégiques espérés par la transition vers ces nouveaux business models, le « potentiel » des SPS pour permettre la réduction des impacts environnementaux tout en maintenant les réponses aux besoins est aussi fortement discuté. Mais si ce « potentiel » paraît évident, la manière de le réaliser pleinement est toujours un challenge non résolu. Quelques travaux montrent que les SPS peuvent générer plus d'impacts qu'une offre produit, et on constate un manque d'études quantitatives sur les impacts des SPS.

De plus, la conception et l'implémentation de SPS manquent largement de support méthodologique : leur absence dans la littérature est à noter. La dimension environnementale en conception est intégrée seulement de manière qualitative. L'objectif de cette thèse est de combler ces manques par la proposition d'une méthodologie pour l'écoconception de SPS. L'écoconception fait référence à la conception, avec une prise en compte de la dimension environnementale en conception. Cette thèse prend donc l'hypothèse initiale que la problématique de l'écoconception de SPS est liée à celle de la conception, en particulier de l'intégration des produits et services au sein de ces « systèmes ». Une question de recherche initiale a donc été posée : QR0 : « Quels sont les challenges de la (/l'éco-)conception intégrée de SPS ? » Pour répondre à cette question, la littérature considérée comme pertinente au regard des questionnements posés et des manques dans le champ des SPS a été explorée.

Apports de la littérature

2.1. La conception / l'écoconception de SPS : littérature existante et manques

Processus de conception de SPS

La plupart des approches existantes en matière de conception de SPS convergent vers les étapes suivantes dans un processus de conception :  Une phase de « conception stratégique » : l'identification des besoins et exigences, le positionnement stratégique de l'offre couplé avec la conception conceptuelle du système (terminant par la sélection d'un concept de SPS)  Une phase de « conception produit / service » pouvant être assimilée à la conception détaillée du système : o Développement du concept o ''Embodiment'' : sélection / identification des sous-systèmes o Conception détaillée des sous-systèmes o Tests  Une phase « d'implémentation ».

La plupart des méthodologies existantes se concentrent sur la phase de » conception stratégique », comme évoqué dans le paragraphe précédent. Parmi les approches qui supportent la « conception produit / service », quelques méthodologies sont proposées qui regroupent des ensembles d'outils de modélisation. Mais l'intégration des outils dans les méthodologies n'est généralement que peu explicitée. D'autre part, les questions de l'intégration des produits et services et le couplage des modèles sont peu traitées.

Environnement et conception de SPS

Il existe quelques contributions traitant de l'écoconception ou de la dimension environnementale de SPS. Mais ces approches s'orientent vers l'évaluation de ces systèmes et sont discutées d'une manière assez découplée des problématiques de la conception. D'autre part, les approches environnementales pour les SPS sont majoritairement basées sur la prise en compte des impacts générés au cours des cycles de vie des produits et n'intègrent pas ou discutent peu ceux des services au sein du système. La littérature SPS qui intègre la dimension environnementale peut être résumée par le Tableau 1. On retrouve deux types d'approches pour l'intégration de la dimension environnementale en conception de SPS. D'un côté les approches dites « orientées service » qui sont proposées en support de la conception stratégique et qui ont été discutées dans le paragraphe précédent. Elles s'opposent aux approches dites « orientées produit » proposées pour l'évaluation environnementale quantitative de ces systèmes mais qui sont quelque peu découplées des problématiques liées au processus de conception.

Approches orientées service

Pour la conception stratégique

Approches orientées produit

Pour l'évaluation environnementale

Point d'entrée

La relation de service Les besoins La création de valeur  La conception et le développement de services : elle est historiquement plus développée dans les disciplines relatives à la gestion business, managériale et marketing, mais de récents développements ont émergé pour adapter les connaissances de l'ingénierie à la conception de services  Les approches « système » : qui englobent l'ingénierie système, la pensée système et les méthodologies qui en découlent et les adaptations des approches systèmes à la conception de services

Les interconnections entre les différents domaines sont schématiquement représentés sur la Figure 2.

Figure 2 Les différents champs de la littérature explorés et leurs interconnections Les principales conclusions qui ont été tirées de cette analyse sont résumées dans le paragraphe suivant.

La revue et l'analyse de la littérature ont permis de mieux cibler l'objectif et le scope (les hypothèses et part pris) de la recherche et de raffiner la formulation de la question de recherche initiale (RQ0) en sous-questions de recherche. Elles sont donc explicitées ensuite dans ce résumé.

Principales conclusions de la revue de littérature

Quatre grandes « vues » pour l'écoconception de SPS

On considère l'existence de domaines de compétences, ou points de vue de d'acteurs qui doivent être impliqués dans un processus d'écoconception de SPS. Les quatre principales « vues » identifiées dans la littérature sont les suivantes :  La vue « bénéficiaire » du système : qui créée de la valeur durant la livraison du service, par la fourniture d'une réponse à ses besoins, attentes et par la création de bénéfices dans une relation de service.  Les deux vues « conception » : o La vue « conception de service » : il s'agit de la littérature qui s'intéresse au service et à son organisation et correspondant aux domaines de compétences orientés marketing, gestion, business, sciences sociales, etc. Dans ces domaines, l'objectif est de mieux appréhender et comprendre la vue « bénéficiaire » par la mise en oeuvre de méthodologies de gestion de la relation client (GRC) ; par des outils et supports pour mieux comprendre l'expérience vécue par le bénéficiaire dans la relation partagée ; et pour progresser dans la proposition de valeur offerte (le service et la relation de service) via un processus d'apprentissage progressif et mutuel entre le bénéficiaire et le fournisseur, donc pour la « co-création de valeur ». o La vue « ingénierie produit » : il s'agit de la littérature s'intéressant à l'ingénierie, dans des domaines de compétences davantage orientés vers la conception des produits que vers celle des services immatériels, comme l'ingénierie de produit, la conception intégrée de produit, mais aussi l'ingénierie « système », qui, malgré son appellation, adopte principalement un raisonnement « tiré par un paradigme produit » [START_REF] Wood | Service Thinking in Design of Complex Sustainment Solutions[END_REF]. Dans ces domaines, de nombreux supports méthodologiques existent pour la systématisation de la tâche de conception et la prise en compte du cycle de vie des produits. La conception intégrée et l'ingénierie système visent à intégrer au mieux et au plus tôt l'ensemble des exigences des parties prenantes dans le processus de conception sur l'ensemble du cycle de vie. Pour cette raison, la vue « environnementale » lui est bien associée, et résulte du développement de supports pour la prise en compte des critères environnementaux dans les approches d'ingénierie.  La vue « environnementale » exprime la « voix de l'environnement » portée par l'expertise environnementale nécessaire en écoconception, qui intègre et dispense la connaissance des impacts environnementaux générés par le système. Si la vue « bénéficiaire » exprime le besoin dont la satisfaction justifie le processus de conception, la vue environnementale exprime les effets (impacts) de la satisfaction dudit besoin sur l'environnement.

Gap méthodologique entre les vues

L'analyse de la littérature a permis d'identifier un gap méthodologique entre les différentes vues qui est résumé ici par la Figure 3. Pourtant, une distance méthodologique existe entre les méthodologies « orientées produit » (ingénierie et vue environnementale) et celles « orientées service » (conception de service et vue bénéficiaire). D'un côté, les approches du marketing et des sciences sociales (« orientées service ») permettent une bonne compréhension des besoins et un management efficace de la relation client, mais leur intégration en conception dans un processus systématique et multi-acteurs est encore difficile. De plus, les approches « orientées service » sont focalisées sur le besoin et sa satisfaction, et ont tendance à ne pas distinguer produit et services, considérant que ressources physiques et humaines sont toutes des ressources (plus ou moins « interchangeables ») permettant la création de valeur. En procédant ainsi, elles négligent parfois les dimensions techniques de la conception de produit et les impacts environnementaux associés au système finalement conçu (requérant nécessairement l'utilisation de produits dans la fourniture des services). D'un autre côté, les approches d'ingénierie produit et d'analyse environnementale (« orientées produit ») permettent de considérer la conception comme un processus systématique et mutli-acteurs, au sein duquel le cycle de vie du produit constitue le socle de l'intégration des différents métiers. L'intégration de la dimension environnementale (en écoconception) permet de générer de la connaissance sur les impacts du produit durant l'ensemble du cycle de vie et ainsi de guider la conception. Pourtant, les approches « orientées produit » peinent encore à intégrer les dimensions sociales de la création de valeur dans la construction de la réponse aux besoins. Les méthodologies de conception et de management du processus de développement doivent encore progresser pour intégrer les aspects plus intangibles de la création de valeur, qui se complexifie dans une relation de service puisqu'elle devient partagée, évolutive et apprenante (dans le mécanisme de co-création).

Les challenges de l'écoconception intégrée de SPS

3.1. De la conception intégrée de produit à la conception de SPS La conception intégrée (couramment de produit) consiste à permettre la pleine coopération entre les parties prenantes impliquées dans le cycle de vie des produits. Si la conception intégrée est en soi un challenge à relever, la conception intégrée de SPS est d'autant plus difficile que la relation de service amène à étendre le champ des acteurs concernés et à appréhender différemment leurs relations.

Des parties prenantes aux acteurs

Si la conception intégrée appelle à la coopération des parties prenantes du cycle de vie des produits et si l'utilisateur est de plus en plus impliqué dans le processus de conception (via des approches telles que la conception centrée utilisateur), la relation de service fait franchir un nouveau pas à la manière de penser la conception dans un ensemble plus vaste de processus composants la relation d'échange. Dans une relation de service, le bénéficiaire devient un acteur du processus de conception, mais aussi de celui de la livraison du service, et du maintien et de la gestion de la relation entre lui et le fournisseur. La création de valeur pour ces acteurs s'opère dans un cadre plus large d'activités qui sont influencées par la relation sociale qui permet le dialogue et l'apprentissage mutuel dans un cycle continu.

De la coopération entre parties prenantes à la co-création des acteurs

La relation sociale change donc la manière dont on perçoit l'échange. Il ne s'agit plus de coopérer pour concevoir, mais co-créer de la valeur entre les acteurs. Les bénéfices, les inconvénients et risques sont désormais partagés au travers de la relation de service. La solution n'est pas seulement co-conçue avec le bénéficiaire, elle correspond à une expérience partagée :  Le processus d'apprentissage qui aboutit à la construction de la solution n'est donc plus seulement le problème du fournisseur, mais intègre le bénéficiaire.  Les dimensions de l'expérience vécue ne sont plus uniquement spécifiques au bénéficiaire, mais concernent aussi le fournisseur.

Le défi de l'ingénierie : De la résolution de problèmes à la conduite d'actions, l'apprentissage progressif et la co-expérience

Quelques travaux sur les SPS [START_REF] Ericson | People, Product and Process Perspectives on Product/ Service-System Development[END_REF][START_REF] Wood | Service Thinking in Design of Complex Sustainment Solutions[END_REF] discutent le fait que les différences qui existent entre deux modes de pensée « système » peuvent expliquer la difficile compatibilité entre la vision ingénierie (de produit) et la vision adoptée pour évoquer le service, plus managériale et gestionnaire : la vue « hard system » qui s'oppose à la vue « soft system » (Pyster et Olwell 2013, p.93). La première vue correspond à celle classiquement adoptée en ingénierie de produit ou en ingénierie système, pour la résolution de problèmes. Le problème est identifié, explicité et partagé entre les acteurs, puis résolu, via l'utilisation de méthodologies systématiques de résolution et des objectifs identifiés.

La seconde regroupe des méthodologies plus participatives pour permettre à différents acteurs de converger vers une nouvelle situation dans un intérêt commun. La méthodologie « soft system » (Checkland et Scholes 1999) a émergé pour répondre aux limites des approches « hard system » pour résoudre des situations complexes dans des organisations sociotechniques. Elle est basée sur un paradigme d'apprentissage et non d'optimisation. Les participants sont confrontés à des « situations problématiques » (par opposition à des « problèmes » pouvant être clairement explicités et formulés) et doivent apprendre de la situation existante sur les changements désirables et faisables en prenant part à l'action. Un certain degré d'entente entre les participants sur les objectifs à poursuivre peut être atteint après que les actions menées ont permis de « réduire l'inconfort » (par opposition à « trouver des solutions » dans la vue « hard system ») de la situation.

Si la première vue est celle de l'ingénierie et de la conception au sens classique du terme, la manière de penser les organisations sociales, et donc, les processus de l'entreprise mais aussi ceux impliquant le bénéficiaire dans une relation de service, est supportée par la seconde vue, « soft system ».

Pour permettre la co-création entre tous les acteurs du SPS (soit les ingénieurs produits, les concepteurs (ou managers) du service, le bénéficiaire, etc…) il est nécessaire que la relation sociale qui les unit soit pensée et gérée efficacement. Pour cela, il est nécessaire d'intégrer dans le processus de conception la vision « hard system » et la vision « soft system ». Il est donc nécessaire d'être capable d'élargir l'approche d'ingénierie par la résolution de problèmes, et de pouvoir l'intégrer à celle basée sur la conduite d'actions, l'apprentissage et la co-expérience.

La création de valeur : un concept central pour l'écoconception

La notion de « valeur » est un concept central qui peut permettre, en tentant de faire converger les points de vue, d'unifier les approches et les différents points de vue des acteurs du « système ». En effet, l'évaluation environnementale consiste à considérer les impacts environnementaux générés relativement à la fourniture d'une réponse aux besoins. L'Analyse de Cycle de Vie (ACV) qui est le standard pour l'évaluation se prévaut de proposer une approche « système ». Mais dans son utilisation courante, le concept d'Unité Fonctionnelle (UF) reste la référence pour l'évaluation. Pourtant, la notion de fonction et celle de l'UF ramènent la satisfaction du besoin au produit et écartent de la focalisation sur les des besoins réels. Fonction et UF sont des concepts qui correspondent à une vision « hard system » et mal à celle « soft system ». Les multiples facteurs intervenant dans la création de valeur et les multiples dimensions du besoin ne transparaissent pas dans le concept d'UF.

Les approches d'évaluations environnementales considèrent la création de valeur comme étant intrinsèquement liée à la transformation de la matière par le biais du concept de cycle de vie : ajoutée au fil de la fabrication du produit, « délivrée » au moment de l'usage du produit (remplissant là son UF), puis détruite à la fin de vie (idéalement réutilisée, recréée…). Les approches orientées service considèrent la valeur comme émergeant (co-création) des interactions sous-tendues par le lien social. Il est donc nécessaire de penser la création de valeur de manière à intégrer ces deux points de vue. La création de valeur peut s'envisager comme un concept multidimensionnel et multi-vues. Comme en analyse de la valeur (initiée par [START_REF] Miles | Techniques of Value Analysis and Engineering[END_REF], la valeur peut se définir comme un ratio entre un ensemble de bénéfices et un ensemble de coûts, relativement à un acteur ou à un point de vue. Le système (SPS) peut être regardé comme un média pour la création (destruction) de valeur. Du point de vue du bénéficiaire, la valeur est créée dans l'usage ou la relation de service. D'un point de vue environnemental, la valeur est détruite (puisque seuls les effets négatifs des activités socioéconomiques peuvent être pris en compte dans ce qui est nommé « impacts »).

Conduite de la recherche

Cadre et objectif de la thèse

Cette thèse se concentre sur la phase de « conception produit / service » du SPS pouvant être assimilée à la conception détaillée. L'hypothèse est donc faite que la conception conceptuelle est terminée et qu'un concept de SPS a déjà été identifié. Cette thèse se concentre sur l'intégration produit-service, comme illustré Figure 4. L'objectif est donc de créer une interface de communication Produit-Service (PS) pour permettre la négociation en conception entre les ingénieurs produits et les concepteurs de services.

Questions de recherche

Grâce à l'analyse de la littérature, les questions de recherche ont été raffinées et sont décomposées comme suit : QR1. Comment permettre la conception et la modélisation intégrée produit-service ?  RQ1.1. Comment définir un cadre « système » pour intégrer produits et services en conception de SPS ?  RQ1.2. Comment permettre la progression de la tâche de conception via un support intégré de modélisation ?

RQ2. Comment permettre l'écoconception de SPS via l'évaluation environnementale en conception ?  RQ2.1. Comment permettre l'évaluation environnementale de SPS en conception ?  RQ2.2. Comment définir et modéliser un cycle de vie de SPS ?

Processus de recherche

Processus global

Le processus de recherche a consisté en deux processus interconnectés, menés parallèlement et en continu :  Un processus de revue et d'analyse de la littérature  Un processus de collaboration industrielle L'exploration continue de la littérature et la collaboration industrielle se sont mutuellement nourries et enrichies au travers du processus d'apprentissage qui en a découlé, comme illustré Figure 5. Ils ont contribué à identifier des problématiques (théoriques ou industrielles) et à fournir des éléments de réponse pour le développement d'un support. Le support a été systématiquement confronté à la littérature et au cas, ou testé / appliqué sur le cas. Cette confrontation / application a permis de progresser dans l'identification de nouvelles questions ou problématiques à approfondir et résoudre. Les propositions de la thèse résultent donc de ce processus d'apprentissage continu.

Figure 5 Processus de recherche : un apprentissage continu au travers de la revue de littérature et de la collaboration industrielle

 Pour l'entreprise, par l'acquisition de connaissances nouvelles sur les impacts environnementaux de ces offres et leur comparaison aux produits, et le démarrage d'un processus de re-conception basés sur l'analyse environnementale.

En effet, l'entreprise souhaitait acquérir des connaissances sur les impacts environnementaux de ces offres, et sur le réel intérêt environnemental des SPS comparativement aux offres de vente classiques. La collaboration industrielle a donc consisté en différentes étapes :  Deux Analyses de Cycle de Vie (ACV) ont été menées : l'une sur l'offre SPS et l'autre sur l'offre « produit ». L'objectif était d'analyser les impacts environnementaux générés par l'offre SPS dans le but de la reconcevoir sur la base des principales « contributions », ainsi que de comparer cette offre avec celle de vente classique pour déterminer les gains effectifs.  Les résultats de ces ACV ont ensuite été diffusés et discutés avec les acteurs de l'entreprise.  Une journée de « brainstorming » a ensuite été organisée avec tous les corps de métier de l'entreprise pour imaginer des scénarios alternatifs de re-conception du SPS sur la base des résultats de l'ACV.

L'entreprise est aujourd'hui en phase d'étude plus approfondie sur les scénarios de re-conception imaginés.

Propositions de thèse pour répondre aux questions

Si le processus de recherche a été mené de front sur le terrain via la collaboration industrielle, et sur le plan théorique via la revue de littérature, de manière simplifiée, l'identification et la résolution de la première question (QR1) ont été principalement liées à la revue de littérature, et l'identification et la résolution de la deuxième question (RQ2) ont été principalement liées à la collaboration industrielle.

Les propositions de thèse permettent de répondre aux différentes questions de recherche, comme illustré Figure 6. Les propositions de thèse sont constituées de deux principaux blocs :  Un cadre conceptuel pour la conception intégrée produit-service (QR1). Il représente la majeure partie du travail de thèse, en termes de temps passé et d'effort fourni.  Un cadre conceptuel pour l'évaluation environnementale en conception (RQ2). Il constitue l'amorce d'un travail qui doit encore être approfondi et amélioré.

La cadre pour la conception intégrée P-S est constitué de plusieurs éléments :  Une approche « système » basée sur la proposition d'un concept de système et donc de SPS (RQ1.1).  Un modèle multi-vues pour la modélisation intégrée P-S dans un cadre permettant la progression de la conception de SPS (RQ1.2).

Le cadre pour l'évaluation environnementale est composé des éléments suivants :  Un concept de cycle de vie « système », basé sur le concept de système proposé, pour permettre la modélisation du cycle de vie du SPS (QR2.1).  Une méthode et des outils pour l'évaluation environnementale du SPS en conception (QR2.2).

Figure 6 Principales propositions de recherche

Proposition d'une méthodologie pour l'écoconception de SPS

Proposition d'un cadre conceptuel pour la conception intégrée produit-service

Une définition système

Une définition « système » a été proposée pour intégrer les approches produit et les approches service. Le système est défini par des propriétés qui existent et sont défini parce que le système interagit, et donc est lié à l'action comme illustré dans le modèle entité-relation présenté Figure 7. L'aptitude du système est la propriété sollicitée dans l'action. Une aptitude pour un produit peut être exprimée comme une fonction. Pour un service, une aptitude peut être une compétence ou un savoirfaire. Une limite du système est une interface du système dans l'action. Une limite a des dimensions spatiales et temporelles. Une limite spatiale sépare physiquement le système de son environnement. La dimension temporelle d'une limite évoque la dynamique de l'interface, comme celle d'un rôle délimité pour un acteur du service, qui n'a de sens qu'en considérant les évolutions possibles de ses interfaces dans des scénarios. Un SPS est donc défini comme un ensemble de composants (sous-systèmes) et leur organisation structurelle. Les composants peuvent être des produits physiques ou des unités de service. Un produit physique est objet tangible et une unité de service une entité structurée de l'organisation du fournisseur correspondant à un « département » dans une entreprise. Elle peut être composée de produits physiques et de sous-unités, équipes, etc... La définition des composants englobe les infrastructures, qui sont des composants définis pour de multiples usages (pas nécessairement ou exclusivement conçus pour le système considéré) et qui peut être préexistant. Elles peuvent être des produits (réseau électrique par exemple), ou des unités de services (département des ressources humaines, support de l'organisation du système). L'« organisation structurelle » du système correspond à l'organisation de ses sous-systèmes et de leurs interactions qui permettent au système d'interagir pour atteindre les objectifs de conception.

Un cadre conceptuel « système » pour la conception de SPS

Un cadre conceptuel de conception est proposé pour l'intégration produit-service. Il est représenté Figure 8.  Un espace des problèmes, appelé « résultat » (à atteindre), où doit être décidé l'organisation des actions.

Processus de décomposition

Relation de conception

Espace de l'Organisation structurelle

Espace des problèmes

Espace de solutions

Espace de négociations

Organisation des actions

Organisation des interactions

Organisation des systèmes

 Un espace des solutions, ou espace de « structure », correspondant au choix d'organisation des systèmes, sous-systèmes, etc., via l'identification et l'organisation de leurs limites (interfaces).  Un espace de négociation, celui de l'organisation structurelle du système, où s'organisent les sous-systèmes et leurs interactions.

Les espaces de problèmes et solutions sont co-évolutionnaires, puisque cette caractéristique a été identifiée en ingénierie de produit [START_REF] Dorst | Creativity in the Design Process: Co-Evolution of Problemsolution[END_REF]Cross 2001, Brissaud, Garro, and[START_REF] Brissaud | Design Process Rationale Capture and Support by Abstraction of Criteria[END_REF]. Ils existent donc simultanément, et les relations qui sont faites en conception entre problème et solution doivent être explicitées, ce sont les « relations de conception

Un modèle « multi-vues » pour la conception intégrée produit-service

Un modèle multi-vues est proposé pour la modélisation intégrée de SPS illustré en Figure 9. Le choix des modèles implémentés dans le cadre de conception a été effectué en considérant que les différentes dimensions à modéliser dans un SPS ne sont pas connues, mais qu'un modèle de SPS se devait de faciliter la communication et la négociation entre les acteurs concernés via l'utilisation d'outils propres à leurs domaines de compétences. Le cadre de modélisation proposé résulte donc principalement de l'implémentation, de l'intégration et de l'adaptation de deux types de méthodologies utilisées pour la modélisation de SPS :  La première correspond à celle proposée par [START_REF] Maussang | Product-Service System Design Methodology: From the PSS Architecture Design to the Products Specifications[END_REF] pour la modélisation du produit dans la SPS ;  La seconde à celle proposée par Partìcio et al. (2008Partìcio et al. ( , 2011) ) Un cycle de vie SPS correspond donc à un ensemble intégré de cycles de vie de produits et d'unités de service (voir Figure 11). Les interactions dans les actions du processus SPS correspondent aux sollicitations des aptitudes acquise en début de vie, et idéalement réutilisées en fin de vie.

Un outil de diagnostic

L'outil de diagnostic permet d'identifier les contributions majeures aux impacts environnementaux du SPS. Dans la thèse, la notion de « coût » est utilisée pour faire référence aux impacts environnementaux et les assimiler à des « coûts environnementaux ». Le principe de l'outil de diagnostic est illustré Figure 12. Le cycle de vie d'un SPS recouvre celui des produits et celui des services qui interagissent dans les actions du système. Le principe de l'outil consiste à allouer les impacts générés durant les cycles de vie des sous-systèmes aux actions du système en utilisant la matrice de conception, par le principe de la sollicitation des aptitudes dans les actions. Des matrices intermédiaires (appelées matrices de ressources) sont utilisées pour allouer les impacts générés au cours des début et fin de vie des sous-systèmes aux aptitudes de ces sous-systèmes.

Phase 1

Phase 2

Actions du processus SPS

Phase x

Entité externe Début de vie Fin de vie Il permet de négocier :  Les spécifications : par exemple, la modularité du compresseur. La matrice « facilité de démontage » peut avoir une contribution forte à l'impact environnemental. Doit-on choisir l'alternative d'une machine plus robuste ?  Les actions à réaliser / les sous-systèmes impliqués. L'action « se déplacer » peut avoir une contribution forte à l'impact. Doit-on envisager des opérations de maintenance à distance ?

INTERACTIONS

Soussystèmes

La négociation est ici basée sur la connaissance des contributions aux impacts des différents paramètres de conception sur lesquels les concepteurs peuvent agir. Figure 8 Representation of all the demands that must be addressed in product development [START_REF] Luttropp | Eco-Design in Early Product Development[END_REF] 12 A conceptual framework for value co-creation [START_REF] Payne | Managing the Co-Creation of Value[END_REF] ........... 80 Figure 13 The definition of service [START_REF] Hara | A CAD System for Service Innovation: Integrated Representation of Function, Service Activity, and Product Behaviour[END_REF]

Un outil de comparaison

Contributions et limites de la thèse

LIST OF TABLES

RC

Resource Cost

RM

Resource Matrix

S-DL

Service-Dominant Logic

SE

Service Engineering

SSN

Service System Navigation (model)

Sys. E System engineering

Chapter 1. Introduction

Research context and goal

Classical business economy is based on the sale of products. Business trades have historically consisted in value-in-exchange delivered when the supplier sales a product to its customer and transfers the product ownership. However, during the last decades, the increasing competition in the globalized economy and the resources rarefaction has led manufacturing companies in developed countries to re-orient their business towards integration of services in their product offers. With this change of paradigm in manufacturing companies, new ways of thinking business trades and of creating customers' value have emerged. The new focus is centred on final user's needs fulfilment by means of products and of services. The Product-Service System (PSS) concept has been used to refer to this new "marketable set of products and services capable of jointly fulfilling a user's need" [START_REF] Goedkoop | Product Services Systems, Ecological and Economic Basics[END_REF].

PSS have created a growing interest in several research streams because of their potential to maintain competitiveness but also to achieve sustainability. PSS changes the classical paradigm of mass production and consumption and could be beneficial for business profit, but also for people and planet. However, a large range of issues for switching towards PSS remain. There is a strong lack of support for designing PSS. The lack of design support makes difficult the environmental evaluation during design and the development of eco-efficient PSS.

This thesis aims at filling this gap by proposing a conceptual framework for integrated Product-Service Systems eco-design. This Chapter introduces the research topic and is organized in six parts. The emergence of PSS as an alternative for supporting sustainable development is introduced in section 1.2. Section 1.3 details the PSSs characteristics, their main "potentials" to achieve sustainability, and some iconic PSS cases. The main issues of PSS to clear the path towards ecoefficiency are provided in section 1.4. Section 1.5 discusses the initial gap identified from the topic exploration and formulates the initial Research Question to explain the orientation of research. Section 1.6 finally details the structure of this thesis.

1.2. Economic development and environmental pressure 1.2.1. Economic development in the mass production paradigm Industrial companies in developed countries are facing increasing challenges for maintaining their competitiveness in the actual economic and environmental contexts. The mass production paradigm historically guided the way industrial companies did business. The reduction of costs through mass production of goods for flooding markets was supposed to fulfil the needs of the largest possible number of people. However, this strategy has resulted in two phenomena. The first consequence is the delocalisation of production systems being more and more transferred toward countries with lowest labour costs. Manufacturing companies located in Europe and in the USA are now facing the necessity to carefully re-define their strategic positioning in the products' value chains to survive. Secondly, the resources rarefaction and the increasing pollution and waste generated by products lead to an environmental emergency for impacts reduction.

The necessity of Sustainable Development

The necessity to sustain the economic growth in a viable state in order to ensure the future of humankind has been defined by the United Nations in the the Bruntland report (1987). This reports defines sustainable development as the "development that meets the needs of today without compromising the ability of future generations to meet their own needs" [START_REF] Brundtland | Our Common Future[END_REF]. The sustainability concept has then evolved towards the Triple Bottom Line approach, or the necessity to create benefits for "People, Planet & Profit" [START_REF] Elkington | Cannibals with Forks: The Triple Bottom Line of 21st Century Business[END_REF]. Economic development is sustainable if conjoint efforts are made for ensuring social well-being and decreasing environmental impacts.

Industrial responsibility

The responsibility of the environmental load generated by products has been historically attributed to industrial companies. Environmental concerns initially emerged from accidental pollutions like the Seveso one in 1976. Considering the increasing amount of waste generated, end-of-pipes solutions like channels for revalorising products through recycling have been implemented.

In 1992, the Rio Summit initiated the concept of product "life cycle", considering that environmental load should be also affected to products generating the economic value. During the Summit, the World Business Council for Sustainable Development proposed to adopt an "eco-design" approach to support sustainable development.

Eco-design aims at integrating the environmental impacts generated over the product life cycle during design in order to decrease these impacts (H. [START_REF] Brezet | Ecodesign: A Promising Approach to Sustainable Porduction and Consumption[END_REF]. Eco-design requires considering all the phases of the product life cycle and their related impacts during design. Product life cycle encompasses the different steps of the product "life" from cradle to grave. These steps classically correspond to (ISO/TR 14062 2003):  Raw materials acquisition: material extraction, acquisition from recycling, forestry activities, etc.  Manufacturing: from initial materials processing to end product, packaging  Sale and delivery: from the manufacturing area to the product buying  Use / maintenance: from product acquisition to end-of-use or disposal  End-of-life: encompasses all the activities for waste operations, eliminating the products but also for energy valorisation, recycling and reuse. Eco-design of products generally consists in evaluation of the environmental impacts generated on existing or similar products to identify the main sources of these impacts within the life cycle and to implement improvement strategies. Eco-design is a powerful tool for integrating the environmental dimension in product design. However, some eco-designed products actually correspond to suboptimizations from an environmental perspective [START_REF] Hauschild | Design for Environment -Do We Get the Focus Right?[END_REF]. Moreover, in the mass production paradigm, the satisfaction of needs is still dependent of the volume of produced artefacts. The human needs' fulfilment requires consuming increasing amounts of resources and generating increasing pollution and waste. The resulting industrial strategies of this production-consumption pattern to generate revenues are based on accelerated technological changes and planned obsolescence of products to renew the cycles of buying behaviours. In order to drastically reduce the environmental impacts of modern societies, a new paradigm should be found.

PSS: emergence of a new paradigm

The PSS concept emerged in the late 1970s with the economists Stahel and Reday who emphasized the potential of substituting the resource intensive "industrial economy" with a "service economy" [START_REF] Stahel | Jobs for Tomorrow: The Potential for Substituting Manpower for Energy[END_REF]. This constituted the foundations of the idea of decoupling the consumption of materials and energy (and the related environmental impacts) from the economic growth, named "dematerialization". The convergence of the economic and environmental interests through the dematerialization strategy of PSS has resulted in a strong emphasis on its potential for achieving "sustainability". In line with Stahel and Reday, the "new service economy" is discussed as a new business model in which profitability is not based on material trade exchange but rather on the provision of "services" to meet essential human needs [START_REF] Jackson | Back to the Future. Reinventing the Service Economy[END_REF]. The evolution towards the replacement of goods by services is linked to the idea of reducing the environmental impacts. "For instance, telecommunication technologies, such as telephone, fax, e-mail, and video-conference, can replace physical transportation of people and goods. It is expected that more added value can be generated with less environmental impacts" [START_REF] Tomiyama | Service Engineering to Intensify Service Contents in Product Life Cycles[END_REF]. The Post Mass Production Paradigm [START_REF] Tomiyama | The Post-Mass Production Paradigm, Knowledge Intensive Engineering, and Soft Machine[END_REF] corresponds to a shift from quantitative sufficiency artefacts (of the mass production paradigm) to qualitative satisfaction. Instead of selling products, the object of sales becomes their "services", i.e. the benefit of its use or its functions. The term of "functional economy" is also used [START_REF] Stahel | The Functional Economy: Cultural & Organizational Change[END_REF]) to refer to this new unit of exchange. The "value-in-exchange" evolves towards "value-in-use". The viewpoint on value as embedded in physical artefacts moves towards a new definition considering that value is created through the interactions in systems, in which products are only a component amongst others [START_REF] Cogoy | Dematerialisation, Time Allocation, and the Service Economy[END_REF]) and their production constitutes only a limited and decreasing part of the total process of generating "value" (den Hertog, Bilderbeek, and Maltha 1997). Using the concept of "Sustainable Product-Service Systems", [START_REF] Roy | Sustainable Product-Service Systems[END_REF] considers that products should be seen as parts of global sustainable systems that provide a "service" or "function" to meet essential needs.

1.3. PSS: an evolution towards a sustainable society?

PSS definitions and characteristics

There is a very large area of PSS definitions and underlying concepts that can differ according to literature fields and authors. Some authors consider PSS essentially as a source of revenues and of a potential competitive advantage due to the strong focus on the customer's needs and the service relationship. But a wide range of definitions integrates the environmental considerations. Some of the most widespread PSS definitions have been summarized in Table 1.

Authors

PSS definitions [START_REF] Goedkoop | Product Services Systems, Ecological and Economic Basics[END_REF]) "A product service-system is a system of products, services, networks of players and supporting infrastructure that continuously strives to be competitive, satisfy customer needs and have lower environmental impact than traditional business models" (J. [START_REF] Brezet | The Design of Eco-Efficient Services[END_REF]) "Eco-efficient services are systems of products and services which are developed to cause a minimum environmental impact with a maximum added value" [START_REF] Mont | Clarifying the Concept of Product-service System[END_REF] "A system of products, services, supporting networks and infrastructure that is designed to be: competitive, satisfy customer needs and have a lower environmental impact than traditional business models". [START_REF] Manzini | A Strategic Design Approach to Develop Sustainable Product Service Systems: Examples Taken from the 'environmentally Friendly Innovation' Italian Prize[END_REF] "An innovation strategy, shifting the business focus from designing (and selling) physical products only, to designing (and selling) a system of products and services which are jointly capable of fulfilling specific client demands". [START_REF] Baines | State-ofthe-Art in Product-Service Systems[END_REF]) "A PSS is an integrated product and service offering that delivers value in use. A PSS offers the opportunity to decouple economic success from material consumption and hence reduce the environmental impact of economic activity". (Vezzoli, Kohtala, and Srinivasan 2014) Sustainable PSS: "an offer model providing an integrated mix of products and services that are together able to fulfil a particular customer demand (to deliver a 'unit of satisfaction'), based on innovative interactions between the stakeholders of the value production system (satisfaction system), where the economic and competitive interest of the providers continuously seeks environmentally and socio-ethically beneficial new solutions"

Table 1 Some PSS definitions in the literature Despite the absence of a common terminology, most of the existing definitions contain the key elements of a PSS defined by [START_REF] Goedkoop | Product Services Systems, Ecological and Economic Basics[END_REF]:  the product;  the service, in which an activity is performed without the need for a tangible good or without the need for the system; and  the combination of products, services, and their relationships. In the Mont's definition [START_REF] Mont | Clarifying the Concept of Product-service System[END_REF], PSS elements also include:

 Network of actors: all the socio-economic actors needed to produce and deliver the PSS, and the partnerships and interactions between those actors;

 Infrastructures: existing collective and private systems (such as roads, communication lines, waste collection systems, etc.). There are several typologies or classifications of PSS. The most widespread PSS typology is those proposed by [START_REF] Tukker | Eight Types of Product-service System: Eight Ways to Sustainability? Experiences from SusProNet[END_REF]) based on a continuum of products and service contents. The typology includes three main PSS types (shown in Figure 1):

 Product-oriented: products with addition of services; the customer can buy the product but an additional value is proposed through services (guarantees, after-sale, advice).  Use-oriented: the unit of transaction is the product use that is not owned by the customer. The examples of car / bike sharing and leasing are used.  Result-oriented: the unit of transaction is a result or a competency, for example a capability instead of the product. However, other PSS categories exist. The product ownership is often used as an additional characteristic in the product and service contents continuum.

Considering that the product ownership transfer has a major influence on the PSS potential for "ecoefficiency", [START_REF] Hockerts | Property Rights as a Predictor for the Eco-Efficiency of Product-Service Systems[END_REF] proposed a resulting categorization based on possible transfer mechanisms. For [START_REF] Gao | Service-Oriented Manufacturing: A New Product Pattern and Manufacturing Paradigm[END_REF], the positioning of the ownership influences the competitive advantage of a PSS. Park, Geum, and Lee (2012a) proposed integrating three dimensions for characterizing a PSS offer: product ownership (provider, customer); nature of integration (mixture / compound); and the role of technology (technology-free / technology involved).

1.3.2. Potential of PSS for sustainability 1.3.2.1. Economic and business benefits

1.3.2.

1.a. PSS: A business transition

Manufacturing companies increasingly integrate services in their product offers to improve their competitiveness. [START_REF] Vandermerwe | Servitization of Business: Adding Value by Adding Services[END_REF] named this evolution "servitization". This shift occurs by a progressive addition of services, then of support (from training to remote maintenance systems), of knowledge and self-services, with an integration of them in the offers.

From the viewpoint of [START_REF] Baines | State-ofthe-Art in Product-Service Systems[END_REF] and of Morelli (2003), the product identity in "servitization" switches from a material content to an integration of the material component and of the service system. This view is opposed to the "productization" as the evolution of the services to include a product or a new service marketed as a product. The PSS is defined as the convergence of these two trends towards integration of products and services initially separated, as shown in Figure 2. [START_REF] Baines | State-ofthe-Art in Product-Service Systems[END_REF] considered "various forms of servitization [that] can be positioned on a productservice continuum ranging from products with services as an "add-on", to services with tangible goods as an "add-on" and provided through a customer centric strategy to deliver desired outcomes for the customer".

Value mainly in product content

Value

Figure 2 Evolution of the Product-Service System Concept (reproduced from [START_REF] Baines | State-ofthe-Art in Product-Service Systems[END_REF]) The servitization of business results from several contextual drivers that encourage manufacturing companies to switch towards service offers in order to maintain their competitiveness.

1.3.2.1.b. PSS benefits for customers

Service allows the provider to create a privileged service relationship with its customer. Through the service relationship, the customers' needs can be efficiently understood and the offer adapted consequently. For the customer, a PSS is a source of value creation through more customisation and a higher quality. The customer is freed from some tasks and their related costs and problems like those associated to acquisition, use, maintenance and disposal of equipment and products (Vezzoli, Kohtala, and Srinivasan 2014). In B2B offers, the customer can concentrate on its core skills and competencies [START_REF] Meier | Industrial Product-Service Systems-IPS2[END_REF].

1.3.2.1.c. PSS strategic advantage for providers

The PSS benefits for companies mainly result from an improved strategic positioning (UNEP 2002). The local and cultural anchoring being of importance in the service relationship, PSS provides to any industries strategic advantage over low-costs manufacturing systems relocated in country with cheaper labour cost. The levers for improving strategic positioning through PSS adoption have been summarized by Vezzoli, Kohtala, and Srinivasan (2014) as:

 New market development: PSS providing added value compared to a product alone  Increased flexibility to respond more rapidly to the changing consumer market, due to new outsourcing relationships  Longer-term relationships which lead to stronger company/customer relationships and thereby customer retention  Improved corporate identity to respond to the demands for a company to be 'responsible and transparent', by showing its environmental and social benefits  Improved market and strategic positioning because of existing and future environmental legislative requirements or restrictions.

PSS eco-efficiency potential

The potential of PSS for sustainability achievement has been largely discussed in the literature (e.g. [START_REF] Roy | Sustainable Product-Service Systems[END_REF][START_REF] Maxwell | Developing Sustainable Products and Services[END_REF][START_REF] Manzini | A Strategic Design Approach to Develop Sustainable Product Service Systems: Examples Taken from the 'environmentally Friendly Innovation' Italian Prize[END_REF], McAloone and Andreasen 2004[START_REF] Tukker | Eight Types of Product-service System: Eight Ways to Sustainability? Experiences from SusProNet[END_REF][START_REF] Maxwell | Functional and Systems Aspects of the Sustainable Product and Service Development Approach for Industry[END_REF], Vezzoli, Kohtala, and Srinivasan 2014[START_REF] Cook | Fluid Transitions to More Sustainable Product Service Systems[END_REF]). 1. 3.2.2.a. An innovation potential PSS have been discussed as levers for changing radically the way to deliver value. The increasing possibilities offered by an integrated mix of products and services for needs' fulfilment generates new opportunities for companies and fosters innovations. The degree of freedom in designing and developing PSS by focusing on needs can lead to solutions maximizing the value for the customer while decreasing the environmental impacts [START_REF] Tukker | New Business for Old Europe. Product-Service Development as a Means to Enhance Competitivness and Eco-Efficiency[END_REF]. In the SusProNet project in which about 200 cases were studied, [START_REF] Tukker | Eight Types of Product-service System: Eight Ways to Sustainability? Experiences from SusProNet[END_REF] attempted to characterize the sustainability potential of PSS according to the typology he proposed. He studied the PSS potential for a "factor X" reduction of environmental impacts, X varying from 4 to 20. He concluded that PSS types having the highest potential for radically decreasing the environmental load are the "result-oriented" ones. A potential explanation is their highest innovation potential.

1.3.2.2.b. Life cycle extended responsibility

Products in PSS are considered as a "capital" to maintain since the economic value created for the producer is now aligned with the needs fulfilment. With the PSS new production-consumption pattern, the value creation is now dependent on the functions delivered by of products instead of on the products' sales. The product becomes a value carrier or a "capital" to maintain for both PSS customer and provider who have converging interests for products being robust and having a prolonged lifetime. Designing and manufacturing products that fit the customer's expectations at best while being intensively used and maintained becomes the provider's priority. Additionally, the non-transfer of ownership leads to an "extended producer responsibility". PSS providers are responsible for the environmental impacts generated over the products' life cycles. Strategies for designing products that could be better managed from an environmental viewpoint is facilitated and even compelled by keeping the ownership. PSS strategies of intervention on the products' life cycles can be summarized as follows [START_REF] Tukker | Eight Types of Product-service System: Eight Ways to Sustainability? Experiences from SusProNet[END_REF]Tischner 2006, Vezzoli, Kohtala, andSrinivasan 2014):

 Maximizing and optimizing the use of products: shared use, multiple use phases and upgrades, or a better use process facilitated by the addition of service (and for example ICT on products)  Managing its end-of-life: product reuse, upgrading, remanufacturing or recycling facilitated by the possibility to take back products and implement reverse logistics channels  Materials' life spans extension by a design that extents lifetime or facilitates materials recycling, valorisation, etc.  Minimisation of the resources used since they generate additional costs in PSS. By widening the scope of possibilities for implementing strategies reducing the products' life cycles impacts, PSS could be seen as powerful levers for eco-efficiency.

PSS social benefits

The social benefits of PSS can be considered from the viewpoints of customers, and more generally from a societal viewpoint as the creation of additional value. The strong focus put on the needs' fulfilment should drive PSS towards the improvement of human well-being. An analysis on the potential of PSS for social equity when adapting its principles to low-income contexts has been provided by Vezzoli, Kohtala, and Srinivasan (2014). Benefits of PSS for these contexts are not further developed here, since this thesis focuses on the environmental dimension of sustainability.

PSS iconic cases

1. 3.3.1.a. Xerox There are many PSS cases examples. Xerox is one of the PSS leaders. The Xerox's business model has shifted from the sale of copier to the "pay-per-copy" through a lease programme. The design of the copiers has been modified and large take-back and remanufacturing programs for parts reuse have been implemented. Through these processes, Xerox estimates an economy of $ 200 million through a remanufacture of 90% of equipment and reducing from 24 000 tons its waste volume [START_REF] Fishbein | Leasing: A Step Toward Producer Responsibility[END_REF] [START_REF] Bourg | Changer La Consommation Dans Le Sens Du Développement Durable : La Voie de L'économie de Fonctionnalité[END_REF].

1. 3.3.1.b. Electrolux Electrolux also proposed leasing of its washing machines. The customer should "pay-per-wash". Contrarily to laundry services, the customer accessed to the machine at home and repair and maintenance services were proposed. This PSS case faced some business model organizational issues and the service stopped [START_REF] Bourg | Changer La Consommation Dans Le Sens Du Développement Durable : La Voie de L'économie de Fonctionnalité[END_REF].

1. 3.3.1.c

. Bicycle sharing

The bicycle sharing service proposed in several cities is also a PSS case. The Velo'V service of the Lyon city (France) has been widely discussed by [START_REF] Maussang | Méthodologie de Conception Pour Les Systèmes Produits-Services[END_REF] in his thesis. This case is iconic because of all its specificities. First, products are pooled between several users who pay for using a bike between different stations. The PSS differs from a rental service in which the customer must take back the bike after use to the rental area. Due to the products pooling and self-services, the bikes design strongly differs from those of bikes for personal use. Products design does not only include the bikes, but also the bike terminals. Moreover, the PSS requires several infrastructures that can be pre-existing (ICT) or necessary to be designed (bike paths). The service implementation generally results from a local policy. The network of actors involved in the design, development and implementation and their relationship are not those of a classical offer linking a provider to its customer. Logistics and organizational issues of bikes availability and maintenance are important parameters of the PSS.

1. 3.3.1.d. Elis Elis proposes a clothing rental and cleaning service. A study was carried out during the Environment Round Table in 2008 in France [START_REF] Grenelle | Rapport Final Au Ministre d'Etat[END_REF] to evaluate the environmental benefits of this PSS. Instead of providing work wear individually to each of its employees, the client company outsources both the ownership of the clothes and their cleaning. Elis provides a service of "continuous clean clothes" to its customers. For this offer, the design of the working clothes consists in more robust synthetic material rather than the traditional cotton-wear of working clothes. The time of use is about twice as long with this material. Professional cleaning techniques including washing, drying and ironing have been specifically designed and optimized for the properties of these materials. Compared to a traditional sale of working clothes that would be used and washed individually, the Elis PSS reduces from about 50 % the energy consumption and of the CO2 emissions, and the water consumption is divided by 10 (according to the study of [START_REF] Grenelle | Rapport Final Au Ministre d'Etat[END_REF].

1. 3.3.1.e. Michelin Michelin has re-organized its business model for its truck tires. These tires were designed to reduce the fuel consumption of trucks from 5 to 11% but their costs were high. The transition towards a PSS offer allowed Michelin to propose to its customers paying "per kilometre travelled". The tires installation and balance is made by Michelin. Michelin guarantees a continuously adapted inflation pressure and advises the drivers for "eco-driving" (reducing the fuel consumption). The tires retreading and regrooving allow lifetime prolongation. For a customer using the Michelin's tires, the costs of fuel by kilometre travelled are decreased compared to a traditional sale [START_REF] Grenelle | Rapport Final Au Ministre d'Etat[END_REF].

1.4. Issues of designing sustainable PSS 1.4.1. PSS issues of eco-efficiency Despite several contributions that discuss the PSS "potential" for sustainability, the way this potential can be effectively achieved still lacks of support.

1. From an environmental viewpoint, the benefits of PSS are not systematic [START_REF] Tukker | Eight Types of Product-service System: Eight Ways to Sustainability? Experiences from SusProNet[END_REF]) (Vezzoli, Kohtala, and Srinivasan 2014). Some rebound effects can occur [START_REF] Tukker | New Business for Old Europe. Product-Service Development as a Means to Enhance Competitivness and Eco-Efficiency[END_REF] (Vezzoli, Kohtala, and Srinivasan 2014). Rebound effects correspond to behaviour or systemic responses to an action adopted for environmental impacts reduction by counterbalancing negatively the effects of this action. [START_REF] Vezzoli | New Design Challenges to Widely Implement 'Sustainable Product-Service Systems[END_REF] mentioned the impact of PSS on consumer behaviour using the example of leasing that, rather than ownership, could lead to "careless (less ecological) behaviours". Tukker argued that for product-oriented and use-oriented PSS, the environmental impacts reduction is often not significant. These PSS can even have higher impacts than products [START_REF] Tukker | Eight Types of Product-service System: Eight Ways to Sustainability? Experiences from SusProNet[END_REF]). As discussed by [START_REF] Vezzoli | New Design Challenges to Widely Implement 'Sustainable Product-Service Systems[END_REF], in models where products are borrowed and returned, transportation costs and associated impacts can be increased. Tukker considered that product-oriented and use-oriented PSS are not "by definition" more resourceefficient than business models based on product sales (Tukker 2015). He confirmed the necessity to switch towards more innovative approaches through result-oriented PSS for achieving substantial reduction.

1.4.1.1.b. A lack of quantitative studies

Very few quantitative studies have been provided in the PSS field to determine the effective reduction of impacts. Tukker's contribution [START_REF] Tukker | Eight Types of Product-service System: Eight Ways to Sustainability? Experiences from SusProNet[END_REF]) aimed at showing how PSS could reduce environmental impacts but used semi-quantitative methods. Some PSS cases have been studied by using quantitative evaluations for comparing with product sales in the Environmental conference Grenelle in France [START_REF] Grenelle | Rapport Final Au Ministre d'Etat[END_REF]). But most of PSS studies are qualitative and generic, and even where they show positive results, it is not clear how much can be earned quantitatively in environmental and economic terms [START_REF] Lindahl | Environmental and Economic Benefits of Integrated Product Service Offerings Quantified with Real Business Cases[END_REF]. The contribution of [START_REF] Lindahl | Environmental and Economic Benefits of Integrated Product Service Offerings Quantified with Real Business Cases[END_REF] is one of the rare quantitative studies that measured the economic and environmental PSS (named Integrated Product-Service Offerings -IPSO here) benefits compared with traditional product sale. Life Cycle Assessment (LCA) (ISO 14040-44 2006) and Life Cycle Costing (LCC) are used to compare existing PSS case with alternative scenarios including the traditional product sale. Their results showed that the PSS (IPSO) is preferable from an economic and environmental perspective in comparison with traditional product sales approaches for the three cases studied.

PSS design issues

The switch towards PSS raises many issues related to their design. Indeed, products and services should now be integrated in an offer instead of being separately considered.

1.4.2.1.a. An integrated design issue

The design and development of PSS is perceived by companies as highly challenging and misses support. PSS development correspond to innovation or "eco-innovation" strategies (Laperche and Picard 2013) implying organizational and structural changes at the company's level. The design of PSS is necessarily associated to business transition. As highlighted by [START_REF] Ceschin | Sustainable Product-Service Systems -Between Strategic Design and Transition Studies[END_REF], PSS design requires linking strategical approaches with transition studies. Some methodologies have been developed to support this business transition. The most widespread are the UNEP's Design for Sustainability manual [START_REF] Crul | Design for Sustainability -A Step by Step Approach[END_REF], the practical guide for companies developed by (Tukker and van Halen 2003), or the Methodology for Product Service Systems Innovation (MEPSS) [START_REF] Van Halen | Methodology for Product Service System Innovation. How to Implement Clean, Clever and Competitive Strategies in European Industries[END_REF]. These methodologies contain toolboxes and guidelines to support development of "innovation" at a strategic level within companies. However, beyond this conceptual phase, there are very few supports for the detailed or technical design of products and services in the PSS literature. This constitutes a strong barrier for effective PSS adoption in industrial companies [START_REF] Beuren | Product-Service Systems: A Literature Review on Integrated Products and Services[END_REF] (Vezzoli, Kohtala, and Srinivasan 2014).

PSS design is challenging because it integrates products and services that are currently designed by different teams having different cultures. The integration issue of products and services is often discussed in the PSS literature (e.g. [START_REF] Mcaloone | Boundary Conditions for a New Type of Design Task: Understanding Product/Service-Systems[END_REF][START_REF] Isaksson | Development of Product-Service Systems: Challenges and Opportunities for the Manufacturing Firm[END_REF][START_REF] Tan | Strategies for Designing and Developing Services for Manufacturing Firms[END_REF][START_REF] Baines | State-ofthe-Art in Product-Service Systems[END_REF][START_REF] Vasantha | A Review of Product-service Systems Design Methodologies[END_REF][START_REF] Tran | Development of Integrated Design Methodology for Various Types of Product -Service Systems[END_REF], but very few effective supports exist.

1.4.2.1.b. A barrier to eco-efficiency

The lack of support for PSS design does not favour their eco-design, i.e. the integration of an environmental consideration during design. The PSS methodologies supporting the strategic level of design generally integrate qualitative environmental evaluations that aim at guiding the process of concept selection. During this highly conceptual phase, qualitative considerations are probably the most adapted way to deal with the eco-design issues. Due to the lack of methodological support for PSS design at the more detailed levels, no efficient support exists for PSS eco-design. Quantitative environmental evaluations are largely missing in the PSS field [START_REF] Lindahl | Environmental and Economic Benefits of Integrated Product Service Offerings Quantified with Real Business Cases[END_REF] and most of them are made a posteriori of design. In order to allow PSS achieving the potential of eco-efficiency, methodological supports for PSS ecodesign should be developed.

1.5. Initial gap identified and research orientation 1.5.1. A need for supporting PSS design and eco-design After an initial literature review on PSS the following conclusions can be provided. Product-Service Systems correspond to an emerging trend stream in the industrial economy as well as to a new research field in the literature. PSS development has been initiated by a willingness of industrial companies to maintain their competitiveness in the developed countries. The replacement of products sale by integrated offers of products and services is claimed to allow the creation of additional value to beneficiaries as well as to the providing companies. Beyond the economic and strategic benefits expected from a switch towards PSS for industrial companies, their potential to decrease the environmental impacts while still fulfilling the needs has been largely discussed in the literature. However, the way environmental benefits can be achieved through PSS design is still an unsolved challenge. A literature gap can be clearly identified for PSS design. Additionally, the environmental dimension is only integrated during design through qualitative evaluations. Eco-design actually refers to "design" while a specific emphasis is put on the environmental dimension during design. The underlying assumption of this research is that the issues of PSS eco-design actually refer to those of "design" and particularly to the product-service integration issue.

Initial Research Question

For this reason, the initial Research Question is formulated as follows: RQ0: "What are the challenges of integrated PSS (eco-)design?" The literature has been explored to answer and to refine this initial question in the relevant fields considering the identified gaps and issues in the different disciplines dealing with PSS.

Orientation of action

The issue of achieving the full potential of PSS in eco-efficiency seems to be tied to the integration of products and services in PSS design. The area of "Product-Service System Design" has been taken literally as the basis for literature exploration, driven by the emphasis put for "integration". This exploration has been conducted in the fields of:

 PSS design and eco-design literature: existing methods and tools and integration of the environmental dimension  Product engineering literature: product engineering uses systematic methods and processes for product (and system) design and has an historical background in environmental impacts evaluation and integration during design (eco-design).  Chapter II provides the elements from the literature investigated to answer this question.  On the light of this in-depth literature exploration, some challenges of integrated PSS (eco-)design can be formulated to answer the initial Research Question. They are detailed in Chapter III. The research is clarified within the larger area of PSS integrated design challenges: its goal and scope are framed, and research assumptions are formulated. The initial Research Question is refined into four sub-questions. The research methodology followed for answering these questions is also detailed in this Chapter.  The refined analysis made and the different elements of the proposal built for answering the Research Questions are explicated in Chapter IV. These elements result in a methodological framework for integrated PSS eco-design.  Chapter V illustrates how the methodology can be applied on an industrial case. Interests of the approach and results provided are discussed.  Chapter VI concludes this thesis by detailing its main contributions and introducing some research perspectives.

Chapter 2. Literature review

This chapter provides an overview of the existing literature that has been explored in order to refine the research questions and as potential sources for methodological development. Dealing with the issues of PSS integrated design; the following areas have been identified as relevant and explored in the literature:  Part II: Product engineering: product design and development, integrated product design; and product eco-design;  Part III: Service design in the fields of marketing / business literature and Service Engineering.  Part IV: System approaches: system engineering, system thinking, and system methodologies applied to service design.  Part V: PSS design and PSS eco-design.  Part VI: PSS "design" complexity. A very schematic representation of the literature fields explored and of the interconnections existing between their contents is provided Figure 3. In each field of product, service or system engineering, some approaches or methodologies can be brought closer or further away to those from another field. These interconnections are further detailed in this chapter. The literature review supports the refinement of the research questions through the identification of their related challenges. This refinement is further discussed in the following chapter.

Stage-based and systematic approaches

During product development, the solution definition and the associated knowledge is a progressive process. The degree of freedom declines as design decisions are made and the costs of modifications increase as well. The product development process has then been organised into several stages to evaluate the feasibility and risks that are associated with a project and decision making. This reduces the associated costs while increasing the chances of success. During the 1980-90's many design theories and approaches have emerged to describe but also to prescribe and / or predict the design process tasks and outputs. The Systematic Approach has been developed in Germany after the World War II and proposes structuring the design process into several phases [START_REF] Hubka | Theory of Technical Systems[END_REF]Eder 1988, Pahl and[START_REF] Pahl | Engineering Design: A Systematic Approach[END_REF]. It results in the well-known VDI design directives [START_REF] Handbook | Systematic Approach to the Design of Technical Systems and Products[END_REF]. However, the increasing market competition and the lead-time pressure for new product development led industrial companies to accelerate the process by treating in parallel some tasks previously performed sequentially [START_REF] Solhenius | Concurrent Engineering[END_REF]). To manage the newly created relationships between stakeholders now working "concurrently" in parallel tasks, domain-based approaches have emerged proposing parallelism of the design worlds or domains.

Concurrent Engineering and domain-based approaches

In concurrent engineering, "domains" mainly aim at linking the design "problems" to an arrangement of physical artefacts composing the product called the "solutions". The domains-based approaches generally prescribe the relationships between domains. That allows starting with the goals or purpose up to the depiction of the solutions that represent the different "views" that a product should contain. Most of the domain-based approaches contain a "functional domain", while many definitions and viewpoints exist on functions [START_REF] Vermaas | The Coexistence of Engineering Meanings of Function: Four Responses and Their Methodological Implications[END_REF]. There are many models illustrating the links between the system "functions" and the system "structure" or "parts". These models generally refer to intermediary domains like in the Function Behaviour State model [START_REF] Umeda | Function, Behavior, and Structure[END_REF], or in the Function-Behaviour-Structure (FBS) model of [START_REF] Gero | A Knowledge Representation Schema for Design[END_REF]. All these models aimed at systematizing the design of the product through its representation of specific views that are shareable and easily understandable by product engineers. The domains are used to facilitate the translation of the initial design problem, i.e. the customer requirements, into a physical solution.

Design for X

Realizing that an increasing number of actors should be implied in the design of the product life cycle (named stakeholders); the integration of their requirements in addition to those of the customer as soon as possible during the design process has become a major concern for engineering design. The integration challenge has been progressively extended over the years: it initially started with manufacturing considerations to be extended towards a life cycle perspective. The DfX methodologies express this evolution. "Design for X" (DfX) correspond to a set of methodologies aiming at integrating the stakeholders' requirements or constraints of specific product life cycle phases into the product development process. The pioneering work of [START_REF] Boothroyd | Product Design for Assembly[END_REF] on Design for Assembly (DFA has evolved towards integration of all the constraints and requirements for the entire product life cycle: the DfX methodologies have emerged. The product characteristics are designed according to DfX 'criteria', where the 'X' represents a specific requirement for a product life phase. DfX guidelines to be integrated at the early stage of product development and integrating the all life cycle phases have been proposed by [START_REF] Meerkamm | Design for X -A Core Area of Design Methodology[END_REF]. The problem in adopting different DfX criteria is the rapidly growing complexity of the design process. Some classifications and hierarchy have then been proposed to organize the guidelines and related criteria according to a specific product life cycle and the company's priorities. However, the disadvantage of design guidelines and checklists is that they may appear too generic, making it difficult to identify aspects relevant to the current design [START_REF] Meerkamm | Design for X[END_REF].

2.1.1.1.b. Co-evolutionary models: problem-solution approach

The domain-based approaches have different orientations that can vary along a prescriptive / descriptive approach of the design process, but all of them attempt to propose a support that should fit the designers' way of thinking. The non-linearity of the design process and the decoupling between the process phases over time resulted in the implementation of iterations within design models [START_REF] Roozenburg | Defining Synthesis: On the Senses and the Logic of Design Synthesis[END_REF]. The domainbased approaches offered an alternative for expressing the non-linearity of the design process by providing different views at different levels of details at the same time. However, the domain-based approaches have also limitations. The main critic to the systematic approaches was that it stated that the design problem could be initially known, expressed and decompose into independent sub-problems [START_REF] Lonchampt | Supporting Problem Expression within a Co-Evolutionary Design Framework[END_REF]. A similar critic has been applied to domain-based approaches because they could not reflect on the cognitive science results that the domains are not considered successively but simultaneously by [START_REF] Lonchampt | Supporting Problem Expression within a Co-Evolutionary Design Framework[END_REF]. The co-evolutionary models are based on the notion of co-existence and co-evolution of two domains during design: one for problem expression and the other for solution definition. Several authors have then proposed co-evolutionary models (see for example Figure 4) in which the problem-space and the solution-space co-exist and are refined simultaneously [START_REF] Dorst | Creativity in the Design Process: Co-Evolution of Problemsolution[END_REF]Cross 2001, Brissaud, Garro, and[START_REF] Brissaud | Design Process Rationale Capture and Support by Abstraction of Criteria[END_REF]. [START_REF] Lonchampt | Supporting Problem Expression within a Co-Evolutionary Design Framework[END_REF] proposed the definition of four design activities that represent the zigzags between problem expression and solution definition: Conjecture, Definition, Evaluation and Reformulation.

Figure 4 Co-evolution of problem-solution as observed in the study conducted by [START_REF] Dorst | Creativity in the Design Process: Co-Evolution of Problemsolution[END_REF] 2.1.1.2. Product and process view for integrated design

2.1.1.2.a. Product-process integration

Integrated (product) design discussions started with the emergence of concurrent engineering and the necessity to couple mechanical approach of product design (facilitated by the development of tools such CAD systems) with the constraints and requirements of manufacturing. The need for integrating the entire life cycle requirements and the related stakeholders emerged.

In the field of integrated (product) design, [START_REF] Tichkiewitch | Co-Ordination Between Product and Process Definitions in a Concurrent Engineering Environment[END_REF] consider the integration challenge from the stakeholders' point of view. Integration is seen as comprising three main levels:  Their communication: that requires the exchange of product data  Their co-ordination: that requires an integrated design process  Their full co-operation: that is achieved through a good management of the two first levels. To support information exchange between stakeholders, a product should be modelled under different viewpoints. The product model then links the knowledge model and the data model by accommodating the stakeholders' decisions [START_REF] Tichkiewitch | Methodology and Product Model for Integrated Design Using a Multiview System[END_REF] and has to be "multi-views, multi-users and multi-places" to integrate all the life cycle phases [START_REF] Brissaud | Design Process Rationale Capture and Support by Abstraction of Criteria[END_REF]Poveda 2003 after Tichkiewitch and[START_REF] Tichkiewitch | Methodology and Product Model for Integrated Design Using a Multiview System[END_REF]). The stakeholders' co-ordination can be ensured through two complementary approaches [START_REF] Tichkiewitch | Co-Ordination Between Product and Process Definitions in a Concurrent Engineering Environment[END_REF]:

 An activity-based approach, which consists in modelling the design activities and their interactions. The design process is the management of parallelism for activities' concurrency and the integration of all the constraints related to product life cycle in the earliest design phases.  A professional-based approach, which is a process based on negotiations for decision-making supported by the use of intermediary objects [START_REF] Boujut | Intermediary Objects as a Means to Foster Co-Operation in Engineering Design[END_REF].

2.1.1.2.b. Product design, product development and project management

As previously discussed, integrated product design aims at integrating product design with product development process. Indeed, starting from the need to couple product design with other constraints like manufacturing ones, integrated design and concurrent engineering required that the stakeholders co-ordinate their tasks [START_REF] Tichkiewitch | Co-Ordination Between Product and Process Definitions in a Concurrent Engineering Environment[END_REF]. This co-ordination requires picturing the product development process integrated with the product definition. This is why many models for product design also prescribe the stages order of the "product development" process. Product development and project management are then hardly separable from "product design". [START_REF] Andreasen | Integrated Product Development[END_REF] for example, emphasized the necessity to broaden the scope to other activities beyond engineering. They propose an Integrated Product Development (IPD) model that aligned the product development perspective with market / business / production ones (see Figure 5). IPD is characterized by a concurrent design approach in which multidisciplinary teams cooperate during activities both vertically and horizontally in the organization. Then, to reach the benefits of integration, IPD require that, at the early stages of the project, the objectives of the development project are complete and well defined first and then that customers' needs and demands are identified (A. R. [START_REF] Tan | What Happens to Integrated Product Development Models with Product/service-System Approaches[END_REF].

Figure 5 Integrated Product Development, an ideal design model showing integration of market and production activities for creating new business [START_REF] Andreasen | Integrated Product Development[END_REF] The main aspects that are generally underlined in product development approaches are:  The organization of the design phases through a process that organizes and plans tasks (stagegate models)  The integration of all the requirements and constraints of the involved stakeholders during development  The iterative cycles made through the process of verification and validation (activity-based models).

The first aspect is like the organization of the development tasks in the IPD [START_REF] Andreasen | Integrated Product Development[END_REF]. Additional information on product development planning can be found in the literature review provided by [START_REF] O'donovan | Design Planning and Modelling[END_REF]. The integration of the stakeholders' requirements during design is the specific focus of the DfX methodologies. The iterative cycles of the design process is the focus of the following section.

2.1.1.2.c. Design process: an iterative and cyclic approach

Design iterations and validations occur during product design and development to ensure to support a shared understanding by the stakeholders and to support negotiations and discussions during the decision-making process. These loops are what differentiate activity based model form stage-gate models. These models are complementary and have to be integrated to support decision-making.

The iterative characteristic of design has been previously discussed: feedback loops are inevitable during design and that is why many stage-gate models of design process have been criticized. The iterations are necessary since the development process needs to guarantee that the solutions proposed fulfil the requirements. The models of product development process have then integrated the concept of alignment of the solution development along the refinement of the problem formulation.

The Waterfall model is one example of such models. It is composed of three evaluation processes, namely [START_REF] Wynn | Models of Designing[END_REF]:  verification, which establishes whether the device design described in the design output conforms to the requirements described by the design input;  validation, which establishes whether the device, produced in accordance to the design output, actually satisfies the users' needs;  review, an activity undertaken regularly to ensure that good practice is followed at all times.

Summary: integrated product design

Product engineering proposes a large scope of theories, methodologies and models for supporting the systematized design and development of products. The required integration of disciplines and competencies has led to progressively encompass more and more perspectives within the design scope: from the product perceived as a form to the product as the support for fulfilling several stakeholders' requirements, from the geometric and assembly constraints to the product life cycle, and from the design as a sequence of decision to an integrated product-process development. To summary, the product engineering literature dealing with integrated product design provides the following elements (that are reused for this research):

 Engineering design consists in ensuring progression between the problem, i.e. the needs to fulfil defining the requirements, and the solution, i.e. the physical product.  An integrated design process should ideally involve all the stakeholders concerned by the product life cycle and integrate their respective requirements and constraints.  To couple the stakeholders' views and ensure consistency of the design considering the entire product life cycle, integrated product design should contain: o An integrated design model that should be "mutli-views", multi-users and multi-places: to support their communication o An integrated design process that should support activities schedule and negotiations through iterative loops: to support their co-ordination o An efficient management of the two inter-related integrated design model and process: to support their cooperation  Two different "views" classically used in product design models are reflected in "domains" that support integrated descriptions and decomposition of problem and solution specific characteristics.  However, the problem-solution progression should be considered as co-evolutionary, and "domains" of design models should be considered simultaneously in models.

However, many challenges remain in the field of product engineering to integrate all these aspects within the design and development process. The integration of all the stakeholders' requirements over the product life cycle is still challenging but would be facilitated by adopting different "views" through domain-based approaches, as a communication channel. The full integration of these views should be supported by an integration of the product being developed and its development process. This integration also requires understanding and capturing the design ways of thinking of the different stakeholders in order to organize the progression from the problem to the solution. However, problem and solution are considered as co-evolutionary during design. Integrating the product characteristics descriptions in models adapted to each stakeholder's "view" while supporting its related design thinking and progression in an organized set of activities (integrated design process) is still highly challenging.

Product eco-design

The necessity of different stakeholders' perspectives integration during design has been broadened to the entire product life cycle. Similarities between the challenges of integrating several DfX methodologies and the environmental considerations have emerged.

From product integrated design to product eco-design

Starting from a need to integrate several perspectives on manufacturing constraints, DfX methodologies have evolved towards the integration of the entire life cycle to enable stakeholders to communicate and co-operate. Since a "product model" should be linked to relevant information about the stakeholders' requirements and constraints and cover the entire product life cycle [START_REF] Tichkiewitch | Co-Ordination Between Product and Process Definitions in a Concurrent Engineering Environment[END_REF], it should integrate a set of DfX methods over the life cycle. However, DfX guidelines are not independent from one another, as the design propositions within the different DfX guidelines can address the same product characteristics [START_REF] Hepperle | Design for X-Guidelines and Lifecycle Phases with Relevance for Product Planning-a MDM-Based Approach[END_REF]. Due to the complexity of this task, a few authors propose supports to manage DfX integration over the life cycle. [START_REF] Hepperle | Design for X-Guidelines and Lifecycle Phases with Relevance for Product Planning-a MDM-Based Approach[END_REF] proposed a generic procedure to process information that supports a better understanding of which lifecycle phases and which DfX-guidelines play a central role and how to organize product planning accordingly.

A contribution from [START_REF] Andreasen | Basic Thinking Patterns and Working Methods for Multiple DFX[END_REF] established that a method for handling multiple DfX methods should integrate several relations:  First, DfX is a relation between a design and a life phase  Second, ∑DfX needs to fit the product to its life cycle  Third, ∑DfX has to depict the relation between a product and its life cycle at four levels: strategical/tactical level; product level; structural level and parts level. [START_REF] Olesen | Concurrent Development in Manufacturing[END_REF] has developed a life cycle approach for product design that integrates these aspects through a "score model" (see Figure 6

below).

Figure 6 The score model as part of Olesen's product life approach [START_REF] Andreasen | 45 Years with Design Methodology[END_REF]after Olesen 1992) Eco-design or Design for Environment (DfE) methods and tools attempt to integrate environmental considerations to the design process. The DfE term refers to the addition of an X criterion on the environmental impacts generated throughout the product life cycle. DfE can then be seen as the integration of several DfX throughout product life cycle considering several stakeholders' perspectives that should be integrated. A guideline for practical DfE has been developed by [START_REF] Olesen | Design for Environment[END_REF] based on the "meeting" concept. "Meetings" correspond to the relations between a product, a stakeholder and a product life phase system. Understanding the "meetings" allows considering the causes of environmental effects and finding potential mechanisms to reduce them. One of the strengths of this method is its capacity to fit into and balance against already established procedural and organisational aspects (Andreasen 2011).

Eco-design principles

Design for Environment (DfE) and eco-design are assimilated. They both consider five main interrelated principles [START_REF] Mathieux | Ecodesign in the European Electr(on)ics Industry -An Analysis of the Current Practices Based on Cases Studies[END_REF]): Life cycle thinking; Tools and methods; Ecodesign process; Ecodesign strategies; Dialogue and partnership.

There are several manners to consider the product life cycle to integrate it during design. [START_REF] Zwolinski | Designing Products That Are Never Discarded[END_REF] considered three adoption perspectives for product life cycle: an enterprise level, a team level and an expert level. The enterprise level is reflected through the marketing-oriented consideration for the life cycle and used for strategic approaches. Its follows the phases of a S-shaped curve, also used for depicting maturity levels of technologies: introduction, expansion, maturity, saturation and decline. The team level is supported by a shared functional analysis perspective on the life cycle, and is functionality-based and mutual to all the design stakeholders. And the expert level is provided through LCA and LCC performed by the corresponding experts.

2.1.2.3. Eco-design methods and tools

2.1.2.3.a. Life cycle assessment (LCA)

LCA standard Existing quantitative evaluation techniques are mainly based on Life Cycle Assessment (LCA) (ISO 14040-44 2006). LCA is defined in the ISO standard as the "compilation and evaluation of the inputs, outputs and the potential environmental impacts of a product system throughout its life cycle".

LCA is a standardized method used to quantify the environmental impacts generated during the life cycle of "systems" from cradle to grave. LCA requires defining one or more "reference flow(s)" that express the life cycle of the system considered.

LCA is a four-phase process. The goal and scope definition includes the selection of a "functional unit" that measures the product utility and is the reference for impacts' calculation or systems comparison. The inventory is the collection of data on energy material and emissions flows as a result of direct and indirect interactions of the system with its environment. The impact assessment allows classifying, characterizing and evaluating the environmental impacts that are generated throughout the life cycle. The interpretation is a transversal phase that ensures the relevance of the scope, framework, data, hypothesis and methods used during LCA. This is the main interface between the modeller and the users of the model.

Suitability of LCA method to product design

The classical barriers for using LCA during design are: the contradiction between a design and an assessment approaches and a lack of relevant environmental information available to decision-makers. LCA is not design-oriented [START_REF] Ramani | Integrated Sustainable Life Cycle Design: A Review[END_REF]). However, in the early discussions about the use of LCA as a design support, [START_REF] Keoleian | The Application of Life Cycle Assessment to Design[END_REF] argued that LCA has several types of application that should be adapted to the design process stage considered. But later, [START_REF] Millet | Does the Potential of the Use of LCA Match the Design Team Needs?[END_REF]) have discussed the inability of LCA to support design. Indeed, LCA utility is limited to the analysis of existing products and to the detailed stages of design. It is also useless for creating a dynamic learning process and can even restrict the capacity for innovation within the company.

In the field of building and housing sector, equivalent discussions exist. They consider the difficulty to couple an Integrated Design Process (IDP) to LCA due to the core nature of the design process and of the LCA tool. [START_REF] Cucuzzella | Expanding the Evaluation Framework in Design Projects When Seeking Transformational Sustainable Innovation[END_REF] argued that LCA adopts a problem-solving approach which requires the definition of the problem and the setting-up of boundaries at the beginning of the project. This difference results in a focus related to the product rather than on a more global perspective on needs and contexts. The positivist approach of LCA is opposed to the constructivist one of design. LCA is a diagnosis tool and design is an heuristic process. Authors conclude that the interactions among the design elements in the design problem are difficult to grasp in LCA approach due to a separation of the expertise fields in analytical tools. The design teams do not assimilate the concerns of the environmental impacts into a common and shared understanding of the design problem. They recommend a more complex vision and systemic approach for understanding the design problem. A similar analysis has been provided by [START_REF] Baumann | Mapping the Green Product Development Field: Engineering, Policy and Business Perspectives[END_REF] who also asked for a systemic approach when considering the environmental dimension and the product development process.

Suitability of the evaluation reference for design: "functional unit" concept

The Functional Unit (FU) is used as a reference in the evaluation and comparison of systems impacts. FU is defined in ISO 14044 as "the quantified performance of a product system for use as a reference unit" (ISO 14044 2006).

The suitability of the "functional unit" concept for performing evaluation of systems has been criticised. FU has been defined as a way to scale the life cycle of the products to units that are comparable for mainly ethical reasons: it will only be "fair" to compare products that perform a similar function (Collado-Ruiz and Ostad-Ahmad-Ghorabi 2010b). However, several factors are not taken into account when using FU for comparison. For example, the reason why a user uses one product instead of another or the constraints added by designers to one of the product are often not reflected in the FU (Collado-Ruiz and Ostad-Ahmad-Ghorabi 2010a; 2010b). The problem when using functional unit is the equivalency made between the needs' fulfilment and the functions provided. [START_REF] Cucuzzella | Expanding the Evaluation Framework in Design Projects When Seeking Transformational Sustainable Innovation[END_REF] underline that the social debates that are inherent to the design problem are undetected in LCA because the "functional unit has embedded in its definition the expected social benefits of the object". Most of the tools in the field of DfE aims at decreasing the environmental impacts while considering unchanged functions [START_REF] Lagerstedt | Functional and Environmental Factors in Early Phases of Product Development-Eco Functional Matrix[END_REF]) whereas re-design activity influences the product performance or the way it can be used. The FU description does not consider functional priorities and customeroriented issues that are the main drivers of design [START_REF] Lagerstedt | Functional Priorities in LCA and Design for Environment[END_REF].

To deal with such issues, several tools built on design ones are presented in the following section.

They have been developed in an attempt to widen the perspective of evaluation towards design concerns on customer satisfaction.

2.1.2.3.b. Design-oriented methods

Most of the existing eco-design tools are based on checklists or guidelines like the DfX tools with a qualitative impacts evaluation. [START_REF] Ramani | Integrated Sustainable Life Cycle Design: A Review[END_REF] proposed an exhaustive review of the literature that deals with eco-design / DfE tools and their specific focus on life cycle.. However, several contributions have proposed to provide a better support to the design process by integrating the environmental dimension as an additional dimension within existing tools.

A balance has to be found between needs' fulfilment and environmental impacts generated and this balance is made based on the object shared during design: the product. Several approaches have attempted to do so by integrating environmental evaluation into design tools in order to highlight the multi-criteria perspective of the design process.

Some methodologies for example are based on Quality Function Deployment (QFD) techniques and generally allow balancing customer requirements with environmental ones based on product specifications or components. [START_REF] Lagerstedt | Functional and Environmental Factors in Early Phases of Product Development-Eco Functional Matrix[END_REF] proposed to use an "eco functional matrix", based on two dimensions: functional profile [START_REF] Lagerstedt | Functional Priorities in LCA and Design for Environment[END_REF] and environmental profile. It balanced functional requirements with environmental impacts, presenting both advantages and disadvantages of the product. The basic idea is to account for user and societal preferences as well as environmental impact when assessing alternative product concepts at early design stages. The Value Analysis-based techniques are also a good support for balancing multiple evaluation criteria. The Eco-Value Analysis (Eco-VA) [START_REF] Oberender | The Eco-Value Analysis. An Approach to Assigning Environmental Impacts and Costs to Customers' Demands[END_REF] has been proposed to balance the functions' importance for the customer with environmental impacts generate throughout the product life cycle as well as with the economic costs for production.

Bovea and Pérez-Belis ( 2012) provided a literature review on the eco-design tools and methods that allow integrating the "environmental requirements" into the design process.  And other methodologies that are more related to process planning or innovation methods Some methodologies use a set of tools for providing a better support for design as well as for evaluation during design, like the "QFD-centred design methodology" proposed by [START_REF] Sakao | A QFD-Centred Design Methodology for Environmentally Conscious Product Design[END_REF]. It starts with the use of LCA to establish an environmental profile and then uses QFDE (QFD for Environment), that allows integrating the Voice of the Environment VOE in addition to the Voice of the Customer VOC) and TRIZ to design eco-efficient products.

2.1.2.3.c. Product Life Management (PLM) tools

To deal with the complexity of sharing a product model that allows the different stakeholders' viewpoints to be expressed, Product Life Management (PLM) tools have been developed. PLM aims at managing product data from its definition to its maintenance, while considering manufacturing aspects and attempts to create interfaces between the existing computer-based tools dealing with these product aspects. They were developed by the same actors that have developed computer-aided design and manufacturing tools. This is why not all aspect of the product life cycle are covered by PLM, particularly the environmental dimension and the end-of-life of products [START_REF] Zwolinski | Designing Products That Are Never Discarded[END_REF]. The need for interfacing the classical tools of the design process with those of eco-design (among the related software such as CAD, PLM, and LCA) has been raised by [START_REF] Rio | A Framework for Eco-Design: An Interface between LCA and Design Process[END_REF]. Authors emphasize on the necessity to link the local design activities based on specific requirements and objectives (horizontal information flow supporting concurrent and integrated design) with the global assessment of the design solution considering the entire product life cycle (vertical information flow following the LCA concept) (see Figure 7). Going further in their analysis for the development of such an interface, the same authors have later identified several issues for the collaboration of product designers with environmental experts (Rio, Reyes, and Roucoules 2013): the difficulty to align environmental parameters with current parameters used in the multi-domain activities of the design process, the variability of eco-design contexts, and the technical limits existing in current Information Systems. Authors then proposed an interoperability method for existing and future tools that allows linking DfX and eco-design approaches.

However, if an increasing interest is raised by the offered possibilities of integrating PLM tools with LCA, the issues of this integration still remain. Concurrently with the issue of tools integration, the issue of "views" integration occurs. Classical PLM tools are currently used to support management of business activities rather than for tracing the product life cycle. Activities managed by external stakeholders of a company are generally not included and the end-of-life of products not dealt.

Increasing efforts are provided to solve these issues, but existing practices do not support efficient product life cycle management in the meaning of its environmental impacts.

2.1.2.4. Eco-design implementation: a challenge

2.1.2.4.a. Challenges of methods and tools implementation

Hauschild, Jeswiet, and Alting ( 2004) argued that products resulting from DfE often are "suboptimizations from an environmental perspective" because the tools have characterized the process and not the other way around. [START_REF] Baumann | Mapping the Green Product Development Field: Engineering, Policy and Business Perspectives[END_REF] stated that there are too many tools developed but that their effective implementation is neglected, and that normative suggestions are rarely tested. The real challenge for an eco-design method is to ensure the effective and efficient use of environmental information during design (Boks 2006).

Studying effective use and the reasons for DfE methods and tools adoption within companies, [START_REF] Lindahl | Integrated Product and Service Engineering -the IPSE Project[END_REF] proposed a list of requirements for DfE tools that effectively support the design task. He noticed that tease of utilization, understanding of the underlying principles and a short training time were crucial factors for tool efficiency.

2.1.2.4.b. A design challenge

Lindahl 2005) showed that one of the problems in several DfE methods and tools is that they only focus on a single objective of reducing the environmental impacts. The need for multi-criteria analysis that consider other dimensions is crucial (Bovea and Pérez-Belis 2012) [START_REF] Ramani | Integrated Sustainable Life Cycle Design: A Review[END_REF]. Environment has to be integrated during the design process, and tools supporting this integration have to comply with it.

The set of design criteria that have to be taken into account during design have been represented by [START_REF] Luttropp | Eco-Design in Early Product Development[END_REF] (see Figure 8) by a pie chart, where every piece of the pie represents an important design aspect. The "environmental" one is not bigger than the others but an additional criterion among others.

Figure 8 Representation of all the demands that must be addressed in product development [START_REF] Luttropp | Eco-Design in Early Product Development[END_REF] 2.1.2.5. Challenges of product eco-design: an integration issue

2.1.2.5.a. Coupling integrated product design and eco-design

The integration of eco-design / DfE tools in the product development process seems to be critical. Several authors have raised this issue [START_REF] Baumann | Mapping the Green Product Development Field: Engineering, Policy and Business Perspectives[END_REF]) [START_REF] Ammenberg | Products in Environmental Management Systems: Drivers, Barriers and Experiences[END_REF] and shown that DfE methods and tools are used separately from the rest of the product development.

Several contributions have been proposed to integrate environmental evaluation in design tools and provide a more adequate support. These propositions integrate more or less the challenges of design but in practice, the effective use of tools is still critical.

Design for Environment can be seen as an additional set of criteria to take into account during product design like DfX methodologies. However, DfE specificity is that it should not be decoupled from other DfX since DfE requires a life cycle perspective. DfE is then by nature dependent on an integrated design process. This should lead to the integration of requirements and constraints of the stakeholders considering the entire life cycle [START_REF] Brissaud | Design Process Rationale Capture and Support by Abstraction of Criteria[END_REF]. However, the integration of all the stakeholders' constraints and needs during the design process increases the complexity of managing the overall process. The question is how all the stakeholders' tasks of the design process should be integrated efficiently. As underlined by [START_REF] Zwolinski | Designing Products That Are Never Discarded[END_REF], designers' teams have increased over the last few years due to the integration of experts from different disciplines but cannot continue to grow without risking being less efficient.

The methods for prioritization of DfX methods according to "hot spots" identified in a preliminary evaluation like the proposal made by Hauschild, Jeswiet, and Alting ( 2004) (see the previous section) have been criticized by [START_REF] Zwolinski | Designing Products That Are Never Discarded[END_REF]. They argue that product life cycle scenarios have to be built and selected according to all the associated life cycle data rather than through the establishment of priorities between life cycle phases that would then focus the design effort on specific stages without regarding other impacts.

The difficulty for integrating the DfE / DfX guidelines and tools during the design process has been discussed by [START_REF] Alhomsi | The Use of DfE Rules during the Conceptual Design Phase of a Product to Give a Quantitative Environmental Evaluation to Designers[END_REF]. They propose defining DfE rules to support the conceptual design phase. The rules are later translated into factors used for evaluation of the rules fulfilment based on a functional representation of the product. However, if this contribution supports the progressive integration of the environmental dimension during design, it still lacks recommendations for the integration of stakeholders' requirements and constraints during an integrated design process.

2.1. 2.5.b. Stakeholders' communication Boks (2006) studied the "soft side of ecodesign". It represents the "social, psychological and sometimes intangible processes that can 'make or break' eco-design implementation". His conclusion is that the most challenging issues for implementation of eco-design within companies are the dissemination of information across stakeholders. He added other factors that can restrain the integration of stakeholders' tasks like the unwillingness to cooperate, gaps between eco-design proponents and executors, and organisational complexities.

He strongly emphasized on the necessity to consider the "soft side" of working organizations in the product development process for developing eco-design tools. He recommended involving psychologists and business organisation specialists because their role is more important than the role of conventional eco-design researchers.

He disagreed with [START_REF] Keoleian | The Application of Life Cycle Assessment to Design[END_REF] by arguing that "one can suppose that currently, there is already enough information about how to do eco-design, it is just pertinent to make it readily available to the right people, and to make sure they know how to use it" (Boks 2006after Boks 2003). He concluded on the necessity to primarily develop tools supporting the stakeholders' communication and on the major role of understanding and over-stressing the mechanisms of communication, language and personal views and objectives in design activities.

His analysis is aligned with issues raised by integrated product design, independently of the environmental dimension.

2.1.2.6. Summary: product eco-design

Eco-design corresponds to a design task in which the environmental impacts must be considered.

The quantitative evaluation of environmental impacts requires the use of LCA. However, LCA is a diagnosis tool. For this reason, most of the approaches in eco-design attempt to couple the evaluation process of LCA in the design process by developing tools:  Based on those of design like QFD  Based on computer support like PLM (however, these approaches are only emerging)  Based on evaluation tools of design, like Value Analysis. However, several issues for implementation remain, mainly due to the difficulties related to integrated product design. Additionally, the Functional Unit reference of LCA does not efficiently deal with the user's needs fulfilment. The main issue raised by product eco-design is the difficulty to overcome the challenges of integrated product design while coupling it with quantitative environmental evaluation over a product life cycle.

Issues of integrated product eco-design 2.1.3.1. Summary of the existing issues

Product engineering literature dealing with the issues of integrated product design and of eco-design provides some elements detailed in this section, and reused for building the proposal. The main challenges identified are the following:

 Integrated product design is challenging and many issues remain to support the stakeholders' communication, coordination and cooperation.  The issues of product eco-design are generally linked to those of integrated product design, except that it requires performing environmental evaluation during design.  LCA is the only tool for quantitative environmental evaluations. However, LCA contains some limitations that require adapting its use to the design process.  The integrated design and LCA approaches are challenging by themselves and should additionally be integrated to support an efficient product eco-design process. The issue of product eco-design corresponds to:

 An issue of integrated product design involving all the stakeholders of the product life cycle  An issue of managing continuous quantitative environmental evaluations during design

Conclusion: a necessity to support integrated life cycle design

In other terms, efficient product eco-design requires an integrated PSS life cycle design that integrates continuous environmental evaluation loops.

To deal with such integration issues, it should be necessary to:  Integrate environmental evaluations within the other negotiations of an integrated design process supported by iterative loops  Consider the environmental expert as a "transversal" approach during design playing the role of diffusion and dissemination of the "Voice of the Environment". Indeed, the difference between integrated product design and DfE consists in the distinction that should be made between the environmental expert and the design teams (assimilated to product experts) like in classification of life cycle stakeholders made by [START_REF] Zwolinski | Designing Products That Are Never Discarded[END_REF]. This distinction is crucial because the environmental expert has a transversal role during the product design and development process and should co-operate with all product designers. The transversal characteristic of the environmental dimension in design is summarised in Figure 7 representing integration of software tools for an integrated design and eco-design process [START_REF] Rio | A Framework for Eco-Design: An Interface between LCA and Design Process[END_REF]. The challenge of environmental integration during design is the ability to build a transversal perspective for the environmental expertise that overcomes the issues of integration of each stakeholder's perspective.

This section has shown that integrated product design and product eco-design are highly challenging. The next one explores the service approaches to identify the challenges of the related fields and building those of PSS integrated design. .

Service Design

Many service theories, approaches, methods and models have been developed by different disciplines. In this thesis, the following areas have been explored to characterise the "service" design and development:

 Marketing literature  Business literature  Service Engineering Marketing (and business) have recently developed the Service-Dominant Logic (S-DL) theory that allows unification and conceptualization at a higher level of abstraction than the previous marketing theories. S-DL is now widely recognized as a significant contribution to a broad service conceptualization and to a better understanding of the value drivers in trade exchanges and the value creation process. S-DL is presented in the following section (2.2.1). However, S-DL is more a "framework" that conceptualizes the value creation than a pragmatic tool supporting the service design. The marketing / business literature on service design is presented in section 2.2.2. Service Engineering literature is detailed in section 2.2.3.

Marketing theories: from Good-dominant to Service-dominant logic

The marketing literature has evolved over the years from an economic focus towards a better integration of social processes and has consequently switched from a Good-dominant to a Servicedominant logic.

Service marketing and management: services vs. goods

Service marketing emerged in the late 1970s and was focused on the opposition of services to goods. This opposition was encapsulated within the well-known "IHIPs" supposed to be differentiators of goods and services. IHIPs refer to the service differentiation characteristics: intangibility, heterogeneity, inseparability, perishability and are largely widespread in service research. However, these characteristics have been later hardly criticized by the advocates of the Service-Dominant Logic (Vargo and Lusch 2004b) arguing that they:

 Do not distinguish services from goods,  Only have meaning from a manufacturing perspective, and  Imply inappropriate normative strategies. Additionally, [START_REF] Gummesson | Transitioning from Service Management to Service-Dominant Logic: Observations and Recommandations[END_REF] pointed out the misconceptions and lack of substance of the IHIPs among other considerations that still persist [START_REF] Gummesson | Marketing as Value Co-Creation Through Network Interaction and Resource Integration[END_REF] in the service marketing science and are obstacles for the transition towards S-DL. Nevertheless, the service vs. goods logic has emphasized on the fact that the customer is present during service production and consumption and that these processes occur simultaneously.

From relationship marketing to S-DL

Originally, marketing science was oriented towards strongly focused on the type of market: B2B / B2C. With the contribution of relationship marketing strongly oriented towards the "value-in-use" creation, the two-party focus of a supplier-buyer (in B2B / B2C context) evolves towards a multi-party view considering "networks of actors" creating value [START_REF] Gummesson | Marketing as Value Co-Creation Through Network Interaction and Resource Integration[END_REF] or "value constellations" [START_REF] Normann | From Value Chain to Value Constellation: Designing Interactive Strategy[END_REF].

2.2.1.2.a. Relationship marketing in two-party focus: Value-in-use creation

Relationship marketing puts the emphasis on the interaction between the trade parties, replacing the transactional approach based on the product as the exchange core element by a relational paradigm based on relationships [START_REF] Grönroos | The Relationship Marketing Process: Communication, Interaction, Dialog, Value[END_REF]). The value creation through interactions and relationships has a central role in relationship marketing which has been summarised in the S-DL theories. The customer is perceived as the value creator and the creation process is only "facilitated" by the provider who only offers a "value proposition". The customer creates the value in his own "sphere" before, during and after his "experience" and independently from the provider (Grönroos 2011b). The provider can join the customer in the process of value creation and then value is co-created by both the customer and the provider. Therefore, the supplier's role in value generation is to facilitate the customer's process of value creation and to join in a so-called "co-creation of value" process (Grönroos 2011a). The "production" and "value facilitation" processes of the provider and the "value creation" process of the customer meet during the co-creation process.

2.2.1.2.b. Relationship marketing in multi-party focus: networks and Value constellations

The relationship marketing mostly emphasizes on the interaction between a customer-supplier dyad and so is two-party focus. [START_REF] Gummesson | Marketing as Value Co-Creation Through Network Interaction and Resource Integration[END_REF]. This perspective has been widened to multiparty focus, or networks. "Many-to-Many" marketing focuses on the interactions within networks of actors. : the firm is an inside network while the outside network is the market or society in general. The "Actor-to-Actor" (A2A) concept replaces the B2C/B2B previous considerations. The value-in-context is also used as a concept that unites the two-party separation of value-in-use and value-in-exchange [START_REF] Gummesson | Marketing as Value Co-Creation Through Network Interaction and Resource Integration[END_REF]. Other authors have developed marketing theories dealing with the value creation process within interacting networks. [START_REF] Normann | From Value Chain to Value Constellation: Designing Interactive Strategy[END_REF], who worked with Boeing, have characterized the evolution of the concept of value creation ("co-production" in their terms) from the "value chain" towards "value constellation" from a network perspective [START_REF] Normann | From Value Chain to Value Constellation: Designing Interactive Strategy[END_REF]. This approach share some similarities with Service-Dominant Logic [START_REF] Michel | Reconfiguration of the Conceptual Landscape: A Tribute to the Service Logic of Richard Normann[END_REF]. The different fields within Marketing science adopt different viewpoints, but have been unified in a grand theory; Service-Dominant Logic (S-DL).

Service-Dominant logic (S-DL): Towards a grand theory

S-DL comes from the United States since it has been initially proposed by Stephen L. Vargo and Robert F. Lusch (e.g. Lusch and Vargo 2006;[START_REF] Michel | Reconfiguration of the Conceptual Landscape: A Tribute to the Service Logic of Richard Normann[END_REF]. Other researchers have collaborated with them for the development of marketing contributions in line with S-DL like Evert Gummesson, in the field of many-to-many marketing (e.g. [START_REF] Gummesson | Transitioning from Service Management to Service-Dominant Logic: Observations and Recommandations[END_REF][START_REF] Gummesson | Transitioning from Service Management to Service-Dominant Logic: Observations and Recommandations[END_REF]; and Paul P. Maglio and his colleague Jim Spohrer ,both affiliated to the IBM Research, Almaden, California (e.g. [START_REF] Vargo | On Value and Value Co-Creation: A Service Systems and Service Logic Perspective[END_REF][START_REF] Maglio | Fundamentals of Service Science[END_REF]. S-DL is perceived as a major effort to harmonize and generalize previous marketing approaches. It solves the discrepancies and dichotomies of the previous theories because it elevates its concepts to a higher level of abstraction [START_REF] Gummesson | Marketing as Value Co-Creation Through Network Interaction and Resource Integration[END_REF]. The main argument is that the "logic" adopted in marketing has previously been "good-dominant" (G-D) and has to switch towards a "service-dominant" (S-D) perspective. The differences between the two logics are a transformation of some of the dimensions under which the value is understood and perceived (see Table 2). The value is created collaboratively in interactive configuration of mutual exchange. These valuecreation configurations are called "service systems" and service science is the study of service systems and of the co-creation of value within complex constellations of integrated resources [START_REF] Vargo | On Value and Value Co-Creation: A Service Systems and Service Logic Perspective[END_REF] [START_REF] Spohrer | Steps towards a Science of Service Systems[END_REF]. In S-DL, all exchanges are based on service and when goods are involved, tools for the delivery and application of resources are available [START_REF] Vargo | On Value and Value Co-Creation: A Service Systems and Service Logic Perspective[END_REF]. [START_REF] Vargo | On Value and Value Co-Creation: A Service Systems and Service Logic Perspective[END_REF] Value is created when the customer accept a value proposition. Co-creation occurs through the integration of existing resources into those available from a variety of service systems that can contribute to system well-being that is defined by the system context. If value derived and determined through use or context, value in exchange is still required when the need to access resources from others arises. So, the process of co-creating value is driven by value in use, but mediated and monitored by value in exchange.

G-D Logic S-D Logic

The value co-creation among service systems in S-DL is represented with the three types of value as in Figure 9. The transition of the business era is opposed to a "logic" which is adopted by companies. S-DL considers service as the mechanism of exchange. He depicted two distinct types of transition in a fourquadrant grid: the product-service and the G-D to S-D (see Figure 10). He added that such a sequential transition seems to be the most likely (and perhaps the only viable) route in many cases towards an S-DL perspective, due to the strong position of G-DL in most manufacturing firms.

2.2.1.5. Service -Dominant Logic: a conceptual framework [START_REF] Edvardsson | Service Portraits in Service Research: A Critical Review[END_REF] argued that a fundamental difference exists between "services" and "service". Authors proposed to look at "service" in the meaning of a logic, as a "perspective on value creation through the lens of the customer" rather than as a "category of market offerings". S-DL is more a perspective adopted by trade exchanges, since service has always been an exchange of service (Vargo and Lusch 2004a). In their "tribute to" Richard Normann, [START_REF] Michel | Reconfiguration of the Conceptual Landscape: A Tribute to the Service Logic of Richard Normann[END_REF] ended by quoting him: "the service logic clearly frames a manufacturing logic rather than replaces it. Creative business thinking comes from applying the service logic mode of thought, recognizing that within an overriding service logic there are islands of a manufacturing logic" after (Normann 2001, p.98). S-DL has to clear the way for imagining the customer benefits and the value in use created in order to design adequate value proposition for the customer. Nevertheless there are very few pragmatic approaches for service design and management that support effective translation of the S-DL principles in practical supports for implementation.

The next sections present the challenges of designing and developing services and the existing approaches and tools that can be applied.

2.2.2. Service1 design in the Marketing / Business literature 2.2.2.1. The multiplicity of service viewpoints [START_REF] Edvardsson | Service Portraits in Service Research: A Critical Review[END_REF] have reviewed the service literature and interviewed scholars in order to answer the following research question: how is the phenomenon "service" portrayed within service research? Authors concluded that defining concepts or even viewpoints differ and are difficult to grasp. As to the "service concept", it seems to have three main dimensions:  activities;  interactions (which could be said are what separate services from physical products); and  solutions to customer problems. The IHIPs, despite the fact that they have been declared irrelevant to characterised services (Vargo and Lusch 2004b), are still used for pointing out the differences between services and physical products [START_REF] Gummesson | Marketing as Value Co-Creation Through Network Interaction and Resource Integration[END_REF]. [START_REF] Quartel | A Conceptual Framework for Service Modelling[END_REF] characterize the existing view of service in the literature as follows:

-Service as interaction -Service as capability -Service as operation -Service as application -Service as feature -Service as observable behaviour It is very difficult to accurately differentiate products and services and to propose consistent definitions of what they are (their nature). However, authors acknowledge that there is a serviceoriented paradigm which is different from traditional manufacturing product-oriented paradigm (A. R. [START_REF] Tan | What Happens to Integrated Product Development Models with Product/service-System Approaches[END_REF]).

(New) Service development process

There are few research contributions dealing explicitly with the service development process. Existing proposals for shaping the service development or New Service Development (NSD) process are quite similar to the New Product Development process and can also contain linear or parallel perspectives. For example, [START_REF] Alam | A Customer-Oriented New Service Development Process[END_REF] depict these two types (linear or parallel) of NSD based on the extension of existing models of both new services and tangible product development. This extension generated additional dimensions like the possibility of stages concurrency. However, due to the lack of shared service concept and definition, many approaches use the term "service design", "development" and "management" with rather different viewpoints and objects of study.

What is service design for a service company?

Despite the lack of shared definitions, the notion of service as a "process" is the most widespread [START_REF] Edvardsson | Service Portraits in Service Research: A Critical Review[END_REF]. Since services are seen as processes and strongly oriented towards the support of customers' own processes, the boundaries of the system under study in design are quite unclear. Moreover, the simultaneity of the service production and consumption processes blurs the limits between the service "delivery" for a specific customer and the internal service management of operations within the company. This is caused by the necessity for the company to manage the service provision for all the customers with its internal capabilities.

Additionally, services design, development and management have mainly been discussed in marketing-and business-related literatures. The role of marketing and business management is to consider the business opportunities and to align the internal company's technology, knowledge, skills and know-how with specific demands of a market. The service design occurs at different levels of abstraction within the company starting with a strategic questioning that considers sets of customers as markets and business positioning in competitive actors' networks. This explains the trend within service theories to expand more and more the business scope (e.g. from "market" to "actors" in A2A). This is why the service literature proposes multiple viewpoints but none of them accurately defines the service "design" task and the related object under study. There seems to be no clearly expressed differentiation between service strategy, design, development, delivery, operations and management since all of these tasks refer to processes within the company. However, to present the existing approaches and tools, two types of viewpoints can be defined for service "design" support:

 Service as a customer interface  Service as an internal business activity The former is more oriented towards the fulfilment of customers' needs and desires and more aligned with a "design" definition. The latter is more related to the service organization for service provision and then more aligned with a "service management" perspective.

Approaches and tools for service design

2.2.2.4.a. Service as a customer interface

Focusing on the creation of interface between the service provider and the service receiver requires: getting a deep understanding of the customer's needs, involving the customer in the design process and being able to model the expected service processes occurring at this interface.

Customers' needs integration in service approaches

Many tools come from the marketing field for analysing and understanding customers' needs. They have been initially used for product design and then adopted for service design. The perspective adopted for the customer integration during design has been extended with the emergence of S-DL towards customer experience co-creation. Service relationship facilitates the dialogue process and the experienced improvement by the providing company. After that, the management of such a relationship is crucial to ensure consistent value proposition. Several approaches dealing with service "interface" design integrate aspects of Customer Relationship Management (CRM) and focus on the design of "service encounters" at the interface.

Customer Relationship design and Management -CRM

Since a service relationship is built through mutual trust and learning, the co-creation process evolves in time and the design evolves as well. The Customer-Relationship Management (CRM), developed in the field of Relationship marketing, is strongly linked to service design and defines additional aspects (to the product design ones) that can produce "relationship value" [START_REF] Payne | A Review of the 'Value' Literature and Implications for Relationship Marketing[END_REF]. Ulaga ( 2003) defines the customer-perceived value in business relationships as a balance of a relationship benefits and relationship costs or sacrifices. Six generic relationship benefit dimensions are defined: product quality, service support, delivery performance, supplier know-how, time-to-market and personal interaction; and two cost dimensions: direct product costs (price) and process costs. [START_REF] Eggert | Value Creation in the Relationship Life Cycle: A Quasi-Longitudinal Analysis[END_REF] have studied the role of a "relationship life cycle" emphasizing the dynamic nature of the relationship. A relationship life cycle is composed of phases of build-up, maturity and decline. Authors argue that the relationship life cycle acts as a moderator on the link between the three sources of value creation and the relationship value construct and show the dynamic nature of the relationship (see Figure 11). However, if some interest is put on "relationship value" and if there are many attempts to understand and capture the value "drivers" [START_REF] Richards | Customer Relationship Management: Finding Value Drivers[END_REF] or dimensions in CRM, there are very few pragmatic approaches to effectively manage the relationship and possibly anticipate it during design.

Current models for representing service interface: process models

The service interface between the customer and the provider is generally modelled through blueprint, process or activity-based models.

The service blueprint has been introduced by [START_REF] Shostack | How to Design a Service[END_REF] and contains five components:  customer tasks  onstage/visible contact employee tasks  backstage/invisible contact employee tasks  support processes  physical evidence The model also adapts elements of PERT charting by proposing the calculation of critical time. The blueprint model represents a "line of interaction" which delimits customer and provider activities. The share of responsibilities between the customer and the service provider in the service delivery process is an important aspect of service development and contract establishment because customers participate in the production process. The actor's roles within the service provider's organization can also be defined by using "interaction lines" between for example the frontand back-office. Another type of information provided by the blueprint model is the "line of visibility" for the customer. The perception the customer or service receiver has about the activities performed by the provider is of crucial importance in the value finally created. The Service Blueprint has been developed to map the process for person-to-person, single-channel service delivery process and does not address technology infusion and the multi-channel nature of services [START_REF] Patrício | Designing Multi-Interface Service Experiences: The Service Experience Blueprint[END_REF]. That is the reason why several adaptations of Service Blueprint have been proposed, particularly the Service Experience Blueprint (SEB) [START_REF] Patrício | Designing Multi-Interface Service Experiences: The Service Experience Blueprint[END_REF] presented later in this section. Process or activity-based models support the representation of the customer activities and then, the design of the necessary service support activities that have to be designed. Most of the proposals emphasize the necessity to strongly focus on the customer's activities and customer outcomes instead of on products and services (e.g. [START_REF] Sawhney | Creating Growth with Services[END_REF]. Activity-based models containing a customer focus are for example:

 The customer's activity cycle [START_REF] Vandermerwe | Jumping into the Customer's Activity Cycle: A New Role for Customer Services in the 1990s[END_REF]): pre-purchase, purchase and post-purchase  The Customer-Service Life Cycle [START_REF] Piccoli | The Customer-Service Life Cycle: A Framework for Improving Customer Service through Information Technology[END_REF]: Requirements, acquisition, ownership, retirement  The customer activity chain (Sawhney, Balasubramanian, and Krishnan 2004) [START_REF] Payne | Managing the Co-Creation of Value[END_REF] go beyond the activity modelling by providing framework to help business organizations to "manage" the co-creation process by integrating non-physical activities. The framework of three main processes: the Customer value-creating processes, the Supplier valuecreating processes and the Encounter processes (see Figure 12).

2.2.2.4.b. Service as a business activity

Several approaches for service development and management are oriented towards the organization of the business core activities for delivering the adequate services to their customers. Since service development currently starts from strategic considerations about business opportunities and the firm's position regarding specific markets in a competitive network, service companies must deal with the issues of:

 Organizing the decision levels: from strategic to operational  Organizing the tasks of service delivery and support processes The organizational issues have led to the development of several tools based on service or business processes and "architecture".

Business Process Models

The Business Process Model / modelling (BPM) technique encompasses several types of models that all allow the representation of business activities. These activities can be expressed at different levels of detail; they can map the generic processes of an entire company or detail more specific activities within a process. [START_REF] Afnor ; Aguilar-Savén | Analyse Fonctionnelle -Caractéristiques Fondamentales. Rapport Technique[END_REF] proposed a review of the BPM literature and existing tools for modelling business processes. She proposed a classification framework that aims at providing a guide for selecting the appropriate tool according to the type of decision and the models' properties. Among other BPM tools, the SADT/IDEF0 standard ("IDEF Family of Methods" 2015) is one of the most used and is supposed to be well adapted to service design purpose [START_REF] Congram | How to Describe Your Service -An Invitation to the Structured Analysis and Design Technique[END_REF]. It is the most popular process-modelling format on the market (Aguilar-Savén 2004).

Service Life (cycle) Management (SLM)

SLM principles are similar to PLM principles. SLM tools aim at supporting the management of service (and in a broader perspective, the enterprise) activities during service life cycle. Service life management includes the following areas [START_REF] Pyster | The Guide to the Systems Engineering Body of Knowledge[END_REF]:

 Service Life Extension  Modernization and Upgrades  Disposal and Retirement SLM relates more to a specific service development or project, while Business Process Management [START_REF] Ferguson | Enterprise Business Process Management: Architecture, Technology and Standards[END_REF] refers to a practice for managing all activities within a company.

Business / enterprise architecture frameworks

Architecture frameworks or models are used to describe the organization of business activities. They generally use UML for modelling the different aspects of the architecture that allow integrating the different views of the enterprise. For example, standardized tools like the Zachman Framework TM [START_REF] Zachman | The Zachman Framework: A Primer for Enterprise Engineering and Manufacturing[END_REF], Department of Defense Architecture Framework (DoDAF) (U.S. Department of Defense 2015), etc., are useful to decompose the service through the "views" approach. These frameworks help to decompose and organize the architecture of complex service systems within a company.

Service-oriented architecture (SOA) [START_REF] Allen | Service Orientation: Winning Strategies and Best Practices[END_REF]) [START_REF] Erl | SOA Principles of Service Design[END_REF]) is a particular IT industry approach to business architectures that incorporates customer, user and provider views [START_REF] Allen | Service Orientation: Winning Strategies and Best Practices[END_REF]. However, SOA approach considers software services and not the broader total solution approach required for output-based contracts [START_REF] Wood | Service Thinking in Design of Complex Sustainment Solutions[END_REF]. These "multi-view" service models support the organizational perspective of multiple services within a service company and are often developed in the context of IT-based services to facilitate the management of complex and inter-related business processes. However, such a modelling support requires a well-developed IT culture within the company.

2.2.2.5. Conclusion on marketing / business approaches for service design

2.2.2.5.a. Summary of the existing contributions

There is no clear definition of "service". Approaches and viewpoints are multiple in this literature. However, all the approaches share some similarities: o The strong emphasis on the customer's needs o The "value creation" defined as a mechanism occurring within actors' interactions o The resulting importance of the customer relationship through service and its efficient management o The focus on "activities" (that can be mental and affect emotional dimensions) in service models According to the viewpoint adopted, service definitions and roles can differ.

 Service can be considered within a larger scope as a business activity: many models and standards exist. These models are useful to: o align the strategic and the operational levels of activities o align the service delivery and the support business activities  Service can be considered as a customer's interface: only few models are developed. They depict the interactions between customer and provider. They should be useful to refine the design for a specific service and its related mechanism of value creation. . There are two main types of service models adopted:

 Process and activity-based models are predominant: they are used both for describing a customer's interface (e.g. blueprint) and business processes (BPM).  Service architecture models: they are mostly used in the view of service business and describe the organization of decision levels and roles distribution within a service company.

2.2.2.5.b. Conclusion: missing elements for service design

If some tools exist for supporting different aspects of service representation and business management, a service definition and reference design framework for organizing the task are still missing. Two main challenges of service "integration" can be noticed:  The necessity to integrate the service customer's interface with those of the business organization in design. This requires better framing "what service design is", since the design task is not framed and often confounded with a set of service activities: service development, delivery, management, etc. This would require a more accurate definition of a "service" as a design object.  The inter-related issue of integrating and dealing with service management and service design in dynamic learning processes. The specificity of service approaches is the importance attached to the customer "relationship" that should be efficiently managed. Customer Relationship Management (CRM) should be integrated with service design within continuous business processes. To solve the issue of organizing the development and management processes, several approaches have been proposed. Service Engineering attempts to systematize the service design and development in an engineering process.

Service Engineering

Service Engineering (SE) has been introduced to fill the existing gaps in service design and development methods. They can be considered neglected and under-developed compared to the broad range of models, methods, and tools available in product engineering [START_REF] Luczak | Architecture for Service Engineering -The Design and Development of Industrial Service Work[END_REF]. Service Engineering is an emerging research stream aiming at providing systematic tools supporting the service development. Among the authors dealing with SE, different approaches have been proposed. Some authors oriented their perspective on the design process and framework that can be used during service design and development based on product design frameworks. Other authors proposed computer-based tools for supporting SE design and development.

Service Engineering design

2.2.3.1.a. Service development process

In the definition of [START_REF] Aurich | How to Design and Offer Services Successfully[END_REF], the service design process includes:

 The planning and conception of the service  The preparation of service realization. The design process is followed by the service realization during which the main element is the interaction with the customer. The service design and realization both represent the service life cycle also called "service production". SE is defined by [START_REF] Aurich | How to Design and Offer Services Successfully[END_REF] as the systematic development and design of services using suitable models, methods and tools as well as the management of service development process. SE is used to intensify, improve and automatize a whole framework for service design and service realization. As for product engineering, SE has developed several types of development models [START_REF] Aurich | How to Design and Offer Services Successfully[END_REF]: linear or phase models; iterative models; or prototyping models.

2.2.3.1.b. SE design frameworks

Among the proposals for engineering services, authors identified similar elements composing the system and requiring specific models. The existing proposals for service engineering process steps generally encompass the following dimensions:

-Outcome dimension: service benefits, customer requirements or specifications identification, analysis and refinement; -Process dimension: service processes modelling; -Resource dimension: resources identification or allocation. These three levels can be assimilated to the "domains" proposed in product engineering design methods. Three examples of Service Engineering frameworks are briefly presented here. First, [START_REF] Bullinger | Service Engineeringmethodical Development of New Service Products[END_REF] proposed a methodology for engineering services which are characterized by three dimensions:

-A "product" model that corresponds to the material and immaterial outcomes of the service on the customer or other objects or "what the service does";

-A process model that expresses "how the outcomes of a service are achieved"; -A resource model that describes the ability to deliver the service. The second example is the framework proposed by [START_REF] Luczak | Architecture for Service Engineering -The Design and Development of Industrial Service Work[END_REF] which develop a Service Development Management Model. Three main constituent elements of service architecture are represented by supporting models connected by means-end relationships:

 Results: the external requirements of customers as well as the internal requirements within the company for service;  Processes corresponding to the means for generating the results;  Skills and resources which are necessary for implementation of the service processes. Finally, the last example is the proposal of the Service Engineering Methodology proposed by [START_REF] Pezzotta | Balancing Product-Service Provider's Performance and Customer's Value: The SErvice Engineering Methodology (SEEM)[END_REF]. The second phase of the method called 'process prototyping', which follows the identification of the customer's needs, is decomposed into two core tasks:

-Requirement and specification design ; -Process design. During the first task, the requirements are refined by using the Service Requirement Tree (SRT). The needs are refined into 'wishes' which determine the 'design requirements' then translated into 'design specifications'. This provides information for the process design in terms of:

-Main activities; -Technical and human resources. Through these examples, it appears that the dimensions discussed above (outcome, process and resource dimensions) fit in the existing frameworks for engineering services.

SE methods and tools

2.2.3.2.a. Generic tools

There is only a small number of specific methods supporting service design and realization; and most of them are the results of adaptations and modifications from existing engineering, business and computer science to make them suitable for the service sector [START_REF] Aurich | How to Design and Offer Services Successfully[END_REF]. Different methods are used by service companies. A survey performed by [START_REF] Fähnrich | Service Engineering-Ergebnisse Einer Empirischen Studie Zum Stand Der Dienstleistungsentwicklung in Deutschland[END_REF] on companies of different sizes -providing services as core or add-on products and in different business sectors; has been reported by [START_REF] Aurich | How to Design and Offer Services Successfully[END_REF]. The methods are described:  During service planning: o Customer surveys or feedback reports, used to identify customer requirements; o Morphological boxes, used to generate new service ideas.  During service conception: QFD or FMEA tools, supporting translation of requirements into service objects analysis of potential failures in the complex system.  During the preparation of service realization: Methods like service blueprinting, used to describe the operative processes of the service supply.

2.2.3.2.b. SE computer-based tools: Service CAD, Service Explorer

Service Engineering tools have been proposed to support the development of services. These specific tools are discussed in the PSS section of the literature review because they attempt to integrate some product dimensions while using SE principles.

In the definition given by SE authors for Service CAD, a service is "an activity that a provider causes a receiver, usually with consideration, to change from an existing state to a new state that the receiver desires, where both contents and a channel are means to realize the service'" [START_REF] Tomiyama | Service Engineering to Intensify Service Contents in Product Life Cycles[END_REF].

In SE tools, the service 'entities' are defined as the service contents and channels [START_REF] Sakao | Service Engineering: A Novel Engineering Discipline for Producers to Increase Value Combining Service and Product[END_REF]. Service content is supplied by a service provider and delivered through a service channel (see Figure 13). Physical products can be either part of the service contents or the service channel itself. Service activities, on the other hand, support service contents, ready to be transferred, or activate service channels.

Figure 13 The definition of service [START_REF] Hara | A CAD System for Service Innovation: Integrated Representation of Function, Service Activity, and Product Behaviour[END_REF] SE models have been developed to describe critical information such as provider/receiver, receiver's state change, functions of service activities and physical products.

Service CAD for example is proposed to support the conceptual design of PSS by using elements of the service environment, provider, receiver, channel, content, goals, quality and value added. An Integrated Service CAD with a life cycle simulator (ISCL) is proposed to support PSS design by using life cycle simulations based on quantitative and probabilistic descriptions [START_REF] Komoto | Integration of a Service CAD and a Life Cycle Simulator[END_REF]. A design method formed a base for computer software, named Service Explorer [START_REF] Sakao | Modeling Design Objects in CAD System for Service/Product Engineering[END_REF]).

The SE approach has the advantage to explicitly incorporate the customer state through ''receiver state parameters'' (RSPs) which may be dynamically assessed, while the conventional engineering approach would introduce customer characteristics through static requirements that constrain design activities [START_REF] Wood | Service Thinking in Design of Complex Sustainment Solutions[END_REF].

Another interest of SE is its contribution for integrating a product model with human service representation in service modelling. An integrated model linking the product and the service activities aspects has be developed [START_REF] Hara | A CAD System for Service Innovation: Integrated Representation of Function, Service Activity, and Product Behaviour[END_REF]) called the 'extended service blueprint'. This model uses two interrelated blueprints: the activity blueprint that expresses the human activities and the behaviour blueprint that represents the product behaviour. The Business Process Modelling Notation (BPMN) is used for modelling the two interrelated blueprints. The extended service blueprint allows associating the lowest-level functions with real entities that can be hardware, humanware and software.

Yet, SE still focuses on service aspect by using specific service tools and the expansion towards PSS is being discussed but is still not fully integrated. SE practitioners underlined the necessity to progress from SE to PSS engineering [START_REF] Shimomura | Toward Product-Service System Engineering: New System Engineering for PSS Utilization[END_REF] and positioned the research conducted in the field of SE in a larger research strategy map.

Conclusion:

Service Engineering as a promising area SE seems a promising research area to support systematic design and development of services. SE could fill the organizational gaps and solve the issues of "integration" discussed in the existing marketing / business service literature for framing the service life cycle processes, i.e. design, development, delivery, management being supported by CRM in a dynamic evolution perspective.

The main SE interest for PSS "design" is that SE design frameworks are inspired from product engineering and should support integration of products and services. However, SE also misses an agreed "service" definition and concept. But SE approaches have the advantage to propose frameworks that define "dimensions" for service design in a similar fashion that "domains" have been proposed in product engineering. Some models or tools are sometimes proposed to support the different "domains" representations, but the implementation challenges and the links between the domains miss further consolidation.  Service Engineering (SE): with a willingness to adapt product engineering knowledge to service design. These two streams propose a strong emphasis on the customer's needs and value creation. They have differentiated and complementary interests for research: Marketing / business literature mainly developed service models that can be:

 Activity-based models: supporting the description of customer-provider interactions that create the value.  Architecture models: supporting the organization of the service within the business structure. But this literature lacks of supportive frameworks for defining and organizing the service life cycle processes in which the design must occur. SE mainly developed service design frameworks that organize:

 Activities of the service life cycle: supporting a better framing of "design" within life cycle processes.  Service design features in "domains": supporting the description and decomposition of integrated "views" on service characteristics. SE should support the fulfilment of some gaps in the marketing literature. Additionally, SE well frames the engineering processes and sometimes proposes use of tools, but the links between these tools and their implementation in a design process are not well dealt.

Summary of the remaining challenges

The remaining challenges of service design and life cycle management are:

 An issue of defining service, its design boundaries and its "life cycle" processes.  Integrated service life management raises the issues of: o Integrating efficiently the design of the "customer interface" to fit in business processes organization o Framing and organizing the tasks of service life cycle: to develop it, implement it, and maintaining it.  An issue of managing the customer relationship at this interface within the dynamical service life processes.

System approaches 2.3.1. System thinking

System and system science finds its origins in two areas of science: the biological-social sciences, and a mathematical-managerial one. Biologist von Bertalanffy developed the Open System theory that attempts to demonstrate the limitations of the previous "classical science" field through the principle that is currently outlined as "the whole is more than a sum of its parts". In the 1950s, Bertalanffy cofounded the Society for General System Theory. General System Theory (GST) attempts to formulate principles relevant to all open systems [START_REF] Bertalanffy | General System Theory: Foundations, Development, Applications[END_REF].

A system approach is defined in GST as: "A certain objective is given; to find ways and means for its realization requires the system specialist (or team of specialists) to consider alternative solutions and to choose those promising optimization at maximum efficiency and minimum cost in a tremendously complex network of interactions" [START_REF] Bertalanffy | General System Theory: Foundations, Development, Applications[END_REF]).

2.3.2. Types of systems Pyster and Olwell (2013, p. 57-58) classified the different open-system domains into three categories: natural, social and engineering systems.

There are many systems classifications (Pyster and Olwell, 2013, p. 62) he overall objectives of Sys.E are: understanding the stakeholder value; selection of a specific need to be addressed; transformation of that need into a system (the product or service that fulfils the need); and use of the product or service to provide the stakeholder value (Pyster and Olwell 2013 p. 152). System thinking (in GST) automatically contains several issues on the way to consider systems holistically, to define appropriate boundaries for problem situations and contexts, and to expand the vision of the system to design to a wider system, called System of Interest (SoI).

System engineering approach

System Engineering proposes an approach on system design that is close to those adopt in product engineering.

2.3.3.2.a. System life cycle

The system has a life cycle that contains the stages that the system goes through, from its inception to its retirement. The current stages depicted in life cycle models are (Pyster and Olwell 2013 p. 157-158): system definition; system development; system Production, Support and Utilization (PSU);system retirement.

The system life cycle is managed through the integration of the stakeholders' requirements and the verification / validation process in iterative cycles ensuring the requirements fulfilment.

2.3.3.2.b. Requirements Engineering (RE)

RE ensures alignment of the system and sub-systems' requirements and guarantees traceability of the requirements with the rest of the system definition, and alignment with project resources and schedule.

RE is composed of four stages [START_REF] Loucopoulos | Requirements Engineering[END_REF]: requirements elicitation; requirements negotiation; Requirements specification; and requirements validation. RE has been translated into several standards [START_REF] Schneider | A Literature Survey on International Standards for Systems Requirements Engineering[END_REF] that are mostly used in software technologies or information systems development.

2.3.3.2.c. System engineering design framework

Sys. E separate the "needs and requirements view" from the "architecture views". Requirements correspond to the problem expression and they should provide a "technology-independent view of what the system solutions(s) should do" (Pyster and Olwell 2013 p. 218).

The solutions refinement operates in the system "architecture" view and allows for the identification of the boundary and interfaces of a system-of-interest (SoI).

An architecture is separated into two views (Pyster and Olwell 2013 p. 219):

 The logical view of the architecture defines the logical operation of the system all along its life cycle. The logical view can be represented by functional, behavioral, and temporal views/models.  The physical view of the architecture is a set of system elements performing the functions of the system that can be either material or immaterial. Two types of relations can be defined when designing / architecting systems.

 The first one has to support the progression from the requirements to the physical architecture  The second one supports the iterations between the logical and the physical architecture definition. The "requirements" and the "architecture" views are integrated within the life cycle process which supports the development process through several iterations that ensure the continuous verification of the system at each level of detail.

System thinking: different methodologies

Many system-based methodologies have been developed since then and led to an high number of contributions that are not all relevant for this research. Only the main types of methodologies are presented here, in order to provide a general overview. There are three main groups of "system methodologies" (Pyster and Olwell 2013, p.93):

• Hard System methodologies that set out to select an efficient mean to achieve a predefined and agreed end.

• Soft System methodologies that are interactive and participatory approaches to assist groups of diverse participants to alleviate a complex, problematic situation of common interest.

• Critical Systems Thinking methodologies that attempt to provide a framework in which hard and soft methods can be applied appropriately to the situation under investigation.

Hard System Methodologies

System thinking generally occurs with the aim of problem solving. However, in complex systems and complex contexts, this aim can be difficult to define. Starting problem-solving by defining a clear goal in order to define an optimal solution is what is defined as hard-system view. Hard system methodologies offer "managers and management scientists a means of seeking to optimize the performance of a system in pursuit of clearly identified goals" (Jackson 2003, p. 16). Methodologies are systematic and have established objectives and are "able to identify problems that stand in the way of optimization and rectify them by employing scientific modelling, rational testing, implementation and evaluation processes" (Jackson 2003, p. 16).

Soft System Methodology (SSM)

2.3.4.2.a. Emergence of the "Soft" perspective

Hard methodologies are consistent for environments in which a clear objective can be defined in order to produce mathematical models that result in the production of an optimal solution. However, "the 'reality' facing today's managers is so complex and subject to change that it is impossible to reduce problem situations to a form that would make them amenable to such modelling" (Jackson 2003, p. 17). The related other limitation of the hard perspective is its inability to deal with multiple viewpoints on problem-solving and the "multiple perceptions of reality" (Jackson 2003, p. 17). Since the hard methodologies require a strict goal definition or a "problem formulation", the multiplicity of perceptions of the concerned actors on the objective cannot be appropriately managed. The emergence of the "Soft System Methodology" (SSM) (Checkland and Scholes 1999) comes from the limitations of the existing predominant hard perspectives to deal with complex issues of sociotechnical organizations. Soft system thinking gives up the possibility (and the necessity) to start problem resolution with the establishment of a commonly agreed goal because of the multiplicity of the participants' values, beliefs and interests (Checkland and Scholes 1999). Instead, attention is paid to the ways of expressing the different viewpoints on the "problem situation" so that alternative perspectives can be explored systemically, compared and contrasted (Jackson 2003, p. 22) (Checkland and Scholes 1999). The emphasis is put on the learning process in which the participants in the problem situation can progressively integrate the others' worldviews and find a common agreement.

2.3.4.2.b. Principles of Soft system thinking

SSM contains seven stages starting with a clarification task making individuals aware of unease created by the problem situation in order to better identify it and ending with the implementation of the desirable actions that could improve the situation (Checkland and Scholes 1999). [START_REF] Checkland | Soft Systems Methodology[END_REF] generalised their perspective on the way a methodology has to be used for supporting a problem situation understanding by developing a generic SSM model that support the resulting theory of "action-research" (Checkland and Holwell 1998a). .

2.3.4.2.c. Differences with the hard system approach

When hard systems approaches pursue an optimization purpose, SSM is based on a learning paradigm. Participants face "problem situations" (by opposition to "problem" in the hard perspective) and have to learn about this situation. The different viewpoints of the participants are analysed in order to define purposeful actions that should be pursued. By taking part in actions that belong to a systemic methodology, participants learn about the feasible and desirable changes that could "reduce discomfort" (by opposition to "finding solutions" in the hard perspective) (Checkland and Scholes 1999). A degree of agreement between participants on purposes will emerge and the whole learning process takes place through an iterative process from the real world to the desired (modelled) world.

Socio-technical system approaches

The term "socio-technical systems" describes systems that involve a complex interaction between humans, machines and the environmental aspects of the work system (Baxter and Sommerville 2011 after [START_REF] Emery | Socio-Technical Systems[END_REF]. STSD correspond to a willingness to integrate methods dealing with social dimensions, for example: Cognitive Work Analysis; Socio-technical method for designing work systems; Ethnographic workplace analysis; Contextual design; Cognitive system engineering; Humancentred design (Mumford 2006, Baxter and[START_REF] Baxter | Socio-Technical Systems: From Design Methods to Systems Engineering[END_REF]. SSM is integrated in the STSD. But STSD still fails in its attempts to provide a more general, standardised method of STSD [START_REF] Baxter | Socio-Technical Systems: From Design Methods to Systems Engineering[END_REF]. STSD is still a conceptualized field of research that is applied through specific approaches mostly for designing computer-based systems. The building of a generic theory is still required.

System engineering applications to service design

Sys. E is used for developing systems with high engineering complexity; high performance and long life (like for example military equipment, large scale infrastructures, major buildings and high value production facilities); and is considered by practitioners as "the" generic engineering method that enables them to manage complexity [START_REF] Wood | Service Thinking in Design of Complex Sustainment Solutions[END_REF].

Its implementation mainly occurs in highly IT-based business contexts and its methodology is generally supported by UML models [START_REF] Booch | The Unified Modelling Language User Guide[END_REF]. This section illustrates application of its principles to the design of services.

2.3.5.1. System engineering models for service design

2.3.5.1.a. UML models

Service using activity-based models, those of engineering / software engineering, like use case diagrams and activity diagrams can be used in service design.

 Use cases describe sequence of actions that a system performs to produce a useful result for a user.  Activity diagrams are flowcharts that emphasize the actions that take place over time and carried on by the different actors [START_REF] Booch | The Unified Modelling Language User Guide[END_REF]. The use of a standard language like UML is advantageous for integrating these models in the engineering activity, but as underlined by [START_REF] Patrício | Designing Multi-Interface Service Experiences: The Service Experience Blueprint[END_REF], while use case and activity diagrams focus on the system being developed and functional requirements, they ignore the customer "experience" aspects and the business goals.

2.3.5.1.b. Service modelling framework

Patrício and colleagues ( 2004) propose a service design framework based on system engineering. It aims at integrating the Customer Experience Requirements (CERs) and coupling these "experience needs" with the usual requirements used in RE [START_REF] Patrício | Customer Experience Requirements for Multi-Platform Service Interaction: Bringing Services Marketing to the Elicitation of User Requirements[END_REF]) [START_REF] Patrício | Designing Multi-Interface Service Experiences: The Service Experience Blueprint[END_REF]. The resulting method for "Multilevel Service Design" (MSD) supports designing complex service systems [START_REF] Patrício | Multilevel Service Design: From Customer Value Constellation to Service Experience Blueprinting[END_REF]. MSD allows the integrated development of service at three hierarchical levels (see Figure 14):

 Designing the firm's service concept with the customer value constellation of service offerings for the value constellation experience;  Designing the firm's service system, including its architecture and navigation for the service experience;  Designing each service encounter with the Service Experience Blueprint (SEB) for the service encounter experience. The different levels proposed represent several "domains" for depicting the service system. Each description displayed within a given level can be refined in a lowest level as illustrated on the scheme Figure 14 by the arrows between levels that show the refinement of the elements coloured in grey. The MSD is one of the rare available methods in the field of service design to propose a set of models for supporting pragmatically the design of service from the highest level of abstraction, i.e. from the customer value level, to a more detailed level (through the SEB) by considering the system as encompassing human actors as well as physical products.

2.3.5.1.c. Conceptual service system definition

In the field of software engineering (service-oriented design and architecture), Quartel and colleagues have worked on a conceptual service definition and model that should unify and reconcile the existing approaches and definitions [START_REF] Quartel | Methodological Support for Service-Oriented Design with ISDL[END_REF] [START_REF] Quartel | A Conceptual Framework for Service Modelling[END_REF]) [START_REF] Quartel | COSMO: A Conceptual Framework for Service Modelling and Refinement[END_REF]. They proposed a service framework for service modelling that aims to bring clarity to the field of service-orientation by fixing terms and providing concepts to model and understand services. A service is defined as the establishment of some effects through the interaction between two or more systems. The effect has or creates some value for one or more of the involved systems and satisfies some goals or accomplishes some desired effects [START_REF] Quartel | COSMO: A Conceptual Framework for Service Modelling and Refinement[END_REF]. They define the service properties as [START_REF] Quartel | COSMO: A Conceptual Framework for Service Modelling and Refinement[END_REF]):

 Involving interaction: a service involves one or more interactions between a service user and some systems that provide the service.  Providing some value: the execution of a service provides some value to the user and the provider.  A unit of (de)composition: processes are composed from or decomposed into services, which define smaller processes.  A broad spectrum concept: The service concept is meant to be applied at successive abstraction levels along a broad spectrum of the design process, i.e., from specification to implementation.

IBM tools for modelling complex service systems

In the field of complex IT-based System of Systems engineering, IBM developed a tool that should support scenarios simulation within complex service systems in order to better understand the interactions occurring in such value constellations. It is the most developed application of systembased approaches in the service domain.

2.3.5.2.a. IBM platform: Splash

IBM has developed a platform called Splash ("SPLASH: Smarter Planet Platform for the Analysis and Simulation of Health" 2015) that aims to integrate and combine heterogeneous, pre-existing simulation models and data from different domains and disciplines (W.-C. [START_REF] Tan | Splash: A Platform for Analysis and Simulation of Health[END_REF]).

Initially the platform was developed to support decision-making in policies and investment for health system [START_REF] Maglio | Social Factors in Creating an Integrated Capability for Health System Modeling and Simulation[END_REF]. However, since this tool has a replicable consistency, it has also been used for modelling "value constellations to understand complex service system interactions" [START_REF] Kieliszewski | On Modeling Value Constellations to Understand Complex Service System Interactions[END_REF]. Splash attempts to facilitate the creation of composite system models supporting ''what-if'' analyses by stakeholders and policy makers and to consider the effects of change on the whole system rather than through the independent lens of individual constituent components. The platform has been tested for example on the case of the London Borough of Sutton [START_REF] Andreu | Reducing the Fear of Crime in a Community as a Complex Service System: The Case of London Borough of Sutton. Call for Abstracts[END_REF]).

2.3.5.2.b. IBM and the "social challenge"

The social challenge in modelling and for the modellers is discussed by IBM researchers [START_REF] Maglio | Social Factors in Creating an Integrated Capability for Health System Modeling and Simulation[END_REF]. Beyond the technical challenges of models integration, as well as the social and behavioural modelling challenges, authors discussed the challenge in social practices of modellers, questioning the way to support fruitful collaboration across diverse communities of experts, broadening the "lens from the particulars of the social and behavioural models themselves to focus more on the meta-level practices of modellers and those who aim to benefit from their results" [START_REF] Maglio | Social Factors in Creating an Integrated Capability for Health System Modeling and Simulation[END_REF].

They acknowledged the challenge of establishing the right environment for collaboration, and the related limitations of the modelling task. The challenges of integration in its broader meaning, i.e. integration of the expert practices through their collaboration, the validity of the constructs are discussed and expressed in several questions that authors intended to explore. . 2.3.6. System engineering vs. PSS requirements [START_REF] Wood | Service Thinking in Design of Complex Sustainment Solutions[END_REF] have discussed the different ways of "thinking" that oppose the classical consideration of "System engineering" with "service thinking" for identifying the PSS challenges. They considered PSS in the context of "contracted performance" delivery of complex engineered service systems such as military equipment, large scale infrastructure and installations, etc. Authors stated that manufacturers of complex systems will not be able to achieve service excellence in the mind of the customer without a paradigm shift in thinking.

According to the authors, the system engineering "default style is to consider constraints in product (machine) terms". The "voice of the customer" in system engineering sets the baseline and "becomes an historical recording" while service requires "a continuing dialogue between the customer and service personnel". Authors emphasized on the necessity to adopt the concept of "mind of customer" in service thinking considering the "service satisfaction resides in the mind of the customer". Authors proposed the representation of PSS activity by completing the view of "product-service system" playing a role of "integration" and following a V process according to the "voice of the customer" in the "conceptual space"; with the representation of the "expert team" playing a role of "connection" through the "mind of the customer" in the "social space" (see Figure 15). Authors emphasized on the necessity to deliver the service through "expert teams" having specific characteristics for cooperate and coordinate. Authors proposed a basis for representing the two ways of thinking that must be integrated in PSS design (Figure 15). They depicted symbolically the solution delivery as actions: Integrate/ connect/harmonise operated by expert teams (M: Mind of the customer) and PSS design (V: Voice of the customer).

Figure 15 Symbolic representation of solutions delivery according to [START_REF] Wood | Service Thinking in Design of Complex Sustainment Solutions[END_REF] They concluded on the "need for service thinking" to be a "style distinct from system thinking".

According to the authors, a radical change in mind sets is required to clearly distinguish system thinking (that authors defined as "equated to system engineering" for system designers) from service thinking.

Authors characterised system thinking ("driven from the product paradigm") by:  A product approach, with the customer at arm's length  Creation of a technical design solution and is an episodic activity  Segregation of solution design from delivery  Understanding of how things connect, incorporating mainly objective requirements  Incorporation reductionist method, supporting both holistic and elemental views They compared these characteristics with those of service thinking described by:  A social activity wherein the customer co-creates and co-delivers the solution  Describing a business solution within which design is a continuing activity  Integrating design and delivery which are closely coupled  Understanding how minds connect and incorporates social content  Not yet amenable to method, supporting only holistic views

Conclusion on system-based approaches

System engineering approach allows widening the consideration of "products" towards systems. System engineering propose standardized procedures for design and development that are close to the product engineering perspective but more supportive for integrating other objects like software or human aspects. "System" consideration would be supportive to integrate products and services views in PSS. Several system-oriented approaches for service design exist, among which two are identified as relevant regarding the gaps in the other service literature fields:  A service design framework based on Sys.E. integrating models from the service marketing literature [START_REF] Patrício | Multilevel Service Design: From Customer Value Constellation to Service Experience Blueprinting[END_REF]).  Service conceptualization as a "system" [START_REF] Quartel | COSMO: A Conceptual Framework for Service Modelling and Refinement[END_REF]). However, challenges remain in system approaches, since two main "system methodologies" exist that are related to different approaches in "system thinking":  The Hard system methodologies being predominant in Sys.E. that is well adapted to problemsolving when the problem is relatively well-known, and correspond to a "product paradigm"  The Soft system methodologies developed for managing complex problem situations within social organizations through actions leading and progressive learning, that would be better adapted to a "service thinking". This methodological breakdown reveals the different "ways of thinking" that differ between product / system engineers and managers of social organization (service designers). The issues of coupling these two "views" and of facilitating their mutual understanding for integrated PSS design should be solved.

Literature has provided some light on the product integrated design and eco-design, service design and management, and system-based approaches. Some contributions has shown their potential for PSS design, but several challenges have been underlined in each field. The next section details the existing literature on PSS design and PSS eco-design / design for sustainability. PSS faces and crystallizes the pre-existing challenges of product and service design since it integrates these two components.

PSS design 2.4.1. Service properties in the PSS literature

Most of the proposals made for defining and conceptualizing services in the PSS literature adopt the "old-fashioned" viewpoint from the marketing field opposing services to physical goods (e.g. [START_REF] Alonso-Rasgado | A Rapid Design Process for Total Care Product Creation[END_REF] . Authors dealing with the service concept in PSS literature are mostly from the product engineering domain and attempt to integrate a service perspective that fit in the product one. The resulting service definitions lack the integration of recent developments of service science like S-DL concepts. A service definition that could support an efficient PSS design, i.e. integrating the actors' viewpoints of service design and product engineering, is still missing.

2.4.2.1.a. PSS challenges regarding integrated product development

A. R. [START_REF] Tan | What Happens to Integrated Product Development Models with Product/service-System Approaches[END_REF] discussed the way PSSs challenge the existing Integrated Product Development (IPD) (as proposed by [START_REF] Andreasen | Integrated Product Development[END_REF]. Authors highlighted the issues of PSS integration and the resulting challenges for IPD model evolution. A. R. [START_REF] Tan | What Happens to Integrated Product Development Models with Product/service-System Approaches[END_REF] summarized the challenges for an IPD in relation to PSS as follow:

 The focus should be on activities -instead of products, as the mediator of value;  The characteristics of services involve the customer in the co-creation of value: an increased user-orientation of the development activities is required;  The expansion of competencies is required to offer and deliver PSS solutions;  The integration of products and services: the development of products and services that are offered should be coordinated.

2.4.2.1.b. Integrated PSS development

Attempting to propose a model for PSS development that supports the alignment of the provider's processes on the customer's activities, [START_REF] Matzen | Product/Service-Systems: Proposal for Models and Terminology[END_REF] discussed PSS concept and proposed models showing different development dimensions that shoud be considered in PSS development, compared to existing development models.

A complex PSS organizational structure contains the three main aspects of PSS integration:  Strategic business/product planning in cooperation with networks and service partners;  Product management and product development projects leading to new PSS 'offers';  PSS delivery system or function, which is steady in relation to the customer delivery services.

Issues of PSS life cycle design / management (PSS-LCM)

Since service life cycle generally broadens the perspective from the design and development towards other supportive business activities (service operations and customer relationship management), proposals in the field of PSS follow the same viewpoint's expansion. Some authors discussed PSS life cycle "management" (PSS-LCM) that should be an integrated perspective crossing product and service life management. As in the service field, several definitions exist for service and different specific aspects can be highlighted related to PSS-LCM challenge.

2.4.2.2.a. Service and PSS life cycle definitions

Aurich, Mannweiler, and Schweitzer (2010) defined the life cycle of service as the service design and the service realization phases.

Cavalieri and Pezzotta (2012) considerd a "PSS engineering process" supporting the entire offering life cycle decomposed into design and realisation (Beginning of Life, BOL), usage and maintenance (Middle of Life, MOL) and dismission (End of Life, EOL). [START_REF] Meier | Life Cycle-Based Service Design for Innovative Business Models[END_REF] related the PSS life cycle to the challenge of defining innovative business models. They used the "life cycle" definition from an economic perspective, i.e. integrate service activities within business model considerations. They proposed a service configurator that is used to specify the type of business model that should be used in a life cycle management perspective. A. R. [START_REF] Tan | What Happens to Integrated Product Development Models with Product/service-System Approaches[END_REF], after discussing the challenges of PSS regarding the integrated product development process, stated that two life cycle systems must be considered in PSS development (see Figure 16):  The life cycle of the physical artefact  The activity life cycle relationship between the providing company and the customer. These two life cycle systems represent a product-oriented and a service-oriented view respectively.

Figure 16 The two life cycle systems that must be considered in the development of PSS (Tan, McAloone, and Andreasen 2006)

2.4.2.2.b. PSS LCM: Integrating PSS design in a management process Design "cycle" integration

The PSS-LCM can be seen as the more generic framework in which the PSS design has to be implemented as a specific phase or module.

In the perspective of [START_REF] Aurich | Life Cycle Management of Industrial Product-Service Systems[END_REF], a PSS-LCM integrates product life cycle and service design and realization. It must cover: customer-oriented planning, integrated PSSdevelopment, knowledge-based PSS control and life cycle-oriented process management. They proposed a "design cycle" that should support integrated PSS development, i.e. a PSS development phase that leads to a complete description of the PSS-product and -process dimensions [START_REF] Aurich | Life Cycle Management of Industrial Product-Service Systems[END_REF].

Dynamism in PSS-LCM: Continuous PSS improvement through LCM

The continuity of the business activity and their management through a PSS-LCM tool must also support a continuous improvement process supported by a steady information feedback in PSS. [START_REF] Schweitzer | Continuous Improvement of Industrial Product-Service Systems[END_REF] presented an approach for a continuous improvement of industrial PSS during the PSS-realization. They proposed a control-loop model that allows continuous improvement of the PSS. The design of the organizational and operational structure of the creation network guarantees the PSS-provider a continuous product, customer and market feedback that allows the continuous improvement of PSS.

Customer relationship life cycle model [START_REF] Matzen | Opportunity Parameters in the Development of Product/service-Systems[END_REF] emphasized on the necessity to continuously create value and to maintain the PSS relationship throughout its life cycle (see Figure 17) according to which the provider must align his operations to match the development of the customer's needs. Throughout the relationship life cycle, several goods are delivered to the customer and supported throughout their individual life cycles. The focus has to be put on the integration between products and service systems towards the customer's activities sequence.

2.4.2.2.c. PSS Life Cycle Management and environment

Lindahl et al. ( 2006) proposed an Integrated Products and Service Engineering (IPSE) methodology for efficient development and production of integrated product and service offerings. It aims at integrating product and service engineering within a Life Cycle Engineering approach that includes DfE but not being solely focused on environmental issues [START_REF] Lindahl | Integrated Product and Service Engineering versus Design for environment-A Comparison and Evaluation of Advantages and Disadvantages[END_REF].

According to the authors, the strong emphasis of DfE on environmental issues contains the risk of suboptimizations. IPSE instead incorporates a wide range of issues/ perspectives in its view and uses scope and flow models to cover the entire product life cycle as well as different stakeholders' requirements [START_REF] Lindahl | Integrated Product and Service Engineering versus Design for environment-A Comparison and Evaluation of Advantages and Disadvantages[END_REF]). Such a methodology building is highly challenging and still not solved. It contains the integration issues of product engineering, service engineering and the coupling of both, while the integrated views on product and service life cycles should be built.

Summary of the integrated PSS Life cycle design issues

The PSS concept emphasizes and crystallizes the challenge of integrating a product engineering viewpoint that must consider:  the technical challenges of integrated product design and development over the entire life cycle,  with the service design viewpoint that must consider the challenge of managing the service life cycle processes  supported by co-creative relationship between the provider and the beneficiary. The difficulty for integrating the different stakeholders' viewpoints is then increased in the PSS field, since different streams and ways of thinking must be integrated. The issues identified for integrated PSS design and development reflect those previously identified in both product engineering and service design literature:  In the product engineering field: o The challenges of integrated product design and eco-design  In the field of service design:

o The challenges of defining service, its design and its "life cycle" processes. o The challenges of integrating the design of the customer interface within a business organization.

o The challenges of managing the customer relationship at this interface within the dynamical business processes.  The issues of integrating these issues in an integrated "system" definition and framework for PSS.

2.4.3. PSS design / eco-design methods and tools 2.4.3.1. PSS strategic design

In order to support companies in their strategic opportunities exploration, several supports have been developed. There is a large range of methods proposed that support the PSS strategic development and the most conceptual phases of PSS design. Some of these methods provide tools for integrating the environmental dimension within these phases.

A range of tools result from research projects and partnership networks dealing with sustainability. For example, the UNEP's Design for Sustainability (D4S) manual has been developed to support companies in sustainable design approaches, and includes a PSS module [START_REF] Crul | Design for Sustainability -A Step by Step Approach[END_REF].

The proposed approach contains several steps, supported by suggested tools from a toolbox. The sustainability aspects and the "potential" of the solutions are integrated through guidelines and qualitatively assessed through "radars" diagrams at different levels of the decision-making process.

In similar approach, other manuals have been developed and propose similar approaches for PSS development coupled with practical guidelines and tools. The Sustainable Product Development Network (SusProNet) project proposed a list of guidelines and tools resulting from a review of many other PSS projects [START_REF] Tukker | New Business for Old Europe. Product-Service Development as a Means to Enhance Competitivness and Eco-Efficiency[END_REF]. Amongst the integrated initiatives, one can find the Method Product Service Systems (MEPSS) project (van Halen, Vezzoli, and Wimmer 2005), or a practical guide for companies developed by Tukker and van Halen (2003) or a partnership orientation within strategic development [START_REF] Manzini | Solution Oriented Partnership. How to Design Industrialised Sustainable Solutions[END_REF].

The general steps proposed in these methods are [START_REF] Tukker | New Business for Old Europe. Product-Service Development as a Means to Enhance Competitivness and Eco-Efficiency[END_REF]) :

1. Analysis: assessment of strengths and weaknesses of the current product portfolio and markets, decision making in priority areas where PSS development could be beneficial for client and firm; 2. Idea generation, selection, refinement and evaluation (finding ideas, selecting the most promising ones, and detailed design); 3. (Planning and preparing) implementation. The methods described use tools and worksheets to support idea generation and creativity enhancement; economic, social and environmental evaluation through radars diagrams; visualization of the PSS in the form of a storyboard; descriptions of the PSS business models, organizational architectures, and revenue streams, including the need for setting up new partnerships to deliver the PSS (Tukker 2015). All these methods propose mainly "toolboxes" and guidelines that mainly support the conceptual definition of PSS. However, once a PSS concept is selected, they do not support the definition of architecture or embodiment of the sub-systems. Some methods detailed in the next section are more supportive for these tasks.

PSS architecture and embodiment design

2.4.3.2.a. Process steps

The viewpoint of [START_REF] Alonso-Rasgado | The Design of Functional (total Care) Products[END_REF] for designing "total care products" propose the following design steps:

1. Concept development  Identification of customer needs.  Specification of the requirements.  Concept design for service. 2. System design  Design details.

3. Testing and implementation. These steps are close from those found in other contributions (Aurich, Fuchs, andWagenknecht 2006, Cavalieri and[START_REF] Cavalieri | Product-Service Systems Engineering: State of the Art and Research Challenges[END_REF].

2.4.3.2.b. Toolbox for the design process phases

Cavalieri and Pezzotta (2012) reviewed a list of PSS design methods and listed a series of tools used for supporting the design process phases at different levels of detail: For these authors, a design process is composed of:

 Requirements refinement (generation, identification and elicitation); and  PSS conceptual design. These two phases are supported by: QFD; Critical Incident Technique and Sequential Incident Technique;

TRIZ; Analytical Network Process (ANP), Analytical Hierarchical Process (AHP); Pairwise comparisons. The following phase are:

 Embodiment design;  Detailed design;  Final design / test (prototyping / simulating); and  Implementation They are supported by: Service Blueprinting (from embodiment to final design); Functional Analysis (for detailed design and test); FMEA (for test).

2.4.3.2.c. Coupling tools within PSS modelling frameworks

Scenario-oriented [START_REF] Morelli | Designing Product/service Systems: A Methodological Exploration[END_REF] proposed the use of scenarios for describing events (use cases modelled using UML) and adapting the blueprinting technique to represent flow events and actors' responsibilities, as well as physical and/or virtual locations where the actions take place. A service architecture (Morelli 2003) is described through a list of functional components characterized by their attributes and priorities levels; and a prototype of the service can be drawn. The use case and scenarios can be coupled with a IDEF0 model ("IDEF Family of Methods" 2015) in "interaction maps" for detailing the functions and actions in the system (Morelli 2006). If the Morelli's approach proposes organizing the use of tools for PSS design, the links between models and the way the resulting framework effectively support PSS design are not well detailed.

Function-oriented framework

The methodology proposed by [START_REF] Maussang | Product-Service System Design Methodology: From the PSS Architecture Design to the Products Specifications[END_REF] details a PSS framework that allows refining the PSS architecture until the product technical specifications. A PSS is defined as including a set of physical products and services units that interact to provide the system external functions. By using tools of the functional analysis approach (AFNOR 1991). In the PSS adaptation of these tools by [START_REF] Maussang | Product-Service System Design Methodology: From the PSS Architecture Design to the Products Specifications[END_REF], the description of use scenarios is made by using SADT/ IDEF0. External functional analysis is then used for each situation identified through the use scenarios.

The system is initially considered as a 'black box' surrounded by external elements (called "outer environment"). The system is then modelled on a "graph of interactors" on which the service functions are added (see Figure 18). External functional analysis lists the "services" the system is required to provide. The external functions or "service functions" can be either Interaction Functions (IF) or Adaptation Functions (AF). Interactions Functions correspond to "transformations" that link external elements and Adaptations Functions reflect reactions, resistances or adaptations by the outer environment. The system constraints have also to be identified. A functional decomposition through the Functional Analysis System Technique (FAST) allows refining the interaction functions into internal (or technical) functions and identifying the "principles of solutions" that could fulfil the functions.

The solutions identified (products and service units) are then modelled in a Functional Block Diagram (FBD). The FBD allows representing the system components and the functional flows that link them. FBD supports the representation of (see Figure 19): 1. the system boundaries separating system components and the outer environment by horizontal lines 2. the set of components: by rectangular (for products) and curved-angles (for service units) boxes 3. the physical contacts between components by black lines 4. the 'functional flows' corresponding to the external functions by lines which go through the components (red flow on Figure 19) 5. the technical (internal) functions fulfilment by using the Design Buckles -or Design Loops) representation (green loops on Figure 19) Internal running scenarios of the components functioning are also displayed using SADT.

Figure 19 Functional Block Diagram model to model PSS [START_REF] Maussang | Product-Service System Design Methodology: From the PSS Architecture Design to the Products Specifications[END_REF] The methodology allows isolating the product components and refining their technical specifications through an iteration of the methodology. This design methodology is one of the rare approaches that deal with the "detailed design" phase of PSS and mostly, one of the rare that emphasizes the product technical design within PSS. However, its weakness is the lack of coupling with service-oriented models. The methodology mainly supports the design of products composing the PSS.

Interest of SADT / IDEF0 model for integrating product and service models SADT/IDEF0 standard ("IDEF Family of Methods" 2015) originally used in product engineering is also used in service and PSS design. IDEF0 represents "activities" using a specific notation which gives to the activities the "function" name. IDEF0 is referred to as a "functional" model. A function in the meaning of IDEF0 is a special kind of activity that "takes certain inputs and, by means of particular mechanisms, and subject to certain controls, transforms the inputs into outputs" [START_REF] Menzel | The IDEF Family of Languages[END_REF]. The inputs and outputs are the transformed objects, controls are things that can guide, constrain or regulate the activity and mechanisms are resources used to achieve the activity. Inputs, Controls, Outputs and Mechanisms are referred to as ICOMs. An ICOM can be any entitymental or physical, abstract or concrete playing a certain role in the activity [START_REF] Menzel | The IDEF Family of Languages[END_REF]). IDEF0 represents "activities" but are still "functional" models and supports the expression of any type of entity through ICOMs. IDEF0 well fits in the activity-based approaches used in service modelling [START_REF] Congram | How to Describe Your Service -An Invitation to the Structured Analysis and Design Technique[END_REF] as well as in the functional models used in product engineering. Their use is often recommended in PSS design [START_REF] Maussang | Product-Service System Design Methodology: From the PSS Architecture Design to the Products Specifications[END_REF] (Morelli 2006).

2.4.3.2.d. Summary of the existing contributions for PSS design

Cavalieri and Pezzotta (2012) proposed a classification of the existing PSS design methodologies according to the covered phases of the PSS engineering process (BOL, MOL, EOL). This review clearly expresses the lack of support for the embodiment and detailed design phases. Several authors proposed generic steps defining an integrated PSS design or development process that attempt to integrate the product and service aspects. However, if these generic processes allow framing the sequences of PSS development, models supporting the system description at the different levels have yet to be considered. Indeed, among other limitations of the existing PSS methodologies previously reviewed by (Vasantha et al. 2012, Tran and[START_REF] Tran | Development of Integrated Design Methodology for Various Types of Product -Service Systems[END_REF] noticed that despite the quantity of descriptions given about the overall processes involved in integration of products and services which is claimed as a major objective, the intricate steps within each stage are not mentioned. Additionally, most of the proposals cover the highest levels of abstraction (strategic planning, concept definition) but the following stages are only described theoretically. Modelling supports mainly consist in sets of tools but few of them are integrated in a methodological approach. Nevertheless, the following key elements have been provided:

 There is a general agreement on the generic PSS design process stages  However, modelling support are unclear: several tools exist but are not well integrated in design methodologies  The proposal of [START_REF] Maussang | Product-Service System Design Methodology: From the PSS Architecture Design to the Products Specifications[END_REF] is supportive for refining the technical design of products in PSS  IDEF0 model is widely used in product, service and PSS design.

DfX for service support

In the literature review provided by (A. R. [START_REF] Tan | Strategies for Designing and Developing Services for Manufacturing Firms[END_REF]) about the most relevant design methodologies for product-oriented approaches in PSS design, the following DfX methodologies have been identified:

 Design for Maintainability / Serviceability: based on design principles for facilitating maintenance, repair, overhaul activities leading to design features such as product modularity, reliability, etc. Service operations like diagnosis, monitoring and remote control can be added to the product.  Design for Supportability: that covers additional service activities (compared to repair and maintenance) such as installation, training, spare parts management, documentation, consultancy, etc.  Design for Service: (a term used by Rolls Royce) that supports a shift towards a perspective of designing a service supported by a product. The focus is put on the Infrastructure and Capability Investment, Product Acquisition, Product Operations and Support, Product Disposal.

Design for Remanufacturing [START_REF] Sundin | Life-Cycle Perspectives of Product/Service-Systems: In Design Theory[END_REF] emphasized on the remanufacturing phase since a remanufacturing strategy for companies can be supported by a business model based on PSS offers. [START_REF] Sundin | Making Functional Sales Environmentally and Economically Beneficial through Product Remanufacturing[END_REF] proposed a matrix displaying the expected product properties for each step identified within a remanufacturing process: the Remanufacturing Property (RemPro) Matrix should be used as a design tool and as a guideline of a Design for Remanufacturing methodology.

Design for intensified use in PSS Amaya, [START_REF] Amaya | Design for Intensified Use in Productservice Systems Using Life-Cycle Analysis[END_REF] proposed a model of the product life cycle in PSS offers defined by the intensification of products use. The proposed parametric model supports the comparison of different scenarios alternatives by using LCA during the design process since the parameters of the different alternatives are linked to the PSS design characteristics.

Issues of using multiple DfX

Using a set of DfX methods over the PSS life cycle would raise the same difficulties and issues than in product eco-design: the complexity of managing the inter-relationships between the methods and the system parameters and the inefficiency of guidelines for supporting design. Additionally, the PSS "life cycle" is still unclear and most of the previous proposals only consider those of "products" in PSS. A strong emphasis is put on the functionality and the potential "optimal" way to provide it: by a product, a service or a PSS. Indeed, [START_REF] Maxwell | Functional and Systems Aspects of the Sustainable Product and Service Development Approach for Industry[END_REF] argued that the mindset should be shifted from providing products to providing functions to meet human needs and consideration of alternative ways to provide the function(s) such as services or PSS.

2.4.3.3.b. PSS design for environment and sustainability

Indeed, in their perspective, "an open-minded approach, not fixed on a specific offering (product, service or PSS) is advocated" in order to deliver "original, out-of-the-box solutions". For all the options considered, the positive and negative environmental and social impacts are assessed for all life cycles stages using a Sustainability Assessment Checklist which provides guidance on issues to be considered. SPSD aims at orienting the life cycle assessment of a "function" and authors suggested representing the life cycle starting with a functional need (see Figure 20). However, authors here also emphasized the product life cycle and did not define the concept of service life cycle. The PSS is assimilated to a mean for optimizing the product life. The emphasis on the functionality is also a questionable way to achieve the sustainability potential, as it has been discussed by [START_REF] Cucuzzella | Expanding the Evaluation Framework in Design Projects When Seeking Transformational Sustainable Innovation[END_REF].

Challenges of service environmental impacts assessment

Environmental evaluation of services and the challenges of designing of eco-efficient services have been discussed by [START_REF] Brezet | The Design of Eco-Efficient Services[END_REF]. They argued that the choice of the system boundaries can be complicated because of the principles of environmental assessment. Indeed, measurement of environmental impact is done for a new system by comparing it with the old one, providing the same functionality. However the choice of the functional unit is often not obvious when the system impacts and modifies the consumer behaviour and requires a shared infrastructure. Consequently, the system boundaries can be blurry. They proposed a six-step method dealing with the design of eco-efficient services (DES) and a list of tools and actions to follow for each step during the design process. Yet, the challenges raised by the use of these tools and of their integration within a design methodology are not detailed.

Decoupling user satisfaction from functional performance in PSS eco-design

A recent contribution dealing with eco-design for PSS [START_REF] Salazar | Eco-Designing Product Service Systems by Degrading Functions While Maintaining User Satisfaction[END_REF] proposed the degradation of function to improve the environmental performance while maintaining the user satisfaction. They used a utility graph to show that products and services with different functional units representing the "same level of service" for users can be compared [START_REF] Salazar | Eco-Designing Product Service Systems by Degrading Functions While Maintaining User Satisfaction[END_REF]. This work is mainly conceptual but contributes to question the relation between PSS design and assessment by stating that needs fulfilment and functional performance should be separated.

A design-evaluation methodology for sustainable PSS

The PSSDAE (PSS design and evaluation) is an integrated two-phase approach of PSS design and evaluation (see Figure 21) which combines six existing methods and tools supporting the global development process (Shih, Chen, et al. 2009) (Shih, Hu, et al. 2009).

The evaluation methods can provide market response, triple bottom line (TBL) performance and life cycle assessment for either new PSS design or existing PSS. During the conceptual phases, the sustainability assessment through TBL is used and based on the procedures developed within the MEPSS project (van Halen, Vezzoli, and Wimmer 2005) and considers influencing factors for implementing PSS. This evaluation is mainly qualitative and LCA can only be used when sufficient data are available at the end of the detailed design phase, for which the design support is not well detailed

Figure 21 The integrated approach of PSSDAE (Shih, Chen, et al. 2009)

PSS conceptual model of sustainability [START_REF] Geum | Designing the Sustainable Product-Service Integration: A Product-Service Blueprint Approach[END_REF] proposed a blueprinting technique adaptation, arguing that the blueprint is a dominant technique for PSS design. The "product-service blueprint" allows visualization of product's use throughout its life cycle, service flow, and relationship between products and services. Several "points" are represented within the scheme. A "point" refers to the position where an event or state transfer happens to change the functional and behaviour state. For example, if the ownership transfer happens during a specific activity, it can be said to be a "point of ownership transfer". A "point of integration" represents the position of product and service. A "point of economic value achieved" is also proposed, and finally sustainability is represented by the "point of sustainability achieved" to show how the PSS improve sustainability in the global process. However, the representation objects proposed are mostly conceptual and do not represent perceptible criteria that should support decision-making during design. Moreover, authors did not precisely define the expectations or principles to use for defining the so-called "points" on the scheme.

PSS sustainability within actors' network [START_REF] Lelah | Collaborative Network with SMEs Providing a Backbone for Urban PSS: A Model and Initial Sustainability Analysis[END_REF] proposed a methodology based on LCA and an associated model to describe a complex PSS collaborative network and the roles of the involved actors. The PSS network is seen as imbrications of successive B2B (Business To Business) PSS offers. Sustainability is defined as depending on the organization of activities built around physical objects and the aim is to show how these objects are used individually or collectively within an actors' network.

PSS Sustainability measurement using system dynamics [START_REF] Lee | Dynamic and Multidimensional Measurement of Product-Service System (PSS) Sustainability: A Triple Bottom Line (TBL)-Based System Dynamics Approach[END_REF] argued that the attempts in measuring sustainability in the literature are strongly oriented towards static and fragmentary approaches that do not fully incorporate the PSS characteristics of dynamic and complex system including various actors with 'multidimensional' impacts. They proposed using system dynamics (SD) to cover the dynamics, and triple bottom line (TBL) to encompass the multidimensionality of PSS sustainability, respectively. The approach is expected to effectively measure PSS sustainability through a comprehensive view. By using causal loop diagrams, they show how simulations can be conducted to measure sustainability through selected indicators. If this approach seems promising to get more accurate perspectives on the multiple dynamic dimensions of PSS and its complex relationships with sustainability achievement, the modelling issues are still very challenging if the approach incorporation into more practical situations would be a fruitful area for the future research [START_REF] Lee | Dynamic and Multidimensional Measurement of Product-Service System (PSS) Sustainability: A Triple Bottom Line (TBL)-Based System Dynamics Approach[END_REF], it seems to be highly applicable during design situations in which the solution is not entirely defined.

2.4.4. Conclusion: PSS eco-design challenges 2.4.4.1. Challenge of coupling design and evaluation

Among the existing proposals for methodological support of PSS design and eco-design, two streams seem to emerge.  A service-oriented literature that supports the highly conceptual phases during design and integrate the environmental dimension by using qualitative evaluation.  A product-oriented literature: some proposals exist for the detailed design phases but miss the integration of environmental evaluation; while other ones propose quantitative environmental evaluations but design is not dealt or the links between evaluation and design is unclear. To summary, when the environmental dimension is integrated in PSS approaches, it is either at the most conceptual levels of design, as a part of the qualitative criteria established for decision-making, or a posteriori of design (or without detail on design) using quantitative evaluations. These approaches and their main differences in the way to view PSS are summarized in Table 3 In service-oriented approaches, the emphasis is put on value creation process. The PSS potential for eco-efficiency is seen in its innovation potential: PSS increase the degree of freedom of design and should allow finding new ways to create value.

In product-oriented approaches, the emphasis is put on the product functions or use. The PSS potential for eco-efficiency is seen in the possibilities offered by service provision to optimize the product life cycle: PSS increases the possibilities for intervention options during the product life (intensifying use, take-back, remanufacturing, etc.).

In each of these views a specific product and service viewpoint is adopted and some essential elements are missing.

In service-oriented approaches, design mainly consists in organizing the service relationships.

Products are supposed to be later selected (from existing ones) to support services. The integration of product design in PSS development is quite neglected.

In product-oriented approaches, two gaps can be found:  The absence of clear links with the design process  The absent consideration for the "services' life cycles" The challenge of PSS eco-design is then to provide a design method integrating these two views: PSS design should support an integrated design of products and services at a refined level (after strategic design) that integrates environmental evaluations during design. It is then necessary to integrate the service-oriented view and the product-oriented view for supporting both design and evaluation.

Life cycle consideration

The "life cycle" perspective of PSS generally separates the consideration of a "product life cycle" from a generic "architecture of processes" that contains the customers' activities to support as well as the provider's activities perceived at different levels of detail. Some authors emphasized on the product life cycle aspect that can be optimally managed through a PSS offer. "Service" lacks of definition and often defined as the related business activities of design / development / implementation / delivery / management. But this definition raises confusion to distinguish the activities necessary to "think" the design within the business activities and those "implemented" for fulfilling specific needs. In order to support environmental evaluation, a service life cycle definition that better fits in the product case should be found. To comply with those of product life cycle, it would be necessary to identify within the company's production activities the "unit" that is used for fulfilling specific needs. To support such a distinction, a definition of a service system and its boundaries is needed.

PSS "Design": A complex socio-technical process

The design process is a highly complex socio-technical activity requiring a broad range of skills even when appearing as quite simple [START_REF] Wynn | Models of Designing[END_REF]. The social dimension has been widely discussed in the literature as one of the main challenges of service and PSS design. This section aims at discussing the complexity of defining "design" in the context of PSS because of the social aspects of value "co-creation" with the beneficiary. Service approaches are strongly focused on the customer's perspective by opposition to the product perspective that is discussed as being technology-centred and focused on the technical aspects (IfM and IBM 2008). However, product engineering increasingly attempts to integrate user's concerns. Several research contributions discussed user integration within product design. This section attempts to avoid such simplifications in order to better contextualize the real challenges of PSS design.

Product engineering: Role of the user within the design process

As previously discussed in this chapter, product design and development has evolved over the years with the apparition of concurrent and integrated engineering concepts. Integrated product design initially results from a need to create co-operation between the design teams and then to focus on specific social aspects of design through the required collaboration and co-operation between its stakeholders. Additionally, another actor has been progressively integrated within the design process. Since the needs fulfilment must guide the design task, the consideration and the integration of the product user has been increasingly discussed in the product engineering field. Such an emphasis on the need for managing user integration during product design has emerged from the necessity to deal with designers' misinterpretations and to support the knowledge creation process.

2.5.1.1. Why designing? The user-designer relationship

2.5.1.1.a. Customer's needs and designers' world in product engineering

It has been widely acknowledged in the product literature that the emphasis should be put on the user's needs and expectation, due to the observation of many designs failing to get approval by users, where the intended use does not translate into actual use [START_REF] Redström | Towards User Design? On the Shift from Object to User as the Subject of Design[END_REF]. A strong effort for integrating social sciences' contributions (psychology, ethnography, etc.) has been made as previously discussed. Additionally, many studies have been done in order to understand, capture, model and support the "way of thinking" of designers during the design process. There are several underlying reasons to make such an effort. First, it is commonly acknowledged that designers' interpretations of users' needs and the real needs are different. It is common to distinguish [START_REF] Pyster | The Guide to the Systems Engineering Body of Knowledge[END_REF]: the real needs; the perceived needs that reflect the user perceptions; the expressed needs; the retained needs; the specified needs that are called "system specifications"; and the realized needs that are fulfilled through the final solutions. Misinterpretations between the different levels can be a source of design failure. The ways designers understand, interpret, refine and translate the needs and how they verify their designs has to be well understood and should be supported to avoid deviations. Second, the designers' collaboration during design is also crucial. If the users' needs are a major focus, the requirements and constraints of the different stakeholders of the product life cycle have also to be integrated during the design process. So, it is necessary to manage such a collaboration process.

2.5.1.1.b. From "designing for" to "designing with"

The issues related to the necessity for designers to better understand and integrate the needs and expectations of the user has led to the development of several approaches attempting to integrate the user during product design. The product user becomes a participant within the design process. His role switches, evolving from a "purpose" in design (through needs fulfilment) to an element of the means to achieve this purpose. Designers' consideration of the user also evolves from the necessity to design "for" his needs to the willingness to design "with" him. Design can then be considered as a social process through which designers and users share a social relationship for achieving a common purpose.

2.5.1.2. How to design? User integration in product engineering processes

2.5.1.2.a. User integration in product engineering approaches

Marketing / engineering integration Facing increasing competitiveness, the necessity for companies to produce goods that better fulfil the customers' needs has led to an evolution of the historical limit that separated the marketing field from the engineering one. In the classical repartition of work tasks, marketers are focused on the customer studies, and their recommendations for design integrating the customer's expectations become the starting point of product engineers' task during design. Even if in practice, this separation is still difficult to break in companies [START_REF] Aurich | Life Cycle Oriented Design of Technical Product-Service Systems[END_REF], the movement towards concurrent and integrated product design has led to a progressive integration of the customer perspective in the product engineering field. The coupling between these marketing tools and product design ones is more and more discussed in product engineering literature. This is best exemplified by the rapid emergence of considerations for "user-centred" approaches in product design.

Human factors in product (software) design

The field of Human-Computer Interaction (HCI) studies have evolved in the field of System engineering towards Human-System Integration (HSI). These fields mainly aim at dealing with organizational aspects of human work [START_REF] Newman | Managing Stakeholder Requirements in a Product Modelling System[END_REF]) and belong to the "socio-technical systems (STS)" approaches and have also been depicted in section 2.3.4.3 of this chapter.

User-centred and contextual design

Focusing on the customers' expectations has become a main concern for product design, leading to the emergence of "user-centred" approaches that attempt to better integrate the product user as a stakeholder of the product development process. Understanding users' needs is even a topic of the International Standards Organisation (2010) that recommends a better understanding of their tasks and the environments in which the tasks are operated, as well as on an active integration of the users in the design activities. The integration of a user perspective into the earliest phases of the design process is a major challenge for product design. There are several ways to integrate the user or beneficiary into the design process [START_REF] Colle | Conception D'une Aide Technique Complexe et Innovante-Application Au Projet ARPH[END_REF] but the general appellation refers to "user-centred design". Several tools or techniques from social sciences (psychology, sociology, ethnography, ergonomics, etc.) or marketing are now integrated in methods or tools for supporting the engineering process. For example, attempting to integrate both the user specificities and the contextual aspects during usage, the term "usage-context-based design" has been used by [START_REF] He | Choice Modeling for Usage Context-Based Design[END_REF].

Conclusion on user integration during design

Product engineering is increasingly attempting to involve the user within the design process in order to integrate his needs and expectations sooner and better. The context and conditions of use and the specificities of each user are more and more a topic for discussion in the product engineering literature. The product is now considered as an interface for knowledge generation. This is discussed in further details in the next section.

2.5.1.2.b. Products as interfaces for knowledge generation

By integrating the user as a participant in the design process, the focus switches from the designers-asbuilders to the designers-as-learners. The user benefits from what is created and concurrently takes part in the creation process. The user integration in product design like in participatory approaches can be seen as an extension of the concept of co-operation between designers that includes the user.

Extended products

In order to better capture user's needs, the context of use and to accelerate the learning process for designers, the role of products has evolved to become an interface for information circulation and knowledge generation. The concept of "extended products" [START_REF] Thoben | Extended Products: Evolving Traditional Product Concepts[END_REF]Jagdev 2001, Jansson and[START_REF] Jansson | The Extended Products Paradigm, an Introduction[END_REF] seems to be a natural link between user-centred design and the PSS concept. Extended products are described as generators of knowledge through information collection by the design team during use to improve / change the design in short cycles. In participatory approaches of user-centred design, a user representative is integrated in the design process but the design task is still decoupled from the use moment (after acquisition). Extended products have a continuous design process according to the so-called "requirements" that are continuously re-analysed. Design and use are concurrent (and involve the same user). Extended products facilitate knowledge generation for designers through continuous learning processes. Extended products orient the discussion towards the PSS concept but miss the issues of social interactions through the service relationship.

A delicate equilibrium in "experience" design [START_REF] Redström | Towards User Design? On the Shift from Object to User as the Subject of Design[END_REF] discussed the ambiguity and the risks associated to the strong focus put on the "user" in user-centred design approaches that could lead to "user design". He analysed the risk of "trapping people in a situation where the use of our designs has been over-determined and where there is not enough space left to act and improvise". When considering products as interfaces for knowledge generation, a delicate equilibrium must be reached between information gathering for learning and experience supporting for people who get the design benefits.

Conclusion: the social dimension in product engineering

Despite some simplifications that are often made when underlying the differences between product engineering and service design, product engineering increasingly considers the importance of users' needs and attempts to better integrate other human-related disciplines to manage the design task. The main gaps between the emphasis put on the "beneficiary" respectively in product and service approaches are linked to the core skills and competencies of the related actors, since the customers' perspective is historically a marketing concern. The involvement of the user as a design stakeholder has moved the classical design boundaries and challenges on the way to consider products, processes and people. Design initially aims at ensuring consistency between "what is created" (a physical product) and "why it is created" (fulfilling the user's needs) by efficiently organizing the means, i.e. "how it is created" (the design process). By involving the user within the design process, these concepts do no longer make sense since the design purpose means and outcome are involved in a continuous learning process with the involved actors. From this perspective, product and service design would be considered as facing the same challenges of "co-thinking" the problem and "co-building" the solution with the people getting the final benefits from design. However, some differences remain. If product engineering emphasizes the necessity to deal with a continuous learning process of the designers, the social dimension through a service relationship is a crucial aspect from a PSS viewpoint since the designers and the beneficiaries share an experience. The social link continuously maintained should allow the learning process to be effective and to reduce the risk of missing the knowledge creation and of "designing the user" [START_REF] Redström | Towards User Design? On the Shift from Object to User as the Subject of Design[END_REF]), since the "user" becomes an actor of a constructive social learning process. This leads to the "value cocreation" concept.

The service viewpoint: What is "design" actually?

When dealing with service concepts that have been emphasized in S-DL, the "design" task is harder to define than in the product engineering approaches because of the social processes that encompass all the service activities. The social relationships blur the border between the processes of service design, development, delivery and management.

From user integration to experience co-creation

The focus on value-in-use through marketing theories has expanded the perspective on how the user / beneficiary should be integrated within the design process. This has led to the emergence of frameworks aimed at better supporting the value creation through experience e.g. [START_REF] Edvardsson | Customer Integration within Service development-A Review of Methods and an Analysis of Insitu and Exsitu Contributions[END_REF] [START_REF] Zomerdijk | Service Design for Experience-Centric Services[END_REF] [START_REF] Mukhtar | A Hierarchical Classification of Co-Creation Models and Techniques to Aid in Product or Service Design[END_REF]. Compared to product engineering that involves the user in design to improve the learning process of the designers through continuity of the design task, the service perspective considers the design process as included in a larger social process in which the service activities take place. The social processes of service design, delivery, and management are supported by a continuous dialogue that favours mutual exchange of benefits and a shared experience from both the beneficiary's and the provider's sides.

Evolution of design through service integration

When considering service aspects, the question of how "design" should actually be defined is raised. Indeed, the concept of value co-creation must be considered from a two-side perspective involving the designers and the other actors involved in value creation in the provider's organization as well as by beneficiary's stakeholders. They are all involved in social processes that must support learning, experience sharing and benefits creation. The co-creation implies considering the "value" created from the beneficiary's AND from the provider's perspectives. The solution is co-designed and co-experienced. Product engineering emphasizes on the necessity for designers to learn through an integrated design process for improving the user's experience, while when considering services:

 The learning process that supports solution building is not only a designers' concern, but involves the beneficiary;  The experience aspects of the solution are not only the beneficiary's concern, but also those of the provider.

2.5.3. Managing the complexity of PSS Design as a socio-technical process

2.5.3.1.a. Service implications for PSS design: Coupling problem-solving with coexperience processes

Many differences can be outlined when comparing the viewpoints adopted in product engineering and service design regarding their respective beneficiaries (product user or service beneficiaries). The "solution" that should provide benefits is not a physical artefact but a service relation that requires the design "problem" to be continuously questioned and refined through experience. The issue of defining "problem" and "solution" when dealing with a decision-making process within social contexts has already been discussed by Soft System thinkers (Checkland and Scholes 1999). [START_REF] Ericson | People, Product and Process Perspectives on Product/ Service-System Development[END_REF] discussed the challenge of integrating the product engineering and the service viewpoints by considering their differences regarding "system thinking". They emphasized the necessity to integrate products and services into a system perspective and proposed recommendations for integration. The principles of Soft System Methodology (Checkland and Scholes 1999) for leading actions within complex problem situations and its difference with the problem-solving approach of the Hard System Methodologies reflect the gap between product engineering and service design.

2.5.3.1.b. Clarifying the PSS design task

The previous considerations emphasized the complexity of dealing with the "design" concept for PSS. Nevertheless, some authors have initiated the exploratory process of such a complexity for a better framing of the PSS design task.

McAloone (2011) discussed the "boundary conditions" that manufacturing must undergo in order to develop systematic approach to the service-related aspects of their business development like it exists today for product development. Through observations of the particular characteristicsof PSS design compared with integrated product development (IPD), he defined six boundary conditions for a PSS development arena (see Figure 22). The six boundary conditions to integrate for defining the PSS development arena are:

1. Competencies and disciplines evolve from Engineering to Innovation, since a PSS project depends on a much broader set of competencies (compared to IPD) for integrating the user's activity cycle and orchestrating the complex network of stakeholders, both in-and outside of the company. 2. The nature of offering evolves from Product to Service. 3. New production forms are related to the evolution from "designing" to "doing" due to the new type of support to provide to the customer's activities. 4. Elements of choice evolve from regulation to choice, i.e. the user is present in the specification of use and usability, leading to the creation of choice, as opposed to living with in-built regulation (on products). 5. Executional interventions (exchanges between provider and user, product and user, product and provider, etc.) must be thought from the user activity to the provider offering, to define which party is active or responsible for certain key activities in PSS conceptual design. 6. Perceptions of value evolve from Quality to Value, in which the challenge is in matching the customer's judgement of value with the company's own ability to provide products of high quality. The nature of PSS design gives opportunities for the development task to get closer to an understanding of value perception that lacks in a traditional product development situation. This contribution helps to clarify the specific challenges of PSS design compared to the product engineering approaches. However, very few proposals for clarifying the PSS design task regarding the existing engineering practices and the service challenges have been proposed. In addition to the McAloone's contribution (2011), those provided by A. R. [START_REF] Tan | What Happens to Integrated Product Development Models with Product/service-System Approaches[END_REF], [START_REF] Ericson | People, Product and Process Perspectives on Product/ Service-System Development[END_REF] and [START_REF] Wood | Service Thinking in Design of Complex Sustainment Solutions[END_REF] are of interest in the domain. However, studies for defining typologies of actors that are (or should be) involved in a PSS design process are largely missing. A better understanding of the relationships existing (or that have to be created) between different types of actors for supporting efficient PSS design, development and management is required. One of the challenges of PSS design is the definition of the actors' roles within the processes and the clarification of the design task in these processes.

Dealing with the issues of service provision requires efficiently managing the social relationship between the beneficiaries and the service provider within inter-related and dynamic processes for cocreation by:  Switching the view of "integrated product design" towards PSS design o Switching from product life cycle stakeholders to PSS actors o Switching from actors' cooperation to actors' co-creation o Switching from problem-solving to actions leading, progressive learning and coexperience.

Chapter 3. Framing and leading research

The literature review has been oriented by the initial research question: "RQ0: What are the challenges of integrated PSS design?" This chapter has detailed how the literature review has supported the refinement of this question and the research process followed to answer the identified sub-questions. Section 3.1 details the analysis made of the contributions from the literature that results in the identification of three main challenges for integrated PSS eco-design. Section 3.2 proposes clarifying this research by positioning its goal and scope regarding these challenges. The research frame allows refining the initial research question into several ones. For answering these questions, a research process has been adopted and is detailed in section 3.3 to explain how the contributions have emerged. The research outcomes are introduced and the way they fulfil the research questions is detailed.

3.1. Challenges of PSS integrated eco-design 3.1.1. Summary of the challenges of integrated PSS eco-design 3.1.1.1. Product-service integration challenge: unifying viewpoints

The main challenges of PSS eco-design have been identified through the literature exploration. They are summarized as follows:

(1) The challenges of integrated product design /eco-design: product life cycle integrated design and environmental evaluation  An issue of "integrated product design" involving all the stakeholders of the product life cycle  An issue of managing continuous quantitative environmental evaluations during design o Integrating an environmental expertise "transversally" during design o Integrating environmental evaluations during design in iterative negotiations loops o Evolving the classical view of LCA towards a better consideration of the needs' fulfilment

(2) The challenges of service life cycle management  An issue of defining service, its design boundaries and its "life cycle" processes.  An issue of integrated service life management: o Integrating efficiently the design of the "customer interface" to fit in business organization o Framing and organizing the tasks of service life cycle: to develop it, implement it, and maintaining it.  An issue of managing the customer relationship at this interface within the dynamical service life processes

(3) The issues of integrating these issues in an integrated "system" definition for PSS  An issue of integrating products and services o For supporting integrated design o For supporting environmental evaluation during design.  An issue of switching from "integrated product design" towards integrated PSS design o From product life cycle stakeholders to PSS "actors" o From stakeholders' cooperation to actors' co-creation.

o From problem-solving to action leading, progressive learning and co-experience  The resulting "system" challenge:

o Integrating the actors' views in system design: different system thinking in Hard and Soft methodologies o Integrating the actors' view in system environmental evaluation. The PSS "system challenge" here results from the others and is detailed in the next section.

3.1.1.2. The "system" challenge of PSS It seems that the main issue remaining when attempting to integrate the different actors' viewpoints for PSS design is the lack of a system concept. As discussed in the related section, several system approaches exist and should be supportive when dealing with issues of conceptualization and integration of several actors' practices. System engineering propose standardized procedures for design and development that are close to the product engineering perspective but misses the "soft" dimension in its classical application. Two rationale that seem better adapted to either product engineering or to service design exist in "system thinking": the Soft System Methodologies with the Hard System ones. These different ways of "system thinking" should be integrated in PSS design and in PSS evaluation.

Environmental evaluation challenge

Additionally, the missing system concept has implications for solving integration issues of design as well as for performing adequate environmental evaluations. The quantitative environmental evaluation from the product engineering viewpoint is performed through LCA required the definition of the system. A system concept must then be defined for PSS in order to properly define the system life cycle and its related impacts. However, the system view proposed corresponds to the Hard System Methodologies when using the Functional Unit concept. The PSS life cycle concept could benefit from the service approaches: it should emphasize the beneficiary's needs instead of adopting the restrictive concept of Functional Unit. Solving the challenge of product-service integration would lead to a higher consistency of the design and evaluation tasks, i.e. by balancing the fulfilment of needs and benefits with the environmental impacts generated over the PSS life cycle.

Value co-creation must be regarded as a multidimensional concept that supports the integration of the different actors' viewpoints and should support the emergence of sustainable PSS. The definition of the value proposed in Value Analysis (VA) (initiated by [START_REF] Miles | Techniques of Value Analysis and Engineering[END_REF]) as a ratio of benefits and costs seems supportive when considering the multiple "viewpoints" that can be adopted on the PSS during design through the value concept. From a beneficiary viewpoint, the PSS creates value (value-in-use). From an environmental perspective (related to the design activity), the PSS removes value (only the negative effects of the technico-socio-economic activities can be determined and termed "impacts"). The economic value should also be considered but is not integrated in the scope of this thesis. Then, based on the concepts proposed in Value Analysis, the PSS should be perceived as a "media" for creating / removing value that has multiple benefits/ costs dimensions for different stakeholders. The Value co-creation then requires considering the value "ratio" to deal with sustainability and then efficiently managing the relationship between two "transversal" views with those of PSS designers:

 Those of the beneficiary that evolves dynamically and must be efficiently managed through the relationship.  Those of the environmental expert that must support the "Voice of the Environment" during design.

Challenges Reformulation

Widening the challenges from integrated product design to PSS

The challenges of integrated PSS design are strongly similar with those of integrated product design, except that the social relationship creates a two-side perspective. As discussed in the previous chapter, when dealing with PSS it is necessary to consider:

 The learning process that supports solution building not only as a designers' concern, but involves the beneficiary;  The experience aspects of the solution not only as the beneficiary's concern, but also those of the provider. As previously discussed, integrated product design can be seen from the actors' perspective as comprising three levels [START_REF] Tichkiewitch | Co-Ordination Between Product and Process Definitions in a Concurrent Engineering Environment[END_REF]:

 The actors' communication: that requires the exchange of product data  The co-ordination between the actors' work: that requires an integrated design process  The full co-operation between the design actors: that is achieved through a good management of the two first levels This perspective about product design has to be widened when considering the service perspective, from the "designers" to all the stakeholders that include the beneficiaries. Then, these actors have not only to co-operate but they must share the experience and learning process through a social relationship. The co-operation dimension must then be broadened towards:

 The actors' co-creation of value through co-experience and co-learning process shared within the relationship. Co-creation results from the actors' full co-operation and supported by social relationships that must be efficiently managed.

Domains of integrated PSS design

In the definition proposed by [START_REF] Mcaloone | Defining Product Service Systems[END_REF], the PSS specificities (ontology) operate in three domains:  In the time domain, it is a sequence of multiple, interrelated life phases and activities throughout the product's service time.  In the artefact system domain, it is a set of multiple, interrelated systems, between which the product life phase system of use is the predominant, but where other systems (the producer's maintenance system, the overall system related to the product, the supply of input to the product, etc.) can also be of importance.  In the value domain, it is a set of multiple stakeholders' values, determining the utilisation and reactions to the artefact systems and activity systems effects and determining how seriously the side effects are regarded. These three domains for defining a PSS can be linked to the different levels of integration proposed for integrated PSS design.

Perspective proposed on the challenges of PSS integrated eco-design

The previous viewpoints proposed on the integration dimensions and on the PSS domains converge towards three main decomposed challenges that have been identified after the exploration led for answering the initial research question "RQ0: What are the challenges of PSS integrated (eco-)design?". The literature review has shown that the challenge of understanding, integrating and supporting the social dimension that conditions all the interactions occurring between the involved actors of the value co-creation process is the main issue of integration. This generic social challenge can be decomposed into three sub-challenges that correspond to the dimensions of integration previously discussed as well as to the three PSS domains proposed by [START_REF] Mcaloone | Defining Product Service Systems[END_REF]. Figure 23 below summarizes the perspective proposed for the identified challenges of PSS integrated eco-design that are further discussed in this section.

3.1.2.3.a. Actors' co-ordination through an integrated design process

The design task clarification, expert teams definition and roles attribution allow framing the design processes, i.e. of the "time domain" among the PSS characteristics given by [START_REF] Mcaloone | Defining Product Service Systems[END_REF]. Many proposals in the PSS literature deal with the challenge of organizing these processes within integrated frameworks. However, the clarification of tasks also require that the actors of each process share common goals and expected outputs of their tasks, and then a common perspective on the "object under study". An integrated PSS design process must be fully integrated in the customer's and the provider's business activities to support co-creation. Once the design task framed, an integrated design process must support the decision-making between various types of actors involved through a clear organization of the actors' tasks in different phases and stage-gates. The decision-making process must be supported by several decisions nodes, verification and validation processes organized through several iterations (like in a Waterfall model).

3.1.2.3.b. Actors' communication for co-operation

For supporting a shared understanding of the system under study between product and service designers, it is necessary to propose an integrated perspective supporting the system representation. Such a system model should facilitate the actors' communication and then the actors' co-operation during design. This means building a common reference of the "artefact system domain" [START_REF] Mcaloone | Defining Product Service Systems[END_REF]. This requires building a "multi-view" model [START_REF] Tichkiewitch | Methodology and Product Model for Integrated Design Using a Multiview System[END_REF] of the system in order to facilitate communication between the different actors and then, the decisionmaking process. A PSS model faces several types of challenges for facilitating actors' communication that have been identified in the literature review. All the actors involved in the PSS design task must be able to communicate internally and with the other business actors that are organized within a larger value creation process. The beneficiaries take part within such a process and should be integrated in the PSS design. The challenge of sharing a PSS model between several actors encompass internal challenges of integration that have been identified in the literature: those of integrated product design for the stakeholders involved in the product(s) life cycle(s); those of service process management for the stakeholders involved in PSS design, development, delivery and management; those of eco-design for the share of a transversal perspective between the stakeholders involved in products and services life cycles and the environmental expert; and finally those of the social dimension that must be created [START_REF] Wood | Service Thinking in Design of Complex Sustainment Solutions[END_REF] between the beneficiaries and expert teams for the share of a transversal perspective on the value creation process. Additionally, all these types of actors must be able to communicate through the PSS model.

3.1.2.3.c. Actors' co-creation through social relationships

Sharing an integrated PSS model to communicate and organizing the decision-making into an integrated design process are both important to support the actors' co-operation. However, as previously discussed, the PSS concept goes beyond the co-operation notion since the social dimension influences the value creation process. Co-creation during design has to be efficiently supported by a deep understanding and management of the actors' relationships and interactions that are not restricted to those of communication for decision-making. Actors' co-creation through co-experience and progressive learning has to be efficiently supported by an understanding of the benefits expected and created for the different stakeholders and then by adopting a shared understanding of the "value domain" [START_REF] Mcaloone | Defining Product Service Systems[END_REF]). An efficient management of the actors' relationships should allow understanding the social aspects of the relationships (including the cognitive, relational and emotional drivers). This should support a shared understanding on the "value" that must be created and then the facilitation of the learning process through experience for the effective co-creation of such a value. This must integrate the benefits and the side effects (McAloone and [START_REF] Mcaloone | Defining Product Service Systems[END_REF] from the different perspectives of the other systems involved as from the environmental one.

3.1.2.3.d. Summary

The previous section details how the literature review has answered the initial research question on the challenges of PSS integrated eco-design. The issue of dealing with the social dimension has been identified as the main challenge. It has been decomposed into three sub-challenges that can be summarized as follows:

 The actors' co-ordination challenge through an integrated PSS design process;  The actors' communication challenge through an integrated PSS model;  The actors' co-creation through an efficient management of the two previous dimensions (cooperation) as well as through an efficient management of the social interactions between the involved actors. All these challenges are inter-related and encompass many other ones that already exist in the literature related to product engineering, service design and management, system approaches and PSS. The next section then attempts to clarify the research conducted in this thesis by detailing its goal within such challenges and its scope. The assumptions made are detailed. The refinement of the research scope regarding the existing challenges of integrated PSS eco-design allows the refinement of the initial research question into more accurate ones.

Research clarification 3.2.1. Research goal and scope refinement 3.2.1.1. Focus of the research

This thesis has focused on the challenge of supporting the actors' communication through a PSS integrated model. Supporting the actors' co-ordination through an integrated PSS design process is still highly challenging, but the literature already provides many contributions that constitute a strong basis. Supporting the actors' co-creation requires an efficient management of the two other dimensions as well as an integration of other competencies and disciplines (e.g. human-related and social sciences) and has not been emphasized in this research. However, these two challenges (co-ordination and cocreation) being necessarily linked to the modelling one and to the environmental evaluation; the contribution proposed in this research also deals with some of their issues.

Underlying assumptions

3.2.1.2.a. Actors of PSS design

As mentioned by [START_REF] Wood | Service Thinking in Design of Complex Sustainment Solutions[END_REF] a PSS design process has no clear 'chief architect'. Moreover, the literature does not really provide support for identifying some typologies of PSS design processes. The company's strategy, for example in a process of transition from manufacturing to services or of re-orientation towards new business activities, necessarily influences the choice of the actors concerned by the PSS design. In an ideal PSS design process that fully integrates all the relevant stakeholders, the following actors should be concerned:

 The product(s') engineers: different design teams, the stakeholders of the life cycle(s)  The service(s') designers: the actors of the service(s) design and development, delivery (frontand back-stages employees as suggested by Zomerdijk and Voss 2010), customer relationship management, support operations, etc.  The relevant business actors organizing the match between company's strategy and PSS deliveries to specific markets (e.g. the 'chief architect' orchestrating the development)  The beneficiaries: the actors from the customer's company that get benefits from the PSS  The environmental expert(s)

3.2.1.2.b. Generic classes of actors: the multiple "views"

In this research, the actors previously mentioned are grouped into generic classes. Four main classes of "view" are proposed grouping different actors: "product engineering", "service design", "beneficiary" and "environmental" ones. In the proposed research, a class is supposed to group actors sharing common practices and viewpoint on the design object. The following assumptions are then made:

 Actors from the beneficiary system do not systematically share the same views on the system under study, but they all have expectations and their needs must drive the design process. From a design perspective, a "beneficiary" class corresponding to the viewpoint of the actors expecting benefits of the system under study then makes sense.  Actors having the environmental expertise are also grouped into a class "environmental view".

This view is supposed to illustrate the specific viewpoint of the natural eco-systems that would be impacted by the "system under study".  Actors from product engineering adopt a common "product-oriented perspective". They share common practices for designing their common object of study (classically a product) through the consideration of the requirements of constraints of its life cycle. Their design culture is driven by the Hard System Methodologies.  Actors from service design share a "service-oriented perspective", common practices for designing a (not so well-defined) object under study: service processes; through a strong focus put on the beneficiary's value creation process supported by service delivery, service relationship and experience. This design culture is driven by the Soft System Methodologies. Beyond the existing challenges of integrating the actors' views in each class, i.e. internally, the specific PSS integration challenge is supposed dependent on the integration of these classes of "views". Classes of actors must be to communicate and co-operate at different levels of detail during design through an integrated PSS model.

3.2.1.2.c. PSS design process

According to the literature review, an integrated PSS design process can be considered as composed of the following stages:

 A "strategic phase" that encompasses: needs identification, requirements definition, strategic positioning coupled with the PSS conceptual design phase (ending by the selection of a PSS concept);  A "product/service design phase" that can be seen as a detailed design phase:

o concept development, o embodiment design o detailed design of sub-systems o testing;  And an "implementation phase".

3.2.1.2.d. An integrated PSS design model

An integrated PSS model should contain all the "views" associated to each actor. Actors being grouped into classes, a PSS multi-view model is supposed to allow these views to communicate. Figure 24 illustrates the perspective proposed in this research for an integrated PSS design model. The model represents the four classes of views adopted on the "system under study": "product engineering", "service design", "beneficiary" and "environmental" views. These views must share interfaces for communication. The challenge of integration is perceived in the building of these interfaces in a consistent manner for each view.

Figure 24 An integrated PSS design model 3.2.1.3. Research Scope

3.2.1.3.a. Actors of concern within the integration challenge

The full integration of all the PSS design actors is challenging and is not dealt in this thesis. The starting point for the integration challenge is perceived as embedded in the creation of an integrated perspective from a "provider's viewpoint", i.e. between product engineers and service designers that should share a common understanding of their design task, i.e. on the goals, on the expected outputs of task, and then on the system under study (PSS). This research then focuses on the way to integrate viewpoints and tasks of the two classes of product engineers and of the service design during the PSS design process, considering that the beneficiary and the environmental views must be integrated and shared by product and service designers and are then transversal viewpoints.

3.2.1.3.b. Phase of concern in a PSS design process

In this research, the focus is put on the "productservice design" or PSS "detailed design" phase during the sub-systems should be integrated. The "strategic phase" is supposed to be ended. Then, the needs have been analysed and the requirements have been relatively refined before a PSS concept being generated, evaluated and selected. This strategic phase can be supported by the large range of innovation methods proposed for PSS strategic / conceptual design (mentioned in the previous chapter) and the qualitative evaluation tools they contain for selecting the appropriate PSS concept. Regarding the beneficiary's expectations, the "problem" is then supposed to be relatively well explored, even if necessary adjustments and further refinements would be necessary during the detailed design phase. The concerns of supporting the detailed design phase are then to propose an adequate support for integrating the product engineering and service design perspectives during the development of the appropriate solutions.

3.2.1.3.c. Research focus

The goal of integration in PSS design is the emergence of a co-creative process between the involved actors, i.e. the four views defined. The "interfaces" that link the views should be supported by efficient tools and practices for facilitating the co-creation process. This thesis emphasizes the Product-Service (PS) interface to support a common understanding of the design objects and the collaboration process between product engineers and service designers. This research goal is illustrated in Figure 25.

The PS interface challenge for co-creation: collaboration and negotiations

This research aims at developing a shared interface between product and service design views. The PS interface has to support the integration of the actors' practices and tools during design until the most detailed levels. The beneficiary and the environmental views have to be shared transversally.

The main dimension emphasized in this thesis for co-creation between product engineers and service designers is the communication process: a PSS design model should be proposed to facilitate their mutual understanding and their collaboration and to support the resulting design negotiations. Negotiations occurring between product and service designs should be supported by a common reference model of the PSS and a common understanding of the value created.

The value created for the beneficiary (that can be captured by a service expert) and the environmental value removed due to the activities necessary for the beneficiary's value creation (that can be captured by an environmental expert) must be aligned through the PS interface. A shared perspective for defining the PSS life cycle as a value media must be proposed in order to efficiently support the PSS evaluation.

The environmental evaluation should then support the PSS design process by integrating the different dimensions of value while supporting the design negotiations between product engineers and service designers.

Internal integration challenges

The views integration contains internal and transversal challenges between "sub-classes" of views. This research does not attempt to solve the respective integration challenges within and between each view and sub-view. This thesis attempts to create an interface between product engineering and service design as generic classes of views sharing a common viewpoint on design without dealing with the internal challenges of integration within and between each view and sub-view.

Transversal integration challenge: the beneficiary interfaces

As shown in the literature review, the product engineering and service design fields do not share the same perspective on the beneficiary. The beneficiary (or user) is still considered as a "constraint" for product engineers in problem-solving approaches while service design has deeper consideration for beneficiaries as sources of value creation. Moreover, even if the trend in product engineering moves towards a better understanding and integration of the customers' needs, the design task is still an episodic activity focused on the product [START_REF] Wood | Service Thinking in Design of Complex Sustainment Solutions[END_REF] that not well captures the process dynamism neither in the design task nor in the value creation for the beneficiary though the relationship. On the contrary, service design strongly emphasizes on the dynamism of the value creation through the customer-supplier relationship life cycle that has to be efficiently designed and managed (CRM). Concurrency between services production and consumption as well as continuity of the experience and learning processes through the relationship lead the service actors to consider design as a "continuing activity" in which the customer co-creates and co-delivers the solution through social interactions [START_REF] Wood | Service Thinking in Design of Complex Sustainment Solutions[END_REF].

The interface linking the beneficiary's view on the PSS with those of service design is more developed and consistent than with those of product designers (expressed by the size of the arrows for the respective interfaces on Figure 25). As underlined in the literature review, the service perspective strongly focuses on the customer since it has been mostly developed in the marketing field, which historically studies the customer/consumer (buying) behaviour. The attempt of this research is not to unify the product and service perspectives regarding the beneficiary since they adopt different logics. However, this work supports the idea that it is necessary to support their convergence towards an agreed representation (see the arrows representing the respective interfaces convergence towards the PS interface on Figure 25) of the goals to achieve regarding the beneficiary's needs. Since the PSS concept has been selected, the design goals are relatively established and have to be shared between the product and service designers. The PSS design refinement along the PS interface has to ensure the consistency of the system being designed with these goals.

Transversal integration challenge: the environmental interfaces

The environmental perspective is more developed in the product design field. The environmental impacts assessment of services is more challenging (J. [START_REF] Brezet | The Design of Eco-Efficient Services[END_REF]. Moreover, integrated product design tends to increasingly integrate the life cycle stakeholders during design, while service design does not propose a clear definition of the service life cycle. The interface linking the environmental view with those of product engineering is then more developed and consistent than with those of service design. In a same manner here, the necessity is to make these views converge towards an agreed perspective of the environmental goals and priorities (the arrows also converge towards the PS interface on Figure 25) throughout the PSS life cycle. The PSS life cycle design refinement along the PS interface should support a progressive environmental evaluation that allows refining these goals and priorities.

Research scope regarding the other PSS challenges

Regarding the other challenges identified, the contribution proposed in this thesis must be framed.

Considering the co-ordination challenge through an integrated PSS design process, the challenge of performing quantitative environmental evaluations during design is raised. Indeed, the decisionmaking process contains environmental considerations and then, raises the issue of aligning the environmental evaluation on the design process. However, this issue is the only one dealt in this thesis regarding the concerned challenge. If the issue of PSS modelling necessarily requires organizing a progression throughout levels of details, the full organization of design tasks into a process containing sequences or stage-gates, and of their required iterations, is out of the research scope.

Considering the value co-creation challenge, this thesis emphasizes the issue of integrating the different concepts and viewpoints on "value" in the meaning of its benefits and costs. Only two types of values are then focused on as essential value components that should be shared by the actors and propose a "transversal" viewpoint overwhelming the local integration challenges during design: The focus has been put on the compressed air domain (company's requirement) representing around 50% of the total activity. AC has developed PSS offers and still proposes classical sales of equipment for compressed air. In sale offers, the company proposes a diagnosis and sizing of installations. AC is a distributor of the Atlas Copco's equipment (OEM) for compressed air at medium pressure ranges. In PSS offers, the customers pay by unit of compressed air volume used (m3) in defined contract terms for air quality, quantity and energy ratio. AC is a service company since it does not design or manufacture the machines but historically has a strong product and technical culture. The service design is not a highly defined and formalized process but has been progressively refined and adjusted through feed-backs and experience.

Industrial collaboration

Ets André Cros has developed PSS offers to broaden its business portfolio and to fulfil customer's expectations. In the last ten years, more and more of its customers have requested a full availability of compressed air and a guarantee of the plant performance. AC has progressively developed PSS contract to answer customers' demands. The company were then in a PSS business transition at the beginning the collaboration. The collaboration has consisted in:  Observation and analysis of this transition process and new business emergence,  Formalization and support development for the new PSS offer, focusing on the environmental impacts dimension. The CEO was aware of the PSS potential for decreasing the impacts generated compared to physical goods sale and was interested in getting knowledge on these impacts in order to orient the PSS development towards their reduction. The company's expectations were then to get information about the environmental impacts of the PSS offers (in the compressed air field) in order to better communicate with their customers and to be able to identify strategies or alternatives for impacts reduction. The collaboration established during the thesis has fulfilled the company's expectations while it has concurrently supported the development and application of the eco-design method proposed in this thesis.

Compressed air offers

Different types of offers exist in the compressed air field that can contain different relative parts of products and services. A schematic illustration of the services proposed in the extreme cases, i.e. the equipment sale and the PSS offer, is proposed in Figure 27. In the case of equipment sale, the service proposed are a diagnosis that allows plant sizing, and installation of equipment. A maintenance contract can be added. The PSS offer corresponds to a result-oriented PSS in the typology proposed by [START_REF] Tukker | Eight Types of Product-service System: Eight Ways to Sustainability? Experiences from SusProNet[END_REF] since the customer pays per unit of air volume consumed. The continuous guarantee of air availability (24/24, 7/7) requires preventive and corrective maintenance services, continuous remote monitoring and control of equipment, on-call duty service (24/24), emergency repairs or equipment replacement services, and spare parts management. Calorific energy dissipated through the compression process can be recovered to be used on a customer's application (e.g. industrial process heating). At the end of first use, the machines are recovered and their end-of-life is managed to maximize their reuse, either in other contracts or through their sale (second-end equipment) or rental by the corresponding departments after remanufacturing. At the end of life, all the machines are systematically dismantled to recover spare parts that can be reused for maintenance operations or sold. Wasted parts are sorted and a large part is managed by the recycling sector.

Figure 27 The extreme types of offer in the compressed air field (AC): from the product to the result offer

Collaboration process

Collaboration steps Two LCAs have been performed during collaboration that have provided a better understanding of the issues raised by PSS life cycle definition and related ones of PSS environmental evaluation for (re-)design. Two contracts have been selected: a product-oriented offer and a service-oriented one; that have been declared "equivalent" regarding the beneficiary's needs (related to their air consumption profiles in equivalent pressure ranges, temperature and dew points) and using the same type of technologies for compression (air-cooled, oil-lubricated and screw compressors). LCA has been conducted on these two offers revealing the difficulties of modelling the PSS life cycle and to efficiently evaluate the environmental impacts in order to define eco-design strategies or (re-)design priorities.

After this initial LCA based on a model built "on-ground" the results have been shared with the company's actors and this has led to identify the difficulties and challenges for their appropriation by these actors. Pursuing a goal of (re-)design, results of an environmental evaluation must facilitate this (re-)design task and facilitate the identification of priorities for building alternative scenarios.

A brainstorming process for generating eco-design alternatives for the PSS has been organized. Since the results have been obtained in absence of a design support for communicating them consistently for re-design, they have been discussed between participants to order them into main thematic areas.

The brainstorming day organized by the design team and involving all the professions' representatives has consisted in (illustrated on Figure 28):  Generate alternative ideas (on the basis of the LCA results)  Grouping the ideas (building scenarios)  Rating and selecting scenarios  Discussing the benefits/risks and advantages/drawbacks of the selected scenarios.

The scenarios selected and discussed constitute the basis for a conceptual (re-)design of the PSS offer that is still studied by the AC design department. These scenarios require to be further refined by the company but they have provided a basis for applying the proposed evaluation framework. The departments and facilities included in the study have been coloured on Figure 29. Representatives from the departments coloured in orange have been interviewed. The departments coloured in green correspond to those have been integrated in the study (i.e. in the initial LCA or during the application of the design method) but interviews have not been performed. Most of the interviews have been done with the design department (and sometimes the CEO) that was the privileged contact. One of the two employees within the design department has previously worked for years as a manager of the industry facility. A sales representative has also been interviewed.

Figure 29 AC business organization into departments (data from 2013)

A meeting has also been organized with customer of the PSS contract case selected. The customer is a branch of an international industrial company specialised in the manufacturing of refrigerating products. His production site and the plant premises have been visited and some employees interviewed.

The information collected deals with the following areas:  The system to design (PSS) that is the object studied  The design process and culture within the company  The company's needs, expectations and difficulties regarding the use of LCA results for (re-)design  The beneficiary's (customer's) needs and value perceived (regarding the PSS offer) Table 5 summarizes the different types of information collected in these different research areas and the types of source for this collection.

Step

Research outcomes and research questions fulfilment

The research outcomes can be separated into two main contributions that are inter-related:  A conceptual framework (1) for supporting integrated product-service design (RQ1)  A conceptual framework (2) for supporting the PSS environmental evaluation during design (RQ2). Each of these frameworks is supported by concepts and tools that have been developed. The design framework (1) is mainly supported by a proposal for a system concept that attempts to integrate the viewpoints of product engineers and service designers regarding their object of study. A system-based framework is proposed (RQ1.1). A multi-view model of the system is implemented in the framework to support the progression of the design task (RQ1.2). The evaluation framework ( 2) is mainly supported by a proposal for a PSS life cycle concept that derives from the system concept, and a PSS life cycle model is proposed (RQ2.2.). An environmental evaluation method and tools are proposed (RQ2.2) to evaluations during design. The elements proposed in the design and in the evaluation frameworks are integrated in a methodological framework for supporting PSS eco-design. The main research outcomes are schematized on Figure 30. The relative research efforts put for building these two contributions (i.e. time spent and level of fulfilment of the related research questions) has been expressed on the scheme by glasses filled. The conceptual design framework concentrates the efforts of this thesis and constitutes the essential research contribution. The conceptual framework for environmental evaluation has been less emphasized and this thesis mainly proposes elements that have the potential for fulfilling the research questions but require to be consolidated in a future research.

Figure 30 Main research outcomes

This chapter has detailed how the literature review has supported the refinement of the initial research question, and of the research goal and scope. The research process followed and its resulting main outcomes that answer the research questions have been introduced. The next chapter details these research outcomes.

Chapter 4. Proposal of a PSS eco-design methodology

This Chapter details the proposal made for building a PSS eco-design methodology. The elements proposed in the conceptual framework for supporting integrated product-service design and modelling are detailed in section 4.1. Section 4.2 introduces the elements proposed for a PSS environmental evaluation framework. Both parts are concluded with the integration of their respective elements within methodologies. An integrated PSS eco-design framework is finally proposed in section 4.3 that introduces the case application proposed in the next Chapter.

Proposal of a conceptual framework for integrated productservice modelling in PSS design

This part aims at explaining and detailing the proposals made for building a conceptual framework for product-service integrated design. This part is divided in five sections. Section 4.1.1 proposes a refinement of some challenges that have been identified in the previous chapter and provides an analysis of the main specific issues of product-service integration. It concludes with the resulting requirements for solving these issues. The next sections detail the different parts of the proposal that compose the conceptual framework for integrated PSS design:

 The proposal of a system concept for supporting PSS design (section 4.1.2);  The proposal of system-based design framework (section 4.1.3);  The proposal of a "multi-view" PSS modelling framework (section 4.1.4). The last section (4.1.5) summarizes these proposals and integrates them in a methodological support for integrated product-service modelling during PSS design. [START_REF] Pss Design | [END_REF].1.1. Analysis of the Product-Service integration issues for design and modelling 4.1.1.1. Introduction The literature review has provided some methods and tools that have the potential to support the PSS design. Attempting to widen the scope of integrated product design to PSS, integrated product-service design should:

 Support integration of product and service views (through a system framework)  Support the problem-solution of the actors  Support the expression of important characteristics for each view in design "spaces" 4.1.1.2. System "views" and the problem-solution issue during design

4.1.1.2.a. The problem-solution spaces in the Hard system view

Most of the product engineering frameworks are based on several "domains" for expressing and modelling various aspects of the product to be designed.

In system engineering, the different layers proposed are aligned on the product engineering ones.

Requirements engineering plays the role of analysing, refining and managing changes in the stakeholders' expectations. The system architecture contains two views: the logical view that defines the logical and the physical views.

Even if the names given differ according to the approaches, the same type of elements seems to be expressed in product and system engineering (see Figure 31) in three main "spaces" or domains. The requirements are the design "goals" for designers. Goals are analysed and translated to be modelled in a comprehensive language for engineers. The problem formulation or modelling for designers is named here the "problem space". The solution formulation or modelling is named here the "solution space". The problem formulation and solution finding require consistently verifying the goals achievement while being linked together and involved in iterative cycles of decomposition.

Figure 31 Schematic representation of the existing design spaces in product and system engineering frameworks (links and iterations omitted)

4.1.1.2.b. Issue of distinguishing problem and solution in the Soft view

In Sys.E., design refinements are essentially made within the system architecture, in which the logical view corresponds to the problem expression and the physical view to the solution definition (even if necessary adjustments and refinements of the goals are made and a full process of verification and validation must ensure the link between the system architecture and the requirements). However, the requirements that express the beneficiary's needs (i.e. the goals here) become an "historical recording" for designers (Wood and Tasker 2011) (despite the possibility to manage changes in Requirements Engineering). The requirements initiate the design process and the solution (physically built) must verify (and is validated by) the fulfilment of these requirements. However, such a hard system view does not fit in the progression approach adopted in service design because of the reciprocal relationships between problem-solution formulations and implementations along service relationships and dialogue processes. These two viewpoints are related to the existing differences between Hard and Soft System Methodologies. An illustration of these differences in terms of progression within the three design spaces identified is proposed Figure 32.

The first part (a) is a simplified representation of the existing progression in product and system engineering (grouped as a class of actors sharing the "product engineering view" in this thesis).

The second part (b) illustrates the mechanisms described in the Soft System Methodology (Checkland and Scholes 1999) applied to the service design and experience.

In Figure 32(b), quotation marks have been used to refer to the "problem" and "solution" for two reasons. First, SSM disagrees with these terms preferring those of "problem situation" and the "discomfort reduction" and second, these terms have been used here to illustrate the difference with the Hard system view but these notions are discussed and elicited in the following sections.

Figure 32 Illustration of the differences between Hard and Soft System Methodologies through the design progression within spaces: (a) a simplified illustration of the Hard system view (iterations and validation process omitted); (b) proposed illustration of the Soft System Methodology applied to the service experience

4.1.1.2.c. Contributions from Service Engineering (SE)

Service Engineering (SE) frameworks have been proposed with the aim to reuse the product engineering knowledge for supporting systematized approaches in service design, and most of them contains layers that could be assimilated to the product and system engineering ones. Service Engineering (SE) frameworks generally converge towards three main dimensions:

 "Outcome" dimension: customer requirements, expected service benefits  "Process" dimension: service processes modelling  "Resource" dimension: (human or physical) resources identification or allocation

The hierarchical layers of SE would be aligned on those of product and system engineering, as shown in Figure 33.

Figure 33 Design spaces in product, system and service engineering frameworks (links and iterations omitted)

These frameworks alignment allows identifying the design elements of interest for each view. They should be coupled for PSS design. However, the proposed hierarchy of domains in SE raises the issue of defining a service "solution". Indeed, here, the service solution would be the humane resources affected to the processes. But considering the beneficiary's viewpoint, the design solution is not composed of human resources but of actions, as shown in the illustration of SSM in Figure 32.

The Soft system view hardly separates the "problem" from the "solution" since they both seem to take the form of actions. However, in SE frameworks, resources correspond to the solution defined and actions to the problem formulation.

Here it is necessary to decouple the PSS design task (and to frame it) regarding the issues of SSM that couples the problem solving approach of design with its implementation.

4.1.1.2.d. The different actors' views on problem-solution

In the SSM, [START_REF] Checkland | Soft Systems Methodology: A Thirty Year Retrospective[END_REF] emphasizes the importance of hierarchical layers for system thinkers currently decomposed into three levels of "Why?" (wider system), "What?" (system) and "How?" (sub-system). However, these layers must be seen as necessarily observer-dependent (see Figure 34 detailing the Checkland's example).

Figure 34 System thinking and the observer-dependency of layers [START_REF] Checkland | Soft Systems Methodology: A Thirty Year Retrospective[END_REF] The same type of mechanism can be revealed by the issue of defining "problem" and "solution" when dealing with the service concept. Figure 35 below details the different meanings that can adopt the "problem" and "solution" concepts for the two different views of the beneficiary and of the service design. SE "dimensions" are hierarchically organized of the three layers. From the beneficiary viewpoint, the system goal ("Why?") corresponds to his needs that must be fulfilled, while the service outcomes corresponds to "What" must be created and to his "problem" area, while the solution consists in the service processes performed by human resources ("How?") being the means for solving the problem. The service designer does not fully access to the beneficiary's needs but only to their transcription into requirements that should express the expected outcomes or benefits. This corresponds to the "goals space" ("Why?") of the designers. The service processes correspond to "What" must be created while the service resources are the means ("How?"). The "solution" from the beneficiary's viewpoint can be seen as the "problem" for designers. A strong relationship exists between the service processes and resources since they are both parts of a problem and of the solution.

Figure 35 Problem and solution spaces in the beneficiary and the service design views

Issues of an integrated PSS design framework

In order to create an integrated interface between product engineering and service design views, their respective understanding of the hierarchy of domains (from "Why?" to "How?") should be understood and efficiently supported. The design spaces used in product, system and service engineering share similarities in the domains used. They should be coupled for PSS design.

When attempting to integrate the existing design framework in product, system and service engineering, the management of the relationships between the design spaces raises several issues. Indeed, the hard and soft system views adopted in PSS integrated development and management cover a very large research area. Only a small part of these challenges is included in the scope of this research.

The issues of building an integrated PSS design framework are summarized in Figure 36. The needs, goals, and the problem and solution spaces (regarding the designers' viewpoint) are shown.

The arrows between spaces represent loops of interactions that make the PSS design and its implementation evolve. These loops contain several issues depending on the design process coordination, the relationship management and the progressive co-experience through actions implementation.

The integrated PSS design framework should allow coupling the product engineering and service design views on the "problem" and "solution" spaces (regarding their designers' viewpoints). This raises the issue of integration of products and services in PSS models. The "problem" and "solution" spaces should be co-evolutionary. The result of design would be the solution from the beneficiary's viewpoint. The benefits provided (outcomes) to the beneficiary correspond to the designers' goals. The outcomes provision is dependent on the PSS solution and should fulfil the needs. The dynamism existing between needs, outcomes and problem-solution progression refer to issues that are not dealt here.

The integrated product-service modelling issues are focused on. A co-evolutionary framework of problem-solution should be defined.

Figure 36 Issues of building an integrated PSS design framework 4.1.1.4. The modelling issue: Functional vs. process models The lack of system concept leads to major difficulties when attempting to represent the system elements in the "solution space". Additionally, the elements determined by models that would express the "problem" have different orientations in product and service design.

4.1.1.4.a. Problem space: Function vs. action

The domain-based approaches in product engineering differ but most of them contain a "functional" domain that drives product design. However, reasoning from function to structure in product engineering strongly differs from the service reasoning on processes and resources due to the models used: "black box" in product engineering and "open box" in SE. This makes many differences in the reasoning from problem to solution.

Analysing the benefits of the coexistence of several engineering meanings of "function", Vermaas (2013) proposes a general scheme of reasoning from a device's goal to its structure (see Figure 37-a).

His analysis shows how different uses of functional descriptions can lead to some simplifications between steps depending on the different purposes when using these descriptions. In most of the existing engineering functional descriptions, the "functions of the device" are directly related to the "goals of the device" while the "actions with device" are bypassed. This is the case for the functional basis [START_REF] Stone | Development of a Functional Basis for Design[END_REF]. Other "domains" can also be bypassed like the behaviour (see Figure 37-b). However, when reasoning in SE on service processes, the focus would be on the "actions" of the beneficiary "with" the service system that are necessarily coupled with the "behaviour" or actions "of" the service system (within the provider's organization). The function concept has (a priori) no reason for existence in service design. The "actions with" are hardly separable from the "actions of" while they both require the description of the systems interacting (e.g. the beneficiary and the provider). The service solution (organized resources) is necessarily depicted concurrently with the formulated problem (expected actions through processes) in the so-called "open-box" models of the "soft system view".

The "function" concept is meaningful in product engineering because it reflects the physical boundary that is initially defined and expressed by the "black box" model. Once defined the possible actions of the user with it, functions express the expected observable effects of the product behaviour from the user perspective. This reasoning supposes decoupling the problem (function) and the solution (internal components) that should support the emergence of innovative solutions. However, considering service design, such a decoupling is impossible. The system boundary is only progressively determined. The "open box" models hardly separate the operated actions and the interacting systems. The service effects have not the same meaning since the focus is more on the effects of the interactions between beneficiary and provider: the inter-related actions can affect the beneficiary's perception and experience through the relationship, and the goals to achieve. Moreover, the observable characteristic also depends on the how the service is internally organized from a provider perspective (e.g. line of visibility in a blueprint model).

The considerations about the differences between product and service models are linked to the focus points adopted in product and service cultures. Understanding how the existing tools propose different lights on specific design aspects should support the building of a unified system perspective and a better collaboration between the design actors.

4.1.1.4.b. Different focuses Focus on the spatial dimension in functional models

Product design currently uses the term of functional chain to refer to the assembly of transformations that provide the expected output. Functional chains mainly express the physical paths followed by flows that are transferred within the system. The functional blocks represent operations on flows and support the identification of the necessary components that would provide these expected operations. Functional models used in product design are mainly oriented towards spatial aspects of the flow transfer.

For example, when a human operator uses a screwdriver to unscrew a machine part, the functional chain can be represented as an assembly of operations on the energy or force operated. This assembly represents a spatial trajectory of the flow (Figure 38).

Figure 38 The spatial perspective used in functional models Functional models are oriented towards a spatial dimension since the refinement process allows defining sub-boxes that correspond to internal parts of the product. Information about the physical location of transformations within parts can be easily expressed. The time dimension is not well managed in functional models. In the functional basis [START_REF] Stone | Development of a Functional Basis for Design[END_REF], the flows that go through functions can be organized in sequential and/or parallel function chains. However, this organization characterizes the functions relationships but not directly reflects a time-organized process. To solve some of these issues, [START_REF] Nagel | Process and Event Modelling for Conceptual Design[END_REF] proposed a process modelling methodology based on functional modelling encompassing several contexts in which the customer interacts with the product. Time dimension is integrated through the external changes that can trigger the expected transformations which are described in "event models".

Focus on the temporal dimension in process models

In service models, the emphasis is put on the temporal aspects. The notions of activity or action are used to depict the transformations and assembled in sequences organized in time. Shostack underlined the importance of the temporal dimension stating that contrarily to products existing in time and space, services are processes existing only in time [START_REF] Shostack | How to Design a Service[END_REF]. Moreover, events and external solicitations (e.g. from the customer) triggering the service activities are central in a service perspective and allow describing scenarios of activities emphasizing the context dynamism. However, if activity-based models used in service design well support the description of processes they somewhat hide the spatial dimensions of the transformations. Using an activity-based model for describing the previous example of scenario should lead to the disappearance of the spatial aspects of the flow transfer due to the simultaneity of operations for the force transmission. The emphasis is put on the operator's action on the screw in order to trigger a movement in order to get the expected state change of this object in time (see Figure 39). Service models currently lack of representation for the spatial dimension (for example, physical location of activities), that is one of the reasons for the blueprint adaptations proposed by Morelli (2003).

Figure 39 The temporal perspective used in process models

4.1.1.4.c. Model-building processes

The "function" notion well fits in the "hard" view reflect the expression of a purpose without presupposing the components necessary for this provision. The refinement process towards solutions currently consists in successive decompositions where each step hides the next one (due to the "black box"). Product is refined by identifying the parts necessary to perform the transformations that are located inside the box. Since service design adopts an outside-in perspective [START_REF] Cavalieri | Product-Service Systems Engineering: State of the Art and Research Challenges[END_REF]) the progressive refinement of solutions can be additive. Service generally follows a scenario-based approach for model-building. Scenarios correspond to system descriptions which differ from models because of their incompleteness: descriptions correspond to a representation of a given area (of expertise) or of a specific view of the system in a given context [START_REF] Mayer | IDEF Family of Methods for Concurrent Engineering and Business Re-Engineering Applications[END_REF]. The modelbuilding process in a soft perspective corresponds to an assembly of scenarios which can be progressively defined while the knowledge on the external / internal solicitations increases.

4.1.1.4.d. Conclusion on the modelling issue

To deal with the challenge of PSS modelling and bridge the hard and soft system views, [START_REF] Ericson | People, Product and Process Perspectives on Product/ Service-System Development[END_REF] suggest building new knowledge from the existing one. They argue that "practically, the existing models within the company for service development and product development respectively have to be used as a basis for conversations in project teams striving to work together. At first, preserving the basic models separate can make the similarities and differences apparent, but also, support understanding for where the dilemmas for PSS lie. Doing so, it seems likely that an interrelated model, that takes the both perspectives into account, will emerge". Authors propose supporting the discussions emerging from the use of distinct models for product engineers and service designers by the means of a focus on the "core ideas". Using product and service models making the "core ideas" visible for each view is proposed as an initial step that should lead to the emergence of interrelated model taking both perspectives into account. Additionally, a system concept must be proposed to provide a common basis on the object under study. 4.1.1.5. Requirements for an integrated PSS design framework

4.1.1.5.a. Generic requirements for product-service views integration

This section summarizes the requirements for building an integrated Product-Service interface resulting from the different analyses previously detailed.

Based on the Ericson and Larsson's recommendations, building a "multi-view" model supporting product-service integration during design requires integrating the actors' practices during design by  Ensuring the specificities of these practices to be maintained: by allowing their respective tools to be used in order to support the design until the most detailed levels.

o The problem-solution progressions must be allowed separately  Unifying these practices through common system framework for design o A system concept should be defined o Multiple "views" should be allowed o The problem-solution progression must be integrated in the system framework 4.1.1.5.b

. An integrated design framework

To support PSS design, an integrated design framework must: 1. Define the design elements for describing the problems and the solutions 2. Organize the design progression within design spaces 3. Support the design progression of each view by:  By defining several levels of detail  By ensuring traceability of the design choices  Allowing iterative negotiation loops between designers.

4.1.2. Proposal of a system concept for PSS design 4.1.2.1. Proposal of a general system concept A general definition of a "system" and its properties is proposed.

A system is characterized by:  Its boundaries  Its state variables  Its aptitudes A system has interacts with other systems through actions.

An action is defined as an operation that an entity (subject of the action) exerts on another one (object of the action) by the means of a flow transfer. An action has temporal and spatial properties. An interaction corresponds to the link created between systems through action(s). Figure 40 represents the entity-relation model linking system to action. The system state is a condition for action and the action can modify the system state. System aptitude is a system property solicited in action. A product aptitude can be expressed by a function; a service unit aptitude can be a skill or competency. System boundary is an interface in system interaction. System boundary has spatial and temporal dimensions. A spatial boundary physically separates a product from its environment. The temporal dimension of a boundary is meaningful for service: for example the delimitation of an actor role requires considering the interfaces of this system as dynamic.

Proposal of a PSS definition

A PSS is defined as a set of components and their 'structural organization'. The components (or sub-systems) can be either physical products or 'service units'. A physical product is a tangible object and a service unit is a structured entity of the provider's organization and can be considered as a 'department' within a company. Service units can be composed of products and of teams or units and the related personnel. The definition of the components encompasses the notion of 'infrastructure'. Infrastructures are defined as components shared for several uses (not necessarily designed for the system considered) which can be pre-existing. They can be physical products (for example an electrical network) or service units (for example a human resources management unit). The 'structural organization' of the system corresponds to its set of sub-systems and the organization of their interactions that allow the system to interact for achieving the design goals. The 'structural organization' of systems encompasses both spatial and temporal dimensions.

. Designers' views regarding the system concept proposed

This section proposes an analysis of the differences between "views" adopted by product engineers and service designers when dealing with the system concept proposed in order to define the design spaces that should support PSS design. The proposed analysis of the differences between views adopted is illustrated in Figure 41. The proposed system concept (defining "system", "action" and the resulting "interaction") is drawn in the middle of the scheme. Systems interact through actions. Actions can be regarded from one or another side, and the interaction is expressed by a link between actions reflecting the related system role played in. The main differences between the product engineering and the service design views consist in two inter-related aspects: their viewpoints when considering systems and the hierarchical layers adopted. These differences lead to adopt different views on an emerging property of interaction: the "function" or the "outcome" concepts.

Figure 41 Differences between product engineering and service design views regarding the proposed system concept

As discussed in section 4.1.1.4.a, product functions can be seen as intermediary concepts between "actions with" and "actions of" ("actions with" being often bypassed). The system to satisfy drives the goals defined while a progressive decomposition within domains allows defining the physical organization of components that compose the solution, i.e. the product structure. The hierarchy of layers follows a means-end organization from "Why?" (goals driven by system to satisfy and requirements) to "How?" (structure). Product function is an intermediary level (corresponding to "What?") that emerges from the behaviour when a given perspective on goals has been defined. However, service design adopts a different viewpoint. Indeed, the two interacting systems are seen as sets of resources displayed between a provider's and a beneficiary's organizations. They are ideally aligned through the defined service architecture in order to interact within service processes (by defining their respective actions). From these interactions emerge the service outcomes (for the system to satisfy) that correspond to the service designers' goals. In the service design view, the hierarchy of "Why?", "What?" and "How?" is differently adopted on the system concepts than in the product engineering view. Product function and service outcome are both an emerging property of the systems' interactions. However, product engineering considers "function" mainly as emerging from the product behaviour while service design considers outcome as emerging from the interaction. When using functions, product engineering focuses on the "system to be designed" when interacting with its environment (but still regarding the goals): it expresses an expected action it must perform (being subject), an expected property (aptitude) it must have when being the object of an action exerted, or a coupling of both (since the distinction between actions and aptitudes when expressing functions is generally not so clear). Functions are useful to define the expectations the product must satisfy.

When using the "outcome" concept, service design focuses on the "system to satisfy" since outcomes are "effects" of occurring interactions through processes. It better integrates the beneficiary's own processes for value creation, but the clear identification of the service expectations is harder. This analysis of the differences between "views" regarding the system concept proposed should help designers to better communicate. Additionally, this research attempts to support an integrated design progression task of these two views by defining design spaces that fit in both of them.

4.1.3.1.b. Proposal of a PSS design framework for product-service integration

A framework is proposed to support an integrated PSS design process and detailed in Figure 42. The framework defines three design spaces: the "result" represents the problem space, the "structure" represents the solution space, and the intermediary "structural organization" represents a negotiation space The problem and solution spaces are co-evolutionary, since this characteristic has been emphasized in the product engineering literature [START_REF] Dorst | Creativity in the Design Process: Co-Evolution of Problemsolution[END_REF]Cross 2001, Brissaud, Garro, and[START_REF] Brissaud | Design Process Rationale Capture and Support by Abstraction of Criteria[END_REF].

The result space contains the expected actions and their organization. Actions have effects for the beneficiary, i.e. the PSS "outcomes" but, as already mentioned, this space is supposed to have been elicited during the conceptual design phase.

The structure space contains the identified systems and sub-systems that must perform the actions.

Result and structure spaces contain hierarchical layers that are linked by a decomposition link to allow different levels of detail. In the result space, actions can be decomposed (through different types of relations that are detailed in the modelling proposal). This decomposition of the problem is made concurrently with those of the solution. In the structure space, the hierarchy of systems (from the "wider system" to the "sub-systems") decomposes the different layers of boundaries identified.

Result and structure spaces are linked by "design relations" corresponding to the attribution of solution elements to solve elements of the problem. The design relation consists in conjectures though identification of potential solutions fulfilling the results and in validations/verifications of these solutions through (objective or subjective) criteria that allows progressing within the decomposition process [START_REF] Lonchampt | Supporting Problem Expression within a Co-Evolutionary Design Framework[END_REF].

The structural organization corresponds to the expression of the resulting association of the actions and systems, i.e. the interactions between systems (and sub-systems). It corresponds to a negotiation space that links two layers of the hierarchical decomposition while expressing the design relation between the result at the upper layer and the structure at the lower level. Indeed, the structural organization of a system corresponds to the sum of its structure that is composed of sub-systems and of their interactions (that allow the whole system to interact for achieving the design goals).

Figure 42 Proposal of a PSS integrated design framework 4.1.3.2. Design spaces and hierarchies

4.1.3.2.a. System structure: hierarchy of boundaries

A PSS design should start with the identification (even incomplete) of the scope of the study and of the system under study. The "system" considered belongs to a wider system considered during design.

Defining the boundaries of the system means a differentiation between these two types of entities: those belonging to the system (sub-systems or components) from those belonging to the wider system but excluded from the system (external entities).

The system "structure" corresponds to the hierarchical organization of systems (wider system, subsystems, etc.) by defining their boundaries at different levels. The systems boundaries correspond to the set of their interfaces in their set of possible interactions. These interfaces have spatial and temporal dimensions. Product systems are mainly characterized by their physical boundaries since their interfaces have a permanent dimension (once the product created for design) and a tangible aspect characterizing the physical separation between the product and its environment. The definition of a product system and its sub-systems mainly consists in defining the different levels of detail adopted when considering these interfaces. Then, a product architecture expressed by a components' tree constitute a product structure: a product is decomposed into sub-products that are bounded by their spatial interfaces. Boundaries of service units correspond to the limitations of their interventions within the scope of the possible interactions with other systems. Their interfaces have a dynamic dimension and an intangible aspect characterizing their respective responsibilities in the (inter)actions. The hierarchical organization of service units has to be displayed by detailing the responsibilities scopes of each unit to characterize the service structure.

A service architecture linking service units to interventions in actions corresponds to a service structure: a service unit can be decomposed into sub-units that are bounded by their roles within possible interactions.

Result Space Structure Space

Structural Organization Space

Problem Space Solution Space

Negotiation Space

Organization of actions

Organization of interactions

Organization of systems

When defining a PSS structure, it is necessary to define its spatial and temporal interfaces that correspond to its boundaries.

4.1.3.2.b. Result hierarchy

To express the "results" of a system, several types of representation exist that correspond to abstractions of actions. The "result" space also contains hierarchical layers being decomposed. The result hierarchy role is to ensure the traceability of the requirements fulfilment by a progressive decomposition of the design "problem".

4.1.3.2.c. Structural organization: a negotiation space

The result domain emphasizes the organization of actions while the structure domain focuses on the organization of systems (their boundaries). The structural organization must ensure consistency between the expected actions (result) of a system with the sub-systems (structure at a lowest level of decomposition) that have been identified.

The structural organization of a system corresponds to the organization of the sub-systems interactions to provide the expected system results. This domain supports the negotiations between expected result and results emerging from the structure. 4.1.3.3. Using the framework for PSS design

4.1.3.3.a. Role of conceptual design: study of the system in its wider system

Analysing the needs that have to be fulfilled and external constraints allow defining the initial design goals. These goals are translated to formulate the design problem through models used in the "result" space.

During conceptual design, the analysis of the needs and of the expected outcomes for the beneficiary requires the study of the different stakeholders and other systems operating within the "wider system" and participating to the value creation process. Conceptual design provides materials for modelling for example an initial structure of the wider system composed of the PSS and of other entities (external for the PSS). This can support an initial elicitation of the PSS boundaries.

4.1.3.3.b. Defining situational elements

To define properly the expected actions of the system, the "situations" in which the system evolves should be identified. Actions of a system are triggered by external events (caused by external entities). They are submitted to conditions that are related to the states of external entities. A set of stable external conditions is called a context. A set of actions triggered by an event and occurring in a given context is called an external scenario. The different situational elements are presented Figure 43.

4.1.3.3.c. Situational relations between result instances

Since the system "result" displays the required actions for fulfilling the goals, it allows defining the expected system (inter)actions with its external environment. Different external scenarios can be identified that should lead to define several instances of result. Identifying the different situational elements that can vary (occurrence of events or context change) is necessary to define the external scenarios and the result instances.

4.1.3.3.d. Expected actions and system properties

As previously discussed, this research assimilates the functional description with the actions description in the result space. Defining external scenarios of (inter)actions involving system and external entities means defining:  The actions the system performs actively (as a subject);  But also the actions operated on the system being the object. The system properties or "aptitudes" solicited in these actions can be identified in the result space. The expression of a function in product engineering generally does not clearly distinguish the expression of an expected system action from the related system aptitude. In both cases, this supports the problem formulation. Design "constraints" use in product engineering for example can sometimes refer to system aptitudes that are solicited in actions exerted by an external entity (being subject) on the system (being object). Constraints are currently identified in the "problem space". They do not support the problem decomposition but have to be verified by the solutions proposed (Nilsson and Fagerström 2006).

4.1.3.3.e. Detailed design: Internal scenarios for sub-systems

An external scenario is a set of interactions occurring between the system and external entities to fulfil a purpose in a given context triggered by an event. Following the decomposition process, internal scenarios can be identified as sets of internal actions involving sub-systems (i.e. interactions between sub-systems). Internal events related to sub-systems trigger internal scenarios.

4.1.3.3.f. Iterations at different hierarchical levels

By using the structural organization space as a negotiation area that is an intermediary description between the different hierarchical layers of decomposition, the framework supports refining the system design at several levels of detail. The structural organization space supports the switch from the system result-structure level to the most detailed sub-systems levels. 4.1.3.4. Conclusion The system concept and the design framework proposed fit in the existing proposals in the field of Service Engineering (SE) or integrative service approaches. The system concept adopts some of the properties proposed by [START_REF] Quartel | COSMO: A Conceptual Framework for Service Modelling and Refinement[END_REF] for conceptualizing service systems. The design framework aligns the design spaces of existing frameworks in product, system and service engineering in a co-evolutionary perspective that supports all of these approaches to adopt a common design progression. The system concept proposes a definition of "boundary" that supports the specific viewpoints adopted on products and on services. The "structure" space integrates the notions of physical and spatial boundaries progressively identified. It integrates the two concepts of product structure and of service architecture that is a set of organized resources. The "problem" space supports the functional viewpoint of product engineering and the process viewpoint of service approaches. The "structural organization" space allows depicting the interactions occurring between sub-systems and ensuring consistency of the design relations established between two layers of the decomposed hierarchy. It supports negotiations between the problem defined and its effective solving by the solutions proposed. Such negotiations are the basis of the communication process that must be established between product engineers and service designers. The system concept and framework proposed for PSS fulfil the related requirements that have been previously defined. 4.1.4. Proposal of a "multi-views" PSS modelling framework 4.1.4

.1. Implementing modelling tools within the design framework

The standpoint of this thesis is that there is no knowledge on the dimensions that should be modelled to design a PSS but still, that an integrated PSS model must be found to facilitate communication and support design negotiations between the concerned actors (focusing on the product engineers' and service designers' collaboration). The role of modelling tools should then be to facilitate the designers' tasks while creating a communication interface between them. This thesis then proposes reusing some existing models of the PSS literature and adapting these models to create such an interface. Table 6 below summarizes the main existing modelling supports found in the PSS (and related) literature for the detailed design phases. They generally integrate sets of models within a methodology. Several criteria seemed of interest for building an integrated PSS modelling framework:

 Models are integrated in a design methodology: in order to progress until the most detailed phases  Models allow representing products and services as system 'components': in order to support the entire system modelling  Interactions between models (within the methodology) are shown, discussed or detailed: to facilitate design progression and/or integration of products and services.  Models have "privileged users" regarding the scope of the proposal. The coloured lines of Table 6 correspond to the models chosen for building the PSS modelling framework. The two modelling methodologies chosen fulfil all the required criteria and adopt complementary viewpoints:  The modelling tools proposed by [START_REF] Maussang | Product-Service System Design Methodology: From the PSS Architecture Design to the Products Specifications[END_REF] are supportive for designing products in PSS.  The modelling tools proposed by [START_REF] Patrício | Multilevel Service Design: From Customer Value Constellation to Service Experience Blueprinting[END_REF] are supportive for designing services (and software) in PSS. These tools have been integrated within the framework. Models have been necessarily adapted and enriched to be integrated for PSS design.

Framework overview

The overall PSS modelling framework proposed integrates existing product and service engineering models within the design framework details in the previous section. It aims at organizing the discipline-oriented and integrating models within the co-evolutionary framework of the problemsolution spaces. The organization of the models in the framework is schematically represented on Figure 44. The models used in each design space are further detailed in the following sections. Three types of "views" are proposed: a product-, a service-, and an integrated-perspective. Each of the "Product view" and "Service view" attempts to support the entire system modelling by still adopting the current models related to the corresponding discipline. These models allow the specificities of the current practices and focuses ("core ideas") of product engineers and service designers to be maintained while being integrated through the design framework proposed and the system concept adopted. Models proposed are existing ones in the field of product, service and PSS engineering but have necessarily be enriched and adapted to support widening their scope towards the entire system representation in the integrated framework. The "integrated" view is used for integrating both product and service views in the "result" domain. The "integrated view" corresponds to a modelling support that is currently used in product and in service approaches and can be easily appropriated by product engineering and service design views. It must support an agreed decomposition of the "problem" and should ensure the traceability of the choices made by designers after negotiations. It uses an IDEF0/SADT model since this model is used in product-, service-and PSS-design. Adaptations of IDEF0 are proposed to a better compliance with the product/service integration issues. From the so-called "product view", the models used are those proposed by [START_REF] Maussang | Product-Service System Design Methodology: From the PSS Architecture Design to the Products Specifications[END_REF]. This is one of the rare PSS design methods dealing with the "detailed" PSS design phase. It allows refining the PSS architecture until the detailed product specifications at a technical level. The "service view" contains several tools from service design and Service Engineering. Models are mainly adaptations of those proposed by [START_REF] Patrício | Multilevel Service Design: From Customer Value Constellation to Service Experience Blueprinting[END_REF] even if the modelling progression differs in the proposed framework. Process model and service architecture models are proposed. The blueprinting technique is reused since this is an adapted tool for depicting the service delivery operations at a detailed design level. Adaptations of the blueprint are proposed to better integrate the product and service aspects and the characteristics of their interactions in the model. External functional analysis has to be used for each use situation identified through the use scenarios.

The system is initially considered as a 'black box' separated from the external elements (called "outer environment") by a boundary. The system is modelled on a "graph of interactors" on which the service functions are displayed (see Figure 18). Actions are organized throughout a timeline that can be arbitrarily defined. It illustrates the organization of scenarios by displaying the occurrence of events. Once elicited, the PSS boundaries separate the external events (related to external entities) and associated external scenarios from the internal ones (related to internal components). External events ("e") related to external entities can occur and trigger the related external scenario ("E"). Events and scenarios are numbered on Figure 47.: an external event "ex" triggers the associated external scenario "Ex". External scenarios can be decomposed into internal ones ("I") triggered by internal events ("i") that are also numbered. For example on Figure 47, the external scenario E1 (triggered by the event e0) is decomposed into two internal scenarios: I0 (also triggered by e0) and I1 (triggered by an internal event i1).

Figure 47 Process model proposed for PSS result for the service view

Structure model

The structure domain must display the hierarchical organization of the different sub-systems composing systems. The structure models adopted is the Service System Navigation (SSN) model proposed by [START_REF] Patrício | Multilevel Service Design: From Customer Value Constellation to Service Experience Blueprinting[END_REF] in Service Engineering. Adaptations have been made to display similarly the structural elements of the PSS in the product and in the service perspectives and to express the actors' responsibilities.

The resulting SSN model proposed is displayed Figure 48. A service structure (or architecture) model must show the sub-systems identified to provide the expected actions defined in the result. SSN refines the Flow model by affecting the identified sub-systems to their participation in the result, i.e. to the actions identified in the process model (shown on the top of the architecture in Figure 48). This affectation is detailed by the representation of the sub-systems' roles. Roles can be active (entity is the subject of action) or passive (entity is the object). Roles actually correspond to actions but here they are used to express a responsibility and a specific structural element from the service perspective.

Roles are used to define the scope of responsibilities of each entity that is bounded by interaction lines. The roles links expressed by the arrows represent the interface points between the sub-systems. The PSS boundaries and the actors' responsibility lines are represented in the SSN similarly than in the process model.

Structural organization model

The model proposed for structural organization in the service view is adapted from the existing blueprint models in service approaches, like the Service Experience Blueprint proposed by [START_REF] Patrício | Designing Multi-Interface Service Experiences: The Service Experience Blueprint[END_REF]. This model named the Blueprint-Based Model (BBM) is shown Figure 49. The structural organization space supports co-evolution of result and structure by integrating both elements of these spaces in order to support negotiations. The structural organization must display the system structure and the sub-systems interactions to provide the result.

The different graphical elements of both the structure and the result model are expressed in the BBM: it shows elements from the structure model (SSN) by detailing how the sub-systems effectively interact to ensure the system to perform the actions defined in the result model (process model). The roles and their structural links are transformed into actions (having different types of links here) organized within scenarios according to the defined timeline of the process model. The scenarios organization according to the timeline is referred to on the top of the scheme, with the reference to the events.

The BBM decomposes the actions of sub-systems for performing the actions of the process. Actions can be linked by flow transfers or sequential relations. The model allows affecting actions to entities performing them (subjects) while it also shows states of entities, those being acted on (objects) can be represented. A link can be expressed between entities involved in reciprocal actions, i.e. "linked actions".

In addition to the PSS boundaries, responsibility and interaction lines, "visibility lines" can be represented in the BBM. They express the visibility of the entities' actions from the beneficiary's viewpoint. These lines typically correspond to an emerging characteristic of the structural choices that can influence the service outcome (value perceived by the beneficiary) and then lead to negotiations between the problem initially defined (result) and the solutions imagined (sub-systems). As already argued, the structural organization of PSS components is at least as well important as the components themselves in PSS design. On the example provided Figure 51, an initial activity depicting a generic process (result) expected for fulfilling the beneficiary's needs can be expressed in the A-0 diagram. Two external events have been identified (e1 and e2) and associated to two external scenarios (E1 and E2). When decomposing the generic process, two A-0 diagrams can be proposed: the result must be achieved through two instances of external scenarios (E1 and E2) in which the actions required (and activities here) differ: the E1 scenario contains two activities (A1 and A2) while the second scenario contains three activities. After decomposition, two internal scenarios have been identified (named I1 and I2). On Figure 51, activity A11 required in the scenario E1 has two different instances related to the internal scenarios. The IDEF0 model currently supports a progressive decomposition of the "black boxes" but the proposal for displaying instances of diagrams in scenarios at each level allows addition of information when scenarios are progressively identified. The model-building process of the service view is then supported.

action descriptions

Result models provide information on the expected actions that provide the required outcomes for the beneficiary. However, in the product and in the service views, different types of elements are displayed since the service view uses a description of actions while the product view uses a functional description.

The process model in the service view organizes the expected actions temporally according to different events and scenarios identified. It well expresses how the different actors and the PSS components must operate the service delivery within the beneficiary's sphere (wider system) to provide value. However, the links between actions that are not temporal ones are difficult to represent. The functions expressed on the Graph of interactors represent a link between systems (reflecting a link between actions). Functions link the system to the external entities by "functions". As previously discussed, functions emerge from interaction. In this sense, the Graph of interactors could be seen as a "structural organization" model of the system in its wider system. However, it focuses only on the specific interactions of the PSS in order to define its aptitudes (formulation of functions) and misses information on the interactions occurring between the external entities. It is considered as expressing a "problem" for the product view for concurrently defining the expectations for the system actions and its properties. The process model emphasizes the dynamic aspect of the expected actions in time, but misses the representation of the links between these actions, while the Graph of interactors expressively represents these links by functions. However, the Graph of interactors misses the dynamism of these actions (and on the system interactions). Several Graphs of interactors should be required to entirely represent the expected actions of (and "with") the system in its evolving environment. The concurrent use of these two models can facilitate and accelerate the design task through an exchange of information between designers. However, since they use different concepts and emphasize different aspects of the problem, an integrated view is required to formulate and communicate it in a comprehensive manner for both views. The IDEF0 model proposed allows representing the different elements necessary for both product and design views and can be shared by these views.

Multiple problem decomposition processes

In the product view, the functions are decomposed by using a FAST model that follows a means-end relationship. Such decomposition is supportive for tracing the reasons of design choices and ensures the requirements traceability for the choice of structure elements.

The service view organizes the actions sequentially linked into processes and organized within scenarios by the different events occurrence. The actions within processes can then be decomposed into smallest ones following a part-whole relationship. Such a decomposition process well supports human thinking on service delivery by decomposing scenarios that can be associated to durations and frequencies of occurrence. These two approaches for decomposition are complementary and can be integrated by the decomposition proposed in the IDEF0 model. IDEF0 activities well support the representation of functions as well as those of actions that are linked logically by the ICOMs. The diagrams support the representation of the elements defined in models of both the product and service views.

The enrichments proposed allow ensuring the goals achievement throughout the problem decomposition process, since the result defined in the highest diagrams must be achieved while different possible configurations of actions can lead to this achievement. Additionally, it supports the decomposition of the boxes while it still allow adding scenarios progressively during design.

Complementarity of the three views for result modelling

The three views proposed should support product-service integration during PSS design. The coupling of their respective models and decomposition processes is illustrated in Figure 52. Product and service views can be used concurrently to be mutually enriched since they emphasize different aspects and do not display the same type of information. The integrated view allows a common representation shared by the product and the service views. The decomposition links adopted in the three views are complementary and the integrated view should ensure the requirements traceability during PSS design.

Figure 52 Coupling of result models within the design framework 4.1.4.4.b. Coupling structure models Models used in product and service views for structure modelling and decomposition are also coupled as illustrated in Figure 53. At the highest level, the product view initially considers the system as a black box: the initial Block Diagram model displays the external entities while the components are hidden. The service view uses an initial Flow model showing initial structural elements: the actors. These two views can differently elicit the identification of boundaries: in the product view the boundaries are supposed initially known separating the system from external entities; in the service view the actors and entities are (more or less) displayed but the boundaries separating external entities from sub-systems are not systematically elicited.

The Block Diagram of the product perspective is useful to depict spatial aspects of the sub-systems' interfaces and to identify a full set of interacting external entities surrounding the system. The Flow model and Service System Navigation are used to discuss the actors' roles in the value creation process. They can help to better adjust system boundaries and to separate the boundaries of actors' systems (current business structures) from the system under study (PSS structure).

Figure 53 Coupling of structure models within the design framework Each of the structure models corresponds to a specific view that is of interest for product engineers or service designers. However, the two models still support the representation of the entire system, but emphasizing different aspects or "core ideas". Their coupling in the PSS design framework proposed fulfils the related requirements previously established for supporting product-service integration during PSS design.

4.1.4.4.c. Coupling of structural organization models

The same statement can be done for the coupling of structural organization models illustrated in Figure 54. The two structural organization models are based on their related structure models in each view and allow displaying different characteristics of the sub-systems' interactions that are complementary. The product view using FBD emphasizes on the spatial dimension of these interactions by displaying for example the flows circulation and the physical contacts between sub-systems. All the interactions a sub-system has with other entities can be visualized simultaneously on the FBD. However, each interaction (flow, contact or DL) has a specific moment of occurrence in scenarios and this temporal aspect cannot be efficiently visualized in the model. On the contrary, the BBM in the service emphasizes the temporal organization of interactions and details their occurrence in the different scenarios. The roles played within interactions and the visibility / invisibility of actions are supportive for discussing the effective result achievement and balancing the structure definition. However, the BBM requires detailing scenarios as sequences and the entire set of interactions of a sub-system for the result provision is hardly visualized.

Coupling structural organization models of product and service views should provide a more complete view of the sub-systems interactions since complementary viewpoints on these interactions are proposed, emphasizing either their spatial or their temporal dimension.

Figure 54 Coupling of structural organization models within the design framework 4.1.4.5. Summary of the proposal for PSS modelling To summary, this section has proposed a multi-view modelling framework for supporting integrated PSS design. Models currently used by product engineers and service designers and have been adapted to better adopt a system approach on design. They have been integrated within the PSS design framework proposed. The way the coupling of these models and their integration in the design framework could support the communication between product engineers and service designers has been discussed.

A methodology for integrated product-service design

This section provides a proposal for a methodological approach that should support product-service integrated design. The way the methodology should be implemented and shared among the different PSS design actors and throughout an integrated design process is not mentioned. This proposal mainly aims at organizing the modelling task into steps of a PSS design methodology, as shown in Figure 56. During the conceptual phase of PSS design, the system is studied within its wider system, i.e. within the beneficiary's sphere in which it operates. The beneficiary's needs and expected benefits must be analysed, and the other actors operating within processes for value creation must be understood. The initial PSS structure model of the service perspective (the Flow model of actors) can be drawn during this conceptual phase, in order to define the initial PSS boundaries. Strategic orientations of the business company must be integrated during this phase. Several possible PSS concepts can be imagined, (qualitatively) evaluated and selected. At the end of this phase, a decision is made for selecting a PSS concept, and expected outcomes are defined. The PSS detailed design phase is then initiated. The PSS outcomes are the goals to achieve for designers. Adjustments and changes in the outcomes defined can be made during design, but this thesis does not deal with these aspects. They should be supported by the relationship management between the PSS designers and the beneficiary (ideally involved). Products and services must be integrated during the PSS detailed design phase. A result-structure formulation must be found. It is initially supported by the PSS concept identified during conceptual design. The modelling task co-defines and co-decomposes result and structure that are co-defined. External entities and the initial "principles" of sub-systems can be displayed. The following phase consists in decomposing the result and the structure elements while establishing the design relation, i.e. affecting structure elements to result elements. Finally, the structural organization models allow representing the decomposed system structure and its internal organization for providing the result. Design negotiations could occur to refine the system design. An agreed set of sub-systems and their specifications should be defined. A decision-making, named a "decision node" is required between the system's hierarchical levels. The structural organization model supports negotiations on the subsystems' choice and on their organization. By establishing the sub-systems' specifications, a new result-structure is formulated and the modelling task van be iterated. Design decisions can also require choosing between several alternatives or analysing the design in order to define (re-)design priorities. For supporting this decision-making during PSS design considering the environmental issues, an evaluation framework is proposed in this thesis. The proposal for a conceptual framework supporting PSS environmental evaluation during design is detailed in the next part of this chapter.

Figure 56 Proposed framework for integrated product-service design during PSS detailed design

PSS

Conceptual design

Strategic phase

PSS Detailed design

Productservice integration phase The limitations of using the Functional Unit concept in PSS LCA and of defining a PSS life cycle have been analysed. They are illustrated here by the case used through the industrial collaboration.

4.2.1.1.a. Definition and relevance of Functional Unit (FU)

As previously mentioned, the collaboration started with Life Cycle Assessments performed on two offers: a product-oriented and a PSS (result-oriented) ones, using compressed air delivery systems. These offers were declared "equivalent" regarding the beneficiary's needs, which have been assimilated to the air consumption profile (in equivalent pressure ranges, temperature and dew points) requiring the same type of technologies for compression (air-cooled, oil-lubricated and screw compressors). The main difference identified between the customers' needs was the required air availability. The customer of the product-oriented offer needs a lower availability rate of the compressed air than the PSS customer. For this reason, he buys the plant equipment, performs the first-level maintenance operations and pays for second-level maintenance operations when necessary. On the contrary, the PSS customer prefers paying per unit of use (in the defined contract terms) since it ensures a higher availability of air.

A Functional Unit has been defined for comparing these two offers in LCA, as follows: "Using electrical energy for ensuring the continuous supply (availability) of pneumatic energy to the customers' piping network during 10 years (duration of the contracts) with a defined level of air quantity (production capacity), air quality defined air pressure and temperature ranges, hygrometry, oil and particles content), and energy ratio (between rates of electrical energy consumed for pneumatic energy provided)". (In the offers considered, the resulting "continuity" of air supply expressed by the air availability rate differs between offers. However, in a PSS design process, one can imagine defining the same availability rate in the FU and considering a different maintenance scenario in the product-oriented offer for ensuring this rate).

The limitations of the FU concept can be illustrated with this example. As discussed by the literature, FU supports comparison of systems that are supposed to provide the same output while the way these outputs effectively fulfils the related needs is not dealt. Indeed, the PSS customer has other needs that explain the PSS adoption: he also needs a flexible offer because of the changes that can occur in his production area. Since the contract started, his production profiles have changed and machines have been added. His need often evolve and the provider (AC company) must adapt his offer consequently. Moreover, this customer has experienced a lot of difficulties with his previous maintenance contractor (of the previous plant), and now he attaches a great importance to the relationship: frequent communication of information, provider's advice and continuous dialogue process. His trust is also based on his perception of the service quality and efficiency: highly specialized skills, service reactiveness, etc.

All these aspects are frequently emphasized in the service literature but not integrated in the FU concept of LCA. However, they actually constitute the way the needs are effectively fulfilled.

The customer of the product-oriented offer has different needs: he perceives the investment for equipment as economically more viable than a service contract considering the lowest importance he attaches to the air availability. Additionally, he owns second-hand machines that are able to relieve the new ones in case of failure. He perceives as economically advantageous to spend time for first-level maintenance instead of paying for a full service contract. The needs of these two customers are strongly different. These differences explain the adoption of different types of solutions (contracts) despite the fact that their tangible and measurable output (defined in FU) can be seen as (more or less) "equivalent".

As underlined by the brainstorming, the re-design process was oriented by qualitative evaluations made by the actors on the potential benefits / costs (or risks) of each scenario.

Then, a tool based on Value Analysis would be better adapted to the comparison of solutions: it allows comparing alternatives regarding their relative benefits for the customer that are balance with the costs generated.

4.2.1.1.b. PSS life cycle modelling for re-design

The issues of defining and modelling the PSS life cycle have also been raised by the industrial collaboration, when comparing the LCA made for the product-oriented offer compared to those made for the PSS one. Indeed, the difficulties underlined in the design part for defining a "service" concept and the resulting boundaries also have implication for defining a PSS life cycle. Moreover, a gap has been identified between the LCA results shared and the re-design alternatives (ideas and scenarios) that have been identified and discussed during the brainstorming.

In the adopted approach, the LCA results were grouped into "hot spots" within the PSS life cycle. The LCA results decomposed the impacts by affecting them to products' life cycle phases or services (like maintenance). However, products and services are integrated in PSS design.

The PSS life cycle model initially built "on ground" was based on the viewpoint that a PSS life cycle can be seen as the "sum" of products' and services' life cycles (even if the service life cycle was not clearly defined) but strongly missed the integration characteristic of their design for achieving specific goals.

The scenarios built during the brainstorming strongly emphasized the inter-related influences between design parameters of integrated sets of products and services, and their resulting potential benefits or costs for the customer.

A PSS environmental evaluation that efficiently supports PSS (re)design must displays the evaluation results in a comprehensive manner for PSS designers, i.e. considering the product-service integration for achieving defined goals.

Value Analysis for environmental evaluations during design

In the product engineering field, Value Analysis is a powerful tool to evaluate (product) solutions during design while considering their respective Values, i.e. the ratio between their benefits and costs. The Value concept is promising for PSS eco-design since it potentially encompasses the concepts of beneficiary's needs satisfaction and those of costs that can be switched from the economic dimension towards the environmental impacts (EI) generated.

Adapting VA for PSS would support a better integration of the service view in the environmental evaluation process during design.

4.2.1.2.a. Value Analysis (VA) in product engineering

Value Analysis (VA) considers the value as a ratio between the provision of benefits and the economic costs. The value of a product is defined as the ratio between the adequacy of the product to fulfil a need and its (economic) cost:

𝑉𝑎𝑙𝑢𝑒 𝑜𝑓 𝑎 𝑝𝑟𝑜𝑑𝑢𝑐𝑡 = 𝐴𝑑𝑒𝑞𝑢𝑎𝑐𝑦 𝑜𝑓 𝑡ℎ𝑒 𝑝𝑟𝑜𝑑𝑢𝑐𝑡 𝑓𝑜𝑟 𝑎 𝑛𝑒𝑒𝑑 𝑃𝑟𝑜𝑑𝑢𝑐𝑡 𝑐𝑜𝑠𝑡
Value Analysis is widespread in France in standards (AFNOR. Nf X50-100 1996) and is supported functional analysis [START_REF] Delafollie | Analyse de La Valeur[END_REF]. VA supports analysis performed on a specific solution (product) or comparison of solutions. The method is divided in 7 phases [START_REF] Delafollie | Analyse de La Valeur[END_REF]):

1. Orientation of actions in VA 2. Information search 3. Functional and cost analysis 4. Solutions search 5. Solutions study and evaluation 6. Presentation of the retained solutions and forecasted financials 7. Realization reporting The core of the analysis approach consists in the functional and cost analysis in phase 3 [START_REF] Chevallier | Produits et Analayse de La Valeur[END_REF]. Several methods can be used for these two analyses [START_REF] Delafollie | Analyse de La Valeur[END_REF]. Functional analysis currently separates the functional requirements that refer to the identification of external functions for needs' fulfilment (like in the Graph of interactors) from the technical functions that are affected to the product components (like in the FAST) and correspond to designers' decisions. Cost analysis in VA allows using different calculation methods of cost. Economic costs are calculated for components and affected to functions in which the components are involved.

Classical tools of VA for analysis and solution choice

To performs the analysis of the solution designed (phase 3) or choosing between several solutions alternatives (phase 5), VA uses the function concept. A function id characterized by three attributes [START_REF] Yannou | Proposition de Deux Nouveaux Outils D'aide à La Décision En Analyse de La Valeur Basés Sur Une Définition Opérationnelle de La Valeur[END_REF]: its cost (relatively to a solution); its importance (independent of any solution); and its satisfaction (relative to a solution). The "importance-cost histogram" and the "solution choice matrix" are tools used in VA for either analysing the design in the former case or choosing between alternatives in the latter case. The use of the function attributes in these tools is illustrated in Figure 57. The classical "importance-cost histogram" shows the repartition of the functions importance (regarding the customers' needs to fulfil) and costs (an illustration is provided in Figure 58). This tool supports the analysis of the importance / cost ratio for each function. When the ratio is weak, the function implementation (through the solution) is questioned.

Figure 58 Example of "importance-cost" histogram proposed in VA For selecting a solution among several alternatives, the classical "solution choice matrix" defines a scoring of each solution. The scoring integrates the degree of satisfaction of the functions by the proposed solutions and the relative importance of each function. Functions can be associated to an importance 𝐼 𝑖 qualitatively defined (1=useful, 2=important, 3=essential). For each solution 𝑋 𝑗 the satisfaction 𝑆 𝑖𝑗 of each function j is defined (1=questionable, 2=intermediate, 3=well-adapted).

The overall "score" of each solution is calculated for hierarchizing solutions as follows [START_REF] Yannou | Proposition de Deux Nouveaux Outils D'aide à La Décision En Analyse de La Valeur Basés Sur Une Définition Opérationnelle de La Valeur[END_REF]after AFAV 1994):

𝑆𝑐𝑜𝑟𝑒(𝑠𝑜𝑙. 𝑋 𝑗 ) = ∑ 𝐼 𝑖 * 𝑆 𝑖𝑗 𝐹𝑢𝑛𝑐𝑡𝑖𝑜𝑛𝑠 𝑖
The solution having the highest score is selected. The solution choice table is illustrated in Table 7.

𝐼 𝑖 Solution 1 𝑆 𝑖1 Solution 2 𝑆 𝑖2 Function 1 3 2 2 Function 2 2 3 2 Function 3 1 1 2 Score (𝑋 𝑗 ) 13 12
Table 7 The classical solution choice table [START_REF] Yannou | Proposition de Deux Nouveaux Outils D'aide à La Décision En Analyse de La Valeur Basés Sur Une Définition Opérationnelle de La Valeur[END_REF] Enriched tools for VA Showing some weaknesses of these tools and the way they somewhat miss an adequate definition for "value" [START_REF] Yannou | Proposition de Deux Nouveaux Outils D'aide à La Décision En Analyse de La Valeur Basés Sur Une Définition Opérationnelle de La Valeur[END_REF] proposed different approaches for analysing the relative values of functions and choosing solutions. For analysis, the "importance-cost histogram" is replaced by a calculation of the relative values of functions that integrates the "satisfaction" in the analysis by using the definitions:

𝑉𝑎𝑙𝑢𝑒 𝑜𝑓 𝑎 𝑓𝑢𝑛𝑐𝑡𝑖𝑜𝑛 𝑖 𝑓𝑜𝑟 𝑎 𝑠𝑜𝑙𝑢𝑡𝑖𝑜𝑛 𝑋 𝑗 = 𝐼𝑚𝑝𝑜𝑟𝑡𝑎𝑛𝑐𝑒 × 𝑆𝑎𝑡𝑖𝑠𝑓𝑎𝑐𝑡𝑖𝑜𝑛 𝐹𝑢𝑛𝑐𝑡𝑖𝑜𝑛 𝑐𝑜𝑠𝑡 = 𝐼 𝑖 * 𝑆 𝑖𝑗 𝐶 𝑖𝑗
𝑅𝑒𝑙𝑎𝑡𝑖𝑣𝑒 𝑣𝑎𝑙𝑢𝑒 𝑜𝑓 𝑎 𝑓𝑢𝑛𝑐𝑡𝑖𝑜𝑛 = 𝐼𝑚𝑝𝑜𝑟𝑡𝑎𝑛𝑐𝑒 × 𝑆𝑎𝑡𝑖𝑠𝑓𝑎𝑐𝑡𝑖𝑜𝑛 × 𝑃𝑟𝑜𝑑𝑢𝑐𝑡 𝑐𝑜𝑠𝑡 𝐹𝑢𝑛𝑐𝑡𝑖𝑜𝑛 𝑐𝑜𝑠𝑡 The graph expressing the following relation is used:

𝐼𝑚𝑝𝑜𝑟𝑡𝑎𝑛𝑐𝑒 × 𝑆𝑎𝑡𝑖𝑠𝑓𝑎𝑐𝑡𝑖𝑜𝑛 = 𝑓 ( 𝐹𝑢𝑛𝑐𝑡𝑖𝑜𝑛 𝑐𝑜𝑠𝑡 𝑃𝑟𝑜𝑑𝑢𝑐𝑡 𝑐𝑜𝑠𝑡 )
The gradient of the straight line linking a function-point to the origin measures the relative value of the function.

For selecting solutions, a scoring is proposed that integrates the cost dimension. The value of a solution j in a function i is defined and named 𝑉 𝑖𝑗 . This allows defining differently the solution choice table expressing the relative values of solutions within functions.

4.2.1.2.b. Interest and difficulties of using Value Analysis (VA) for PSS

Tools proposed in VA would be of major interest for supporting the integration of the service view in PSS evaluations. Indeed, VA specifically integrates the notion of needs fulfilment (through function satisfaction and function importance) that are balanced with the economic costs generated (that should be replaced environmental ones). However, VA adopts a product view based on functions. But several differences have previously been underlined between the hierarchical layers adopted in product engineering and those of service design.

In order to adapt VA for PSS evaluation, it is necessary to replace its existing hierarchical layers by other ones that can fit in both product and service design views.

Proposal of a conceptual framework for PSS environmental evaluation during design

This section details the different parts of the proposal made in this thesis for PSS environmental evaluation during design. First, an "environmental view" on the system is proposed in section 4.2.2.1 to support the definition of a PSS life cycle and the environmental evaluation during design. Section 4.2.2.2 proposes a PSS life cycle definition and its related model. Tools for supporting the environmental view on the system are proposed. Section 4.2.2.3 shows how the VA tools can be adapted for PSS. A costs analysis based on the life cycle definition and model is proposed to evaluate the environmental impacts in section 4.2.2.3.a. An environmental evaluation framework based on VA is proposed section 4.2.2.3.b. The resulting proposal for an environmental evaluation methodology is detailed in section 4.2.3.

Proposal of a PSS environmental view

This thesis proposes adopting a specific "environmental view" for PSS environmental evaluation. The all set of "spaces" to take into account during the eco-design process and the specific views on the hierarchical levels that can be adopted are shown in Figure 59 The needs, goals, and problem-solution spaces previously identified are shown. Additionally, a "resources space" is defined. It corresponds to the products' and service units' life cycles that should be identified for defining the PSS life cycle.

Figure 59 Proposed PSS eco-design spaces and the specific "views" adopted on their hierarchy As previously discussed, specific hierarchies of "Why?", "What?" and "How?" are adopted on these spaces by the beneficiary and the PSS designers. Issues of integrated product-service design have been dealt in the previous section by the definition of a co-evolutionary design framework between the "problem" and the "solution" spaces to be adopted by product engineers and service designers. The issues of integration of the beneficiary view (adopting a different viewpoint on the hierarchy) with those of designers has not been dealt but is supposed to have been partially elicited during the conceptual design phase. The products' and services' life cycles are considered as resources necessary for the provision of benefits (outcomes) fulfilling the beneficiary's needs. The hierarchy of spaces when dealing with the PSS life cycle definition should correspond to an alignment of the beneficiary view with the environmental one:

 "Why?" corresponding to the needs' fulfilment through outcomes provision;

 "What?" corresponding to the PSS: a set of products, services and their structural organization (to provide the outcomes);  "How?" corresponding to the life cycles of the products and services defined. The proposed environmental view supports the definition of the PSS life cycle and of the environmental evaluation framework proposed.

Proposal of a PSS life cycle concept and model

4.2.2.2.a. Proposed "life cycle" definition based on the system concept

Based on the system properties defined for PSS design, a system "life cycle" definition is now proposed. Using the environmental view, products' and service units' life cycles are the means used for PSS realization. They correspond to "resources" that can be physical or mental. These resources carry the sub-systems' aptitudes that allow them to (inter)act for outcomes provision. Aptitudes can be product functions, or service units' skills, knowledge and know how. A system life cycle is a set actions existing for the supporting aptitudes acquisition, use, and sustainment and / or valorisation. Aptitudes are system properties: a sub-system life cycle is a set of actions operated on its physical or mental resources (carrying the aptitudes). An example of a service unit life cycle is shown in Figure 60. This unit is supposed to operate in the PSS offer of AC and is responsible for monitoring the plant and performing remote diagnosis. The unit aptitudes considered are its software tools expertise, and its ability to analyse machines data. These aptitudes are related to different sets of actions for their acquisition, their solicitations in PSS processes, and their possible valorisation or reuse. These actions constitute the service unit life cycle.

Figure 60 Example of a service unit life cycle Based on the system concept proposed, the system life cycle uses the notion of sub-systems being "resources" carrying and delivering aptitudes. This definition well fits in the current viewpoint adopted on services in the literature: they are generally seen as requiring intangible resources being skills or knowledge. By using this definition of life cycle that fits with both the product and the service unit cases should support the PSS life cycle modelling.

4.2.2.2.b. Proposed PSS life cycle model

The PSS life cycle corresponds to the set of actions for acquiring, using and valorising its aptitudes. These aptitudes are used in the PSS (inter)actions to provide the PSS outcomes. Since the design decomposes the system into sub-systems, the sub-systems aptitudes are decomposed as well. At any decomposition level during design, the PSS life cycle corresponds to the set of products', service units' life cycles that are integrated in the PSS process to provide the outcomes. The PSS life cycle actions are defined by:  Those in which the system (decomposed into sub-systems) aptitudes are solicited (PSS process) for providing outcomes  Those in which the system (decomposed into sub-systems) should acquire and sustain / valorise / eliminate its aptitudes. The resulting PSS life cycle model is illustrated in Figure 61. The set of entities that are integrated in the evaluation scope are represented on the left side by busing the graphical elements of the design proposal. Different sets of actions are represented along the PSS life cycle at the top of the figure. They are distinguished in categories:

 Actions of the PSS process (solution) in which sub-systems interact.

 Actions of the sub-systems' life cycles, that can occur: o before the PSS process for aptitudes acquisition: their "Beginning of Life" (BoL); o after the PSS process for aptitudes sustainment or valorisation (or material elimination for products): their "End of Life" (EoL). To simplify, actions of the second category (BoL and EoL) are named "Life Cycle actions" (despite the fact that actions occurring in the PSS process are excluded). In Figure 61, interactions are represented here by marks that correspond to solicitations of aptitudes in actions.

Figure 61 PSS life cycle as a set of integrated resources' life cycles

The life cycle model and the life cycle Matrixes are used in the environmental evaluation framework.

4.2.2.2.c. Tools for PSS environmental view

Since all the challenges of integration are not dealt in this thesis, simplified tools are proposed between the spaces proposed to link the views for PSS environmental evaluation. Life cycle Matrixes should facilitate the link between the design, the beneficiary and the environmental views. These Matrixes are shown in Figure 62. The Design Matrix (DM) can be used to link the PSS actions (result) to the sub-systems identified (structure). Actions and structure can be progressively decomposed during design. The DM ensures the links between these spaces. At a given level of design decomposition, actions and structure are identified. Structure elements are affected to the actions by their required properties; or "aptitudes" to (inter)act. DM can also be used during design for negotiating the structural organization of the system: since it shows the expected properties of sub-systems involved in actions, it can support negotiations of the sub-systems' specification before modelling iterations. Negotiations loops can occur between the structural organization models, sub-systems' specifications proposed, and result-structure models of the sub-systems by using the DM. The two other matrixes proposed are used to align the evaluation of the design artefact (the resultstructure defined) on the goals pursued (the PSS outcomes) and on the means employed (the subsystems' life cycles). The Problem Matrix (PM) is used to represent the mutual influences between the PSS actions defined and the PSS outcomes provided. The Resource Matrix (RM) is used to represent the link between the sub-systems defined design and the actions of their life cycles. PM and RM are used as simplified links with the transversal views (the beneficiary and the environmental ones), since the issues of their full integration in the PSS design process are not dealt. In this thesis, VAbased tools are proposed for performing the "costs analysis" (step 3 in VA) in order to identify the environmental "hot spots" of the PSS design, and for performing the PSS evaluation (step 5 in VA) in order to compare design alternatives.

4.2.2.3.a. Environmental Costs Analysis

The "cost" name is given to the environmental impacts in order to show how the VA concepts are adapted here. The costs analysis in VA supports the solution costs calculation and questioning.

The PSS life cycle Inventory (LCI) is required for PSS environmental evaluation as well as tools for costs analysis of the system. Two types of costs are supposed to be extracted from the PSS LCI (by using environmental databases): the costs of "Life Cycle" (LC) actions and the Direct Actions Costs (DAC).

Considering the PSS life cycle:  The costs of LC actions actually correspond to costs of actions occurring in the BoL and the EoL in the PSS life cycle  The DAC correspond to costs of actions occurring in the PSS process (for outcomes provision). They are distinguished by the colour code used in Figure 61: actions (and phases) in red generate the resources costs (RC) of the PSS; actions of the PSS process in grey generate the Direct Actions Costs (DAC). The PSS LCI is supposed to allow these costs calculation. The issues of data collection during design are not dealt here.

The costs analysis tool proposed aims at affecting (allocating) the costs generated over the PSS life cycle (LC actions) to the actions of the PSS process. This analysis should support the identification of the "hot spots" directly on the system being designed. Design alternatives would be easy to generate. The approach proposed for PSS environmental costs analysis is summarized in Figure 63. The costs analysis uses the life cycle Matrixes to perform allocations and is composed of three main steps (using a colour code on the Figure ):  First, the Life Cycle Inventory (LCI) allows calculating the costs of all the actions related to the PSS life cycle (LC and Direct).  Then, the costs of LC actions of sub-systems are affected to their aptitudes by using the Resource Matrix (RM). The costs of aptitudes are named Resource Costs (RC).  Finally, the RC are affected to the PSS actions. The sum of the RC and of the Direct Actions Costs defines the Allocated Costs of Actions (ACA).

Figure 63 Proposal of a PSS environmental costs analysis approach

The next sections detail the allocation mechanisms proposed. They are based on the attribution of "importance" coefficients in the Matrixes.

Resources Costs

If the identification of the actions composing the products' life cycles is quite easy, those of service units should be facilitated by the Resource Matrix (RM) use.

The RM can be used for linking the actions of the BOM and of the EOL of the sub-systems' life cycles to the aptitudes. The previous service unit life cycle example defined in Figure 60 is reused here. The RM associated is shown in Table 8. Some life cycle (LC) actions (BOM and EOL) are necessary for the aptitudes acquisition or valorisation.

In the example, the software expertise is valorised by the records' reporting. The expertise can be used in other contracts, avoiding additional software training sessions. Similarly, the experience feedback allows intensifying the use of the ability to analyse machines' data: a single FMEA supports several contracts.

The LC actions have costs (EI) generated for defined "flows of aptitudes". In a similar approach than for the "product flow concept", the "quantities" of properties that are solicited in the PSS should be defined in the LCI. When aptitudes can be reused, the LC actions costs should be decreased. The RM can be used for performing the PSS costs analysis. The costs of aptitudes named Resource Costs (RC) are calculated.

The RC calculation can be made by using different allocation mechanisms.

The costs of LC actions can be calculated and affected to the aptitudes in which they are solicited. For example, the cost (EI) of the software training action can be affected to the software expertise. The cost of the documents reading action can be affected to the two aptitudes and weighted by coefficients.

The RC corresponds to the sum of the affected costs of LC actions to an aptitude. The second mechanism distributes the costs of LC actions of each sub-system between the aptitudes. The all costs of LC actions are calculated for a defined sub-system and affected to the aptitudes according to their importance (with a necessary consideration for some aptitudes' reuse). Estimation of the relative importance of aptitudes is made by designers. The costs of the LC actions are distributed between them, as shown in the example provided by Table 9. This mechanism is preferred in the following chapter detailing the case study.

Aptitudes distribution

The Design Matrix is used to perform the affectation of the RC in the actions of the PSS process. DM is built with information from design: a set of actions are defined and associated to a set of subsystems. The sub-systems (inter)act in the actions through the aptitudes solicitations. A DM example is shown in Table 10. The action A1 solicits the product aptitude 1 and the Service Unit aptitudes (1 and 2).

PSS PROCESS ACTIONS SUB-SYSTEM APTITUDE A1 A2 A3 Product Apt. 1 X X Apt. 2 X S. Unit Apt. 1 X X Apt. 2 X Apt. 3 X Table 10 PSS Design Matrix
To the costs of aptitudes (RC) are affected to actions by using the DM: their costs are distributed according to relative importance of their solicitations. The importance of aptitudes solicitations is distributed like in Table 11. Here, the aptitude 1 of the product is solicited in the two actions A1 and A2. The relative importance of the solicitations is distributed as follows: 80% in A1 and 20% in A2. Table 11 Distribution of the relative importance of aptitudes solicitations in the DM Like the DM, the distribution of importance coefficients can be supported by the design models and particularly the structural organization ones. Indeed:  The product view (of structural organization) supports the identification of all the interactions a sub-system has: the entire set of its aptitudes and of their solicitations can be defined.  The service view (of structural organization) supports the identification of several occurrences of the solicitations within scenarios. The coefficient choices for each aptitude solicitation can integrate the aspects of duration and frequency.

An example of distribution is shown Table 12 dealing with actions of a maintenance scenario for repairing a failed compressor 2 . Three actions have been defined in the PSS process for the maintenance scenario:  Dismantling operation  Failed module detection and diagnosis  Repair operation These three actions solicit aptitudes of the technical unit responsible for maintenance and of the compressor (adaptation functions). The dismantling operation solicits the compressor aptitude to be dismantled (for example a modularity property) as well as the technical unit knowledge on the machine's modules. The failed module detection also solicits this knowledge. The repair operation solicits the aptitude of the compressor to be repaired (reparability property) and the repair expertise of the technical unit. The knowledge on modules is solicited in several actions: more importantly in the failure detection and diagnosis (relative importance of 75% compared to the all solicitations) than in the dismantling operation (relative importance of 25%).

Costs Analysis Table

The previous distribution tables support the calculation of the allocated costs of the PSS actions. Allocated cost of Action corresponds (ACA) to the sum of the direct action cost (DAC) and of the resource costs (RC) affected to this action, i.e. the sum of affected costs of the aptitudes solicited in this action. The Functional Unit of LCA should be replaced by the PSS outcomes supposed to fulfil the needs.

The PSS expected outcomes are defined during the conceptual design phase and must reflect the expected PSS characteristics from the beneficiary view. They can encompass PSS functions and quantitative dimensions but also more intangible aspects of the PSS expected benefits and qualitative criteria of appreciation.

Outcomes are associated to a relative importance for a (specific) beneficiary. Considering a PSS solution, outcomes are associated to attributes of satisfaction and costs.

Issues raised

The proposed framework for adapting VA to PSS environmental evaluation raises several questions on the definition of outcomes and their roles considering the needs to fulfil. They correspond to emerging characteristics of PSS regarding the beneficiary's perception. Their definition and the system evaluation regarding their provision contain challenges that are not explored in this research.

For such a reason, the VA-based framework is mainly a conceptual proposal. It illustrates how the PSS environmental evaluation should evolve to better integrate some intangible dimensions. The VA-based tools are applied only for comparing design alternatives in this thesis. Absolute considerations for benefits provision and costs generation would not be meaningful considering the scope of this thesis.

Proposed VA-based tool This research proposes adapting the VA tool proposed by [START_REF] Yannou | Proposition de Deux Nouveaux Outils D'aide à La Décision En Analyse de La Valeur Basés Sur Une Définition Opérationnelle de La Valeur[END_REF] for choosing between design alternatives (Solution choice table), in which "solutions" correspond to PSS actions supported by resources, and "functions" are now replaced by "outcomes". Each outcome i should be associated to:

 An importance 𝐼 𝑖 (regarding the needs of a specific beneficiary).  A satisfaction 𝑆 𝑖𝑗 for a defined PSS j.  A cost 𝐶 𝑖𝑗 for a defined PSS j.

The costs of PSS outcomes are defined by an affectation of the costs of the PSS actions. This affectation can be made based on the Problem Matrix (PM). The PM is shown in Table 14. As for costs analysis, the costs of PSS actions (ACA) can be affected in the outcomes according a distribution of their importance.

PSS OUTCOMES

Outcome 1 Outcome 2 Outcome 3 Interest of the conceptual VA-based framework: an integrated view on "value" In an ideal PSS design process, the VA-based framework for environmental evaluation should support a better integration of views of the beneficiary, of the product engineers and service designers and of the environmental expert.  The importance 𝐼 𝑖 of outcomes would be defined by the beneficiary (involved in the design process);  The satisfaction 𝑆 𝑖𝑗 of outcomes for each solution would be negotiated between the beneficiary and the PSS designers;  The affected environmental cost 𝐶 𝑖𝑗 would be negotiated between product engineers, service designers and the environmental expert. The alignment of the different perspectives of these actors through the value concept should facilitate the actors' co-creation. The VA-based conceptual framework should support the building of an integrated view on "value" to create between these different actors. It should ensure consistency between the PSS solution being designed (by the product engineers and the service designers), the goals pursued by this solution (generating benefits for the PSS beneficiary), and the costs concurrently generated for the benefits creation (the environmental impacts).

PSS ACTIONS A1 X X A2 X X A3 X X X

Proposal of a PSS environmental evaluation methodology

An environmental evaluation framework is proposed that integrates a VA approach. A PSS life cycle has been defined and a model proposed. This model is used to initiate the environmental evaluation of the system. The proposed methodology for PSS environmental evaluation during design is illustrated Figure 65. The methodology couples those of LCA with the Value Analysis adapted to PSS. The three first steps (and the fifth) of the VA method are coupled to the steps proposed in the LCA standard 3 .

Goal and scope

First, the goal and scope of evaluation must be defined. Goal of evaluation can be the definition of the (re)design priorities or comparison of design alternatives. The outcomes must be identified. The scope of the study must define the actions of the PSS process, the sub-systems, and the external entities considered. Environmental indicators are selected for the environmental costs calculation. Assumptions must be declared. Inventory Inventory corresponds to information search and data collection. Data are implemented in the PSS life cycle model for EI (costs) calculation. Data can be collected from the design models or from existing systems' life cycles. The issue of information and data collection during design is not dealt in this thesis. Environmental databases are used to couple the PSS life cycle data with EI data.

Value Analysis

The proposed tools for VA-based environmental evaluation are used in this phase. The costs analysis allows identifying the main system "hot spots" in the Costs Analysis Table and directly questioning its design. The VA-based comparison is only used here for alternative selection. Costs and satisfaction should be affected to the outcomes (importance being defined independently of any solution). The Solution Choice Table is used to select the "best" PSS alternative.

Generic framework proposed

The proposed PSS integrated design methodology and the PSS environmental evaluation ones are integrated in the larger framework proposed for integrated PSS eco-design. The framework is shown in Figure 66. The PSS eco-design conceptual phase allows defining the PSS outcomes. During the PSS detailed design phase, the PSS life cycle integrated design should be continuously supported by the environmental evaluation. A relation should ensure continuous communication between designers, beneficiary, and environmental experts. In the proposed approach, only two aspects of this relation are dealt (expressed on the scheme by the two links between the conceptual phase and the detailed eco-design phase):

 The initialization of the PSS integrated design during the detailed phase by the PSS outcomes.  The PSS environmental evaluation that should be made regarding the outcomes provision. The PSS life cycle integrated design should be linked to the environmental evaluation by the PSS life cycle model. The integrated design task allows building the model that is then used for performing evaluation. The integrated PSS design results in the building of the Design Matrix (DM) for integrating products and services. However, the two latter designs correspond to "internal challenges" of integration that have been previously discussed out of the research scope. In order to integrate the different life cycles of the resources (products and services), the Resource Matrixes can be used to couple the products' and services' life cycle models with the integrated PSS model. This results in a proposal for PSS life cycle model that supports the environmental evaluation during design. Continuous environmental evaluation can be made during PSS design to question the design choices and selecting a design alternative. The PSS life cycle model supports the representation of sets of products and services integrated in the system for outcomes provision and the evaluation tools allow questioning this design regarding its costs and the effective benefits for the beneficiary.

Scope of the thesis contributions to integrated PSS eco-design

The proposals made are focused on the product-service integration issue. The emphasis has been put on the integrated product-service modelling for supporting PSS design, and on the environmental evaluation based on PSS life cycle definition considering an integrated set of sub-systems' life cycles. However, many other issues are necessarily linked to those of product-service integration. The proposed framework for integrated PSS eco-design (shown in Figure 66) ideally requires solving the issue of product-service integration in addition to the internal PSS issue of integrated product and service design and eco-design. Since this thesis focuses only on the product-service integration issue, some tools for linking the product-service interface with the "internal" views are then proposed: the Design and Resource Matrixes. In further research, it would be of interest to progress towards the integration of the all actors concerned by the sub-systems' life cycles in the PSS integrated design process.

The proposed framework for environmental PSS evaluation reuses the principles of VA. It should ideally allow performing analyses and evaluations of the design by balancing the PSS costs (EI) with the benefits provision for the beneficiary. The VA-based evaluation framework would be strengthened by a better integration of the beneficiary view, and on the expected outcomes. However, the processes and tools for supporting their understanding and definition are not dealt in this thesis. The Problem Matrix is proposed to integrate the beneficiary view in the PSS environmental evaluation. Since the VA-based evaluation is a conceptual framework that still requires to be strengthened, it is only used for comparing PSS design alternatives. The proposal made is a basis for further research to progress towards a better integration of the beneficiary's consideration in PSS environmental evaluations.

Application of the PSS eco-design methodology

This Chapter aims at illustrating how the proposed PSS eco-design methodology can be used. The industrial case of Ets André Cros (AC) is used as a basis to apply the methodological tools proposed. This chapter is organized as follows. Section 5.1 introduces the case by detailing essential elements that should have been identified in a hypothetical "conceptual design phase". Details on the PSS offer, on the actors involved in the value creation process of the beneficiary, and on the contractual commitment are provided. The PSS outcomes that have been retained in this study are explained. The PSS modelling framework proposed is applied on the case in section 5.2. The different models proposed are detailed and the way the modelling framework supports product-service integration at different levels of design refinements is discussed. Section 5.3 shows how the elements resulting from system modelling are used for defining the PSS life cycle and perform the environmental evaluation. The environmental evaluation framework is finally used in section 5.4. The way the cost analysis proposed can support PSS design negotiations about integrated sub-systems is illustrated. By using the cost analysis, an alternative scenario is proposed. The scenarios comparison using VA-based tools supports the discussion proposed on the necessity to broaden the environmental evaluation towards a better consideration for intangible aspects of the needs fulfilment.

5.1. Introduction to the case study: elements from the conceptual design phase

PSS offer characteristics

A specific PSS contract has been studied during the thesis and is used to apply the proposed PSS ecodesign methodology. The details of this contract are provided in this section.

Customer

The PSS provider offers a pneumatic energy delivery system to his customer through long-term contracts (10 years). The PSS customer is an industrial company specialized in the manufacturing of small-sized compressors used for refrigerating systems. The customer needs the pneumatic energy to supply his production engines continuously (24/24, 7/7). Production machines use pneumatic energy to shape raw material. During the needs analysis, measurements of their consumption and definition of their consumption profiles (air quantity and ranges of consumption) are performed by the PSS provider. Indeed, the diagnosis phase allows knowing the applications of the compressed air, their number and their location on the customer's site: specific supplying points on the production line, varying supply rhythms and different air quality levels can be required. By using measuring tools during two weeks, it is possible to know the expected flow and pressure profiles varying according to the production needs (weekends can require weaker flows for instance).

Products and Services

As previously detailed, AC proposes technical services: maintenance, repair, overhaul, continuous remote monitoring of equipment (on-call service) and spare part management. Products concerned in plant installations are: three compressors (one variable speed and two on/off regulations), pumps, tanks, drains filters, pipes, electrical equipment, etc.

The PSS uses a specific type of compressor technology:

 Screw-compressors  Oil-lubricated  Air-cooled

Criteria Level Flexibility

Annual production … m3/y ± 10%

Production capacity … m3/h ± 10%

Reserve capacity … m3/h Minimum

The electrical energy provider is responsible for provision of electrical energy to the PSS plant machines (the electrical energy consumed by the customer's ones is excluded here) and for maintenance and repair of the electrical infrastructures. PSS machines are manufactured and sold by the OEM to AC (a few other sub-contractors of AC provide specific parts but they are not represented here). AC is responsible for installation, maintenance, repair, overhaul (MRO) of these machines and for remote control and monitoring. AC must also regularly provide information to the customer. The beneficiary must maintain his production machines that must run in the contractual ranges of air consumption. The beneficiary pays for the electrical energy consumed by the plant machines. That is why AC is committed to an energy ratio.

Through the remote monitoring of the plant, AC is able to detect the presence of leaks that can be created within the beneficiary's piping due to damages. The sub-contractor can be alerted and lead operations for searching and repairing leaks.

Intangible aspects of the Value co-creation process

The technical performance is an important aspect that defines the contractual commitment. However, it only constitutes a limited part of the value creation (and co-creation) process for the beneficiary, since several "intangible" attributes of the PSS offer have been revealed during the interviews led.

As previously discussed (in the previous chapter), the PSS customer has experienced many difficulties in his previous compressed air maintenance contract. The customer was the plant owner and a subcontractor was responsible for sizing and maintaining the plant equipment.

The customer is specialised in the manufacturing of (small-sized) compressors for refrigerating systems and the personnel has knowledge on the different compressors' technologies and technical skills related to the products used in a compressed air plant.

The previous plant was undersized and could then not fulfil the production needs. Many failures and incidents have stopped or slow down the customer production processes (stops estimated to 150 h per year). The sub-contractor was not reactive: the intervention time could be of several days. The relationship was been progressively degraded. The customer's employees were forced to "got their hands dirty" (according to their own expression) for attempting to repair the plant machines by themselves.

In their testimonies, they mention the degradation of their working conditions due to the constant emergency climate. Additionally, the recurrent production problems on specific stations had led to several work stoppages. Due to this hard previous experience, the customer's employees attach a great importance to the trustfulness of the relationship with the PSS provider. This trustfulness implies an adequate PSS technical performance (adapted sizing and services), but also a high service and relationship quality: service reactivity, flexibility, and continuous dialogue. The dialogue process is maintained through multiple communication channels but (mainly) at the occasion of maintenance operations.

The value is co-created between AC and the customer through the share of common (professional) values and the importance they both attach to performance and quality. They mutually provide benefits that build the relationship value. For example, the customer's employees have cleaned the plant premises and repaint its walls before the contract signing and they now maintain it clean. AC employees mention the fact that, on many other installations (other contracts), plant premises are often dirty. They declare "feeling comfortable" when working in this one. Another example can be given. An employee of AC lives near to the customer's production area. He regularly stops at the premises before going home to control the plant state and discuss with the customer's employees, simply because of his professional care. Such an aspect could seem anecdotal while it actually constitutes a strong basis of the relationship trustfulness for the customer's employees.

Outcomes definition

According to the elements mentioned in the previous section, several expected benefits and related outcomes can be defined. They are illustrated in Figure 71.

The expected technical outcomes are those of the contract identified by a functional analysis and defined in the requirements specifications. They constitute the basis for designing PSS, initiated by a diagnosis. However, other types of outcome can be determined:  The service quality: the service reactivity and flexibility;  The relationship quality: the technical information communication (through detailed monthly reports) and the dialogue process between customer's and AC's employees. The proposed outcomes list is not exhaustive but still broadens the perspective on the PSS benefits to additional (and intangible) aspects compared with the restrictive viewpoint of the PSS technical performance.

Figure 71 PSS outcomes identified 5.1.5. Assumptions for methodology application

In the proposed case study, the goal is to show how the eco-design methodology proposed could support PSS design. The modelling and evaluation frameworks appear as tools supporting the designers' discussion of the different (re)design priorities and the PSS design alternatives. The way the methodology can be used by product engineers and service designers for modelling, evaluating and discussing the PSS design is illustrated in this chapter. However, in the AC industrial case, the products are (mainly) designed and manufactured by the OEM while the AC services are designed a posteriori in function of these products. Despite the knowledge developed by AC on these products, they are still designed separately from services. The following sections detail how the proposed methodology could support their integration for PSS eco-design. Then, contrarily to the real industrial case, the assumption that all the PSS components could be integrated in the PSS design is made. The design tools are used here as if there was the possibility of design products and services in an integrated system.

PSS integrated design

This section shows how the proposed methodology for PSS integrated design could be applied on the case. Section 5.2.1 details the way the modelling framework can be used and discusses its potential for supporting designers' communication. Section 5.2.2 shows and discusses the way the integrated PSS design task should be led until the most technical phases, by using the modelling framework and the Design Matrix as negotiation tools. Section 5.2.3 summarizes the discussions on the potential of this "multi-view" approach of PSS modelling for supporting PSS integrated design.

5.2.1. Application of the modelling framework 5.2.1.1. Initial service view: result and structure models

The initial result model of the service view has been shown in the Flow model (Figure 70) representing the different PSS actors, their respective roles and responsibilities in the processes that create value in the beneficiary's sphere. From a service design viewpoint, the problem formulation and the structural elements (here the actors' systems) are hardly separable. The Flow model already provides information on the elements that must be taken into account in the "wider system" as well as on the sub-systems involved in the PSS (like the plant machines or the remote monitoring system), and on the events that can occur within the beneficiary's sphere like leaks creation on pipes that can degrade the energy ratio. In the service view, the result model can be detailed concurrently with an initial perspective on the system structure.

5.2.1.1.a. Result model

The result model represents the expected actions occurring in the wider system, i.e. those involving the PSS and other ones for creating value. The entities that belong to the "outer environment" are separated from the sub-system by the system boundary. However, this boundary is initially supposed to be not well-defined in the service view. The process model is displayed in Figure 72, it organizes the actions temporarily. The following processes can be depicted (and associated to entities):  The continuous use of pneumatic energy by the production machines of the beneficiary  The continuous carry of the pneumatic energy by the piping network of the beneficiary  The continuous provision of pneumatic energy by the plant machines of the PSS (that are supposed to be still not well detailed)  The continuous provision of electrical energy by the electrical energy source.  The continuous monitoring of the plant functioning and control actions that ensures the provision of pneumatic energy with the expected performance level (quantity, quality, availability, energy ratio).

On Figure 72, the actors are represented on the left of the scheme and separated by the responsibility lines. They are associated with the structure elements of the wider system: external entities (and represented by ovals) or system components, i.e. physical products (represented by rectangular boxes) or service units (represented by curved-angled boxes). The "plant machines" are grouped in a product. Two "sub-systems" supporting the monitoring and control of the plant are represented by dotted linedboxes since they require being further detailed. An external event is identified triggering an external scenario: the state degradation of the piping network through leaks creation is assimilated to an "event" here triggering a scenario for leaks detection by the remote monitoring system before being searched and repaired. Repairs are performed by a service unit within the sub-contractor system. Actions of processes have been numbered from A1 to A6 (on the rights side of the Figure ) and associated to a colour code. Actions A1 to A4 (represented in yellow) correspond to those that ensure the energy transformation and supply and are attributed to the electrical energy source, the plant machines, the piping network and the beneficiary's machines. Actions for monitoring are named A5

(represented in violet) and include the leaks detection. Control of the plant is represented by actions named A6 (in green) including leaks repairs.

Actions are organized following an arbitrary timeline. In the model, e0 corresponds to an initialization event (for example, the plant installation and starting operation) and e1 corresponds to the arbitrarily defined event of "leaks occurrence" (making the simplifying assumption that the pipping network state degradation occurs as an event). The external scenario E0 corresponds to the current pneumatic energy delivery while the E1 scenario corresponds to a pneumatic energy delivery with a degraded performance (energy ratio) during which rapid actions of leaks search and repairs must be operated.

The service view model questions the way to define the PSS boundaries. Here, the service unit performing piping maintenance can be considered either as an external entity that is decoupled from the PSS, or as a PSS sub-system that is a part of the system-to-design. The latter possibility is retained here, considering for example a partnership between the PSS provider and the sub-contractor for ensuring the supply of pneumatic energy to the beneficiary. In this case, the action of "carrying pneumatic energy" is partially under the sub-contractor's responsibility (even if this aspect is not represented on Figure 72). However, this piping network is not designed by the sub-contractor and should be excluded from the PSS and considered as being under the beneficiary's responsibility. Links between actions are represented by arrows named from A to G and following the colour code. The use of italics corresponds to the "internal" interactions that are necessarily (partially) displayed in this "open box model" of the service view. Interactions A, B, and C correspond to the energy transformation. D and E correspond to internal interactions for monitoring and maintaining the plant machines. F corresponds to the leaks alert and is also a sequential link between alert and repair. G is a maintenance interaction between the control system and the plant machines, and H is the search and repair interaction between the sub-contractor Unit and the piping. The "open-box" model of the service view allows representing the expected actions concurrently with some elements of the structure. This well supports the discussion about the definition of the boundaries of PSS in terms of stakeholders' responsibilities (ownership, roles played in actions for needs' fulfilment, roles played in the PSS design process, etc.). These discussions can lead to the definition of a preliminary structure model.

5.2.1.1.b. Structure model

The Service System Navigation (SSN) model is used to descirbe the PSS structure in the service view. It details the structure elements that are affected to specific roles in the realization of the actions defined in the process model. The SSN model is shown in Figure 73. Structure elements are shown on the left. The different types of boundaries existing in the PSS are displayed on the SSN: the system boundaries that separate the external entities from sub-systems, the interaction lines between entities that define their sets of interfaces, and the actors' responsibilities lines. Three main actions composing the PSS processes are considered: "pneumatic energy supply", "monitor", and "control". Since the piping maintenance Unit has been integrated as a sub-system, the control action encompasses the maintenance of piping network with those of plant machines. The same type of elements than in the process model has been made visible.

The actions from A1 to A5 are shown. The monitor and control actions (A5 and A6) should ensure the continuity of the pneumatic energy supply actions (A1 to A4). To show the roles distribution according to the scenario, each action of the PSS process can be separated into several possibilities. Here, the "monitor" (A5) and the "control" (A6) actions require different roles according to the scenario. A specific structure of roles is required in the external scenario E1 in addition to the classical structure (that is required in both E1 and E0).

Interactions from A to G can also be reflected by in the "roles links". The process model emphasizes on the temporal organization of actions. Here, the arrows are used to express the links between the entities' roles.

For example, the "monitor" role of the monitoring system is linked to the role "supply" of the plant machines, as well as to its own roles "detect and alert". The role "detect and alert" is linked to the role "search and repair" of the piping maintenance Unit. The system result model from the product view be coupled with the service one and integrated into the integrated view.

5.2.1.2.a. Result model of the product view

The service view is coupled with the product one. The service view models initially emphasize on the beneficiary's sphere by representing the PSS as a contributor among others within the wider system. In the product view, the emphasis is put on the PSS itself and its direct links with external entities in the wider system. The Graph of interactors represents the system as a "black box" while it displays the external entities and the functional links of the system with them. A (partial) system modelling using the Graph interactors is proposed in Figure 74. Five external entities within the system "outer environment" have been identified: the customers' piping (defined as external), the electrical energy source, the ambient air, the premises, and the customers' technical units. The Graph of interactors proposes a contextualized representation of the system. Function actually refers to the system "aptitudes" to interact. IF1 is the main (interaction) function that corresponds to "Use external air and electrical energy to continuously ensure the supply of pneumatic energy to the customers' piping". Three adaptation functions can be defined in the E0 scenario (a):  AF1: To ensure safety and comfort of the customer's technical units (safety standards, sound level, etc.)  AF2: To comply with the premises area  AF3: To be adapted to the ambient air (particles rate, atmospheric conditions, etc.)

In the E1scenario (b), an additional adaptation function AF4 is defined:

 AF4: To ensure leaks detection and repair in the customer's piping An additional scheme is proposed in Figure 75 representing the system functions as interactions, i.e. as links between actions exerted by and on the system. Only the external interactions are visible through the black box model, then D, E, F, and G cannot be represented. C is an interaction occurring between two external entities and does not appear on a Graph of interactors.

Interactions A and B link the actions A1 of the electrical source, the action A2 of the PSS (for energy transformation), and the action A3 of the customer's piping carrying the pneumatic energy. The "ambient air" required for these actions is additionally taken into account here. Its interaction with the system in the action A2 is named A'. All these interactions correspond to the interaction function (IF1) of continuous supply of pneumatic energy on schemes (a) and (b). The customer's piping is submitted to the action of detection and repair of the system in the A6 action.

The resulting interaction H corresponds to the adaptation function AF4 on the scheme (b). The Graph of interactors supports the identification of different types of external entities compared to the service view model: some of the external entities and their interactions with the system can hardly be identified by using the process model. For example, the "ambient air" or the "premises" seem hard to be represented in a process model but still interacts with the system (AF2 and AF3) by exerting actions on it. Technicians present in the customer's area can enter in the premises and work near to the plant machines. An interaction exists between the customer's technical units and the system (AF1). All these external interactions identified through the Graph are gathered and named I (in blue on Figure 75). They will not be detailed further here. The service view emphasizes the temporal aspect of the organization of actions. For example it emphasizes the sequential link between leaks detection (and alert) and leaks repair in the E1 scenario, followed by the interaction F for piping repair.

The product view represents functions and emphasizes the system interactions (while the actions composing these interactions are not well expressed). However, functions reflect some actions exerted by or on external entities that are hardly representable in the service view, like the continuous action exerted by the ambient air on the system. It somewhat focuses on the spatial interactions between the system and its surrounding environment and allows expressing the system required aptitudes by functions Nevertheless, the contextualized approach of this model can be enriched by using the service view to identify the PSS external scenarios. The coupling of these models could support the identification of multiple design elements that can be integrated in the IDEF0 result model.

5.2.1.2.b. Coupling product and service views: integrated result model

The integrated result model represents the activities occurring in the beneficiary's sphere, i.e. in the wider system. An A0 diagram is provided Figure 76. It represents all the activities in the wider system and their relationships through the ICOMs (input, control, output, and mechanism links). Activities shown on the A0 correspond to the actions previously numbered from A1 to A6. Those performed by the PSS are A2 "Perform the pneumatic energy supply", A5 "Monitor", and A6 "Control". Their links can represent physical flows and also express the entities' roles (as subjects / objects of actions) through the ICOMs.

The physical flows of energy correspond to the interactions previously named A, A', B and C. They can be represented (in orange) as input/output flows being operated on by the actions (activities here) A1 to A3 (A4 is not shown in this Figure ). Energy input from electrical infrastructures is added.

The internal interaction D corresponds to an input information flow from A2 to A5. The interactions E and F correspond to an output information flow of A5 being a control flow to A6. Outputs flows of A6 are two control flows either for A2 (corresponding to the internal interaction G), or for A3 corresponding to the external interaction H).

The interactions between the system and the premises, the ambient air and the customers' technical units (named I) correspond to a control flow on A2, A5 and A6. They correspond to influences or constraints exerted on the system's actions. The A0 model supports the representation of the different elements identified in the result models of product and service views. The actions occurring in the wider system are shown, like in the process model. However, the direct interactions of the system with external entities are expressed.

The "logical links" between actions (through ICOMs) propose a viewpoint that is neither oriented towards temporal aspects of their organization nor towards spatial ones, but IDEF0 still allows representing physical flows as well as state changes and the roles of entities regarding actions.

Result models of the product and service views offer different perspectives on actions and allow identifying different elements. IDEF0 should be used as a bridge between these views for representing all these elements and facilitating product engineers' and service designers' communication.

Result-Structure decompositions

The result models express the organization of actions for fulfilling the needs. The result is now decomposed from the three viewpoints proposed: the product, service and integrated perspective. Such a decomposition process supports the identification of the sub-systems and their affectation to the result achievement that establishes the design relations. The decompositions of the system result and of the system structure are co-evolutionary.

5.2.1.3.a. Product view

Result decomposition

The Functional Analysis System Technique (FAST) is used to decompose the external functions of the product view into internal functions. The FAST proposed is shown Figure 77 The decomposition is made for the interaction function IF1 into three internal functions named here TFA "To perform the pneumatic energy supply", TFB "To ensure availability of the energy supply", and TFC "To ensure maintenance of equipment". TFA is not detailed here: it corresponds to the energy conversion performed by the plant machines among which the essential component is a compressor.

The guarantee of air availability (TFB) requires the development of a Failure Mode and Effects Analysis (FMEA) which should support the refinement of technical functions to support all the possible internal events. However, they are not detailed here.

Here, two internal events are revealed: a "compressor failure" (corresponding to its stop) and a planned event triggering a maintenance operation. In the following sections detailing the PSS models, the maintenance operations are not integrated. TFB is decomposed further into a monitoring function (1) that also ensures the detection of leaks (the Adaptation Function AF4 in the E1 scenario), a function for ensuring the supply continuity of pneumatic energy supply (2), and a function for repairs. These three technical functions share the same purpose of availability guarantee.

TFC is decomposed into a function for preparing maintenance operations (1) and performing these operations (2).

Figure 77 PSS Result decomposition of the product view: FAST (partial)

The sub-systems identified as principles of solutions correspond to an initial decomposition of the PSS structure. This structure is detailed in the corresponding model in the next section.

Structure decomposition

The Block Diagram represents the system structure by hierarchizing the sub-systems boundaries. The Block Diagram of the pneumatic energy delivery PSS is shown Figure 78. The external entities are separated from the sub-system by the boundaries. Four main sub-systems compose the system:  the plant machines,  the Remote Monitoring (RM) Unit, that operates in the back-office  the Front Office (FO) Unit, and  the Piping maintenance Unit (that has been integrated as a component even if it is not used in the FAST decomposition of IF1). The sub-systems colour on Figure 78 corresponds to the colour code used in the FAST and in all the previous models: sub-systems and technical functions in yellow are affected to the pneumatic energy supply action, in violet to the monitoring action, and in green to the control action. These components are themselves composed of sub-systems. The all set of plant machines are not detailed on the scheme. The main product is a head compressor for supplying the pneumatic energy (TFA). However, a reserve compressor is required to ensure the supply when the head is failed (TFB2). The Remote Monitoring (RM) Unit that performs the monitoring technical function (TFB1) is composed of Remote Monitoring System (RMS) coupled with a software application (that uses a computer support not shown on the scheme) and of a Supervision Unit. RMS and software support continuous collection, storage and analysis of data on the plant state (TFB1.1). The software can detect a head compressor's failure (TFB1.2) and leaks (AF4). The Supervision Unit uses the software data for continuous supervision (TFB1.1.3), for diagnosing the failures being detected (TFB1.3), and for preparing the (planned) maintenance operations (TFC1). The Front Office (FO) Unit is composed of a technical Unit, of a truck and of the spare parts necessary for operating immediate repairs if the head compressor is failed (TFB3) or maintenance operations (TFC2).

5.2.1.3.b. Service view

Result decomposition Some processes identified in the result model are decomposed into sub-processes in Figure 79 (the maintenance actions have been excluded here). The model shows the sequences of actions into scenarios, following a timeline. The scheme is a simplified view of the processes: it only shows some sub-systems' actions occurring in the E0 and E1 scenarios. To simplify the temporal view, all the actions of the service Units are grouped, but the colour code is maintained. The PSS boundary separates the internal events from the external ones. The E0 scenario is decomposed into two internal scenarios triggered by two internal events i0 and i1. The i0 event is an arbitrary event starting the internal scenario I0 corresponding to the current system

FO Unit

Truck functioning. The monitoring action requires the collection and storage of plant data (by the RMS and software) and the continuous spot of the information by the Supervision Unit. The i1 event corresponds to a compressor failure and triggers the "I1 scenario". The provision of air must be ensured by the reserve compressor, and failure must be detected, diagnosed and repaired.

Figure 79 PSS Result decomposition of the service view: Process decomposition (partial)

Compared to the product view, the result decomposition in the service view does not support tracing the design relations. The decomposed result model is descriptive, while the means-end decomposition of the FAST allows tracing the reasons for the technical functions and the sub-systems' choice. However, if the FAST decomposition reveals the internal events and their corresponding technical functions, the way the system must operate the functions in time is not detailed. By using complementarily the process decomposition, external and internal scenarios are easier to capture. These two approaches can be mutually enriched if being used concurrently by product engineers and service designers.

Structure decomposition

As for the product view, the decomposition of the service view allows detailing the corresponding structure model. The SSN model decomposing the PSS structure is shown in Figure 80. It displays the same structure elements than in the Block Diagram: external entities are separated from sub-systems (except the truck of the FO Unit is not represented here for simplifying the model). They are affected to their decomposed roles (easy to identify through the decomposed actions of the result).

The required structure of roles can still vary according to the configuration of scenarios considered. For example, the action pneumatic energy supply can be performed by the head compressor in the classical scenario (E0-I0) or by the reserve compressor in the internal scenario of failure of the main compressor (E0-I1). The links between the entities' roles can be traced.

Here, the plant data are collected by the RMS. They are stored and analysed by the software that must detect any defect. The Supervision Unit must diagnose the defect. In the case of a compressor's failure, the alert should be given to the technical Unit for repairing; in the case of leaks, the alert should be given to the piping maintenance Unit. Such a model supports the identification of the service units' boundaries (scope of their roles) using the viewpoint of "what-if" scenarios often used in service design. The resulting service structure or architecture should facilitate the definition of service procedures for example, that trace the "intangible" boundaries of each unit. In the E0-I0 scenario, the A5 activity consists in data collection, storage and analysis by the RMS and the software application as well as in continuous spot by the supervision Unit that must be kept informed of the plant state.

In the E0-I1 scenario (compressor failed), the A5 activity has the same instance than in the E1 scenario (leaks occurrence): data are collected, stored and analysed before a defect be detected that triggers its diagnosis by the Supervision unit using the software. The output of this diagram controls (triggers) the A6 activity.

The control activity (A6) has two possible instances: in the E0-I1 scenario (picture c), A6 is triggered by a failure alert and consists in repair operations performed by the FO Unit; in the E1 scenario (picture d), A6 is triggered by a leaks alert, and leaks are searched and repaired by the piping maintenance Unit.

Figure 81 PSS result decomposition of the integrated view: IDEF0 diagrams configurations

5.2.1.3.e. Interest of the integrated view

The result decomposition through the IDEF0 model is supportive for coupling the product and the service views. The product view allows tracing the reasons for choices through the means-end relationships between technical functions. The service view decomposition traces the temporal links of actions into scenarios through a part-whole decomposition. The IDEF0 model emphasizes the logical links between actions and shows the links between technical functions since it is a functional model. It then completes the FAST for the product view.

The decomposition using configurations allows linking the functions fulfilment in diagrams decomposition with their occurrence in scenarios. It supports the service view on result and on structure.

(a) (b) (c) (d)
The three types of decomposition can be used complementarily for identifying the actions' links. For example, the links between the "diagnosis" and the "repair" actions is differently perceived and apprehended in the three views.

In the FAST, these two internal functions are linked by their common purpose, i.e. ensuring the pneumatic energy availability. These two actions are temporally linked as a sequence in the process model and have an occurrence in specific scenarios. The IDEF0 model shows the control link existing between these two activities and their different instances according the scenario configuration: the diagnosis exists in different scenarios (E0-I1 and E1) while the repairs occur only in the E1 scenario. IDEF0 can be easily understood by both types of designers and completes the product and service views. It can support their integration and then facilitate successive decompositions of the result that would be continuously modelled and shared.

Structural organization models

The two models of structural organization proposed in the product and service views can be used as complementary viewpoints on the internal organization of the sub-systems and their interactions. Structural organization models are intermediary descriptions that link the result to the structure spaces. They represent the system structure with additional information on the way the sub-systems interact to achieve the results and they are the basis for designers' negotiations about the fit of structure-results defined. The two structural organization models emphasize different characteristics of interactions that are complementary. The two views proposed for structural organization can be confronted and used for supporting the design negotiations between product engineers and service designers.

5.2.1.4.a. Product view

The Functional Block Diagram (FBD) of the PSS is shown Figure 82 and represents a partial view of the structural organization of the system. FBD displays the system structure with the interactions occurring for fulfilling the system result. The physical contacts (i.e. permanent interactions) and the flows circulating between components are detailed: the pneumatic energy flow provision (TFA); the information flows for defects detection and diagnosis (TFB1, AF4). Design Loops (DLs) are used to express the set of sub-systems involved in a specific action, i.e. their interactions. Several DLs are detailed in Figure 82 and numbered: (a) defect detection, (b) diagnosis, and (c) failure alert, (d) (head) compressor repair, (e) leaks alert, and (f) leaks search and repair. These internal interactions have been identified in the decomposed result and structure models previously used. For example, the action of repairing a compressor (d) requires an interaction between the technical unit, the spare parts and the compressor being repaired. This interaction is shown in the IDEF0 diagram A6-E0-I1 (Figure 81) decomposing the control activity, and in the SSN model (Figure 80) displaying the decomposed sub-systems' roles in this action.

All the interactions of a specific sub-system are visualized simultaneously on the FBD. Here, all the interactions of the compressor can be identified4 : its physical contact with the reserve compressor, with the energy source and the customer's piping, the physical contact supporting the flow of information transfer towards the RMS, and its interactions with technical Unit and spare parts during repairs. Identically, the interactions of the supervision Unit are all displayed: with the software, the technical Unit and the piping maintenance Unit. However, each interaction has a specific moment of occurrence in scenarios and this temporal aspect cannot be visualized in the model.

Figure 82 PSS structural organization model of the product view: Functional Block Diagram (FBD)

5.2.1.4.b. Service view

The Blueprint-Based Model (BBM) used in the service view is shown in Figure 83 The product view emphasizes on the spatial perspective of the interactions (through functional flows in the FBD); the BBM is more oriented towards their temporal organization for fulfilling the results expressed in the process model. Contrarily to the SSN that provides a somewhat static (since structural) perspective on the possible roles played in the expected actions of the result, the BBM expressed the temporal links between the roles that are solicited in the sequences of actions within scenarios. In this view, actions can occur concurrently or sequentially. The timeline organizes the actions in scenarios. The same type of elements than in the FBD can be shown to express the structural organization. The energy and information flows circulating between the sub-systems are also displayed. However, the FBD emphasizes on their spatial aspect showing the physical "path" of flows between sub-systems, the BBM emphasizes on their temporal aspect since they can have limited duration of circulation. Four DLs (a, b, c and d) of the FBD are expressed in the BBM as a sequence. BBM supports the representation of these actions within the context of other actions organized in PSS process. For example, the failure detection must be ensured by the RMS while it should simultaneously maintain the storage and analysis of data. This action occurs in the E0-I1 scenario, the head compressor being failed and the reserve one being supplying pneumatic energy.

The visibility / invisibility of actions can also be expressed. The actions performed by the plant machines and by the Front-Office Unit are visible. The RMS is mostly located in the premises and is visible while the software use and the supervision Unit's actions are not visible for the beneficiary. This characteristic of the "internal" interactions between the sub-systems emerge from the way the result and the structure have been concurrently decomposed but can influence the service outcomes.

5.2.1.4.c. Complementarity of the structural organization models

Product and service views propose complementary approaches for depicting sub-systems' interactions. Using the FBD is supportive for product engineers since it details the interactions by focusing on their spatial aspects. The sub-systems are seen as spatially surrounded by other sub-systems linked by physical interactions. The sets of sub-systems and interactions can be embraced simultaneously in the FBD. This helps product engineers to progress in the detailed design phase. However, the temporal aspects of these interactions cannot be identified by using the FBD.

The BBM focuses on the temporal dimension of interactions. It displays the roles played by the subsystems within interactions that are temporally organized. The entire sequence of roles that a subsystem must play according to the scenario can be identified in the BBM. For example, the software must store and analyse plant data, detect a compressor's failure when it occurs and display the plant data stored to support the failure diagnosis when solicited by the Supervision Unit. However, the BBM requires detailing scenarios as sequences of actions. The set of interactions of a sub-system are identified only when all the scenarios are described.

The structural organization models are a support for negotiating the internal organization of the subsystems to achieve the expected system result. The product and service views coupling should allow designers to get the useful information about this internal organization for supporting the progression of their own design task while sharing it for negotiating the structural choices. For example, failure detection and diagnosis can raise different issues for product engineers and for service designers due to the viewpoint adopted. The physical infrastructure required for supporting the information transfer The repair operations have not been detailed, but specific AFs can be traced between the compressor and the FO Unit component, for example (as shown by dotted lines on Figure 84):  To be easily dismantled by the technical Unit;  To have parts easy to replace, etc. The modelling framework supports isolations of product components and refining their design by using specific tools of product engineers. Indeed, the result-structure decomposition and structural organization models can be used in the product view for refining the technical specifications of products. The all set of specifications of products should be detailed and the models refined until the identification of the elementary products' components.

5.2.2.1.b. Technical design of services

Iterations can also be made for service units and support refinements of the service specifications. Actions of the PSS process can be detailed as in Figure 85. The actions of the service units and in particular of the technical Unit are detailed into sequences. The refinements of actions (concurrently with structure, even if structure is not shown here) allow identifying essential characteristics for service design:  The different roles played by the units Here, for repairing, the technical Unit must move (using a truck), dismantle the compressor, diagnose the failure, replace parts, reassemble the compressor, etc. This supports the definition of service procedures for example.  The service processes organization

Here, between the compressor failure and the first operation on it (dismantling), there are three actions of remote detection, remote pre-diagnosis and alert (performed by the RM Unit) and the technical Unit move. Maximum times should be defined for each of them when organizing the service delivery process for achieving the expected service outcomes (here, availability).  The required aptitudes of the service units as well as of the products they interact with

In Figure 85, the actions of the technical Unit involve the compressor. The AF6 compressor's function identified in the Graph of interactor (Figure 84 (b)

The Design Matrix well supports the communication and the negotiation process between product engineers and service designers because it displays the reciprocal influences of the expected PSS process (result) and the sets of sub-systems' properties (structure) that should be defined. For example the failure detection represents an interaction between the RMS, the software and the head compressor. It solicits the specific aptitude of the compressor defined for data transmission (AF4).

The repair actions represent interactions between the head compressor, the technical Unit and the spare parts. They solicit:  Specific compressors' properties: for example here, safety and comfort provision, ease of dismantling and of parts replacement  The ability to drive quickly and the dismantling, diagnosis and parts replacement expertise of the technical Unit. Design negotiations can be led to determine and refine the sub-systems requirements according to the constraints and flexible parameters of each designer. For example, one can imagine that the repair actions are associated to maximum times not negotiable. The ease of dismantling of the compressor refers to a modularity parameter. The compressor's manufacturing constraints to facilitate its modularity must be negotiated regarding the technical Unit capacity to dismantle it (considering number and duration of operations) for respecting the schedule. The PSS design must be negotiated by using the structural organization models. Indeed, they detail the internal sub-systems' organization defined. Designers must find an agreement on this organization before refining their design and pursue modelling iterations. In the previous example, supposing that the intervention time must be very short, different structural organization choices can be made. An alternative could be that the failure alert is send by the software application directly to the technical Unit (on cell phones for example). The Unit moves on the customer's area while the supervision Unit concurrently performs the diagnosis and communicate it to the technical Unit. In the FBD (Figure 82), this alternative would be modelled by adding information flows and the corresponding loop from the software to the technical Unit (cell phones). In the BBM (Figure 83), the alternative would lead to a reorganization of the actions along the timeline: the remote diagnosis of the supervision Unit and move of the technical Unit would occur simultaneously.

The proposed PSS design models allow expressing the links between actions (in the result space), those between sub-systems (in the structure space) and those that are made between both (in the structural organization space) for organizing solutions in the result provision. The resulting definition of sub-systems' properties for interacting within the PSS process can be expressed in the Design Matrix to be negotiated between product engineers and service designers. Once negotiated and established the sub-systems' specifications, the PSS design can be refined through modelling iterations. In order to support the sub-systems' integration until the most detailed phases, the decomposition of the requirements (or sub-systems' specifications) must be traced during PSS design.

5.2.2.2.b. Requirements modelling and traceability

The integrated IDEF0 model is of major interest for the traceability of the specifications during the design progression, since it supports integration of product and service views when decomposing the system result. It can be used during the entire design process to progressively detail the links between the subsystems specifications. The "bundle" property of ICOMs [START_REF] Menzel | The IDEF Family of Languages[END_REF] allows progressive detail of the expected actions and of the corresponding sub-systems in the co-evolutionary framework.

Two examples of decomposed diagrams that detail the components through bundles are proposed Figure 86. The repair activity (A6-E0-I1) is shown in picture (a) and displays the elements that have been previously identified through the decomposed result models of sub-systems (Figure 84 and Figure 85). Some components are added her, like the truck necessary for repair moves and the tools for performing repairs. Additionally, the bundle property allows showing the required aptitudes of the technical Unit that are solicited in activities. The dismantling activity (A62) is supposed to be further decomposed once some structural elements of the compressor have been defined. The corresponding activity diagram is shown in picture (b). Here, the compressor is composed of a carcass comprising a door, and an oil circuit module in which an oil filter has been identified as a critical part leading to a specific compressor failure (through a FMEA for instance). This type of failure is an internal event named y. The occurrence of y is a particular instance of the E0-I1 scenario. Activities represented show the structure decomposition of the compressor and the specific skills of the technician that are solicited and expressed in bundles. A particular tool is required here (screwdriver). The IDEF0 decomposition supports an integrated representation of the expected system result during design while the different structure elements chosen are detailed. The traceability of the activities within the decomposition proposed in the IDEF0 model favours the traceability of the requirements at different levels of details during the progressive sub-systems refinements. This section summarizes the discussions on the way the PSS modelling framework should support the integrated design of PSS by adopting a "multi-view" approach.

5.2.3.1.a. Coupling the solution space views

The product and service views of the system structure modelling should be used complementarily. The Block Diagram of the product perspective is useful to depict spatial aspects of the system interfaces and to identify a full set of interacting external entities surrounding the system. However, the boundaries are supposed to be initially elicited by using the "black box" approach during the decomposition. The SSN is used to discuss the actors' roles in the value creation process. It should help to separate the boundaries of actors' systems (responsibility lines) from the system under study (PSS boundaries) while it expresses the entities' roles boundaries (interaction lines). The SSN provides a comprehensible organization of the system structure for service designers since it hierarchizes the elements according to intangible (and evolving) boundaries.

5.2.3.1.b. Coupling the problem space views

The two models of result from the product and the service views also focus on different aspects.

The process model well supports the identification of the different actors and entities operating within the beneficiary's sphere. Events and scenarios during which the system must perform specific actions are described. The service view emphasizes on the evolutionary aspects of the system actions but misses some actions links. The Graph of interactors better supports the identification of the system physical boundary, and of interactions with the surrounding environment through functional representation. However, the Graph misses the dynamism of some actions. The concurrent use of these two models can facilitate and accelerate the design task through an exchange of information between designers.

Additionally, the integrated result model using IDEF0 supports the expression of the different elements identified in the two result models from the product and service views. Indeed, the IDEF0 model allows representing the state changes of entities and the circulation of flows that can be physical or immaterial. It shows the logical links between actions while the sub-systems interacting are linked in activities by the ICOMs.

5.2.3.1.c. Coupling decomposition processes

The decomposition processes can also be used complementarily by designers. The product view decomposes the problem though a means-end approach using the FAST tracing the reasons for design choices. The service view organizes the result provision into processes and decomposed actions can be organized through sequences and linked by the different events triggering scenarios. These two approaches can be mutually enriched if being used concurrently by product engineers and service designers, who can decompose the problem (or result) by ensuring the decisions traceability and the temporal organization of actions. Additionally, they can be integrated in the IDEF0 model. If the classical IDEF0 model adopts a black box approach, the enrichments proposed allow representing the different possible configurations of scenarios when decomposing the result fitting in the service view. The integrated result model should support an agreed perspective on the problem decomposition until the most detailed levels of PSS design.

5.2.3.1.d. Coupling the negotiation space views

The structural organization models detail the structural choices made for the sub-systems with the internal organization of their interactions. The sub-systems and the way they could effectively achieve the result can be discussed by coupling the models' views.

The FBD emphasizes on the spatial perspective of interactions. The sub-systems links through flows circulation, physical contacts, and Design Loops can be expressed. All the interactions a sub-system has with other entities can be visualized simultaneously on the FBD. However, each interaction has a specific moment of occurrence in scenarios and this temporal aspect cannot be visualized in the model. The BBM of the service perspective is supportive for detailing such temporal aspects. The roles affected to the sub-systems are temporally organized in the different scenarios for achieving the result. The visibility / invisibility of roles could also question the effective result achievement and balance the structure definition. However, the BBM requires detailing scenarios as sequences of actions which require detailing all the scenarios. Coupling product and service views on the structural organization could accelerate the building of a more complete view of the sub-systems interactions through complementary viewpoints.

5.2.3.1.e. Supporting PSS integrated design refinements through negotiations

Structural organization models can be considered as integration points through which designers can negotiate the problem and solution at different levels of their refinement. They represent a defined structure and its organization for result provision at a given level of the system hierarchy. They support the Design Matrix building that identifies the possible sub-systems specifications. These specifications must be negotiated before detailing the sub-systems' design in modelling iterations. Negotiations are supported by the structural organization models reflecting the result-structure decomposition.

Through the integrated model decomposing the problem, the traceability of the requirements is ensured between the levels of detail. This should favour the integrated design of products and services until the most technical phases.

Case study limitations

The modelling framework should support the design tasks of both product engineers and service designers by facilitating their communication through the use of system representation models. However, the proposed framework is mainly theoretical in its building as well as in its application. The case studied did not allow experimenting the implementation "on ground" of the framework but has been used for illustrating what should happened in the case of a full co-operation of the concerned companies for designing. In an ideal co-operation, the compressors, the service units, the software and RMS would be all designed in an integrated system. However, the effective integration in PSS design is strongly dependent on the business characteristics of the offer. These aspects should be further explored to provide the most adapted support to companies switching towards PSS. The goal of this thesis is to show the framework applicability and illustrate its potential for "integrated" PSS design. However, as underlined in the challenges of PSS, the integration dimension of PSS design strongly depends on larger ones in the actors' network. Further research should be conducted to better appreciate the scope of its usefulness and the effective support it can constitute in an industrial context.

Conclusion

This part has detailed how the modelling framework proposed should be applied on a PSS case integrating products and services during design. By using classical models of the related disciplines, the framework offers the possibility for the design tasks to progress until the most detailed phases. Models have been enriched to efficiently represent all the system elements in a comprehensible manner for both views and integrated in a co-evolutionary framework that should support progressive refinements in common design spaces. The way the framework facilitates collaboration and negotiations between product engineers and service designers during PSS design has been illustrated and discussed. The next Part details the PSS life cycle used in the environmental evaluation. Its definition results from the integrated PSS modelling.

From PSS modelling to PSS evaluation: PSS life cycle

This section shows how the PSS life cycle has been defined for applying the environmental evaluation framework.

Design Matrixes

The Design Matrixes are supposed to be built during the integrated design phase. This section details the products and service units that have been integrated and the resulting Design Matrixes built.

Products in the PSS

The products that compose the PSS (and should ideally have been identified during PSS modelling) are shown in Figure 87. The compressed air plant equipment encompasses:  A Variable Speed compressor (VSD) considered as a head compressor  Two All-or-Nothing (named AoN) compressors: one of them is used as a head and the second as a reserve  Other plant equipment: a receiver, two filters, a water-oil separator, a condensate trap, a piping network, and an energy recovery system. Remote Monitoring equipment corresponds to the Remote Monitoring System (RMS) and the software application supported by the computer use. MRO equipment encompasses the spare parts and the consumables (oil and refrigerating gas) replaced during MRO services. Spare parts are divided into three categories:

 Spare parts of maintenance operations: parts replaced on the two compressors; on the other plant equipment and on the remote monitoring system  Spare parts of repair operations: the repair operations have been considered only for the compressors.  Spare parts of overhaul: they are specific to the VSD compressor, the AoN compressors being not overhauled. The Design Matrix proposed is a simplified Matrix that does not integrate all the sub-systems' aptitudes. Table 18 and Table 19 show the Design Matrix resulting from the PSS modelling after some refinements or iterations. The two compressors are decomposed into two sets of sub-systems: the "main parts" correspond to the main elements, i.e. air, oil and dryer circuits; and their internal Control and Monitoring System

5.4.1.2.b. Reference for evaluation

The core of the needs fulfilment is the provision of the technical performance outcomes since they are contractually defined. From this viewpoint, the reference to use would correspond to a Functional Unit. Because this thesis does not deal with the conceptual design phase, the way the outcomes can be identified, qualified and potentially quantified has been excluded. However, a set of outcomes has still been previously proposed. The needs' fulfilment should correspond to the provision of this set of benefits in defined "acceptable levels". Those of the technical performance are quantified in the contract commitment (levels of flexibility in Table 16), but those of the other dimensions should also be qualified by acceptable levels terms during design. These aspects are discussed at the end of the section 5.4 (i.e. in section 5.4.6).

In order to simplify the analysis while illustrating these issues, the reference taken is the provision of the technical performance outcomes in the contract terms during the contract duration (10 years) AND the provision of the other outcomes supposing the respect of "acceptable levels" for fulfilling the needs.

When two scenarios will be later compared, the non-technical outcomes are not equivalently provided but the two alternatives are still supposed to fulfil the needs.

5.4.1.2.c. Products' life cycles

The evaluation integrates the environmental impacts generated through the life cycles of several categories of products. Almost all the products previously shown Figure 87 have been integrated in the proposed evaluation, except the consumables replaced and the EOL and BOL of the computer supporting the software application. Consumables (oil and gas replaced during maintenance operations) have been excluded from this study since the initial LCA has shown that their related environmental impacts were negligible.

The product flows must correspond to the provision of the expected outcomes during the contract duration defined, i.e. 10 years.

The compressors are the main products of the plant and the initial LCA shows that they have a significant contribution in the EI generated by the PSS life cycle. The products' and particularly the compressors' life scenarios and the related assumptions are now detailed. All these scenarios have been defined with the AC's design department.

Compressor's use scenarios Three compressors are used in the plant. Their use scenarios are detailed in Figure 88. Their life data (energy consumption, service operations, etc.) have been collected for a two-year period, considering data from their installation in 2011 until the LCA performed in 2013. They have been extrapolated for the remaining contract time, i.e. until 2021. A second contract has been imagined considering that the compressors used or reused operate in the same conditions and that this second contract provides identical outcomes for the beneficiary. On Figure 88, the compressors' use durations are expressed in machine hours relative to a timeline showing the elapsed times of the contracts. The three compressors are new at the beginning of the first contract. The VSD and one of the two AoN compressors provide the main pneumatic energy flow (they are head-compressors). The second AoN compressor is used as a reserve (but is weekly started to avoid its performance degradation).

At the end of this contract, the VSD compressor has been overhauled and is recovered. Its end-of-use (EOU) scenario is detailed later. The roles of the two AoN compressors are inversed (the previous reserve becomes the head and vice versa) in order to ensure they age similarly at the end of the second use. They are then associated to end-of-use scenarios at the end of the second contract.

End-of-use (EOU) scenarios

At the end-of-use (in PSS contracts), the compressors follow the same generic scenario shown in Figure 89. They are recovered and can be remanufactured (at least cleaned).

In 90% of the cases, they are rented with use rates and durations varying according to the compressor's age (VSD vs. AoN). They are then dismantled, and parts can be reused. The remaining parts are wasted. In 10% of the cases, the compressors are sold as second-hand equipment (varying use rates and durations) before being wasted.

Figure 89 Compressors' end-of-use scenarios

The other products' scenarios of use and end-of-use have been defined. They vary according to the product, they are not detailed here. The waste scenarios defined vary according to the equipment and materials. Assumptions have been made by using available data on the AC's waste sub-contractors, and related sectors in the local area (e.g. [START_REF] Sindra | Observatoire Des Déchets En Rhône-Alpes[END_REF].

The beneficiaries of the PSS offer, the rental offer and of the second-hand offer clearly do not have similar needs. Each of them has specific expectations for outcomes. Then, the expected technical performances of the products reused and their reuse conditions are not equivalent than in their first use. However, in the initial approach proposed for PSS environmental evaluation, the reuse of products and parts have been considered as being operated in similar conditions than in the PSS contracts fulfilling equivalent outcomes.

5.4.1.2.d. Service Units' life cycles

Since the evaluation framework has been built through the industrial collaboration, effective data collected are those of the initial LCA led. Time has missed for collecting additional data once the proposal defined.

Then, in order to propose an evaluation that integrates EI generated throughout the service units' life cycles, many assumptions have been made a posteriori. Imagining a collaboration process between the OEM and AC, training sessions have been imagined for acquisition of the two service units' expertise of the compressors' technology: a week of training is organized for all the employees (technical and supervision units) who take individual transport vehicles for moving.

For the training and empowerment of the technical unit, three training sessions (each of three days) are organized for the AC's employees (individual transport vehicles). Two employees of the certification agency then move twice a year for auditing. Reports are printed (500g of paper) for each audit. An additional ton of paper is supposed to be printed (during the contract time) for the training sessions and maintenance reports.

The software implementation is supposed to require a computer use during 500h and three updates are required (50h for each one). The supervision unit is supposed to be trained by the software provider: several computers are used by the employees during a week (8 hours a day). Three additional sessions are required (after each update). Individual moves of the software providers' employees for software implementation and training sessions have been integrated. A ton of paper is also supposed to be printed for the training sessions, the exchange of documents (requirements' evolutions) and reporting of the diagnoses and analyses. The possibility to reuse the Service Units' aptitudes acquired (in other contracts, for example) through reporting is supposed to be integrated in these assumptions.

5.4.1.2.e. Actions of the PSS process

The energy consumption has been integrated. The values taken are those measured on the plant by the RMS.

The simplifying assumption has been taken that the recovered energy for process heating leads the customer (paying for electrical energy) to avoid a part of his classical consumption. The energy recovered has been directly subtracted from the energy consumed, despite the fact that these energies are not equivalently used and provide different benefits.

The energy consumed (/recovered) during the reserve supply has been affected to the "supply action" to simplify: the reserve supply duration is supposed to be very short. The intervention time of the technical Unit in case of failure (and during the reserve supply) is of 4 to maximum 6 hours and the frequency of failures is weak. Moves of the Technical Unit for the MRO operations during the PSS process have been integrated. On the basis of AC data, the study has considered: 54 maintenance operations, 6 repair operations and the unique overhaul for the VSD compressor. Maintenance and repair are made on the customer's area while overhaul requires transporting the compressor at the AC's production facilities.

The IE generated by the actions of the supervision Unit for monitoring and cell phones for alerts have been mostly excluded because their relative impacts were negligible.

Costs Analysis

The costs analysis is applied on the existing system. It supports the identification of the main environmental "hot spots" in the PSS process and to link them with some design variables. It should be noticed that all the weighting coefficients used for this analysis have been chosen arbitrarily. As previously mentioned, time has missed for consolidating the case study by interviews with the actors involved in the PSS.

Costs distribution

The Design Matrix previously shown allows identifying the solicitations of the sub-systems in the actions of the PSS process.

For each system / sub-system involved, the relative importance of aptitudes has been defined. Each aptitude is distributed in the actions. Table 23 and Table 24 displayed below show the relative importance and the distributions chosen for each aptitude. The choice of these weighting coefficients must be made through design negotiations between product engineers and service designers. Designers must negotiate between the expected performance of the action in the PSS process and their own constraints for defining the respective "efforts" they can define for each aptitude and solicitation.

For example here, all the control activities require the VSD compressor to be dismantled by the technical Unit. First, a negotiation can be made about the respective weights that can be attributed to the concerned sub-systems' aptitudes. Here, it is expressed by the fact that among the skills of the technical Unit, the dismantling expertise has the higher weight (60%). Since the Unit has a high expertise level, the relative importance of the required compressor aptitude "ease of dismantling" represents only 8% of all its expected aptitudes.

Then, the aptitudes solicitations in their costs affectation can be discussed. The compressor's ease of dismantling (or the modularity of the concerned parts for example) can be different in the three actions. For example, the parts to replace during maintenance have a short lifetime and should be designed to be easily disassembled from the other modules. A smallest proportion of the parts to replace (during overhaul) have a longer lifetime, the design "effort" made for their ease of dismantling can be weaker because of their weaker frequency of replacement. Considering all the solicitations of the dismantling aptitude, its cost is mainly affected to the maintenance and repair actions (40% in each case), while only 20% of its cost is affected to the overhaul. This repartition must still be thought considering the abilities of the technical Unit. For example, since the ease of compressor's dismantling is supposed to be weaker for the overhaul operation, the technical Unit should put a higher "effort" in this solicitation. Considering all the solicitations of its aptitude (expertise), a larger part of its cost should be affected to the overhaul (40%) than to the maintenance and repair operations (30% respectively). (Table 25, andTable 26 andTable 27 respectively). The relative weights (in %) of the ACA of each action in the overall solution cost are expressed, as well as the respective contributions (in %) of the RC and of the DAC in the ACA. Additionally, the distribution of the RC regarding the sub-system's aptitudes is detailed on the Tables. This costs analysis allows identifying the main "hot spots" in the actions defined in the PSS process, and the sources of these costs. A colour code has been used to better illustrate the relative contributions in this costs analysis. The colour code used is detailed in Figure 90 below. The major source of environmental impacts isunsurprisingly -the consumption of electrical energy, despite the amount of energy considered as "recovered". The ACA of the "energy supply" action represents around 86% of the overall EI generated for the indicator ozone layer depletion, 75% for the mineral extraction, and 94% for the aquatic acidification. The main contributor of the ACA for ozone layer depletion and aquatic acidification is unsurprisingly the DAC, i.e. the energy consumption process due to the emissions related to the fossil fuels combustion. For the ozone layer depletion, the contribution of RC is higher than for aquatic acidification, because of some sub-systems' life cycle parts that have been affected to the action: the refrigerant gas within compressors (despite its recycling) and the processes of extraction and manufacturing of the steel and chromium steel parts like the piping. On the mineral extraction, the energy consumption has a higher contribution (around 70%) but the RC highly influences the ACA (around 30% of the cost) because of the material resources affected. The second main contribution (weaker) is due to the maintenance operations: around 12% of the EI on the ozone layer depletion, 9% on the mineral extraction and 4% on the aquatic acidification. Concerning the ozone layer depletion, the main sources of this contribution are the air emissions due to the transport (DAC representing about 80% of the ACA) that is also a large part of the ACA (70%) for the aquatic acidification. Mineral extraction, on the contrary, is logically more impacted by the attribution of sub-systems to the maintenance (RC represents 70% of the ACA), and particularly the spare parts that represent about 45% of the RC. 55,2% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0%

Ozone layer depletion

Pneum

Ease of dismantling 8% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 4,2% 13,4% 5,8%

Ease of maint. / repair 10% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 8,0% 12,6% 3,6%

Ease of transportation 2% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 7,3%

Internal CMS Regulation 90% 0,3% 1,3% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% Data transmission 10% 0,0% 0,0% 1,8% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0%

AoN compressor

Main parts Supply of energy 41% 20,6% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0%

(OR) Reserve supply 41% 0,0% 97,7% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0%

Ease of dismantling 8% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 3,9% 12,2% 0,0% Ease of maint. / repair 10% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 6,3% 10,7% 0,0%

Internal CMS Regulation 90% 0,2% 1,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% Data transmission 10% 0,0% 0,0% 1,4% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0%

Other plant equipment

Air cleaning / delivery /… 93% 23,6% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% Ease of maintenance 7% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 3,4% 0,0% 0,0%

RC Distribution VSD compressor

Main parts Supply of energy 80% 42,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0%

Ease of dismantling 8% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 7,7% 28,7% 5,7%

Ease of maint. / repair 10% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 14,5% 26,9% 3,5%

Ease of transportation 2% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 7,1%

Internal CMS Regulation 90% 0,1% 0,4% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% Data transmission 10% 0,0% 0,0% 0,3% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0%

AoN compressor

Main parts Supply of energy 41% 13,2% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% (OR) Reserve supply 41% 0,0% 99,3% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0%

Ease of dismantling 8% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 5,9% 22,0% 0,0% Ease of maint. / repair 10% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 9,7% 19,3% 0,0%

Internal CMS Regulation 90% 0,0% 0,3% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% Data transmission 10% 0,0% 0,0% 0,2% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0%

Other plant equipment

Air cleaning / delivery /… 93% 44,7% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% Ease of maint. / repair 7% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 15,5% 0,0% 0,0% F.O. Unit Spare parts (maintenance) -100% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 44,8% 0,0% 0,0% Spare parts (repair) -100% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% Spare parts (overhaul) -100% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 82,0%

Technical Unit Dismantling expertise 60% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,7% 2,5% 1,3%

Maintenance expertise 30% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 1,1% 0,0% 0,0%

Repair expertise 10% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,6% 0,3% R.M. Unit RM equip. Collect data 10% 0,0% 0,0% 44,7% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% Store/ analyse 30% 0,0% 0,0% 0,0% 0,0% 98,6% 0,0% 0,0% 0,0% 0,0% Detect failures 60% 0,0% 0,0% 53,7% 94,5% 0,0% 97,6% 0,0% 0,0% 0,0% Supervision Unit Data analysis expertise 40% 0,0% 0,0% 1,2% 4,2% 0,0% 2,1% 0,0% 0,0% 0,0%

Diagnosis expertise 50% 0,0% 0,0% 0,0% 0,0% 1,4% 0,0% 0,0% 0,0% 0,0% Communication skills 10% 0,0% 0,0% 0,0% 1,3% 0,1% 0,3% 0,0% 0,0% 0,0%

RC Distribution VSD compressor

Main parts Supply of energy 80% 49,9% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0%

Ease of dismantling 8% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 4,0% 16,1% 5,0%

Ease of maint. / repair 10% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 7,5% 15,1% 3,1%

Ease of transportation 2% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 6,2%

Internal CMS Regulation 90% 0,5% 2,8% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% Data transmission 10% 0,0% 0,0% 2,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0%

AoN compressor

Main parts Supply of energy 41% 17,5% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% (OR) Reserve supply 41% 0,0% 95,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0%

Ease of dismantling 8% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 3,4% 13,8% 0,0% Ease of maint. / repair 10% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 5,5% 12,0% 0,0%

Internal CMS Regulation 90% 0,4% 2,2% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% Data transmission 10% 0,0% 0,0% 1,6% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0%

Other plant equipment

Air cleaning / delivery /… 93% 31,6% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% Ease of maint. / repair 7% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 4,7% 0,0% 0,0% F.O. Unit Spare parts (maintenance) -100% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 58,9% 0,0% 0,0% Spare parts (repair) -100% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 13,3% 0,0% Spare parts (overhaul) -100% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 60,6%

Technical Unit Dismantling expertise 60% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 6,0% 24,3% 20,1%

Maintenance expertise 30% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 10,0% 0,0% 0,0% Repair expertise 10% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 5,4% 5,0% R.M. Unit RM equip. Collect data 10% 0,0% 0,0% 34,9% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% Store/ analyse 30% 0,0% 0,0% 0,0% 0,0% 76,5% 0,0% 0,0% 0,0% 0,0% The Costs Analysis Tables are useful for negotiating the design since they support the identification of the "hot spots" and of the weaker contributors directly on the design object, i.e. the PSS actions. It can support the design negotiations to establish design priorities, or building alternative scenarios. The "hot spots" can be identified locally, i.e. for each action, or more generally, i.e. at the PSS process scale.

5.4.3.3.a. Local negotiations

From a local viewpoint, some actions of the PSS process can be focused on and the concerned designers can negotiate the involved design parameters.

Here the focus is put on the "maintenance operations". The EI of this action on the ozone layer depletion and on the aquatic acidification are mainly due to the transport (the DAC representing respectively about 80 and 70% of the ACA). However, the Resource Costs are not negligible and, on the mineral extraction, RC represents about 70% of the ACA.

The design priorities can be identified:  First, the EI generated by the transport could be reduced  Second, the affected resources could be re-negotiated. Detailing the contributions to the RC of the different sub-systems' properties, it appears that:

 The cumulated properties of the compressors and other plant machines for being easily dismantled and maintained represent about 26% (of RC);  The spare parts represent about 42%;  The cumulated capacities of expertise of the technical Unit represent 32%. The distribution of the costs can be questioned. For example, the compressors and machines could be designed with less effort made for their ease of dismantling and maintenance if the expertise of the technical Unit is increased. However, this should require an intensified training of the Unit (BOL), and a higher cost of its set of aptitudes. Each designer can also re-negotiate its own sub-system design. For example, considering that the maintenance operations frequency depends on the state variables of the compressors (MTBM), the designers of the compressors could also replace the design effort initially made for facilitating their dismantling by a prolonged lifetime of parts (more robust machine). Less spare parts should be replaced and the EI generated by maintenance transport reduced.

5.4.3.3.b. General negotiations

From a more general PSS viewpoint, the "hot spots" in PSS actions and the costs distribution can also be negotiated. Re-design priorities can be identified for the all PSS. Here, the design priority would be obviously the reduction of the energy consumption and / or of the compressors' materials for reducing the EI generated by the action of supplying the pneumatic energy. This could be seen by product engineers as the application of eco-design or re-design strategies to the plant products. However, such strategies are limited. Indeed, materials used in the plant machines seem already to have been reduced to the maximum. Their weight and optimization have even almost reached the acceptable limits for avoiding performance degradation, according to the AC designers who often face problems with filters or draincocks sized too much tight. Moreover, the energy consumption and its recovery process are managed very carefully by AC: the variable speed regulation, the leaks detection and (essentially) the energy recovery system have led to a resulting energy ratio that could be hardly improved by simply focusing on the plant products. PSS allow thinking products and services as integrated sub-systems that both deliver the expected benefits. By using the Costs Analysis Tables, the relative costs of PSS actions can be regarded as sources for re-thinking the all PSS design. For example, when looking at the ozone layer depletion indicator, it appears (and reflected by the colour code) that the energy supply action is strongly predominant (about 87% of the total cost), the control action (MRO) has an intermediary contribution (about 13%) while the monitoring action has a very weak contribution (less than 0,4%). The costs distribution in these three actions could be questioned. For example, for decreasing the energy consumption, an improved process of monitoring and supervision could be imagined.

Alternative scenario (re-)design: Intelligent system

An alternative scenario should be designed on the basis of the costs analysis. One of the alternative scenarios imagined during the brainstorming is reused in this section. This scenario was built on the basis of the LCA results pointing the "hot spots" discussed in the costs analysis. However, the alternative scenario was a re-design of the services since the products are not manufactured by AC. Enrichments for integrating the possibility to re-design products and integrate them with services are then proposed. Additionally, the brainstorming mainly provided discussion elements on potential benefits or risks / costs associated to the alternative scenario. This scenario has not been further explored from a technical viewpoint. Then, arbitrary coefficients resulting from assumptions are proposed in this section to perform the comparison with the existing case.

Scenario description

The alternative scenario proposes improving the remote monitoring and control capacities through the installation of remote control instruments for the supervision Unit, and intelligent systems that would be able to perform self-diagnosis and self-adjustments. The main goals and expected benefits of this scenario are:

 The possibility to optimize the pneumatic energy production for the "just" need of the customer by a better regulation and self-control of the machines (particularly the compressors), ) then reducing the electrical energy consumed;  The possibility to perform some remote control operations, then reducing the frequency of maintenance travels. A full re-design process would require a new PSS modelling phase. Different products (remote control systems, and internal CMS in the compressors) and service units' roles would be identified, and other scenarios integrating other actions would be defined. However, in absence of details on the possible new products in this alternative scenario, simplifying assumptions have been made. In this thesis, the modelling of the alternative scenario is not made, but differences between the actions of the PSS process and the sub-systems involved in are summarized in the assumptions shown Table 28. The new scenario considers the reduction of electrical energy consumption through an intensified data supervision supported by bigger monitoring systems installed on the plant equipment. Then, a part of the maintenance operations is delocalised (performed by the supervision Unit) and another part is automated. The remaining part of maintenance operations performed by the technical Unit is reduced. However, in this scenario, the reduction of the human/ visual control frequency is supposed to increase the risk of failure of the compressors. The repair operations occur more frequently. The reserve is more often solicited and this requires performing an overhaul of this machine. differently provided in the two scenarios. However, the assumption is made that despite possible differences between the benefits of each design alternative, the needs are still fulfilled in the two cases.

Comparison of solutions' costs

When comparing the two scenarios on the basis of their EI, the alternative scenario is advantageous.

The comparison results are shown in Figure 91. The EI generated in the alternative scenario (Sc1) are decreased compared to the existing case (Sc0) for the three indicators selected. The decrease is clearly not significant for the mineral extraction because of the increase of the required materials in this scenario.

The decrease is less significant for the aquatic acidification than for the ozone layer depletion. Indeed, the relative contribution of transport in maintenance operations is higher for the ozone layer depletion; its decrease has a stronger influence on the total EI decrease for this indicator.

Figure 91 Comparison of the environmental impacts (costs) of the two scenarios When comparing the costs of these two PSS design alternatives considering that the needs' fulfilment is based on the technical performance, the alternative scenario appears as the best design alternative. However, many other aspects have been integrated in the expected outcomes for the beneficiary. The Value Analysis tools are used in the following sections to discuss these aspects.

Comparison of benefits provision

A "satisfaction" attribute has been defined for the outcomes in the two PSS design alternatives. The levels of satisfaction determined on scale from 0 to 10 are detailed in Table 32. They have been defined arbitrarily but are inspired from the brainstorming discussions between AC's employees on the potential benefits and risks of the alternative scenario compared to the existing offer. Figure 92 shows the comparison of the relative satisfaction levels in the two scenarios. As previously mentioned, the technical performance is supposed to be equivalent, with improved energy efficiency in the alternative scenario. The flexibility of the offer is also supposed to be improved in the alternative scenario, because of the systematization of the machines' overhaul: it allows AC to change some of them if required. The logistics management of the compressors' fleet can be optimized and their turnover increased through the different contracts. The technical information provided to the customer can be more accurate because of the development of the remote monitoring and the specialized skills development of the supervision Unit. However, the service reactivity can be impacted. Indeed, the alternative scenario suppose an increased risk of failure and then a design effort put on the compressor's reliability, and on the reserve capacity. The intervention time is reduced in this scenario. Nevertheless, the service reactivity is important for the customer. Customers' employees are able to visually detect and identify defects and failures on the machines and a long intervention time could strongly degrade their perception of the service quality. Additionally, the dialogue process that currently occurs through the frequent maintenance operations is less frequent in the alternative scenario. The relationship would be probably changed and the customer's perception of its quality degraded. The satisfaction of the two outcomes "reactivity" and "dialogue" typically correspond to emerging properties of the system structural organization. The move of the "visibility line" in a new BBM (even if the model is not shown here) of some maintenance actions -that are now performed in the backoffice, strongly influences the resulting outcomes provided to the beneficiary. In order to manage the decision-making process, the proposed VA-based tools are used.

Costs of outcomes

To allocate the costs to the outcomes, the Problem Matrix is used since it expresses the reciprocal influences between the actions in the PSS process and the outcomes. Different distributions of the PSS actions costs are proposed according to the scenario considered. Table 33 shows the proposed costs affectation for the existing case, and Table 34 the costs affectation for the alternative scenario. The costs affectations mainly differ because of the different focuses adopted in the two scenarios. In the existing case, the emphasis is almost equivalently put on the guarantee of the three outcomes for technical performance: air quality, energy efficiency and availability, while the reactivity is an important dimension of the offer. In the alternative scenario, a stronger effort is put for maintaining the plant availability, while the reactivity is less emphasized. The relative costs of outcomes between the two scenarios are represented in Figure 93. The air quality and energy efficiency have a lower cost in the alternative scenario for all the types of costs (i.e. all the indicators chosen). Logically, the availability has a higher cost in the alternative scenario while the reactivity has a lowest cost. The flexibility is dependent on the overhaul operations that generate higher costs in the alternative scenario. The dialogue is dependent of the maintenance operations that generate lower costs in the alternative scenario due to their partial delocalisation. The technical information cost varies according to the type of indicator.

Figure 93 Relative costs of outcomes between the two scenarios

The costs of outcomes can be decreased or increased in the alternative scenario. Their relative increase/decrease must be balanced by the relative increase/decrease of the satisfaction levels of these outcomes and weighted by the importance that the beneficiary attach to each of them.

Importance of outcomes

Importance levels should be defined by the beneficiary. They have been defined arbitrarily. Table 35 shows the importance levels chosen for each outcome, defined on a scale from 1 to 10 (on the first line) and the resulting relative importance (on the second line) supposing that the set of outcomes selected entirely describe the needs of the beneficiary. The technical performance outcomes have the highest importance since they define the basis of the contract commitment. The flexibility and technical information are relatively less important. Here it is supposed that dialoguing is more important for the customer than the technical information provided, and that the service reactivity is relatively quite important due to his previous difficult experience and his need to feel quickly supported in case of failure. The cells coloured in red show the outcomes having lowest values in the alternative scenario (compared to the existing case) and cells in red show the outcomes having a highest value. The scores of the solution are similarly coloured: in green when the score is higher in the alternative scenario, in red when this score is lower. One can notice that regarding the aquatic acidification and the mineral extraction, the alternative scenario has a lower score. It means that regarding the way the costs have been affected to the outcomes, the way the PSS solution satisfies them and their importance for the beneficiary, the alternative scenario should not be selected. Regarding the ozone layer depletion and the aquatic acidification, three outcomes have a lowest value in the alternative scenario: the availability, the reactivity and the flexibility. Indeed, availability and flexibility have higher costs in this scenario, but availability is satisfied equivalently and the increase of satisfaction of flexibility is weak. Flexibility has a lower cost but is concurrently less satisfied whereas its importance level is high. Regarding the ozone layer depletion, these negative gaps of values are finally compensated by the positive ones in the final score (weighted by the importance levels) being higher for the alternative scenario. On the contrary, regarding the aquatic acidification, the compensation does not occur and the relative solution score is lower.

Regarding the mineral extraction, the relative value of technical information is additionally lower in the alternative scenario, because its cost is strongly higher. The final solution score is then also lower.

PSS Sc0 PSS Sc1

Importance When comparing the two proposed PSS scenarios regarding the provision of equivalent technical performance, the alternative scenario is advantageous from an environmental viewpoint. However, the restriction of the needs' fulfilment to the technical performance results in a lack of consideration for many other dimensions that can still have a great importance for the beneficiary.

In product engineering, Value Analysis emphasizes the necessity to not focus only on the solutions' costs, but to align the provider company's goal for reducing these costs with the customer's expected benefits. The solution choice must be made by balancing the functions' costs with their satisfaction and importance [START_REF] Yannou | Proposition de Deux Nouveaux Outils D'aide à La Décision En Analyse de La Valeur Basés Sur Une Définition Opérationnelle de La Valeur[END_REF].

The value analysis tools proposed here follow a similar approach. In PSS design, there is a necessity to decrease the environmental impacts generated while still emphasizing the effective benefits provided.

Due to the intangibility of many benefits or outcomes, they are difficult to integrate in an evaluation process.

The proposed affectation of the PSS costs to the outcomes is clearly questionable: how to understand the affectation of 10% of the maintenance costs to the dialogue process? However, it is necessary for PSS designers to consider that the PSS solution is designed for the provision of 'a set of benefits' that can be hard to measure but should still be affected to a part of the design effort made. Despite its questionability, the proposed affectation of PSS costs to the expected benefits allows embracing the entire set of dimensions contained in the needs to fulfil. Then, considering that PSS solutions are supposed to fulfil equivalently the needs when providing the same functions (or technical performance), the alternative scenario is supposed to be selected because of its lower environmental costs. However in the VA-based approach, PSS should fulfil several dimensions of needs (outcomes) and their design influences this effective fulfilment (satisfaction). The importance of these dimensions for the beneficiary helps to determine the most appropriate solution balancing the benefits with the costs generated. When adopting this viewpoint, the existing PSS is better appropriate for two types of environmental costs: the aquatic acidification and the mineral extraction.

5.4.6. Discussion on the environmental evaluation framework implementation

The proposed VA-based tools raise many questions on their effective applicability and on the procedures or methodologies that should support the determination of the weighting coefficients that have been proposed arbitrarily here.

The costs analysis should support discussions and negotiations between product engineers and service designers, through the facilitation of the "hot spots" identification in the PSS solution, i.e. actions in the PSS process and their affected sub-systems.

The proposed costs analysis can be seen as creating a convergence between the interfaces of the designers' views (product engineering and service design) and the environmental expert views. The PSS design can be negotiated between product and service actors by using the Costs analysis Tables.

Costs analysis Tables are based on the Design Matrix that results from the PSS modelling. The PSS life cycle model is aligned on the Design Matrix for identifying the BOL and the EOL actions of the sub-systems. Then, the environmental impacts calculation proposed is aligned on the PSS design models. This would allow progressing in the environmental evaluations and in the evolution of the priorities definition along the design refinements made.

The environmental expertise and the designers' expertise are all required for defining the costs affectations and building the Tables. These actors can co-operate through a shared view by using the PSS life cycle model and costs analysis tools. The proposed VA-based tools for comparing PSS alternatives should be a support for creating a convergence between the interfaces of the designers' views (product engineering and service design) and the beneficiary view. The importance of the outcomes should be defined by the beneficiary during the conceptual design phase, and the evaluation process should be made by integrating the way the design alternatives satisfy these outcomes. The satisfaction levels should probably be discussed between PSS designers and the beneficiaries. The affectation of the solution costs to the outcomes is the most questionable part. This affectation evolves the current way to think the link between the EI generation and the provision of a solution, since EI are classically affected to a tangible result. However, EI generation should be considered more generally as related to a set of benefits that fulfil needs. It questions the way to define "acceptable" levels of needs fulfilled. In this thesis, the technical performance has still been defined as equivalently fulfilled to avoid such difficulties since its goal was to illustrate an approach. But considering that the reference to be used for evaluation should be a set of outcomes that can be more or less "satisfied" raises the question of the levels under which the needs are considered as not fulfilled. Similar issues for PSS have been underlined by [START_REF] Salazar | Eco-Designing Product Service Systems by Degrading Functions While Maintaining User Satisfaction[END_REF] although expressed quite differently.

The main issue when dealing with service aspects is that the comparison of "systems" does not make sense (at least from a design viewpoint). A beneficiary has an experience containing more or less perceived benefits. The comparison should be made regarding the effects of "interactions between systems". Different service processes involving the beneficiary and the PSS provider result in different benefits that should be balanced with the EI generated. The goal of the proposed environmental evaluation framework is not to prescribe an evaluation process, but to show how environmental evaluation should evolve for integrating these aspects during PSS design. This contributes to initiate a new way of thinking the interface that should be created between the "beneficiary view" (prescribing the reason for being of systems) and the "environmental view" (measuring the externalities of the system being designed). Integration of several types of disciplines (and particularly human sciences) is probably the key to better understand the needs and identify the expected outcomes during the PSS conceptual design, and ensuring the needs fulfilment by evaluating the outcomes provision and the EI generated during PSS detailed design.

Conclusion on the evaluation framework: a path to progress towards value creation

The environmental evaluation framework has been used on the case to illustrate the existing limitations of the classical environmental evaluation tools (like LCA) when reasoning on PSS. Comparing systems by using the Functional Unit as the evaluation reference does not fit in the service aspects of PSS. The role of a PSS eco-design process is to ensure the value creation process of the beneficiary while decreasing the Environmental Impacts (EI) generated. Classical environmental evaluation tools adopt a product engineering view that neglects several intangible benefits that contribute to the value creation. They are mostly focused on the reduction of EI whereas they do not integrate the entire set of benefits that could be expected for ensuring the value creation. Value Analysis tools have historically emerged with the era of "quality assurance" to avoid such deviances regarding the economic costs. The search for the lowest solution cost should be balanced with the needs' fulfilment to avoid missing the products' adoption. This thesis argues that the sustainability achievement through PSS development should adopt a similar viewpoint. The environmental load should be evaluated regarding the effective needs' fulfilment that is, when dealing with service interactions and relationships, strongly dependent on intangible dimensions of the solution benefits. The environmental evaluation framework proposed adopts VAbased tools. Qualitative estimations of the benefits are proposed. (Environmental) costs affectation mechanisms are also proposed, based on the assumption that a set of system costs must be related to a set of its expected benefits since they are linked by the system design. This section illustrates the differences between a classical evaluation based on the provision of the technical performance outcomes and a VA-based evaluation integrating other intangible dimensions. When comparing PSS alternatives using these two evaluations, the results differ. Defining and selecting the "best" design alternative depends on the viewpoint adopted on the balance between costs generation and benefits provision. Despite the somewhat simplistic assumptions made, the questionability of the proposed tools and the issues they raise in terms of effective implementation, the approach proposed and illustrated in this chapter show a possible way to evolve the existing environmental evaluation supports towards a better fit for the PSS specificities. of the sub-systems' interactions. Structural organization allows linking two hierarchical decomposition layers and establishing the design relation between result at the upper layer and structure at the lower layer. This facilitates the negotiations during decomposition.

6.1.3.1.b. Multi-views modelling framework for integrated PSS design (RQ1.2)

The multi-view modelling framework implements design models in the system-based framework to support integrated PSS modelling during design. Several models are used to display two main "views" on the system, i.e. the "product view" and the "service view", while the entire system is represented in each model. Models are those existing in product engineering and service design but have been enriched to be integrated within the framework. Using two views allow each designer to focus on specific design aspects of importance while the entire system is still modelled. An integrated view has been proposed for supporting the PSS requirements decomposition and traceability during design.

6.1.3.1.c. PSS integrated design framework for articulating product, service and system logics

The proposed integrated PSS design framework should support designers' communication through a shared understanding of the design elements used. Negotiations between product and service designs are supported by the framework that should facilitate the decision-making of the involved actors. Moreover, the framework allows performing modelling iterations and progress until the most technical phases of each sub-system while their inter-relations at the system level are maintained. Most of the existing models used for PSS design in the literature either adopt a "product/ system engineering" or a "service design" view, while the other dimension is not well managed. By integrating these views in a co-evolutionary framework, the design models and their progressions can be articulated to facilitate the design tasks independently and interactively at the system level. The models are those used in each discipline. Their enrichments to represent the entire system facilitate their coupling, but do not require changing the existing actors' practices. Their implementation should be facilitated, from this viewpoint.

Framework for PSS environmental evaluation (RQ2)

In order to support PSS environmental evaluation during design, an integrated PSS design framework has been proposed. The framework is based on an environmental evaluation method supported by tools and a PSS life cycle concept and modelling tools.

6.1.3.2.a. Environmental evaluation method and tools (RQ2.1)

A PSS environmental evaluation method is proposed to support environmental evaluations during PSS design. The method couples the LCA methodology with some phases of the Value Analysis (VA). Three main steps are proposed:

 Goal and scope,  Inventory, and  Value Analysis : it can consist in Costs Analysis or in a VA-based comparison Two main tools support the method:

 The Costs Analysis Table is proposed to support costs analysis and questioning PSS design  The Solution Choice Table is proposed to compare and select PSS alternatives The method and its related tools are based on the PSS life cycle model that can be defined during design.

6.1.3.2.b. PSS life cycle concept and modelling tools (RQ2.2)

A system life cycle concept is proposed, based on the system concept. It allows defining a service unit life cycle having similar characteristics than a product life cycle. A PSS life cycle is defined as a set of integrated products' and service units' life cycles.

Implementation issues in companies

The inter-related issue of the applicability scope is the question of the utility of tools and the issues of their effective implementation. It would be interesting to define or qualify their effective utility by leading experiments or studying their implementation, for example comparing the all framework implementation with the use of separated "views" by designers, to test the completeness of views, and / or studying the communication mechanisms between actors using each view. Studying the framework implementation issues would allow enriching the models and tools proposed and better understanding their relative usefulness. Their effective implementation issue would probably question the "process" or the actors' coordination. The question of organizing the tasks of designers would help to reinforce the support. The framework allows designers to work separately or in collaboration, and/or to have some "touch points" for negotiations and evaluations. The aspects have not been dealt in the thesis but are necessary to question for implementing or testing the framework. 6.2.2. Assumptions and scope: a need for further studies Some gaps in the PSS literature have obliged to take many assumptions that are questionable and would require further research to be better managed.

Actors' co-creation

As mentioned in the research scope, the issues of PSS integrated design process and of actors' cocreation through an efficient relationship management have not been dealt in this thesis. However, these issues are still inter-related with those of actors' communication. The communication of product engineers and service designers is strongly influenced by organization of tasks and of decisions within an integrated process. The service relationship along a continuous design and improvement process is a crucial aspect of the value co-creation since it supports mutual learning and co-experience between the involved actors. This should be seen as an essential part of the "design" issues even if covering a larger scope within business processes to manage. From a theoretical viewpoint, some of these issues have been sketched under the angle of view of the "system methodologies". Hard and Soft System Methodologies integration issues are connected to the issues of actors' co-ordination and co-creation. The same type of discussion has been provided when dealing with the complexity of "clarifying the PSS design task": design being classically a cognitive problem-solving approach should now be perceived as a social process in which actions' leading is integrated in the problem-solving.

PSS design actors and practices

This thesis has taken the standpoint that several "views" exist and could be adopted on the PSS that should be shared and communicated between the concerned actors. These views have been identified through the literature exploration. These views exist in the literature and correspond to different research cultures and viewpoints. However, the reality of the cultures and of the service actors within companies is questionable. Several authors emphasize the lack of clarity of service actors and of their roles. Who are actually the "real-life" actors of service in PSS? And what "practices" should be considered in deisgn supports? For example, AC employees have a strong product culture since they size plant equipment, but are acquiring competences to design services. Should the "practices" to consider be those of the existing way or should the transition mechanism towards PSS be emphasized to acquire new skills? Services design and development seem to be mostly under the responsibility of managers who probably miss the technical aspects of design, while product engineers often miss the social ones.

Regarding the increasing interest raised by services in the literature and by PSS development in industrial companies, one can suppose that a specific "service view" will probably be built. As discussed by PSS authors, new skills and competencies are required for efficient services and PSS development and would probably emerge in a few years. This evolution would probably require integrating the tools and bridging the cultures previously developed in product engineering and service design. The utility of the proposed framework should be questioned in the context of PSS transition.

Inter-related issues of integration

The focus adopted on the product-service integration issue shelves many other issues that are still inter-related. Emphasizing the "product-service interface" while not considering the specific challenges of "integrated product design" and of "integrated service design" is a questionable shortcut. Similarly, integration of the "beneficiary" and the "environmental" views corresponds to a major issue that is strongly linked to those of product-service integration because of the specific emphasis of each field on one or another view. 6.2.3.1. Integrated product design and integrated service design Integrated product design and eco-design contains several issues that necessarily remain for PSS ecodesign. Service design, implementation, delivery and management processes also raise many issues. These issues have been mostly excluded from the research scope. However, the "interface" building between the product and service views necessarily contains these "internal" challenges. Integrated design of the products' life cycles for example, is a key challenge that, if efficiently managed, would strongly facilitate the PSS integrated eco-design task. The PSS life cycle model and evaluation tools proposed being focused on the product-service integration issue, they somewhat hide these "internal" challenges. The design levers for intensifying the products' use or prolonging their lifetime through PSS cannot be shown when using Costs Analysis Table. These aspects also deal with questions of multiple PSS beneficiaries having different needs (perceiving different PSS outcomes for a similar offer) that have not been dealt. In further research, it would be of interest to progress towards the integration of the all actors concerned by the sub-systems' life cycles in the PSS integrated design process. A larger viewpoint on the integration issues and on the all involved systems' life cycle management should be adopted to deal with the complexity of PSS. This is an emerging trend in the PSS field.

Needs' fulfilment and value creation

As introduced in the case study discussion, the issues of the beneficiary view integration have been excluded while they are crucial to be efficiently managed throughout the service relationship. The needs understanding and analysis, their qualification and/or quantification during the conceptual design phase would allow further developing the proposal made for a VA-based environmental evaluation framework. The proposed framework traces a generic orientation to better integrate this view in the PSS evaluations, but misses some essential elements of this beneficiary view. For example, the issues of defining the needs "boundaries" or acceptable levels of risks and benefits have been discussed. The proposal made is a basis for further research to progress towards a better integration of the beneficiary's consideration in PSS environmental evaluations. These issues are larger than the initiation of PSS design in the conceptual phase and would require reinforcing integration of social sciences with the engineering ones.

Figure 3

 3 Figure 3 Conclusion principale de l'analyse de la littérature : un gap méthodologique entre les approches "produit" et "service" Le schéma Figure 3 montre l'existence de liens renforcés entre différentes vues. La vue « bénéficiaire » et celle de la « conception de service » sont assez bien intégrées. En effet, les approches pour la conception de service sont très orientées sur les mécanismes intangibles de la création de valeur pour le bénéficiaire et tendent à intégrer de plus en plus d'approches issues des sciences humaines et sociales pour permettre à la relation de service d'évoluer vers la co-création de valeur. La vue « environnementale » et celle de l'« ingénierie de produit » sont historiquement intégrées. La conception intégrée et l'ingénierie système visent à intégrer l'ensemble des parties prenantes du cycle de vie produit dans la conception et l'expertise environnementale permet d'intégrer cette dimension dans le processus d'écoconception par des outils d'analyse et via le développement de méthodologies supports. Pourtant, une distance méthodologique existe entre les méthodologies « orientées produit » (ingénierie et vue environnementale) et celles « orientées service » (conception de service et vue bénéficiaire). D'un côté, les approches du marketing et des sciences sociales (« orientées service ») permettent une bonne compréhension des besoins et un management efficace de la relation client, mais leur intégration en conception dans un processus systématique et multi-acteurs est encore difficile. De plus, les approches « orientées service » sont focalisées sur le besoin et sa satisfaction, et ont tendance à ne pas distinguer produit et services, considérant que ressources physiques et humaines sont toutes des ressources (plus ou moins « interchangeables ») permettant la création de valeur. En procédant ainsi, elles négligent parfois les dimensions techniques de la conception de produit et les impacts environnementaux associés au système finalement conçu (requérant nécessairement l'utilisation de produits dans la fourniture des services). D'un autre côté, les approches d'ingénierie produit et d'analyse environnementale (« orientées produit ») permettent de considérer la conception comme un processus systématique et mutli-acteurs, au sein duquel le cycle de vie du produit constitue le socle de l'intégration des différents métiers.L'intégration de la dimension environnementale (en écoconception) permet de générer de la connaissance sur les impacts du produit durant l'ensemble du cycle de vie et ainsi de guider la conception. Pourtant, les approches « orientées produit » peinent encore à intégrer les dimensions sociales de la création de valeur dans la construction de la réponse aux besoins. Les méthodologies de conception et de management du processus de développement doivent encore progresser pour intégrer

Figure 4

 4 Figure 4 Objectif de la thèse : créer une interface produit-service pour l'intégration

Figure 7

 7 Figure 7 Proposition d'un concept système: le modèle entité-relation liant le système à l'action Un système est donc caractérisé par :  Ses limites  Ses variables d'état  Ses aptitudes Une action est une opération qu'une entité (sujet de l'action) exerce sur une autre entité (objet de l'action) par les moyens d'un transfert de flux. Une action a des propriétés spatiales et temporelles. Une interaction correspond au lien créé entre des systèmes par l'action. L'état du système est une condition à l'action et peut être modifié par l'action.

Figure 8

 8 Figure 8 Proposition d'un cadre conceptuel pour la conception intégrée de SPS Le cadre est composé de trois principaux espaces de conception : Un espace des problèmes, appelé « résultat » (à atteindre), où doit être décidé l'organisation des actions.

Figure 9

 9 Figure 9 Cadre de modélisation multi-vues pour la conception intégrée de SPS

5. 2 .

 2 Proposition d'un cadre conceptuel pour l'évaluation environnementale de SPS en conception Une définition du cycle de vie « système » Une définition d'un cycle de vie est proposée, sur la base de la définition classiquement utilisée d'un cycle de vie produit, composé d'étapes et de portes. Un cycle de vie d'unité de service est représenté Figure 10. Le cycle de vie se compose de trois principaux ensembles d'étapes :  Celles du début de vie : pour l'acquisition d'aptitudes  Celles de la satisfaction du besoin par la sollicitation des aptitudes dans les actions du système  Celles de la « fin de vie » où idéalement les aptitudes doivent être revalorisées / réutilisées au maximum.

Figure 10

 10 Figure 10 Proposition d'un cycle de vie d'unité de service

Figure 12

 12 Figure12Principe de l'outil de diagnostic proposé L'outil de diagnostic consiste en un tableau basé sur la matrice de conception illustrant les relatives contributions à l'impact environnemental et nommé « tableau d'analyse des coûts ». Il permet de négocier : Les spécifications : par exemple, la modularité du compresseur. La matrice « facilité de démontage » peut avoir une contribution forte à l'impact environnemental. Doit-on choisir l'alternative d'une machine plus robuste ?  Les actions à réaliser / les sous-systèmes impliqués. L'action « se déplacer » peut avoir une contribution forte à l'impact. Doit-on envisager des opérations de maintenance à distance ?

Figure 13

 13 Figure 13 Principe de l'outil de comparaison basé sur l'analyse de la Valeur Cet outil de comparaison est davantage une proposition qui ouvre la voie pour évoluer vers de nouveaux modes d'évaluation environnementale, qu'un outil validé par le travail de thèse. Il permet de discuter les limites des outils actuels d'évaluation environnementale lorsqu'on évolue via les SPS vers une meilleure prise en compte de la complexité de la création de valeur dans la relation de service. L'intégration produit-service requiert le développement de nouveaux outils d'évaluation environnementale, et cet aspect est discuté sur la base de la proposition de l'outil de comparaison.

1. 5 .Figure 1 Figure 2 Figure 3

 5123 Figure 1 Main and subcategories of PSS according to Tukker 2004 (Figure reproduced) ................... 51 Figure 2 Evolution of the Product-Service System Concept (reproduced from Baines et al. 2007) ..... 52 Figure 3 Schematic representation of the literature fields explored and of their interconnections ....... 60 Figure 4 Co-evolution of problem-solution as observed in the study conducted by Dorst and Cross (2001) .................................................................................................................................................... 62 Figure 5 Integrated Product Development, an ideal design model showing integration of market and production activities for creating new business (Andreasen and Hein 1987) ....................................... 63 Figure 6 The score model as part of Olesen's product life approach (Andreasen 2011 after Olesen 1992) ...................................................................................................................................................... 65 Figure 7 An example (a possibility among others) of product design and eco-design software tools along the design process (Rio, Reyes, and Roucoules 2011) ................................................................ 69 Figure 8 Representation of all the demands that must be addressed in product development (Luttropp 1999) ...................................................................................................................................................... 70 Figure 9 Value co-creation among service systems (Vargo, Maglio, and Akaka 2008) ....................... 75 Figure 10 The two distinct service transitions (Kowalkowski 2010) .................................................... 76 Figure 11 Conceptual model of the relationship life cycle role in relationship value creation (Eggert, Ulaga, and Schultz 2006) ...................................................................................................................... 79 Figure 12 A conceptual framework for value co-creation (Payne, Storbacka, and Frow 2008) ........... 80 Figure 13 The definition of service (Hara, Arai, and Shimomura 2009) .............................................. 84 Figure 14 Component models of multilevel service design (reproduced from Patrício et al. 2011) ..... 90 Figure 15 Symbolic representation of solutions delivery according to Wood and Tasker (2011) ........ 91 Figure 16 The two life cycle systems that must be considered in the development of PSS (Tan, McAloone, and Andreasen 2006) .......................................................................................................... 94 Figure 17 PSS life cycle of a customer relationship (Matzen and Andreasen 2006) ............................ 95 Figure 18 Graph of interactors for External Functional Analysis (Maussang, Zwolinski, and Brissaud 2009) ...................................................................................................................................................... 98 Figure 19 Functional Block Diagram model to model PSS (Maussang, Zwolinski, and Brissaud 2009) ............................................................................................................................................................... 98 Figure 20 Life cycle stages for Sustainable Products and Services Development (Maxwell, Sheate, and van der Vorst 2006) ............................................................................................................................. 101 Figure 21 The integrated approach of PSSDAE (Shih, Chen, et al. 2009) .......................................... 102 Figure 22 PSS development arena and its boundary conditions (reproduced from McAloone 2011) 109 Figure 23 Proposed perspective on the challenges of PSS integrated eco-design resulting from the exploration of the initial research question ......................................................................................... 115 Figure 24 An integrated PSS design model ......................................................................................... 118 Figure 25 Main research goal: creation of an integrated interface (PS) between 'product engineering' and 'service design' views in an integrated PSS model ...................................................................... 119 Figure 26 A continuous learning process through literature review and industrial collaboration ....... 122 Figure 27 The extreme types of offer in the compressed air field (AC): from the product to the result offer ..................................................................................................................................................... 124 Figure 28 Brainstorming for PSS conceptual (re-)design: (a) discussion between participants; (b) ideas generation; (c) scenarios rating and selection; (d) scenarios discussion ............................................. 125 Figure 29 AC business organization into departments (data from 2013) ............................................ 126 Figure 30 Main research outcomes...................................................................................................... 127

  Figure 1 Main and subcategories of PSS according to Tukker 2004 (Figure reproduced) ................... 51 Figure 2 Evolution of the Product-Service System Concept (reproduced from Baines et al. 2007) ..... 52 Figure 3 Schematic representation of the literature fields explored and of their interconnections ....... 60 Figure 4 Co-evolution of problem-solution as observed in the study conducted by Dorst and Cross (2001) .................................................................................................................................................... 62 Figure 5 Integrated Product Development, an ideal design model showing integration of market and production activities for creating new business (Andreasen and Hein 1987) ....................................... 63 Figure 6 The score model as part of Olesen's product life approach (Andreasen 2011 after Olesen 1992) ...................................................................................................................................................... 65 Figure 7 An example (a possibility among others) of product design and eco-design software tools along the design process (Rio, Reyes, and Roucoules 2011) ................................................................ 69 Figure 8 Representation of all the demands that must be addressed in product development (Luttropp 1999) ...................................................................................................................................................... 70 Figure 9 Value co-creation among service systems (Vargo, Maglio, and Akaka 2008) ....................... 75 Figure 10 The two distinct service transitions (Kowalkowski 2010) .................................................... 76 Figure 11 Conceptual model of the relationship life cycle role in relationship value creation (Eggert, Ulaga, and Schultz 2006) ...................................................................................................................... 79 Figure 12 A conceptual framework for value co-creation (Payne, Storbacka, and Frow 2008) ........... 80 Figure 13 The definition of service (Hara, Arai, and Shimomura 2009) .............................................. 84 Figure 14 Component models of multilevel service design (reproduced from Patrício et al. 2011) ..... 90 Figure 15 Symbolic representation of solutions delivery according to Wood and Tasker (2011) ........ 91 Figure 16 The two life cycle systems that must be considered in the development of PSS (Tan, McAloone, and Andreasen 2006) .......................................................................................................... 94 Figure 17 PSS life cycle of a customer relationship (Matzen and Andreasen 2006) ............................ 95 Figure 18 Graph of interactors for External Functional Analysis (Maussang, Zwolinski, and Brissaud 2009) ...................................................................................................................................................... 98 Figure 19 Functional Block Diagram model to model PSS (Maussang, Zwolinski, and Brissaud 2009) ............................................................................................................................................................... 98 Figure 20 Life cycle stages for Sustainable Products and Services Development (Maxwell, Sheate, and van der Vorst 2006) ............................................................................................................................. 101 Figure 21 The integrated approach of PSSDAE (Shih, Chen, et al. 2009) .......................................... 102 Figure 22 PSS development arena and its boundary conditions (reproduced from McAloone 2011) 109 Figure 23 Proposed perspective on the challenges of PSS integrated eco-design resulting from the exploration of the initial research question ......................................................................................... 115 Figure 24 An integrated PSS design model ......................................................................................... 118 Figure 25 Main research goal: creation of an integrated interface (PS) between 'product engineering' and 'service design' views in an integrated PSS model ...................................................................... 119 Figure 26 A continuous learning process through literature review and industrial collaboration ....... 122 Figure 27 The extreme types of offer in the compressed air field (AC): from the product to the result offer ..................................................................................................................................................... 124 Figure 28 Brainstorming for PSS conceptual (re-)design: (a) discussion between participants; (b) ideas generation; (c) scenarios rating and selection; (d) scenarios discussion ............................................. 125 Figure 29 AC business organization into departments (data from 2013) ............................................ 126 Figure 30 Main research outcomes...................................................................................................... 127

  Figure 31 Schematic representation of the existing design spaces in product and system engineering frameworks (links and iterations omitted) ........................................................................................... 131 Figure 32 Illustration of the differences between Hard and Soft System Methodologies through the design progression within spaces: (a) a simplified illustration of the Hard system view (iterations and validation process omitted); (b) proposed illustration of the Soft System Methodology applied to the service experience ............................................................................................................................... 132 Figure 33 Design spaces in product, system and service engineering frameworks (links and iterations omitted) ............................................................................................................................................... 133 Figure System thinking and the observer-dependency of layers (Checkland 2000) ...................... 133 Figure Problem and solution spaces in the beneficiary and the service design views ................... 134 Figure Issues of building an integrated PSS design framework ..................................................... 135 Figure 37 (a) Reasoning from a device's goal to its structure; (b) Bypassing actions and behaviour in functional basis design reasoning about devices (Vermaas 2013) ...................................................... 136 Figure The spatial perspective used in functional models .............................................................. 137 Figure The temporal perspective used in process models .............................................................. 137 Figure Proposal of a system concept: the entity-relation model linking system to action ............. 139 Figure 41 Differences between product engineering and service design views regarding the proposed system concept .................................................................................................................................... 140 Figure Proposal of a PSS integrated design framework ................................................................. 142 Figure Situational elements for defining external scenarios .......................................................... 143 Figure Proposed "multi-views" modelling framework for PSS integrated design ......................... 147 Figure 45 Models for the product view: (a) Block Diagram proposed for system structure modelling; (b) Functional Block Diagram (adapted from Maussang, Zwolinski, and Brissaud 2009) used for structural organization modelling ........................................................................................................ 148 Figure (Initial) Flow model for system structure modelling from the service view ....................... 149 Figure Process model proposed for PSS result for the service view .............................................. 150 Figure 48 The Service System Navigation (SSN) proposed for PSS structure modelling for the service view (adapted from Patrício et al. 2011) ............................................................................................. 151 Figure 49 The Blueprint-Based Model (BBM) proposed for PSS structural organization modelling for the service view ................................................................................................................................... 152 Figure Proposal of an activity construct in the IDEF0 model of the result for the integrated view 153 Figure Adapted IDEF0 model proposed for result modelling for the integrated view ................... 154 Figure Coupling of result models within the design framework .................................................... 155 Figure Coupling of structure models within the design framework ............................................... 156 Figure Coupling of structural organization models within the design framework ......................... 157 Figure 55 Overview of the "multi-views" modelling framework proposed for PSS integrated design (also displayed Figure 44) ................................................................................................................... 157 Figure Proposed framework for integrated product-service design during PSS detailed design ... 159 Figure Cost-Importance-Satisfaction triptych (according to Yannou 1999) .................................. 162 Figure Example of "importance-cost" histogram proposed in VA ................................................. 163 Figure Proposed PSS eco-design spaces and the specific "views" adopted on their hierarchy ...... 165 Figure Example of a service unit life cycle .................................................................................... 166 Figure PSS life cycle as a set of integrated resources' life cycles .................................................. 167 Figure Linking the hierarchical layers of the environmental view: Life cycle Matrixes ............... 168 Figure Proposal of a PSS environmental costs analysis approach ................................................. 169 Figure Proposal for adapting VA to the PSS evaluation: replacing the hierarchical layers ........... 174 Figure Proposed PSS environmental evaluation framework .......................................................... 177

Figure 1

 1 Figure 1 Main and subcategories of PSS according to Tukker 2004 (Figure reproduced)

Figure 3

 3 Figure 3 Schematic representation of the literature fields explored and of their interconnections

Figure 7

 7 Figure 7 An example (a possibility among others) of product design and eco-design software tools along the design process (Rio, Reyes, and Roucoules 2011)

Figure 9

 9 Figure9Value co-creation among service systems[START_REF] Vargo | On Value and Value Co-Creation: A Service Systems and Service Logic Perspective[END_REF] 2.2.1.4. Service transition mechanism: Logic vs. business transition[START_REF] Kowalkowski | What Does a Service-Dominant Logic Really Mean for Manufacturing Firms?[END_REF] has pointed out that there have been misconceptions of what S-DL actually means, leading to misinterpretations and erroneous managerial implications. He provided a detailed explanation of the differences between a product-service transition and a transition from a Goods-Dominant logic to a Service-Dominant Logic.

Figure 10

 10 Figure10The two distinct service transitions[START_REF] Kowalkowski | What Does a Service-Dominant Logic Really Mean for Manufacturing Firms?[END_REF] He emphasized the fact that many firms in service industries may have a G-DL perspective, taking the IBM example as a typical path of evolution through the grid proposed. IBM has strong relationships with S-DL as previously mentioned. IBM has been used in literature as an example of a successful transition from a manufacturing logic to a service logic(Maglio and Spohrer 2013). Kowalkowski argued that IBM claims that S-DL has been the theoretical foundation of the change in its service-science business model built on thorough research led in California, whereas IBM has actually moved from Cell I to Cell II (on Figure10) over the last decades and more recently to Cell IV (after Kowalkowski and Ballantyne 2009). He added that such a sequential transition seems to be the most likely (and perhaps the only viable) route in many cases towards an S-DL perspective, due to the strong position of G-DL in most manufacturing firms.

Figure 11

 11 Figure 11 Conceptual model of the relationship life cycle role in relationship value creation[START_REF] Eggert | Value Creation in the Relationship Life Cycle: A Quasi-Longitudinal Analysis[END_REF]

Figure 12 A

 12 Figure12A conceptual framework for value co-creation[START_REF] Payne | Managing the Co-Creation of Value[END_REF]

Figure 14

 14 Figure 14 Component models of multilevel service design (reproduced from Patrício et al. 2011)

Figure 17

 17 Figure17PSS life cycle of a customer relationship[START_REF] Matzen | Opportunity Parameters in the Development of Product/service-Systems[END_REF]

Figure 18

 18 Figure18Graph of interactors for External Functional Analysis[START_REF] Maussang | Product-Service System Design Methodology: From the PSS Architecture Design to the Products Specifications[END_REF]

2. 4 . 3 . 3 .

 433 PSS Eco-design and Design for Sustainability 2.4.3.3.a. DfX for PSS life cycleUsing DfX in each phase of the PSS life cycle[START_REF] Sundin | Life-Cycle Perspectives of Product/Service-Systems: In Design Theory[END_REF] defined the PSS life cycle perspective as life-cycle considerations that must be integrated for both physical products used in the PSS and the services used during and between the contract times. He proposed using DfX methodologies to support the product life cycle design. The product life cycle phases considered are: manufacturing (Design for Assembly, Design for Manufacturing); Delivery (Design for Delivery); Usage (supported through service activities for monitoring, giving use instructions etc.); Maintenance (Design for Service); Recycling (Design for Disassembly and Design for Recycling); and Remanufacturing.

Figure 20

 20 Figure 20 Life cycle stages for Sustainable Products and Services Development (Maxwell, Sheate, and van der Vorst 2006)

Figure 22

 22 Figure 22 PSS development arena and its boundary conditions (reproduced from McAloone 2011)

4 .

 4 Conclusion: The co-creation challenge of PSS design

Figure 23

 23 Figure 23 Proposed perspective on the challenges of PSS integrated eco-design resulting from the exploration of the initial research question

Figure 25

 25 Figure 25 Main research goal: creation of an integrated interface (PS) between 'product engineering' and 'service design' views in an integrated PSS model

Figure 28

 28 Figure 28 Brainstorming for PSS conceptual (re-)design: (a) discussion between participants; (b) ideas generation; (c) scenarios rating and selection; (d) scenarios discussion Information collection During the LCAs that have been performed, several source of information have been used. Internal documents have been provided and 12 meetings have been organized with different representatives of the company for the two LCAs. AC is organized according to five departments that are displayed on Figure 29 (indicating the number of employees for each department). The technical department is the largest one. It has been subdivided into three main facilities. The industry facility is the largest one. The Building and Public Works facility fulfils the specific needs of Public Works contracts while the pumps facility is dedicated to the equipment specific to the vacuum and water activities of the company. Two other departments ensure the support of the technical area management: the supply facility and the tools facility.The departments and facilities included in the study have been coloured on Figure29. Representatives from the departments coloured in orange have been interviewed. The departments coloured in green correspond to those have been integrated in the study (i.e. in the initial LCA or during the application of the design method) but interviews have not been performed. Most of the interviews have been done with the design department (and sometimes the CEO) that was the privileged contact. One of the two employees within the design department has previously worked for years as a manager of the industry facility. A sales representative has also been interviewed.

Figure 37

 37 Figure 37 (a) Reasoning from a device's goal to its structure; (b) Bypassing actions and behaviour in functional basis design reasoning about devices (Vermaas 2013)

Figure 40

 40 Figure 40 Proposal of a system concept: the entity-relation model linking system to action

4. 1 . 3 .

 13 Proposal of a PSS design framework 4.1.3.1. Proposal of a conceptual design framework4.1.3.1.a

Figure 43

 43 Figure 43 Situational elements for defining external scenarios

Figure 44

 44 Figure44Proposed "multi-views" modelling framework for PSS integrated design

  Models of structure and of structural organization are displayed in Figure45. The "Block Diagram" on the left side (a) is used to represent the hierarchical decomposition of the system into sub-systems and the so-called system "structure". It corresponds to a FBD without the representation of the functional flows. The black lines on the scheme represent the system boundaries with external entities. The set of system components are represented by rectangular (for products) and curved-angles (for service units) boxes. Product can be decomposed into sub-products and service units into sub-units. The Functional Block Diagram (FBD) displayed on the right side of Figure 45 (b) and initially proposed by allows representing the functional flows circulating within the structure, i.e. the so-called system "structural organization". Physical contacts between components are represented by thin black lines. Here, authors propose representing functional flows by circulating flows between components (dotted grey lines on Figure 45-b) and by using Design Loops (DLs).

Figure 45

 45 Figure 45 Models for the product view: (a) Block Diagram proposed for system structure modelling; (b) Functional Block Diagram (adapted from Maussang, Zwolinski, and Brissaud 2009) used for structural organization modelling 4.1.4.3.b. Models used in the Service view Initial structure model In service design, the initial service structure is generally displayed in terms of stakeholders or actors involved in the value creation process. Their identification is the initial step for starting the elicitation of service boundaries. A Flow model is proposed to initiate the PSS structure definition in terms of actors involved and their relative scope of responsibilities. Such a Flow model is similar to the proposal made in SE for Service CAD[START_REF] Hara | A CAD System for Service Innovation: Integrated Representation of Function, Service Activity, and Product Behaviour[END_REF]. It displays the links between the actors involved in the value creation process by expressing their respective scopes of intervention in the process (see Figure46).

Figure 46 (

 46 Figure 46 (Initial) Flow model for system structure modelling from the service viewResult model A process model is proposed for expressing the system result in the service view. The process model's role is to display the temporal links between expected actions (organized into sequences, triggered by events). The proposed process model is displayed Figure47. Activity-based models used in service design being "open-box models", the representation of processes are hardly separable from those of the structure elements (initially identified as actors in the Flow model). Some structural elements can still be graphically expressed (like in the Block Diagram used in the product view). The PSS boundaries can be expressed by thick black lines separating the external entities from the sub-systems. Additionally, the separation of the actors' responsibilities (actors' roles) regarding the processes performed by entities is expressed by a "responsibility line". Actions are organized throughout a timeline that can be arbitrarily defined. It illustrates the organization of scenarios by displaying the occurrence of events. Once elicited, the PSS boundaries separate the external events (related to external entities) and associated external scenarios from the internal ones (related to internal components). External events ("e") related to external entities can occur and trigger the related external scenario ("E"). Events and scenarios are numbered on Figure47.: an external event "ex" triggers the associated external scenario "Ex". External scenarios can be decomposed into internal ones ("I") triggered by internal events ("i") that are also numbered. For example on Figure47, the external scenario E1 (triggered by the event e0) is decomposed into two internal scenarios: I0 (also triggered by e0) and I1 (triggered by an internal event i1).

Figure 48

 48 Figure 48 The Service System Navigation (SSN) proposed for PSS structure modelling for the service view (adapted from Patrício et al. 2011)

Figure 49

 49 Figure 49 The Blueprint-Based Model (BBM) proposed for PSS structural organization modelling for the service view 4.1.4.3.c. Model used in the integrated view Product and service views emphasize different aspects of the problem by adopting a specific formulation that depends of the model. However, it is necessary to define an integrated representation of the result space to trace the problem decomposition. To support the integrated view in the result domain, the IDEF0/SADT model that is used for product-, service-, and PSS-design is extended and adapted for representing elements from both the product and the service views on result. The proposed construct of activity for IDEF0 modelling allows representing the two patterns: statechange and operations on flows. The interacting entities are expressed by the ICOMs links between activities: Inputs or Outputs being object of the action, Controls being entities that trigger or influence the action (by generating events, for example), Mechanisms being the subject of the action. The resulting activity construct proposed is displayed in Figure 50.

Figure 50

 50 Figure 50 Proposal of an activity construct in the IDEF0 model of the result for the integrated view Classical IDEF0 models are based on black box principles and should better fit with the product view. IDEF0 model systematically represents contextualized activities: the purpose and context of modelling have to be expressed at the beginning of the modelling task. Adaptations of the diagrams decomposition process in IDEF0 are proposed to ensure the representation of several "contextualized" diagrams at different levels of decomposition and better fit with the service view. The proposal for an adapted IDEF0 model is shown Figure 51. Each diagram models a given activity instance in a scenario. The model allows decomposing each activity into a set of several instances that are required in specific scenarios. The activity class is mentioned in the bottom left square. The reference of the scenarios in which the diagram instance is required is mentioned in the bottom right square of each diagram.On the example provided Figure51, an initial activity depicting a generic process (result) expected for fulfilling the beneficiary's needs can be expressed in the A-0 diagram. Two external events have been identified (e1 and e2) and associated to two external scenarios (E1 and E2). When decomposing the generic process, two A-0 diagrams can be proposed: the result must be achieved through two instances of external scenarios (E1 and E2) in which the actions required (and activities here) differ: the E1 scenario contains two activities (A1 and A2) while the second scenario contains three activities. After decomposition, two internal scenarios have been identified (named I1 and I2). On Figure51, activity A11 required in the scenario E1 has two different instances related to the internal scenarios. The IDEF0 model currently supports a progressive decomposition of the "black boxes" but the proposal for displaying instances of diagrams in scenarios at each level allows addition of information when scenarios are progressively identified. The model-building process of the service view is then supported.

Figure 51

 51 Figure 51 Adapted IDEF0 model proposed for result modelling for the integrated view 4.1.4.4. Models coupling within the design framework 4.1.4.4.a. Coupling and decomposing result models Functional vs.action descriptionsResult models provide information on the expected actions that provide the required outcomes for the beneficiary. However, in the product and in the service views, different types of elements are displayed since the service view uses a description of actions while the product view uses a functional description. The process model in the service view organizes the expected actions temporally according to different events and scenarios identified. It well expresses how the different actors and the PSS components must operate the service delivery within the beneficiary's sphere (wider system) to provide value. However, the links between actions that are not temporal ones are difficult to represent. The functions expressed on the Graph of interactors represent a link between systems (reflecting a link between actions). Functions link the system to the external entities by "functions". As previously discussed, functions emerge from interaction. In this sense, the Graph of interactors could be seen as a "structural organization" model of the system in its wider system. However, it focuses only on the specific interactions of the PSS in order to define its aptitudes (formulation of functions) and misses information on the interactions occurring between the external entities. It is considered as expressing a "problem" for the product view for concurrently defining the expectations for the system actions and its properties. The process model emphasizes the dynamic aspect of the expected actions in time, but misses the representation of the links between these actions, while the Graph of interactors expressively represents these links by functions. However, the Graph of interactors misses the dynamism of these

Figure 55

 55 Figure 55 Overview of the "multi-views" modelling framework proposed for PSS integrated design (also displayed Figure 44)

Figure 57

 57 Figure57Cost-Importance-Satisfaction triptych (according to[START_REF] Yannou | Proposition de Deux Nouveaux Outils D'aide à La Décision En Analyse de La Valeur Basés Sur Une Définition Opérationnelle de La Valeur[END_REF]

  (on the bottom of the Figure). The representation of a PSS multi-views model previously proposed in the research clarification is also shown on the top of the Figure.

Figure 62

 62 Figure 62 Linking the hierarchical layers of the environmental view: Life cycle Matrixes 4.2.2.3. Proposal of VA-based tools for environmental evaluation VA contains different steps and allows analysing a design or comparing solution.In this thesis, VAbased tools are proposed for performing the "costs analysis" (step 3 in VA) in order to identify the environmental "hot spots" of the PSS design, and for performing the PSS evaluation (step 5 in VA) in order to compare design alternatives.

Figure 64

 64 Figure 64 Proposal for adapting VA to the PSS evaluation: replacing the hierarchical layers

Figure 65

 65 Figure 65 Proposed PSS environmental evaluation framework

  Regarding the thesis proposals, the PSS life cycle integrated design is supported by several contributions: The integrated product-service design framework support the building of an integrated PSS model and successive refinements during design until the most detailed phases.  Some Life cycle Matrixes, i.e. the Design Matrix and the Resource Matrix, support the link between integrated product-service design and integrated design of the sub-systems' life cycles.  The life cycle definition proposed allows integrating the products' and services' life cycles in the resulting PSS life cycle model proposed. These contributions are illustrated in Figure67. The PSS Life Cycle Integrated Design should be composed of:  Integrated Product-Service design supported by an integrated PSS model (in the centre of the Figure)  Integrated design of products supported by products' life cycle models (on the left)  Integrated design of services supported by services' life cycle models (on the right)

Figure 67 Figure 68

 6768 Figure 67 Framework for PSS Life Cycle integrated Design4.3.2.2. PSS environmental evaluationThe proposed PSS evaluation framework is supported by the PSS life cycle model proposed. A costs analysis tool is proposed to analyse the design. The PSS life cycle model (the PSS integrated design) can be directly questioned. A VA-based tool is proposed to compare design alternatives by balancing costs generated with the benefits provided regarding the outcomes provision. This allows selecting a PSS alternative.

Figure 72 PSS

 72 Figure 72 PSS Result model of the service view: Process model

Figure 73

 73 Figure 73 PSS initial Structure model of the service view: Service System Navigation (SSN) model 5.2.1.2. Coupling the views: Result models

  Since two external scenarios have been identified, two Graph of interactors are shown: the E0 scenario (a) and in the E1 scenario (b).

Figure 74 PSS

 74 Figure 74 PSS Result model of the product view: Graphs of interactors (a) in the E0 scenario; (b) in the E1 scenario

Figure 75

 75 Figure 75 Representation of PSS functions as system interactions

Figure 76 PSS

 76 Figure 76 PSS Result model of the integrated view: A0 diagram

  (partial). The decomposition follows a means-end axis shown on the top of the Figure: on the left side functions are decomposed, on the right side, the identified sub-systems are detailed. The links between them are expressed (design relations).

2 .

 2 To detect failures TF A-To perform the pneumatic energy supply TF B -To ensure availability of energy supply IF1 -Use external air and electrical energy to continuously supply the customer's piping with pneumatic energy

Figure 78 PSS

 78 Figure 78 PSS Structure model of the product view: Block Diagram (partial)

Figure 83

 83 Figure 83 PSS structural organization model of the service view: Blueprint-Based Model (BBM)

Figure 84

 84 Figure 84 Result model of the head compressor: Graphs of interactors (a) in the E0-I0 scenario; (b) in the E0-I1 scenario

Figure 86 PSS

 86 Figure 86 PSS Result model of the integrated view (partial) after decomposition: (a) repair activity diagram; (b) dismantling activity diagram

Figure 87

 87 Figure 87 Products taken into account for evaluation 5.3.1.2. Design Matrix (DM): Aptitudes solicitations in PSS actions

Figure 88

 88 Figure 88 Compressors' use scenariosFor fulfilling the expected outcomes of these two contracts, two VSD and two AoN compressors are required that are respectively identically aged at the end. Then, considering the fulfilment of the expected outcomes for a single contract, only one VSD compressor flow and one single AoN compressor flow are required. In the PSS life cycle model used, only these two compressors have been modelled, considering that equivalent proportions of the AoN have been designed to be dedicated to the head and to the reserve supply.

Figure 90

 90 Figure 90 Colour code used in the Costs Analysis Tables

Figure 92

 92 Figure 92 Relative satisfaction levels of outcomes in the two scenarios

Figure 94

 94 Figure 94 Thesis contribution: A framework for integrated PSS eco-design

Espace de Résultat Espace de Structure

	Sur-système
	Système
	Sous-
	système
	…

  ). Problèmes et solutions coévoluent, ils sont décomposables. Dans l'espace de résultat, les (inter)actions externes au système sont décomposées jusqu'aux actions internes aux sous-systèmes, et dans l'espace de structure, le sursystème se décompose pour identifier le système, séparé des entités externes par ses limites, puis les sous-systèmes, etc. L'espace de négociation est celui qui permet l'association de l'espace de résultat avec l'espace de structure. Il est à l'intersection entre deux niveaux de décomposition, puisqu'il permet d'identifier les sous-systèmes (solutions internes) et leurs interactions pour la réalisation des actions du système

(problème externe). Il permet la négociation entre les concepteurs entre les solutions imaginées (soussystèmes), et la manière dont elles s'organisent pour réaliser les actions attendues (problème). D'autres éléments pour l'utilisation de ce cadre en conception ont été proposés, comme :

 Les évènements (externes ou internes)  Les scénarios (externes ou internes) déclenchés par les évènements  …

négociations de conception via la matrice de conception

  Le cadre de modélisation permet de représenter les actions ou fonctions attendues dans les modèles de résultat, et de représenter dans les modèles de structure l'organisation du système et de ses soussystèmes. Les actions / fonctions attendues peuvent être décomposées progressivement et associés aux solutions (sous-systèmes) par la relation de conception, qui s'établit différemment dans les vues produit et service. Les deux vues se focalisent sur des aspects différents mais complémentaires des (inter)actions et des sous-systèmes, et peuvent s'enrichir mutuellement par l'utilisation couplée des modèles dans le cadre de conception. Les modèles d'organisation structurelle permettent de représenter les sous-systèmes et leurs interactions, et se focalisent dans les vues produit / service sur différentes dimensions des interactions : la dimension spatiale est principalement mise en avant dans la vue produit, la dimension temporelle dans la vue service. Ces modèles sont le point de départ des négociations de conception qui doivent s'opérer pour déterminer les choix à faire entre les paramètres produit et service. des spécifications et importances différentes) pourrait être le choix d'un compresseur robuste nécessitant peu de maintenance mais des compétences techniques hautement qualifiées de l'unité de service en cas de nécessité d'un démontage (panne). La matrice de conception permet donc d'exprimer et de négocier les alternatives et les choix de conception sur les sous-systèmes du SPS, et vient compléter le cadre de modélisation pour la conception intégrée produit-service. Le cadre de modélisation et la construction de la matrice s'inscrivent dans une méthodologie de conception de SPS qui a été proposée. Les outils et la méthodologie ont été testés sur le cas industriel pour vérifier son applicabilité et discuter sa capacité à favoriser la communication entre les concepteurs et à permettre les négociations de conception.

	Les ACTIONS	MAINTENANCE
	Sous-système	Aptitudes	Importance des aptitudes (% sur l'ensemble des aptitudes)	Se déplacer	Démonter	défectueuses	les pièces	Remplacer
	Compresseur	Robustesse	Basse
		Facilité de démontage	Haute	X
		Facilité de remplacement	Haute			X
		des pièces
	Unité de	Capacité à se déplacer	X
	service	/conduire
	technique	Expertise de démontage	Basse	X
		Expertise de réparation	Basse			X
	Pièces de	Disponibilité				X
	rechange
	Tableau 2 Matrice de conception : exemple de l'action « maintenance » et du choix d'un compresseur
			modulaire

L'outil de modélisation permet de modéliser et décomposer les spécifications et les sous-systèmes (produits et services). Les négociations de conception peuvent s'opérer via la matrice de conception (voir Tableau 2) qui permet de croiser les actions attendues avec le choix des sous-systèmes et de leurs spécifications (aptitudes). Un exemple est fourni Tableau 2 pour illustrer une partie d'une matrice de conception. L'action de « maintenance » est attendue et décomposée en sous actions (se déplacer, démonter, remplacer les pièces défectueuses) dans lesquelles des sous-systèmes interagissent : le compresseur, l'unité de service technique, et les pièces de rechanges. Les aptitudes attendues de ces sous-systèmes (spécifications) sont sollicitées dans les actions. Par exemple, l'action de « remplacer les pièces défectueuses » sollicite la « facilité de remplacement des pièces » du compresseur, « l'expertise de réparation » de l'unité de service et la « disponibilité » des pièces de rechange.

Des niveaux d'importance des aptitudes peuvent être définis (et exprimés qualitativement par des % de contributions sur un ensemble d'aptitudes), pour négocier les choix de conception. Par exemple ici, les concepteurs ont sélectionné un compresseur modulaire en considérant que les opérations de maintenance seraient fréquentes et le remplacement des pièces régulier. Mais un scénario alternatif (exprimé avec

Début de vie Fin de vie Tombe Berceau

			Etape	Etape	Etape	Etape
	Acquisition d'aptitudes	Sollicitations d'aptitudes dans les actions du système	Valorisation / réutilisation d'aptitudes
	Formation logicielle	Lecture de documents	Réalisation d'une AMDEC	Surveillance à distance	Télé-diagnostic des pannes	Reporting Télé-enregistrements	Retour d'expérience

Porte Porte Satisfaction des besoins Fourniture d' « outcomes » Figure

11 Proposition pour définir le cycle de vie d'un SPS

Un cadre d'évaluation environnementale

Un cadre pour l'évaluation environnementale est proposé, pour supporter la conception intégrée de SPS. Il est basé sur les principes de l'Analyse de la Valeur et se compose de deux outils principaux qui s'intègrent dans une méthodologie :

 Un outil de diagnostic : pour déterminer les « contributions majeures » des impacts environnementaux générés par le SPS, via un « tableau d'analyse des coûts ».  Un outil de comparaison : pour pouvoir comparer différentes alternatives de conception, via un « tableau de choix des solutions ».

  Le principe global de l'outil de comparaison est basé sur ceux proposés en Analyse de la Valeur et est illustré Figure13. La comparaison est basée sur un ratio entre un ensemble de bénéfices attendus (qui incluent des dimensions plus intangibles du besoin, comme la réactivité, le dialogue, etc…) et un ensemble de coûts environnementaux générés par le SPS pour la satisfaction de ce besoin. Lorsque l'on compare des alternatives de SPS en conception, il est nécessaire de considérer les disparités entre ces alternatives du point de vue des dimensions des bénéfices (et donc du besoin) qui sont effectivement fournis (besoin effectivement rempli) au bénéficiaire. L'idée étant qu'entre deux alternatives, les coûts environnementaux varient, mais les bénéfices aussi.

L'outil de comparaison permet de comparer des alternatives de conception, en intégrant les multiples dimensions du besoin / des bénéfices attendus par le bénéficiaire et qui vont au-delà de la considération fonctionnelle (classiquement une UF quantifiable). L'outil de comparaison réutilise et adapte aux spécificités des SPS le « tableau de choix des solutions » proposé en Analyse de la Valeur

[START_REF] Yannou | Proposition de Deux Nouveaux Outils D'aide à La Décision En Analyse de La Valeur Basés Sur Une Définition Opérationnelle de La Valeur[END_REF]

) pour pouvoir sélectionner la meilleure alternative de conception au regard des bénéfices générés, de leur importance relative pour le bénéficiaire, et des coûts (environnementaux) engendrés par la solution.

  Le second correspond au cadre d'évaluation environnementale proposé pour appuyer la conception intégrée du système (QR2), via la modélisation progressive du cycle de vie du système et les outils proposés pour l'évaluation environnementale qui viennent alimenter la discussion et les négociations d'écoconception.

	Un ensemble de bénéfices attendus I. Conception stratégique du SPS	VERSUS Bénéficiaires, besoins, attentes Positionnement stratégique de l'offre
	Performance (qualité d'air, ratio technique		flexibilité…) Qualité du service (réactivité, CONCEPT DE SPS
	énergétique…)
	II. Phase de « conception produit-service » du SPS Intégration	Qualité de la relation (feed-back, dialogue…) Cadre conceptuel pour la conception intégrée produit-service	Modèle de cycle de vie SPS	• • • •	Destruction de la couche d'ozone Extraction minérale Acidification aquatique … Cadre conceptuel pour l'évaluation environnementale
	produit-	Un ensemble de coûts
	service	(environnementaux)
	QR1			QR2
		CADRE DE LA THESE
	Toutes ces pistes de recherche ont été ouvertes par la proposition faite dans cette thèse pour
	l'écoconception intégrée de SPS, dont l'applicabilité a été montrée par une utilisation sur un cas
	industriel, et dont le potentiel pour faciliter la communication et les négociations entre les acteurs de la
	conception a été discuté dans ces travaux.

La contribution de la thèse est donc un cadre conceptuel pour l'écoconception intégrée de SPS et est illustré à la Figure

14

. Il se compose de plusieurs blocs, et le cadre de la thèse se concentre sur certains. La phase de conception stratégique est exclue du cadre de la recherche. Cependant, cette phase est supposée permettre d'identifier clairement les bénéficiaires, leurs besoins et attentes et permettre le positionnement stratégique de l'offre. Cette phase doit se terminer par la sélection d'un concept de SPS. La thèse se concentre sur la phase de « conception produit-service » du SPS. Le cadre conceptuel proposé englobe deux principaux blocs méthodologiques :

 Le premier correspond au cadre de conception intégrée produit-service, via la modélisation du système et la construction de la matrice de conception (QR1). Il permet aux ingénieurs produit et aux concepteurs de service de progresser dans la conception du système jusqu'aux phases les plus détaillées, car il facilite leur communication et les négociations de conception sur les sous-systèmes.  Figure 14 Contribution de la thèse : un cadre conceptuel pour l'écoconception intégrée de SPS Plusieurs perspectives de recherche s'ouvrent avec cette thèse.  D'abord, la thèse se concentre sur l'intégration produit-service en conception, tout en intégrant la dimension environnementale. Pour progresser vers l'écoconception intégrée totale du SPS, il est nécessaire d'intégrer les problématiques liées aux décisions / négociations pour la conception intégrée des produits et des services (sur l'ensemble de leurs cycles de vie respectifs) avec celles de les décisions / négociations produit-service. De plus, la relation de service rend la tâche de conception évolutive avec un processus d'apprentissage faisant évoluer les besoins et attentes du bénéficiaire (supposés prédéfinis dans la phase dite « stratégique » ici) qui rend la conception dynamique et requiert une gestion intégrée des modèles proposés du système au sein du processus de conception.  Ensuite, les propositions méthodologiques ont été développées et testées / expérimentées sur un cas d'étude unique (AC) et l'approfondissement des investigations serait intéressant sur d'autres cas. Le cadre d'applicabilité doit encore être défini. De nombreuses questions sur l'implémentation effective du cadre ouvrent la voie à des expérimentations. Notamment, les questions autour de la manière de faire collaborer les différents acteurs de la vue produit et ceux de la vue service pourraient être analysées : quelles sont les phases de conception pouvant être réalisées individuellement / séparément et celles durant lesquelles la communication / les négociations sont indispensables ? Quels résultats de conception obtienton lorsqu'on fait travailler les « vues » séparément et lorsqu'on propose le cadre intégré ?

TABLE OF CONTENTS

 OF Chapter 1. Introduction .......................................................................................................................... 1.1. Research context and goal .......................................................................................................... 1.2. Economic development and environmental pressure ................................................................. 1.2.1. Economic development in the mass production paradigm ................................................. 1.2.2. The necessity of Sustainable Development ........................................................................ 1.2.3. Industrial responsibility ...................................................................................................... 1.2.4. PSS: emergence of a new paradigm ................................................................................... 1.3. PSS: an evolution towards a sustainable society? ...................................................................... 1.3.1. PSS definitions and characteristics ..................................................................................... 1.3.2. Potential of PSS for sustainability ......................................................................................

1.3.2.1. Economic and business benefits .................................................................................. 1.3.2.2. PSS eco-efficiency potential ....................................................................................... 1.3.2.3. PSS social benefits ...................................................................................................... 1.3.3. PSS iconic cases ................................................................................................................. 1.4. Issues of designing sustainable PSS ........................................................................................... 1.4.1. PSS issues of eco-efficiency ............................................................................................... 1.4.2. PSS design issues ................................................................................................................

  ...................................................................................................................................................... 70

Figure 9 Value co-creation among service systems (Vargo, Maglio, and Akaka 2008) ....................... 75 Figure 10 The two distinct service transitions (Kowalkowski 2010) .................................................... 76 Figure 11 Conceptual model of the relationship life cycle role in relationship value creation (Eggert, Ulaga, and Schultz 2006) ...................................................................................................................... 79 Figure

  Figure 31 Schematic representation of the existing design spaces in product and system engineering frameworks (links and iterations omitted) ........................................................................................... 131 Figure 32 Illustration of the differences between Hard and Soft System Methodologies through the design progression within spaces: (a) a simplified illustration of the Hard system view (iterations and validation process omitted); (b) proposed illustration of the Soft System Methodology applied to the service experience ............................................................................................................................... 132 Figure 33 Design spaces in product, system and service engineering frameworks (links and iterations omitted) ............................................................................................................................................... 133 Figure System thinking and the observer-dependency of layers (Checkland 2000) ...................... 133 Figure Problem and solution spaces in the beneficiary and the service design views ................... 134 Figure Issues of building an integrated PSS design framework ..................................................... 135 Figure 37 (a) Reasoning from a device's goal to its structure; (b) Bypassing actions and behaviour in functional basis design reasoning about devices (Vermaas 2013) ...................................................... 136 Figure The spatial perspective used in functional models .............................................................. 137 Figure The temporal perspective used in process models .............................................................. 137

) ............................................ 126 Figure 30 Main research outcomes...................................................................................................... 127 Figure Proposal of a system concept: the entity-relation model linking system to action ............. 139 Figure 41 Differences between product engineering and service design views regarding the proposed system concept .................................................................................................................................... 140 Figure Proposal of a PSS integrated design framework ................................................................. 142 Figure Situational elements for defining external scenarios .......................................................... 143 Figure Proposed "multi-views" modelling framework for PSS integrated design ......................... 147 Figure 45 Models for the product view:

  Figure 66 Framework proposed for integrated PSS eco-design .......................................................... Figure 67 Framework for PSS Life Cycle integrated Design .............................................................. Figure 68 Framework for PSS environmental evaluation during design ............................................ Figure 69 AC's illustrations of some PSS components (a) compressed air plant equipment; (b) maintenance operation; (c) remote monitoring operation ................................................................... Figure 70 Initial Flow model (PSS structure of the Service view): actors' roles in the PSS .............. Figure 71 PSS outcomes identified ..................................................................................................... Figure 72 PSS Result model of the service view: Process model ....................................................... Figure 73 PSS initial Structure model of the service view: Service System Navigation (SSN) model ............................................................................................................................................................. Figure 74 PSS Result model of the product view: Graphs of interactors (a) in the E0 scenario; (b) in the E1 scenario .................................................................................................................................... Figure 75 Representation of PSS functions as system interactions ..................................................... Figure 76 PSS Result model of the integrated view: A0 diagram .......................................................

.............. 168 Figure Proposal of a PSS environmental costs analysis approach ................................................. 169 Figure Proposal for adapting VA to the PSS evaluation: replacing the hierarchical layers ........... 174 Figure Proposed PSS environmental evaluation framework .......................................................... 177 Figure 77 PSS Result decomposition of the product view: FAST (partial) ........................................ Figure 78 PSS Structure model of the product view: Block Diagram (partial) ................................... Figure 79 PSS Result decomposition of the service view: Process decomposition (partial) .............. Figure 80 Structure model of the PSS from the service perspective: SSN (partial) ............................ Figure 81 PSS result decomposition of the integrated view: IDEF0 diagrams configurations ........... Figure 82 PSS structural organization model of the product view: Functional Block Diagram (FBD) ............................................................................................................................................................. Figure 83 PSS structural organization model of the service view: Blueprint-Based Model (BBM) ... Figure 84 Result model of the head compressor: Graphs of interactors (a) in the E0-I0 scenario; (b) in the E0-I1 scenario ................................................................................................................................ Figure 85 Result model decomposing the technical Unit actions in the PSS process ......................... Figure 86 PSS Result model of the integrated view (partial) after decomposition: (a) repair activity diagram; (b) dismantling activity diagram .......................................................................................... Figure 87 Products taken into account for evaluation ......................................................................... Figure 88 Compressors' use scenarios ................................................................................................. Figure 89 Compressors' end-of-use scenarios ..................................................................................... Figure 90 Colour code used in the Costs Analysis Tables .................................................................. Figure 91 Comparison of the environmental impacts (costs) of the two scenarios ............................. Figure 92 Relative satisfaction levels of outcomes in the two scenarios ............................................ Figure 93 Relative costs of outcomes between the two scenarios ....................................................... Figure 94 Thesis contribution: A framework for integrated PSS eco-design ...................................... Figure 95 Detail of the thesis contributions to integrated PSS eco-design .........................................

Table 1

 1 Some PSS definitions in the literature ...................................................................................... Table2G-D logic vs. S-D logic on value creation[START_REF] Vargo | On Value and Value Co-Creation: A Service Systems and Service Logic Perspective[END_REF] ........................ Table3Two types of integration of the environmental dimension in PSS: service-vs. product-oriented approaches ........................................................................................................................................... Table 4 Contributions of the literature review and of the industrial collaboration to RQs identification and solving .......................................................................................................................................... Table 5 Information collected and types of source for the research areas of concern ......................... Table 6 Existing PSS modelling methodologies ................................................................................. Table7The classical solution choice table[START_REF] Yannou | Proposition de Deux Nouveaux Outils D'aide à La Décision En Analyse de La Valeur Basés Sur Une Définition Opérationnelle de La Valeur[END_REF] ................................................................ Table 8 An example of a Service Unit Resource Matrix (RM) ........................................................... Table 9 Example of Resources Costs (RC) distribution ...................................................................... Table 10 PSS Design Matrix ............................................................................................................... Table 34 Affectation of solution costs to the outcomes (alternative scenario) .................................... Table 35 Importance levels and relative importance defined for each outcome ................................. Table 36 Solution choice table regarding ozone layer depletion ......................................................... Table 37 Solution choice table regarding aquatic acidification...........................................................

	LIST OF ACRONYMS
	AC	Ets André Cros (industrial case)
	ACA	Allocated Action Cost
	DAC	Direct Action Cost
	BD	Block Diagram (model)
	BBM	Blueprint-Based Model
	DfE	Design for Environment
	DfX	Design for X
	DM	Design Matrix
	EI	Environmental Impacts
	FAST	Functional Analysis System Technique (model)
	FBD	Functional Block Diagram (model)
	FU	Functional Unit
	G-DL	Good-Dominant Logic
	LCA	Life Cycle Assessment
	LCI	Life Cycle Inventory
	PM	Problem Matrix
	PSS	Product-Service System(s)

Table 11 Distribution of the relative importance of aptitudes solicitations in the DM ....................... Table 12 Example of aptitudes solicitations distribution .................................................................... Table 13 Costs Analysis Table for PSS ............................................................................................... Table 14 PSS Problem Matrix ............................................................................................................. Table 15 Solution choice table for PSS (adapted from Yannou 1999)................................................ Table 16 (Some) contractual criteria defining the PSS technical performance ................................... Table 17 Design Matrix built after PSS design modelling (partial) .................................................... Table 18 PSS Design Matrix: Solicitations of PSS components' aptitudes in PSS process ................ Table 19 PSS Design Matrix: Solicitations of PSS components' aptitudes in PSS process (suite) ..... Table 20 PSS Problem Matrix: Reciprocal influences between PSS actions and expected outcomes Table 21 The PSS life cycle ................................................................................................................ Table 22 Types and sources of the data collected for environmental evaluation ................................ Table 23 Aptitudes importance and distribution in PSS process ......................................................... Table 24 Aptitudes importance and distribution in PSS process (suite) ............................................. Table 25 Cost analysis Table (Ozone layer depletion) ........................................................................ Table 26 Cost analysis Table (Mineral extraction) ............................................................................. Table 27 Cost analysis Table (Aquatic acidification) ......................................................................... Table 28 Assumptions made for the alternative scenario .................................................................... Table 29 Aptitudes importance and distribution in the alternative scenario ....................................... Table 30 Aptitudes importance and distribution in the alternative scenario (suite) ............................ Table 31 Change of the design parameters' values in the alternative scenario ................................... Table 32 Outcomes selected and their satisfaction levels (1-10) according to the scenario ............... Table 33 Affectation of solution costs to the outcomes (existing case) .............................................. Table 38 Solution choice table regarding mineral extraction ..............................................................

mainly in service content Product-service system

		Service content
		(intangible)
		Product content
		(tangible)
	Pure	A	Pure
	product		service

: Product oriented B: Use oriented C: Result oriented

	1. Product	3. Product	6. Activity
	related	lease	management
	2. Advice and	4. Product	7. Pay per
	consultancy	renting/	service unit
		sharing	8. Functional
		5. Product	result
		pooling

new meaning of "design" in the PSS context is

	The following areas are considered:
	o Integrated product design
	o Product eco-design and environmental evaluation
	 Service design and development: is historically more developed in business, managerial and
	marketing disciplines, but recent developments emerge to adapt engineering background to
	service design in Service Engineering. The following areas are considered:
	o Service design, development and management in the business / marketing literature
	o Service Engineering
	Since PSS are "systems", products and services should be considered with this angle of view.
	 System approaches have been explored in the following scope of interest:
	o System engineering
	o System thinking and the related methodologies
	o System approaches adapted to service design
	PSS put a strong emphasis on the needs' fulfilment. In PSS, the "product user" becomes a "service
	beneficiary" through the service relationship.
	 A specific focus on the proposed, integrating
	the aspects of:
	o User-centred product design vs. service design
	o Design stakeholders' co-operation vs actors' co-creation.
	1.6. Thesis structure
	This thesis is organized as follows.
	This Chapter aimed at introducing the research context and the initial Research Question.

SYSTEM ENGINEERING SERVICE DESIGN PRODUCT ENGINEERING LIFE CYCLE

  Product engineering has evolved over the years attempting to integrate the different stakeholders' expectations and constraints about the design object as soon as possible in the development process.

	PRODUCT ECO-DESIGN	LCA	EVALUATION ENVIRONMENTAL
		STAKEHOLDERS
		INTEGRATION
				ENVIRONMENTAL
		INTEGRATED PRODUCT DESIGN	EXPERTISE INTEGRATION
	SYSTEM ENGINEERING DESIGN	PSS design &	SERVICE ENGINEERING
		eco-
		design
	socio-technical	service system concepts		BUSINESS / MARKETING
	systems design			SERVICE
			DOMINANT
		SYSTEM		LOGIC
	METHODOLOGIES
		Hard vs. Soft
	2.1. Product engineering literature
	2.1.1. Product design
	2.1.1.1. Product engineering design: evolution towards integration
	2.1.1.1.a. Evolution of engineering models until modern approaches

Table 2 G

 2

-D logic vs. S-D logic on value creation

  2.4.2. Integrated PSS design and development 2.4.2.1. Issues of Integrated PSS development The issues of PSS development are closely linked to those previously discussed in each field of product engineering and service design.

  Sustainable Products and Services Development[START_REF] Maxwell | Developing Sustainable Products and Services[END_REF] and[START_REF] Maxwell | Functional and Systems Aspects of the Sustainable Product and Service Development Approach for Industry[END_REF] proposed a method for Sustainable Products and Services Development (SPSD) that attempts to integrate all the aspects of the Triple Bottom Line (TBL) for achieving sustainability (environmental and social impacts), with a special emphasis on the functionality concept as a TBL concept. The method enables to identify, assess and implement the options for optimum sustainability of the resulting offer. A checklist that helps navigate the TBL issues to be considered in the development of a sustainable product and/or service is also proposed[START_REF] Maxwell | Developing Sustainable Products and Services[END_REF]. The SPSD is composed of several stages: Concept Development; Detailed Design; Testing/Prototype; Offering Launch and Marketing; Offering Review[START_REF] Maxwell | Functional and Systems Aspects of the Sustainable Product and Service Development Approach for Industry[END_REF].

oriented approach For strategic design Product-oriented approach For environmental evaluation

  and detailed in this section.

	Entry point			Service relationship	Products' use
					Customer's needs	Product function
					Value creation	Products environmental impacts
	Evolution of the consumption-	New Services' roles	New Products' roles
	production pattern			Dematerialization	Products use / functions
	Preferred view			Service economy	Functional economy
	PSS	potential	for	eco-	Innovation potential	Strategies for products' life cycle
	efficiency				interventions
	Design orientation			Strategy / business models	Design -evaluation coupling
					Actors' networks and relationships
	Type of design supports		"Innovation" tools	Not well dealt
					Toolboxes
	Products and services		Products selected for supporting services	Services added for optimizing products'
						life cycles
	Missing elements			Integration of product design	Service life cycle
	Environmental	dimension	Guidelines	Quantitative
	integration			Qualitative during design	-	A posteriori of design
						-	Link with design surfaced

Service-

Table 3

 3 Two types of integration of the environmental dimension in PSS: service-vs. product-oriented approaches

Table 5

 5 Information collected and types of source for the research areas of concern

  To facilitate P-S integration, a coupling of designers' dedicated tools should be of interest.o Some of them are more related to product design in PSS and propose models from the Product Engineering (PE) field. Their intended use is for product engineers o Some of them are more related to service design and developed in the Service Engineering (SE) field. Their intended use if for service designers. o One of the proposals is a hybrid approach reusing knowledge from SE and System engineering (Sys. E). Models can also fit in the expectations of software engineers.

	Authors	Scope of the	Models	Models	Models	Privileged users
		design support	integrated in a	represent	interactions	of models
			design	products and	detailed
			methodology	services
	Alonso-	Design of 'total	YES	A priori but	NO	Product
	Rasgado et al.	care products' in		no detail		engineers
	2004 / 2006	PSS
		PE (PSS)
	Morelli	PSS design	YES	A priori	models	P/S designers
	2003 / 2006	PE (PSS)		+ details on	interactions not	A priori
				given steps	especially
					highlighted
	Maussang et	PSS architecture	YES	YES	YES	Product
	al. 2009	and product				engineers
		component design
		PE (PSS)
	Bullinger et al.	Service design	YES	NO	NO	Service
	2003	(SE)				designers
	Luczak et al.
	2007
	Hara et al.	Service and	YES	YES	YES	Service
	2009	product design				designers
		For CAD
		(SE)
	Patrìcio et al.	Multilevel service	YES	YES	YES	Service /
	2008 / 2011	design				software
		(SE / Sys. E)				designers

Table 6

 6 Existing PSS modelling methodologies

  Wider system study: beneficiary, actors, needs, processes  Needs analysis, benefits definition: requirements and PSS outcomes  Initial PSS structure model (Flow model): Initial PSS concept Proposal of PSS environmental evaluation during design This section details the proposal made for PSS environmental evaluation during design. Section 4.2.1 analyses the issues of PSS environmental evaluation during design that have been previously discussed in the literature review and in the resulting challenges identified. The light provided by the industrial case is initially detailed (section 4.2.1.1) to illustrate these issues.

	GOALS: PSS OUTCOMES 4.2. Value DECISION -MAKING
	Analysis (VA) approach would be supportive for performing evaluations during design and is detailed
	Initiates Section 4.2.2 details the different proposals made for supporting PSS environmental evaluation during Possible adjustments during in section 4.2.1.2. design
	Result-structure formulation (initial: PSS concept) Section 4.2.3 finally proposes a methodological framework for PSS environmental evaluation design.
	integrating these proposals. PSS MODELLING 4.2.1. Analysis of the issues of PSS environmental evaluation during design Iterations (lower system level)
	Models of Result 2. Integrated view 1. Product / Service views 4.2.1.1. Light provided by the industrial collaboration on the issues systems models  "Principles" of sub-structure Models of Structure  External entities 1. Result-
	2. Decomp. Design relation	Result decomposition	Structure decomposition and affectation
	3. Negotiation	Structural organization models
	models	(product and service views)
	DECISION
	NODE	Sub-systems' specifications
		 Refined Result-Structure formulation

Table 8

 8 An example of a Service Unit Resource Matrix (RM)

Table 9

 9 Example of Resources Costs (RC) distribution

Table 12

 12 Example of aptitudes solicitations distribution

  Table 13 corresponds to the resulting Costs Analysis Table proposed for performing a cost analysis of the PSS. It summarizes the steps of costs affectations proposed, using the same colour code than in Figure 63.

						PSS ACTIONS
					A1	A2	A3
	LC actions	Aptit.	Aptit.	RC i	RC	RC	RC
	cost		Importance
	Product	Apt. 1	50%	15	12	3
	30
		Apt. 2	50%	15		15
	S. Unit	Apt. 1	20%	16	4	12
	80	Apt. 2	40%	32	32
		Apt. 3	40%	32			32
			RC =∑ RC i		48	30	32
	TOTAL		DAC		60	100	30
			ACA = RC + DAC		108	130	62

Table 13

 13

Costs Analysis Table for PSS

Table 14

 14 The resulting solution choice table (adapted from Yannou 1999) is used for selecting a PSS design alternative as shown in Table15. Solutions having the higher score are those that have the higher "value": they provide maximum benefits for minimum costs. The Table also allows analysing the respective values of each outcome. Their increase or decrease between different solutions could support the re-design process.

	PSS Problem Matrix

Table 15

 15 Solution choice table for PSS (adapted from[START_REF] Yannou | Proposition de Deux Nouveaux Outils D'aide à La Décision En Analyse de La Valeur Basés Sur Une Définition Opérationnelle de La Valeur[END_REF]

Table 23

 23

	Aptitudes importance and distribution in PSS process

Table 24

 24 Aptitudes importance and distribution in PSS process (suite)5.4.3.2. Costs Analysis TablesAfter negotiating the weighting coefficients affected to the aptitudes and their distribution, the Resource Costs (RC) and Direct Action Costs (DAC) are calculated for each type of cost, i.e. the three environmental impacts indicators chosen. The RC, DAC, and their sum into Allocated Costs of Actions (ACA) calculated for the three types of costs, i.e. the ozone layer depletion, the mineral extraction, and the mineral extraction are detailed in the Costs analysis Tables

Table 25

 25 Cost analysis Table (Ozone layer depletion)

				Mineral	Pneum. energy		Monitoring		Control
				extraction	supply
				(MJ Surplus)	Energy supply/recov.	Reserve supply	Data supervision	Monthly reporting (customer)	Failure detection diagnosis	Preparation maintenance operations	Maintenance operations	Repair operations (compressors)	Overhaul operation (VSD)
				DAC	2,52E+04	0	3,70E+00	1,28E+00	0	0	1,58E+03	5,47E+00	3,91E+01
				RC	1,71E+04	2,14E+03 7,63E+02	2,16E+02	2,08E+03 4,19E+02	3,48E+03	9,39E+02	2,38E+03
				ACA	4,23E+04	2,14E+03 7,66E+02	2,18E+02	2,08E+03 4,19E+02	5,06E+03	9,44E+02	2,42E+03
				ACA % TOT	75,10%	3,79%	1,36%	0,39%	3,68%	0,74%	8,98%	1,68%	4,29%
				DAC (% action)	71,15%	0%	0,49%	0,59%	0%	0%	31,23%	0,58%	1,62%
				RC (% action)	28,85%	100%	99,51%	99,41%	100%	100%	68,77%	99,42%	98,38%
	Comp.	Sub-	Aptitude	Aptitude
		comp.		importance

Table 26

 26 Cost analysis Table (Mineral extraction)

				Aquatic	Pneum. energy		Monitoring		Control
				acidif	supply
				(Kg SO2eq)	Energy supply/recov.	Reserve supply	Data supervision	Monthly reporting (customer)	Failure detection diagnosis	Preparation maintenance operations	Maintenance operations	Repair operations (compressors)	Overhaul operation (VSD)
				DAC	2,75E+03	0	1,06E-01	6,85E-02	0	0	9,50E+01	5,12E-01	2,34E+00
				RC	7,34E+01	1,26E+01 3,89E+00	1,81E+00	1,07E+01	2,49E+00	3,45E+01	8,52E+00	1,38E+01
				ACA	2,82E+03	1,26E+01 4E+00	1,88E+00	1,07E+01	2,49E+00	1,29E+02	9,03E+00	16,0988
				ACA %TOT	93,80%	0,42%	0,13%	0,06%	0,36%	0,08%	4,31%	0,30%	0,54%
				DAC (%	98,20%	0%	2,65%	3,64%	0%	0%	73,38%	5,67%	14,54%
				action)
				RC (% action)	1,80%	100%	97,35%	96,36%	100%	100%	26,62%	94,33%	85,46%
	Comp.	Sub-	Aptitude	Aptitude
		comp.		importance

Table 27

 27 Cost analysisTable (Aquatic acidification) 5.4.3.3. Using the costs analysis to negotiate PSS design

  Table 29 Aptitudes importance and distribution in the alternative scenario

	Comp.	Sub-comp. Aptitudes	Aptitude	Pneum. energy		Monitoring	Control
						importance	supply
							Energy	Reserve	Data	Reporting	Failure	Preparation	Maintenance	Repair	Overhaul
							supply/rec	supply	supervision	(customer)	det./diag.	of maint.	operations	operations	operation
	Other plant			Air cleaning /	93%	100%	0%
	equipment			delivery /…
				Ease	of	7%				100%
				maintenance
	F.O. Unit	Spare	parts	-		100%				100%
		(maintenance)
		Spare	parts	-		100%				100%
		(repair)
		Spare	parts	-		100%				100%
		(overhaul)
		Technical Unit	Dismantling	60%				30%	30%	40%
				expertise
				Maintenance	30%				100%
				expertise
				Repair expertise	10%				40%	60%
	R.M. Unit	RM equip.	Collect store /	40%			70%	20%	10%
				analyse data
				Detect failures	30%				100%
				Remote control	30%				100%
		Supervision	Data	analysis	25%			40%	20%	40%
		Unit		expertise
				Diagnosis	25%				100%
				expertise
				Communication	10%				50%	30%	20%
				skills
				Maintenance	40%				100%
				expertise

  Table 30 Aptitudes importance and distribution in the alternative scenario (suite)

Table 32

 32 Outcomes selected and their satisfaction levels (1-10) according to the scenario

	120%
	100%	100%	86,18%	100%	91,14%	100%	99,71%
	80%
	60%						Sc0
	40%						Relative cost of Sc1
							(% Sc0)
	20%
	0%
		Ozone layer	Aquatic	Mineral
				acidification	extraction

Table 33

 33 Affectation of solution costs to the outcomes (existing case)

				Actions PSS process	Technical performance		Service quality	Relation. quality
					Air quality	Energy effic.	Availab.	Reactivity	Flexibility	info	Technical	Dialogue
	supply.	Energy	Pneum.	Energy supply/ recov. Reserve supply	30%	30%	40% 100%
				Data supervision	20%	20%	35%	10%	15%
		Monitoring		Monthly reporting Failure detect./diag.				100%	100%
				Prepare maintenance			100%
				Maint. operations	20%	20%	50%		10%
		Control		Repair operations			80%	20%
				Overhaul operation	20%	20%	50%		10%

Table 34

 34 Affectation of solution costs to the outcomes (alternative scenario) 241

Table 35

 35 Importance levels and relative importance defined for each outcome

  Based on the outcomes importance, their satisfaction levels, and their affected costs, three Solution choice Tables can be built for each type of cost: Table36regarding ozone layer depletion;  Table 37 regarding aquatic acidification;  Table 38 regarding mineral extraction. Solution choice table allow defining the values of the outcomes (regarding a specific PSS scenario) 𝑉 𝑖𝑗 . The solution choice is made by a sum of these values weighted by the importance of the outcomes.

	5.4.5.6. Solution Choice Tables
	200,00%
	180,00%
	160,00%
	140,00%
	120,00%
	80,00% 100,00%	Sc0 costs
	60,00%	Ozone layer depletion
	20,00% 40,00%	Aquatic acidificiation
	0,00%	Mineral extraction
		242

Table 36

 36 Solution choice table regarding ozone layer depletion 𝑉 𝑖𝑗 = 𝐼 𝑖 * 𝑆 𝑖𝑗 𝐶 𝑖𝑗 ⁄

					PSS Sc0			PSS Sc1
		𝐼 𝑖	𝑆 𝑖𝑗	𝐶 𝑖𝑗	𝑉 𝑖𝑗 = 𝐼 𝑖 * 𝑆 𝑖𝑗 𝐶 𝑖𝑗 ⁄	𝑆 𝑖𝑗	𝐶 𝑖𝑗
				(Kg	SO2			(Kg SO2 eq)
				eq)
	Air quality	20,45%	90%	1,03E+03	1,78E-02	90%	8,03E+02	2,29E-02
	Energy efficiency 20,45%	85%	1,03E+03	1,69E-02	90%	8,03E+02	2,29E-02
	Availability	20,45%	90%	9,23E+02	1,99E-02	90%	1,11E+03	1,65E-02
	Reactivity	15,91%	80%	1,60E+01	7,95E-01	40%	9,91E+00	6,42E-01
	Flexibility	6,82%	70%	1,61E+00	2,96E+00	75%	2,68E+00	1,91E+00
	Technical info	6,82%	70%	2,68E+00	1,78E+00	80%	3,03E+00	1,80E+00
	Dialogue	9,09%	60%	1,29E+01	4,23E-01	30%	2,79E+00	9,78E-01
			Score (Sol 1) = ∑ 𝑰 𝒊 * 𝑽 𝒊𝒋 𝒊	= 5,00E-01	Score (Sol 2) = ∑ 𝑰 𝒊 * 𝑽 𝒊𝒋 𝒊	= 4,57E-01

  Table 37 Solution choice table regarding aquatic acidification 𝑉 𝑖𝑗 = 𝐼 𝑖 * 𝑆 𝑖𝑗 𝐶 𝑖𝑗 ⁄

				PSS Sc0			PSS Sc1
		𝐼 𝑖	𝑆 𝑖𝑗	𝐶 𝑖𝑗	𝑉 𝑖𝑗 = 𝐼 𝑖 * 𝑆 𝑖𝑗 𝐶 𝑖𝑗 ⁄	𝑆 𝑖𝑗	𝐶 𝑖𝑗
				(MJ				(MJ surplus)
				surplus)
	Air quality	20,45%	90%	1,72E+04	1,07E-03	90%	1,42E+04 1,29E-03
	Energy efficiency 20,45%	85%	1,72E+04	1,01E-03	90%	1,42E+04 1,29E-03
	Availability	20,45%	90%	1,86E+04	9,88E-04	90%	2,48E+04 7,43E-04
	Reactivity	15,91%	80%	2,71E+03	4,70E-03	40%	1,68E+03 3,79E-03
	Flexibility	6,82%	70%	2,42E+02	1,97E-02	75%	4,51E+02 1,13E-02
	Technical info	6,82%	70%	3,71E+02	1,29E-02	80%	5,92E+02 9,22E-03
	Dialogue	9,09%	60%	5,06E+02	1,08E-02	30%	1,93E+02 1,41E-02
			Score (Sol 1) = ∑ 𝑰 𝒊 * 𝑽 𝒊𝒋 𝒊	= 4,58E-03	Score (Sol 2) = ∑ 𝑰 𝒊 * 𝑽 𝒊𝒋 𝒊	= 3,97E-03

Table 38

 38 Solution choice table regarding mineral extraction 5.4.5.7. Results discussion

The term service is used in this section (and in this thesis) in its broad sense to distinguish it from physical product since there are still many differences between product and service provision. Service does not refer to the S-DL concept but to the provision of something which is not manufactured and sold.

The example provided implicitly suggests that the frequencies of occurrence of actions are unitary in the PSS process.

The "interpretation" phase of LCA that occurs during the entire evaluation process is not represented here but must be integrated.

All the interactions and functional flows are not detailed on the Figure to avoid overloading, for example the physical contact with the premises.

These interactions should be shown in the FBD, but they are not all represented in Figure82to avoid overloading.

AF1, AF2 and AF3 correspond to actions of external entities influencing (controlling) those of the system as shown in the IDEF0 model (Figure

76): the resulting expected system properties are affected to the compressor here, and their solicitations distributed in the PSS actions.

Availability

100% …

 the "value" creation for the beneficiary captured by a service expert; and  the "value" removal for natural ecosystems that is analysed by an environmental expert. These values are captured by expert teams or individuals (service or environmental experts) playing the role of dissemination of the experience or environmental value throughout the design process. The system under study, i.e. the PSS, is the "media for value creation" and then should integrate a transversal view of these values. The value creation is here restricted to its management by the environmental evaluation process. The other issues related to the support for value co-creation are out of the research scope.

Refined research questions

Since the initial Research Question (RQ0) has been explored, the challenges of integrated PSS ecodesign have been identified. The goal and scope of the research regarding these challenges have been defined in the previous section. This allows refining the initial RQ0 into the following Research Questions (RQ): RQ1. How to support product-service integrated design and modelling?  RQ1.1. How to define a system framework to integrate products and services during PSS design?  RQ1.2. How to support the progression of the design task through an integrated modelling support? RQ2. How to support PSS eco-design design through environmental evaluation?

 RQ2.1. How to support PSS environmental evaluation during design?  RQ2.2. How to define and model a PSS life cycle? The research process followed to answer these research questions and the main outcomes of this thesis are detailed in the next part. 3.3. Research process and main outcomes 3.3.1. Research process The research process consisted in two inter-related processes led in parallel:

 Literature review  Industrial collaboration The continuous exploration of the literature and the collaboration process with an industrial company were mutually fed and enriched through the resulting progressive learning process that is illustrated in Figure 26. They both provided some issues (theoretical issues or industrial issues) and some elements for solving them and for developing a design support. The support was systematically confronted to the existing literature and to industrial case or tested / applied on the industrial case. This confrontation / application resulted in new questions or issues to deepen and to solve. The proposals made in this thesis then result from this progressive learning process involving both the literature review and the industrial collaboration. The main research questions have been introduced in this chapter. They have been identified through the literature review (0) but also through the industrial collaboration. The materials provided either by industrial collaboration or by the literature for identifying the RQs and progress towards their solving (through continuous learning) are schematically summarized in Table 4.

Literature review

Industrial collaboration RQ1. How to support product-service integrated design and modelling RQ1.1. How to define a system framework to integrate products and services during PSS design? X RQ1.2. How to support the progression of the design task through an integrated modelling support? X RQ2. How to support PSS eco-design design through environmental evaluation?

RQ2.1. How to support PSS environmental evaluation during design? (X) X RQ2.2. How to define and model a PSS life cycle? (X) X Table 4 Contributions of the literature review and of the industrial collaboration to RQs identification and solving

From a simplified viewpoint, the literature exploration and analysis has mainly supported the identification and solving of RQ1 for conceptualizing a PSS as a system and supporting its modelling during design; and the industrial collaboration has mainly helped to perceive and experience the difficulties of modelling a PSS life cycle and to better understand the expectations of the industrial actors regarding the environmental evaluation during design.

Using the Costs Analysis during PSS design

The proposed PSS life cycle definition and its related "costs" (EI) analysis both emphasize the integration dimension by showing how resources must be integrated for the solution provision.

The allocation method proposed is based on the sub-systems' aptitudes for interacting. This perspective emphasizes the way the sub-systems are integrated within the PSS. The costs (or EI) analysis allows making the necessary links between the solution being designed through productservice integration and the environmental evaluation of this solution.

The Costs Analysis Table can be used during PSS design to identify the environmental "hot spots" of the system. It facilitates the identification of (re-)design priorities since the Major contributions in the solutions can be identified in the actions of the PSS process. These actions correspond to the expectations (result) being decomposed (and affected to the decomposed structure).

Major contributions are meaningful for designers when related to the PSS actions since their refinement can be questioned.

The actions can also be analysed by identifying major contributions related to:  The DAC: in this case, the organization of the PSS actions can be questioned.  The RC: in this case, the sub-systems and their properties can be questioned. The design progression allows refining the DM and the costs analysis during design.

Pre-requisite

Since the LC actions costs are affected to PSS actions, the "hot spots" of the sub-systems' life cycles cannot be identified in the proposed costs analysis. The link between PSS design decisions to specify the sub-systems and those on their other LC actions should be efficiently managed during and integrated design process. These internal challenges of integration are not dealt in this thesis, but are crucial issues for efficient PSS eco-design. The integration of all the views of the concerned actors (for each sub-system life cycle) should be made through a transversal view providing the environmental expertise. The evaluation tool proposed here (for costs analysis) aims at supporting design decisions made for the structural organization of the system: its role is to support the product-service integration during PSS eco-design.

4.2.2.3.b. Proposal of a PSS environmental evaluation framework based on VA

Generic framework

The proposed evaluation framework for PSS environmental evaluation is based on VA by replacing its product-oriented hierarchical layers by the ones proposed for the environmental view. The environmental view considers means for needs fulfilment as PSS outcomes, instead of functions. The VA-based environmental evaluation is illustrated in Figure 64. VA logic is displayed in the left side while the proposed adaptation for PSS environmental evaluation is shown on the right side. Instead of using the importance, satisfaction, and cost attributes for characterizing product functions (in VA), these attributes are now used for characterizing the PSS outcomes. The resulting evaluation logic proposed shown on the right side of Figure 64. An energy recovery system is installed for heating other customer's premises.

Remote monitoring equipment includes:

 Equipment directly included within compressors that are also used for regulation;  Equipment on the plant installation: temperature and pressure sensors, air flow meters, selfregulation equipment, external weather stations etc. Some of the PSS components are represented on Figure 69. A compressed air plant (picture (a) on Figure 69) is associated with technical services like maintenance, repair and overhaul operations (illustrated by picture (b) on Figure 69). The remote monitoring system supports a continuous supervision of the plant functioning supported by a software application (picture (c) on Figure 69). AC is committed to supply compressed air with a guarantee of availability in defined ranges of air flow, air quality, energy ratio (electrical energy consumed by unit of air volume produced). The PSS technical performance is declined in several criteria having a defined quantitative level and a possible flexibility, as illustrated in Table 16. AC provides to the customer a monthly report based on the measurements of the remote monitoring equipment that proves the contract compliance. It also informs the customer about the services provided, e.g. the maintenance operations planning, etc. In return, the customer is responsible for maintaining his consumption characteristics in the ranges contractually defined. In case of production changes (rhythms, addition of machines, etc.), the customer must inform AC that can adapt his offer consequently. The value creation occurs in the customer's (or beneficiary's) own "sphere" (Grönroos 2011). Several stakeholders can be involved in the beneficiary's processes for fulfilling a specific need.

During the conceptual design phase, the system to design (PSS) is analysed within its wider system, i.e. within the beneficiary's system encompassing multiple inter-related systems that can be managed by different actors.

In order to illustrate the different actors' roles considered in this chapter, the initial Flow model of the PSS structure is shown in Figure 70 (the different actors involved in the PSS have been restricted and their roles simplified for this study). The initial structure model can be seen as the organization of the stakeholders' interactions for fulfilling the beneficiary's needs. In the case studied, five main actors have been defined for fulfilling the beneficiary's needs (Figure 70): the beneficiary (AC customer), the PSS provider (AC), the OEM, the electrical energy provider, and a sub-contractor responsible for the maintenance of the piping network of the customer.

Beneficiary (AC customer)

PSS Provider (AC)

Electrical energy provider

5.2.1.3.c. Design relation expression in product and service views

In the product view, the design relations are shown in the model used for result decomposition: the FAST traces the links between the technical functions and the sub-systems identified. In the service view, the design relations are expressed in the model used for decomposing the structure: the SSN shows the affectation of the sub-systems' roles in the actions. In all cases, the technical functions and the sub-systems' roles must correspond to an equivalent set of actions that should be affected to an equivalent set of sub-systems. The two views can be used separately by designers in a co-evolutionary decomposition of the result-structure, but an agreed view of the identified sub-systems and decomposed results must be defined. The result decomposition in the integrated view supports a description that fits in the product and in the service views and should facilitate the designers' communication in this way.

5.2.1.3.d. Integrated view for result decomposition

The proposed decomposition through the IDEF0 model is shown in Figure 81: the two activities A5 and A6 identified in the A0 model (Figure 76) are decomposed into lower diagrams. In this should be the main issue of product engineers while the duration of operations and their frequency can be the focus of service designers. They visibility lines of the BBM express the beneficiary's viewpoint. These lines typically correspond to an emerging characteristic of the structural choices that can influence the result. The sub-systems organization must be discussed through the negotiation occurring in the structural organization space.

Here, the influence of visible repair operations on the beneficiary's satisfaction can also require discussing the acceptable failure frequency for the compressor and the reactiveness of the technical service unit. These aspects can be shared and discussed by coupling the two perspectives proposed in the structure organization models.

PSS integrated detailed design

The proposed modelling framework supports the PSS design until the most detailed phases. Indeed, the proposed models allow iteration at the sub-system scale that supports the progression of the specific designers' tasks while the models coupling in the proposed framework supports the integration of these tasks.

5.2.2.1. Sub-systems' design and modelling iterations

5.2.2.1.a. Technical design of products

The models proposed in the product view support the refinement of the detailed product specifications as already shown by [START_REF] Maussang | Product-Service System Design Methodology: From the PSS Architecture Design to the Products Specifications[END_REF]: the Graph of interactors can be used to iterate the modelling on physical products.

Modelling the Graph(s) of interactors of products is facilitated by the FBD and the BBM models depicting structural organization.

In Figure 84, two Graphs of interactors of the head compressors are shown. By using the BBM, two different scenarios in which this compressor interacts are identified: E0-I0 and E0-I1 (here). It is necessary to model two Graphs shown on pictures (a) and (b). The colour code used is adapted: in the E0-I0 scenario, the compressor supplies energy and is represented in yellow (picture a); in the E0-I1 scenario, it is failed and being repaired and is represented in green (picture b). Due to the different compressor's interactions in these scenarios, the "external entities" (from a compressor viewpoint) are different in the two Graphs.

The functional links expressed are easy to identify by using the FBD. Here, the Adaptation Functions identified at the system level are still expressed here 5 : AF1, AF2 and AF3 that exist in the two scenarios. It should be noticed that AF1 (ensure safety) defined for customer's technical units must be maintained for the PSS technical Unit.

To simplify, the IF1 function is unchanged because the detail of plant products is not provided (but the functional flow should link the compressor to the filters instead of to the customers' piping).

In the E0-I0 scenario, the compressor has two additional Adaptation Functions:  AF4: To allow data transmission to the RMS  AF5: To share an integrated control and regulation with the reserve compressor. AF4 supports the link between the "pneumatic energy supply" and the "monitoring" actions. AF5 has not been previously detailed on the FBD (except by a physical contact) but corresponds to the required mechanisms for regulation and switch between compressors in case of failure. In the E0-I1 scenario, the compressor is failed and IF1 is not provided. Instead, the compressor interacts with the FO unit. AF4 should still exist to allow failure detection by the software. AF5' corresponds to the automated switch on the reserve compressor. When interacting with the FO Unit, FA6 can be expressed as:

 AF6: To be easily repaired by the FO Unit.

Another example is provided in the BBM and could be further detailed: the remote (pre-) diagnosis of the supervision Unit is supported by the software interface. Detailing the required actions for diagnosis could support refining the software technical specifications as well as the expertise required for the Unit.

Refinements of Units' aptitudes can be affected to existing human resources or created by training sessions.

Figure 85 Result model decomposing the technical Unit actions in the PSS process

The modelling framework supports detaining the design of service unit components (concurrently with product ones) by using specific tools of service design. The result-structure decomposition and structural organization models can be used in the service view for refining the properties of service Units and organizing the service delivery process. The all set of processes, roles and expected skills of the Units can be detailed and the models refined until the identification of the elementary human resources.

Integration during technical design

Each view can be focused on by product engineers and service designers for technical refinements of their specific sub-systems. However, their coupling in the proposed modelling framework supports the views integration by using systematic representation of the entire system. Then, when detailing the compressor's functions in Graphs of interactors and the service units' actions in the process model, each view refers to the other one. Models should be mutually enriched when used concurrently and support integration of the sub-systems' specifications until the most detailed design phases. Additionally, if sub-systems structure is progressively identified and can be detailed in each view, the requirements can be continuously traced and modelled by the integrated view proposed for result modelling.

5.2.2.2.a. Integration of sub-systems' specifications: negotiation loops

The models used in each view the framework support the progressive detail of the result and structure representations.

Design negotiations can occur (at different levels of detail) for result decomposition and for selecting the sub-systems. Sub-systems and their expected properties should be progressively identified during PSS design. The properties of sub-systems must be defined or chosen according to the interactions it has with other sub-systems. (CMS). The internal CMS is used for the automated regulation of the two compressors (named AF5 in the design section) and for data transmission to the RMS (named AF4 in the design section). The other AFs of the compressors previously mentioned are excluded. The FO Unit is composed of the MRO equipment (spare parts, consumables) and of the Technical Unit. The RM Unit is composed of the RM equipment (RMS, software application) and of the Supervision Unit.

The actions identified during PSS modelling are further detailed here. Those for piping maintenance have been excluded from the environmental evaluation scope and are not represented here. The main actions of the PSS process included are:  The pneumatic energy supply performed by the plant equipment: the head supply in the E0-I0 scenario, and the reserve supply in the E0-I1 scenario.  The plant monitoring operated by the RM Unit. Several sub-actions exist in different scenarios configurations. The data supervision is performed daily, and a customer reporting is performed monthly. They both exist in the E0-I0 scenario. The failure detection and diagnosis exist in the E0-I1 scenario. A planned event of maintenance (i2) triggers the E0-I2 scenario.

Maintenance operations are prepared by the RM Unit.  The plant control operated by the FO Unit: the repair operations (E0-I1), the maintenance operations (E0-I2). A planned event of compressor's overhaul (i3) triggers the E0-I3scenarios composed of overhaul actions. The aptitudes identified for the sub-systems are affected to the corresponding actions. All the subsystems' aptitudes have not been fully detailed here. The technical Unit for example, must have an expertise for dismantling the plant equipment, for their maintenance (cleaning, consumables and small parts replacement) and for their repair (diagnosis of failures, big modules replacement). The supervision Unit must be able to analyse the software data, to perform remote diagnosis and to communicate the technical information with different interlocutors. The compressors' aptitudes are simplified here. First, the internal CMS is considered as a specific module having two aptitudes of regulation and data transmission to the RMS. Second, the remaining parts have aptitudes for pneumatic energy supply (head or reserve). Here, only a few aptitudes for MRO operations are defined:

 Their ease of dismantling;  Their ease of repair / maintenance (all the related aptitudes have been grouped for simplifying);  And, in the case of overhaul, the ease of transportation. The scenarios configurations are determined by the internal events that depend here on the compressors' states. These states are expressed in this Matrix (Table 18) to show their influence in PSS actions in the cells coloured in grey. The main state variable influencing the actions' occurrences are:

 Their Mean Time Between Maintenance (MTBM): determining the frequency of maintenance and associated scenarios;  Their Mean Time Between Failure (MTBF): determining the frequency of repair and associated scenarios;  The critical parts lifetime for the VSD compressor (determining the overhaul occurrence).

This lifetime is superior to the use scenario duration of the AoN. These state variables result from the structural choices made for the compressors. Ease of dismantling X X X

Ease of maintenance/repair

X X X

Ease of transportation X

Main parts Supply of energy X (OR) Reserve supply X

Ease of dismantling X X

Ease of maintenance/repair

X X

Internal CMS Regulation X

Data transmission X

Problem Matrix (PM): Influences between PSS actions and expected outcomes

The Problem Matrix aims at ensuring consistency between the PSS solution imagined (PSS actions supported by sub-systems identified) and the goals initially determined during the conceptual design phase (beneficiary's expectations expressed by the outcomes). The PM should be used to support the design validation and verification processes. This thesis does focus neither on the way the design outcomes should be identified nor on the issues of validating and verifying the PSS design. The Problem Matrix should probably be built through a co-operation between the PSS designers and the beneficiary.

The Problem Matrix (PM) shows the reciprocal influences existing between the defined actions of the PSS process and the expected outcomes. The PM is displayed in Table 20. The air quality (and quantity) and the energy efficiency are influenced / conditioned by the pneumatic energy supply, but also by the maintenance and overhaul operations. Repair operations are supposed to influence mainly the availability of air and the service reactivity. Actions of the back-office staff for monitoring can initiate the MRO operations and indirectly influence the outcomes. The customer reporting influences the technical information provision.

Outcomes

To simplify, the remote failure detection and diagnosis is supposed to mainly influence the service reactivity, while the remote preparation of maintenance operations is supposed to mainly influence the availability: it supports the pre-diagnosis and the required tools and spare parts are not forgotten. The data supervision initiates the all monitoring and MRO actions, then its influence is distributed between the technical performance outcomes, the service reactivity and the customer's reporting.

To simplify, the reserve supply is supposed to influences only the air availability.

The dialogue is supposed to occur at the occasion of maintenance operations. The flexibility of the offers is supposed to be dependent on the overhaul operations, since they represent a possibility for AC to change equipment in a contract, and the opportunity to optimize the management of the AC's machines fleet.

The PM raises many issues about the appropriate management of its building and the consistency of the influence links identified. These issues are further discussed at the end of the environmental evaluation section, in which this matrix is used.

PSS life cycle definition

The Design Matrix supports the definition of the PSS life cycle model. The products' and service units' aptitudes defined in the DM can support the identification of the different actions of the PSS life cycle.

The PSS life cycle defined in this study is shown in Table 21. As previously defined, the PSS life cycle actions are those of the sub-systems' Beginning of Life (BOL), End of Life (EOL) and of the PSS process.

The products' life cycles include:  In the BOL their manufacturing (after material extraction), delivery, and installing;  In the EL their uninstalling, end-of-use (EOU) scenarios, and waste scenarios. The service units' life cycles can contain different types of actions according to their defined aptitudes. In this study, both the FO and the Supervision Units' life cycles contain (in the BOL) training sessions (to the compressors' technology for example) and FMEA. To acquire maintenance expertise and skills, the FO Unit must be empowered to manipulate and transport refrigerant fluids (according to the current legislation). Indeed, the gas R104a used in the PSS is a fluorinated refrigerant fluid (greenhouse gas) submitted to several regulations, at the European (842/2006/CE and1005/2009/CE) and national levels (articles R-543-75 and R-543-123 of the Environmental Code). The certification agency trains the personnel to get the empowerment. An accurate reporting of gas transportation and replacement must be made systematically by the technical unit. The certification agency regularly (twice a year) controls the strict respect of procedures by an audit. In a similar way, the expertise of the Supervision Unit for remote analysis of the plant data can lead to the definition of the requirements for the software application before its implementation (during the BOL). The software provider implements the application and organizes training sessions. Regular updates of the software can occur concurrently with the progressive evolution of the Supervision Unit's requirements (because of the expertise acquisition). The Supervision Unit must also acquire communication skills for providing technical information to the customer or communicate the failure diagnosis to the technical Unit. The acquisition of such skills can also require training. As previously mentioned in the research methodology, this part of the thesis should be further consolidated. The environmental evaluation framework has been built through the industrial collaboration insights and corresponds to a support proposal that should be further explored and reinforced by its application and enrichment on other cases. The proposed tools are used in this section for an illustration purpose: to show their potential as communication supports between product engineers and service designers when performing a PSS environmental evaluation during design.

The study is organized as follows. First, the scope of the study is detailed. The costs analysis is then applied on the existing PSS case. The way this tool allows identifying some "hot spots" in the PSS design and could support PSS design negotiations is discussed.

Scope of the study

5.4.1.2.a. Boundary of the study

The environmental evaluation focuses on the PSS processes that involve AC and its customer. The OEM's processes are integrated since the assumption has been made that the OEM collaborates with AC in an integrated PSS design process. The customer's production machines (life cycles) are excluded from the scope. The only process taken into account is their pneumatic energy consumption; their electrical energy consumption is excluded. The customer's piping being pre-existing to the offer, its life cycle is also excluded, as well as the other actors' processes like the customer's piping maintenance.

All the infrastructures (electrical, telecom network, road, rail, etc.) and their life cycle processes have been excluded.

The data supervision performed daily (10min/day) has been integrated. For the action of providing technical information to the customer, the assumptions are: the computer use for 1 hour of analysis and the printing of a report (50g) monthly.

5.4.1.2.f. Environmental indicators

The calculation method Impact 2002+ (v2.12) has been used. Three types of indicators have been chosen for this study. These indicators illustrate three impacts categories. First, the ozone layer depletion (Kg CFC-11 eq) has been chosen as an indicator of impacts on human health. Second, the mineral extraction (MJ surplus) reflects the natural resources depletion. Finally, the aquatic acidification (Kg SO2 eq) has been chosen for the impacts on the ecosystems quality while it also completes the different types of environments that are impacted by the system. The costs analysis is performed for these three "types of costs".

Life cycle data

The data used for modelling the PSS life cycle can be either assumptions made by the AC designers or by the modeller (me) or they can be more accurate data provided by different types of sources (internal AC reports, websites, etc.). The different types and sources of the data collected for environmental evaluation are shown in Table 22. Table 22 Types and sources of the data collected for environmental evaluation

The Simapro software (V.8) has been used for modelling. The environmental database EcoInvent (system processes) has been mostly used when the data were available. A few other databases have been used when EcoInvent data did not exist, e.g. BUWAL 250 for some materials' recycling. New Design Matrixes are required for the alternative scenario, since the PSS actions, the sub-systems' aptitudes and their solicitations in actions have changed. The weighting coefficients for defining the relative importance of aptitudes and their distribution in actions are also changed. All these changed are summarized in the Table 29 andTable 30. The colour cells indicate the changes operated compared to the existing case.

The distribution of the relative importance of aptitudes has been changed for the two compressors: since they are less often dismantled and maintained / repaired by humans, these aptitudes are consequently less relatively important. The AoN being now overhauled, the capacity to be transported is required and some of its other aptitudes are solicited during overhaul. The compressors' internal CMS and the RM equipment have a control mission that is solicited in the maintenance operations. The Supervision Unit must acquire a maintenance expertise. The distribution of its aptitudes importance is changed.

Design parameters

The design parameters of the existing system are modified for the alternative scenario. Table 31 details the modifications made in the life cycle model. The expected reduction of the all energy consumption is of 7%, integrating the reduction of energy consumption for supplying compressed air balanced with the over-consumption generated by a bigger RMS and associated instruments. Less maintenance operations are performed, supposing that remote adjustments can be made. Due to the risk of failures, and in order to maintain the air availability, the compressors must be designed more reliable. This is translated by a material increase in the model. However, the number failures and of repairs is still supposed to be increased. The AoN compressor is supposed to be designed more reliable too and additionally, its reserve capacity (that is, in the reality, materialised by a second compressor) must be increased. Since the AoN is more frequently solicited for reserve supplies, an overhaul is necessary. This overhaul allows maintaining an equivalent lifetime than in the existing case. An aptitude to be transported is then added to the AoN in this alternative.

The internal CMS of compressors and the RMS used by the supervision Unit are supposed to be bigger: this is translated by a material coefficient. The supervision spent more time to use the software on the computer. The number of maintenance operations is supposed to be decreased (from about a half).

The technical Unit is supposed to be less trained and to perform less reporting (printing of reports) because a part of these activities is now affected to the supervision Unit. As previously mentioned, this thesis propose considering the beneficiary's needs as a constant basis, while several design alternatives can be proposed that must be discussed and selected on the basis of their benefits (the way the effectively fulfil the needs) and their costs.

The technical outcomes constitute the core of the needs fulfilment and are supposed equivalently provided (with an improved energy ratio in the alternative case), but the non-technical outcomes are

Chapter 6. Summary of the contributions and research perspectives

This Chapter discusses the research contributions, limitations and perspectives. The research contributions are summarized in the section 6.1. Section 6.2 discusses the research limitations and the resulting research perspectives identified. Section 6.3 concludes the thesis.

6.1. Research contributions 6.1.1. Research questions

The goal of the thesis was to provide a support for PSS eco-design. The issue of product-service integration has been identified as a critical one for allowing PSS achieving its eco-efficiency potential.

After further exploration and refinement of the research scope, the following research questions have been identified: RQ1. How to support product-service integrated design and modelling?  RQ1.1. How to define a system framework to integrate products and services during PSS design?  RQ1.2. How to support the progression of the design task through an integrated modelling support? RQ2. How to support PSS eco-design design through environmental evaluation?

 RQ2.1. How to support PSS environmental evaluation during design?  RQ2.2. How to define and model a PSS life cycle? This research provides several contributions to answer these questions.

Generic contribution: A conceptual framework for PSS integrated ecodesign

A conceptual framework to support PSS integrated eco-design has been proposed to answer the RQs. The framework should:

 Support PSS integrated design (RQ1) over its life cycle  Support PSS environmental evaluation (RQ2.1)  Through a PSS life cycle model ensuring evaluation during design (RQ2.2) Consequently, the framework should support integrated PSS eco-design during the detailed design phase. The PSS conceptual design phase is out of the research scope. The framework and the scope of this thesis are shown in Figure 94. Within this framework, research contributions to each question can be refined. In order to support product-service integration during PSS design, an integrated PSS design framework has been proposed. The framework is based on a conceptual system-based design framework and a multi-view modelling framework.

6.1.3.1.a. System-based design framework for PSS design (RQ1.1)

A conceptual system-based design framework is proposed to integrate the classical approaches of product engineers and service designers in a common framework that supports:

 Adoption of a system terminology  A common design progression process through a co-evolutionary framework A system concept is proposed to integrate the viewpoints of product engineers and service designers on their object under study. The system concept can facilitate the understanding of their specific viewpoints on design. For example, the differences between the concepts of product "function" and service "actions" or "outcomes" have been discussed regarding the system concept. The system concept is used to define a system-based design framework that aims at integrating the design progression tasks within an integrated reference. The co-evolutionary framework proposed contains three main design "spaces" defined on the basis of existing frameworks in the fields of product, system and service engineering. The system-based framework proposes a co-evolutionary representation and decomposition of the problem ("result") and solution ("structure") spaces. The system concept defines actions as having effects on the beneficiary. The "result space" formulates the problem by organizing actions. The system concept defines system boundaries as interfaces of systems in actions. The "structure space" organizes the solution by organizing systems. Both spaces contain hierarchical layers of decomposition and are linked by design relations. They can be decomposed concurrently in the co-evolutionary framework. The co-evolution is supported by a negotiation space ("structural organization") used to represent the internal organization

The proposed PSS life cycle definition conceptualizes the service life cycle and facilitates the PSS life cycle modelling during design. Additionally, support tools are proposed to facilitate the PSS life cycle modelling. Life cycle Matrixes support the identification and modelling of the sub-systems' life cycles their integration within the PSS life cycle during design. By facilitating the link between design and evaluation, the PSS life cycle definition and support tools for modelling allow continuously performing environmental evaluation during design.

6.1.3.2.c. PSS environmental evaluation framework for ensuring consistency between beneficiary's value and environmental impacts generated (articulating the RQs)

In order to overcome the challenges of balancing the beneficiary's "value creation" with the environmental impacts generated, a VA-based evaluation framework is proposed. The framework allows continuous focus on the impacts generated during PSS design as well as alternatives comparison focusing on the beneficiary's needs. The costs analysis support continuous analyses of the EI generated during PSS design. It allows identifying the main "hot spots" to continuously question the design at different levels of detail. The design priorities can be established and refined concurrently with the system design, in order to maximise the impacts reduction throughout design progression. VA-based comparison emphasizes on the balance to find for the design solutions between the way they provide benefits (outcomes here) and the costs generated (Environmental Impacts -EI here). The beneficiary' needs being the classical of focus of service design and the environmental impacts those of product engineering, the VA-based comparison should support a better integration of these two views in PSS evaluation.

Research limitations and perspectives

Several limitations can be underlined in this thesis. They result in several research perspectives.

A mainly theoretical viewpoint: a need for further ground investigations

The PSS integrated eco-design framework proposed in this thesis mainly result from the literature exploration, even if some issues identified have been specifically lightened by the industrial collaboration. The resulting proposals are based on existing literature contributions. They are discussed in the case study to detail their "potential" for supporting issues identified in the literature. Their effective interest for industrial companies is supposed and discussed but has not been further explored.

Scope of applicability

First, the question of the scope of applicability of the frameworks tools is raised. The business contexts, types of PSS and of design process, the types of transition processes towards PSS have not been explored. The boundary conditions of the framework implementation are not detailed, whereas they should actually constitute the basis for further research. For example, the modelling tools proposed seem well adapted to the case study, but to what extent are these models useful for companies and for which type of actors? The case proposed here is a B2B PSS corresponding to a "result-oriented" PSS in the Tukker's typology. In which conditions and PSS cases the framework can be applied? One can suppose that for a use-oriented PSS like bicycle sharing, the needs of the design teams strongly differ, particularly for modelling. The system framework should probably be enriched by using other types of models or completing the existing ones according to the different types of PSS, of actors involved in its design and of the context.

Conclusion

Focusing on the issue of product-service integration in PSS eco-design, this thesis provides a specific light on the PSS integration challenge by considering several "views" that should be adopted on PSS. This contributes to evolve the classical consideration of product and service differences as encapsulated in the objects' nature. Instead, their differences are discussed as resulting from the actors' perceptions. A framework is proposed to support PSS integrated eco-design. A "multi-views" PSS modelling support is integrated in a system-based framework. The framework is expected to support the actors' current practices while facilitating their communication. Models from product engineering and service design are used to represent each "view" while models are integrated in a system model. An environmental evaluation framework is proposed to evaluate the system during design. A Value-Analysis based framework is proposed to build a shared view on the PSS "value" that should be assessed: a balance that should be found between the beneficiary's benefits and the environmental impacts generated. Such an evaluation mechanism is expected to clear the path for evolving the product-oriented tools for environmental evaluation towards service aspects. The potential of PSS for eco-efficiency depends on the capacity of each actor to extend its viewpoint and skills towards other ones from different disciplines.