The Model-Driven Decision Arena: Augmented Decision-Making for Product-Service Systems Design

Abstract

The shift towards Product-Service Systems (PSS) stresses the need to embed new and unique capabilities in Decision Support Systems, with the aim of helping the engineering team in handling the pool of information and knowledge available during decision events. Emerging from a multiple case study in the Swedish manufacturing industry, this paper describes the development of the Model-Driven Decision Arena (MDDA), an environment for collaborative decision-making that focuses on the early design phases of PSS. Based on the findings from multiple case studies, this paper illustrates the main goals of the MDDA, detailing its main functions, its physical environment, and its software architecture and models. This paper demonstrates the use of the MDDA in a case study related to the development of an asphalt compactor, presenting and discussing the results of verification activities conducted with industrial practitioners on the current MDDA prototype.

1. Introduction

Increasingly saturated and commoditized global markets drive manufacturing companies towards shifting their business focus, adopting a strategy where customer value is in the spotlight, and where products are bundled with services to offer Product-Service Systems (PSS) [1]. The emergence of this “servitization” [2] trend challenges traditional product-based business models, stressing the dematerialization of the physical artefacts [3] and the creation of restorative and regenerative systems that decouple economic growth from environmental impact, generating new revenue streams out of extending the residual value of products.

Since the main business benefit of PSS lies in the opportunity to leverage “value generation” for customers and stakeholders along the entire life cycle, new aspects become influential in the design decision-making process. For this reason, the engineering team requires systematic facilitation, in the form of Decision Support Systems (DSS) [4], to handle the pool of information and knowledge available during decision events, so as to correctly evaluate design trade-off. The main challenge in creating such a DSS is the lack of processes, method, and tools to model the more intangible value aspects of a PSS at decision gates, including sustainability compliance. Value and sustainability are not yet available as model-based disciplines—equivalent to, for instance, fluid dynamics or multibody dynamics—at least when seen from a computational modeling perspective [5]. The ability to assess these two dimensions resides not only within the product definition but also within their life cycle and usage context. For this reason, the engineering team requires decision support able to handle multi-domain models that consider the entire system of products and services. At the same time, a DSS shall be able to generate all the necessary information to assess the value creation opportunity linked to alternative concepts along every aspect of their life cycle.

Noticeably, decision-makers are rarely experts on all knowledge domains needed to navigate through the vast design space for PSS [6]. Without proper steering and coordination, these teams strive to optimize the subsystem they are responsible for, and often generate suboptimal solutions from a system perspective. The quality of design decisions is likely improved by encompassing a broader representation of knowledge and values in the process, and by supporting a more collaborative working mode across disciplines. Hence, a DSS for early PSS design shall be designed to ensure stakeholder involvement and participatory integrated assessment [7] in the decision process. This shall encompass a Human-in-the-Loop approach [8] to capture and reflect preferences of the stakeholder group, allowing the design team to “shop for a solution” [9], increasing design freedom, as well as trust and acceptance of subsequent decisions.

The main aim of this paper is to describe the development of a model-driven environment for collaborative decision-making for early PSS design. The main function of this environment, named the Model-Driven Decision Arena (MDDA), is to leverage a common understanding of complex, multi-disciplinary, and uncertain design situations in a cross-functional team setting. This is obtained by creating a visual representation of what each actor needs to know to deliberate about a given situation, showing rationale, origin, and connections between different sources of information. A similar type of decision environment has been successfully deployed within other scientific areas, one example being the decision theatre at Arizona State University [10]. Yet, a question remains concerning how individuals from different functions and roles can take advantage of 3D visualizations, simulation models, and other computer-assisted tools, to ultimately improve decision-making in design.

This paper initially describes (in Section 2) how the model-driven decision environment is intended to foster a process where models are used to learn about a design and to explore the solution space, in contrast with merely verifying if a PSS fits the requirements. Section 3 further illustrates the overall logic of the MDDA, detailing its main functions, architectural components, and models. Section 4 presents the results of verification activities conducted with industrial practitioners on the initial MDDA prototype. Section 6 presents the materials and methods related to the development of the MDDA concept, while Section 7 presents conclusions and further activities related to the ongoing research work.

2. Models for Systemic Design Space Exploration

2.1. Systemic Design and the Need for a Model-Driven Decision Environment

The recent challenges that have come from the increased complexity caused by trends such as globalization and sustainability, render traditional design methods insufficient and call for a more systemic approach to the discipline of design. The concept of Product-Service Systems is often linked to systemic design practices [11,12], mainly because PSS are designed based on the idea of providing a “satisfaction unit” [13] rather than merely “products”. This “unit” is built around innovative interactions among all actors of the system, in an effort that continuously pushes the design process towards environmental and socio-ethically sustainable innovations. Efforts to cope with this more systemic view on design solutions include more business-to-business collaboration [14], more intense interactions with stakeholders found in several sectors of society [15], the recruitment and development of more multicompetent staff (able to work across traditional disciplines) ([16], p. 159) and the adoption of a life-cycle thinking approach in the development of design concepts—where reuse, repair, reconditioning, and refurbishment become part of a manufacturer’s operation [12].

A cornerstone of the PSS transformation is the ability to cross sectorial and disciplinary boundaries [17,18], because no single individual, working group, or company function can by itself produce sustainable outcomes. Even more important is the opportunity to provide these cross-disciplinary teams with ad-hoc support tools that enable detailed evaluations and comparisons of a large number of solution options in a short time [19]. At the same time, it is critical from a systemic design perspective to be able to visualize the results of these investigations in an understandable way [20], so that an informed expert judgment is possible, creating an opportunity to balance the desired properties of the conceptual solution and to understand the impact of changes and decisions over the life cycle.

The above considerations have driven the vision of creating a model-driven decision environment, to integrate all relevant methods and tools for sustainable PSS innovation into business leaders’, business developers’, and product developers’ regular work practices [21,22]. These methods and tools are unique in the way they bring together knowledge, competencies, and skills in the joint decision environment to introduce a systemic perspective in design.

2.2. Model-Based Decision Support: From ‘Verifying’ to ‘Learning’

Model-based decision support is already applied in many product development tasks, in a wide array of manufacturing industries. Here, engineers exploit different types of models, experimenting with design parameter settings to assess the expected properties of a design before a decision. Designers typically bounce back and forth between problem setting and solving, exploring the design space through experimentation to unveil behaviors and constraints. This iterative nature of the engineering design process decision-making is well illustrated by the Basic Design Cycle proposed by Roosenburg and Eekels [23].

While the literature recognizes the importance of models as a means for verification, it also stresses the need for a broader view on how models are used to learn about “what” to develop, rather than to verify if a design fails to meet the performance targets [24,25]. The design process is essentially about generating solutions that best satisfy customer and stakeholder needs (in the form described by Ulrich et al. [26]) with available means (in the definition provided by the Systems Engineering Handbook ([27], p. 82)). Unfortunately, the notions of ‘needs’ and ‘means’ are both ill-defined and conflicting. Neither the needs nor the available means (e.g., design constraints, in the words of Gero [28]) are given in a project’s fuzzy front end, and unveiling them then becomes an integral part of the design process.

The literature (e.g., [5]) stresses the opportunity for broadening the view on how virtual models can be used to support conceptual decisions, from early product positioning to the definition of a program’s high-level objectives, to architectural design choices. This calls for a decision support environment that, early in the design process, raises awareness about the vastity of the feasible design space, unveiling behaviour and constraints through experimentation. The environment shall provide the necessary contextual knowledge to orient trade-off resolution, not only looking at the design of the technical hardware, but at the entire system of products and services over the lifecycle of the solution [29].

Enhancements in computer-based product modeling and simulation are critical in this respect. Manually performed what-if analyses prohibit extensive exploration of a vast design space. The latter emphasizes the need to develop more systematic (and automated) approaches to raises awareness on the behavior and performances of many heterogeneous designs, so as to identify potential failures as well as improvements. The automotive and aerospace sectors have been at the forefront of the implementation of simulation-driven approaches to support the entire design—evaluation loop, allowing iterative design [30]. Car body design, for instance, has benefited from the application of rule-based techniques, making it possible to reuse the boundary conditions (and analysis type) from project to project, simulating the effect of a design change within hours instead of weeks or months. Virtual modeling methods are becoming a commodity in aerospace sub-system design [31], mainly in the domain of structural mechanics, aerothermodynamics, and fluid mechanics. Simulations are exploited already at a conceptual design stage to assess the effect of welding on distortions and induced stresses in the product [32], sometimes even considering the whole lifecycle in the design exploration activity, developing practices and models for geometrical robustness simulations [33].

2.3. Model-Based Decision Support for PSS Design

Nowadays, PSS models exist in different forms (e.g., physical models, service models, business models, and business process models [34]) and with different modeling supports (e.g., models with or without a structured method, multi-level models, and symbiotic models [35]). A majority of the modeling effort in the PSS community is devoted today to the task of representing, displaying, and simulating the process component of the PSS (see: [36,37]), which is to represent how the recipients of the services (the users) interact with each other and with the PSS provider. Modeling and simulation techniques are often applied at a high level of abstraction to gain an understanding of the likely performance of the system being designed, carrying out what-if analyses to assess the dynamic impacts of variation in input parameters to output parameters.

These approaches are typically based on the Business Process Modeling Notation (e.g., [38]), the Unified Modeling Language (UML) (e.g., [39]), and the Event-driven Process Chain (EPC) (e.g., [40]). Process models can be further translated into simulation models for learning purposes. By executing them early on in the design process, the design team can obtain an estimation of the behaviour of the PSS along its lifecycle (e.g., [41,42]). Discrete event simulation (e.g., [43]) and hybrid simulation (e.g., [44,45]) are among the most commonly used techniques to help decision-makers in selecting—in a project fuzzy front end—the PSS embryos with the highest potential for market success.

With regards to the hardware component of the PSS, early efforts in the domain of model-based PSS design date back to the late 2000s [46,47] and focus on how to support designers in generating concept models in the early phase of development, fostering the functional behavior of PSS artefacts. Reed et al. [48], for instance, proposed a model-based approach that can generate an integrated description of both hardware reliability and service support processes—including details such as maintenance task unreliability—making it possible to compare and optimize hardware and service configuration choices early in the design process. Others [49] described a tool capable of converting a description of a functional product into a model, analyzing it through simulation to predict its availability in operation. Optimization models for PSS configuration have also been proposed (e.g., [50]), which make it possible to mix and match product ‘modules’ to find the most optimal combination from a lifecycle perspective (i.e., the one with the highest expected profit over 15 years), considering how the product will be recovered and reused/remanufactured/recycled at end of life. Another recent example of how to include the service discipline in the model-based systems engineering of PSS was proposed by Apostolov et al. [51].

The literature review shows that the issue of model adoption raised by Vezzoli [52] is still mostly valid: achievements in the model-driven PSS field tend to remain theoretical, with verification activities being conducted mainly in a laboratory setting, often through simple hypothetical examples. In addition to this, the development of computer-based models and simulations able to account for the behavior of PSS over time—and for its capability to dynamically deliver value—is still limited and unable to address a systemic perspective in design. Another limitation of existing model-based approaches is their tendency to consider the hardware element from a service management perspective, reducing it to distribution mechanisms for service provision. As highlighted in the literature [53], PSS must consider product design within the product life-cycle perspective, linking hardware design with corresponding organizational issues, to provide the design team with efficient means for optimization in the life cycle perspective. Hence, the hardware is understood and typified by the vast range of equipment presently on offer for sale to customers, rather than being considered as an ‘enabler’, and therefore being designed ad-hoc, to support the service part of the system.

3. Results: The MDDA Concept and Implementation

The development of the MDDA environment is driven by a perceived gap in the way model-based support is exploited in a systemic way in the PSS design process. Initial work on conceptualizing, developing, and testing the environment was conducted in collaboration with four major manufacturing companies in Sweden, as described in Section 6. This work was anchored in a practical industrial case, similar to the one described in Section 4. The research work featured several iteration loops terminated by the creation of increasingly refined demonstrator to showcase the intended MDDA capabilities, as well as to further understand requirements and possibilities related to such an environment. These demonstrators were based on a multi-domain model (functional/engineering and value-driven design), simulating the value of conceptual designs from an end-user perspective.

3.1. The MDDA Physical and Virtual Environment

The findings from the descriptive study indicate a preference towards conceiving the MDDA as a physical location where design decision-makers gather to share ideas, knowledge, and values to evaluate conceptual designs. For this reason, the first prototype of this physical environment can accommodate between three and six people in a “design” session and can fit up to 10 individuals in a presentation session. Elements of the room are furniture, whiteboards, a large multi-touch screen, a computational server, and a video wall intended as a canvas for displaying a variety of items, such as concept descriptions, models, and simulation results (Figure 1).

Table 1. Basic specifications of the MDDA physical space.

Specification	Value	Rationale
Number of individuals in the room	2 to 10	The opportunity of inviting collocated collaboration is the main principle guiding the creation of the physical space, which is designed to encourage user interaction in small groups, typically consisting of five or fewer individuals, even though the room itself can accommodate up to 10 individuals.
Size of the room	Approx. 20 sqm
Information visualization	Six 55-inch Full HD screens mounted in a 3 × 2 matrix.	The large vertical displays are intended to facilitate audience-based viewing, allowing the group to see information from the same perspective, improving tasks such as 3D navigation. Several sources can be displayed simultaneously, enabling content sharing of selected material between personal workspaces like laptops and the shared workspace.
User interface	Horizontal, multi-touch tabletop screen, 49 inches	The centerpiece of the hardware infrastructure makes it possible for all individuals to share, visualize, and discuss digital content. The multi-touch feature encourages participants to take control of the environment compared to a traditional mouse and a keyboard.
Distance communication	Full HD camera, video conferencing system	The video conferencing system is added, allowing participants to join meetings remotely to the design session.
Other equipment	Two whiteboards (3 × 1.2 m)	Analog media were found to have a positive impact on fueling the design discussions. Two whiteboards are mounted on opposite sides of the room to avoid situations where one individual takes control over the board making it challenging for others to take the floor

summarizes the base specifications derived from the cross-company study with regards to the physical space currently prototyped at the authors’ home institution.

At the core of the MDDA lies a hybrid model environment with a multi-level model hierarchy, encompassing, for instance, discrete event simulations, finite element simulations, differential equations, algebraic equations, and mathematical logic, as shown in Figure 2. The model framework is designed with well-defined interfaces between the server/module/client.

The MDDA server, implemented in Microsoft Excel, controls interaction, data transfer, and execution of all modules in the environment. The functionality of each module is based on submodules implemented in different software (clients), which allows models of different fidelity to be used in different stages of a project. This is a critical feature to seamlessly evaluate radical alternative business strategies, as well as to just move between different projects.

Noticeably, the MDDA is designed to store the complete system definition in a single repository, to mitigate the problem related to redundant and possibly outdated information. Every data element is stored only once, and updates are automatically propagated through the system. The main objective of this approach—which is often referred to as Single Source of Truth (SSoT) in Model-Based Systems Engineering (MBSE) [54]—is to make sure that everyone is using the same data, improving transparency, traceability, and ownership of the data.

3.2. Generating ‘Variants’ of Existing Product Platforms

In its current configuration, the MDDA is mainly intended as an environment to assess the suitability of different configurations of an existing ‘product platform’ for the targeted PSS business model. A main reason for limiting the scope of the investigation to incremental improvements, in contrast with radical redesign, shall be found in the results from the descriptive study. The participating companies pointed out that design freedom for new PSS hardware is limited. Radically new designs are often discarded due to the need to comply with existing standards, regulations, and manufacturing constraints, as well as by considerations related to the management of the supply chain and its logistic. For this reason, the MDDA is designed today to support the generation of a number of possible ‘variants’ of an existing product platform. The exploration of the performance space for these variants requires reliable information/data of a proposed design, such as its structural behavior and physical performances. Hence, the MDDA server receives as input a description of the PSS hardware concept that contains information about system hierarchy, geometrical data, contextual data, envisioned operation scenario, and more (see Figure 3).

A major part of the data needed in the MDDA is digitally stored in a Computer-Aided Design (CAD) model, from which functional as well as non-functional attributes may be directly derived. Although the CAD model, besides defining geometrical entities, can store a lot of metadata, that quickly becomes tedious and cumbersome to edit and maintain. Hence, a second data source is added in the form of a spreadsheet to store concept-specific and other contextual data. Using a spreadsheet also significantly eases communication and data sharing with other software in the model framework compared to storing them as metadata in the CAD model.

The CAD model is feature-based and parametric, i.e., it is defined by dimensional, geometric, and algebraic constraints. Its capabilities are further extended using ad-hoc rules, which may be embedded or implemented in other software and linked back to the CAD environment. The generation of variants from a generic platform is controlled by MS Excel^®.

Design space exploration in the MDDA server is supported by an automated Design-of-Experiment (DOE) routine [55] that exploits Latin hypercube sampling through the lhsdesign function in the MATLAB^® software developed by MathWorks^® (Natick, MA, USA). In the DOE, design team members can select a subset of design variables to be varied in the study, including geometrical dimensions (continuous variables), number of sub-systems or components (discrete variables), and/or technological options (categorical variables). Upon selection, the design team is also requested to input lower and upper limits of such variables, to guide the routine in generating a near-random sample within the admissible values in the experiment.

3.3. Functional Analysis

MS Excel^® works today as main server for the MDDA environment. An example of the functional model currently set-up in the arena is shown in Figure 4. This module controls and interacts with several other software (CAD, finite element method (FEM), numerical computing platform, etcetera), here referred to as clients, running specific models needed to assess different aspects of the studied concept. The connection between MS Excel^® and the clients is ensured by custom application programming interface (API). These API make it possible, for instance, to input the data generated by the experimental plan into the Inventor^® application developed by Autodesk^® (Mill Valley, CA, USA), to automatically generate the 3D model of the corresponding PSS hardware configuration.

Several functional attributes are derived from the CAD description, such as the mass of a sub-system or component, and its geometrical features. Other performance attributes, such as energy consumption, are evaluated through engineering models, in the form of differential equations, algebraic equations, or mathematical logic. Non-functional attributes might, for example, be estimates of the CO₂ footprint linked to specific materials, production processes, and transportation activities.

3.4. Cost Analysis

The cost analysis module of the MDDA (which is inspired by the work of Fabrycky and Blanchard [56]) aims at quantifying the economic gains (and the losses) of a new concept compared to a baseline design. The analysis is based on a Total Cost of Ownership (TCO) equation (1), which distinguishes two main cost families—ownership (OW) costs and operating (OP) costs. The TCO model for PSS design proposed by Finken et al. [57] was used in this study as a main reference to define the cost items to be featured in the MDDA. Noticeably, not all items listed in this model are relevant for all products and related applications. Hence, the design team must initially shortlist from this template those costs that are considered to be priorities in the calculation, neglecting those that are perceived to be less meaningful or too difficult to assess with certainty in an early design phase.

$$\mathrm{TCO}={{\displaystyle \sum }}_{\mathrm{i}=1}^{\mathrm{n}}\frac{\left(\mathrm{DPc}+\mathrm{FINc}+\mathrm{OH}\right)+\left(\mathrm{Ec}+\mathrm{Lc}+\mathrm{Sc}+\mathrm{Mc}+\mathrm{Rc}+\mathrm{Lc}+\mathrm{EoL}\right)}{{\left(1+\mathrm{r}\right)}^{\mathrm{i}}}+\frac{\left(\mathrm{DCc}-\mathrm{RV}\right)}{{\left(1+\mathrm{r}\right)}^{\mathrm{n}}}$$

(1)

The main cost types of the TCO model featured in the MDDA are described in

Table 2. Main cost items in the MDDA Total Cost of Ownership model.

Cost Item	Description
DPc: Depreciation cost	Capitalization of the acquisition cost over the lifecycle.
FINc: Financial cost	E.g., interest on loans and taxation reduction.
OH: Overheads	E.g., training, recruitment, and insurance costs.
DCc: Decommissioning cost	For the hardware, only if it is not sold second-hand.
RV: Resale value	For the hardware, only if it is sold on the second-hand market.
Ec: Energy cost	Proportional to the energy used during the entire lifecycle.
LC: Labor cost	Proportional to the human labor needed to operate the system.
Sc: Setup cost	E.g., preparation and inspection of the hardware.
Mc: Maintenance cost	E.g., labor, consumables, and downtime/opportunity cost.
Rc: Repair cost	E.g., labor, spare parts, and downtime/opportunity cost.
Lc: Logistic cost	E.g., transportation, storage, and other costs.
EoL: End-of-Life cost	E.g., waste disposal, reverse logistics, disassembly.

below.

Populating the equation requires the development and executions of a set of sub-models, such as the lifecycle performance model and the manufacturing model. The first one simulates the system-level behavior of each design configuration—replicating typical usage scenarios—in a way to predict how each concept will behave in the customer operational process. This is built as a collection of Discrete Event Simulation (DES) models, that are iteratively developed and refined during the development process, and then ‘called’ by the arena when needed. The DES models take as input geometrical-, physical-, and performance-related data stored in MS Excel, as well as other parameters, such as energy consumption, man-hours needed for conducting tasks according to the given operational scenario, and more. They are run to obtain time-, resource-, and capacity-related information, to later predict the accumulated usage cost during the lifetime of the PSS hardware. Specific modules are used to calculate maintenance costs, which may depend on selected design features, components, and assembly structures, as well as on the operational scenario, end-of-life costs, depreciation cost, and resale value. The model further provides an indication of the time whilst a solution is perceived by the customer as having inferior performance, functionality, or appearance compared to what already proposed on the market [58].

The manufacturing model uses geometrical data from CAD, such as number of components in a system (affecting assembly cost), estimated mass (affecting logistics in the manufacturing operations), or component size, to estimate the cost for production of the entire system. Engineering models linked to the functional module might also be used. An example of such a model might be a welding analysis, where necessary weld throat thickness is estimated considering required component life, geometric description, and load case. Predicted thickness affects the time required for the weld operation and dictates what shall be considered feasible welding techniques, thus having a direct effect on manufacturing cost.

3.5. Value Analysis

The descriptive study further showed that focusing only on cost driver reduction leads to false perceptions of value and does not enable a sound judgment to be made during the design of an engineering product. Conceptual design activities shall encompass intangible factors—such as brand acknowledgment, aesthetics, or sustainability impact—going beyond cost to provide a more complete view of the value of PSS concepts. The MDDA proposes two complementary approaches to capture value aspects beyond cost and technical performances: a quantitative one measuring value in monetary terms and a more qualitative one.

It is possible, on one end, to quantify all aspects of value in monetary terms, so that they can be more easily traded-off with more traditional requirements. Monetary units are convenient, practical, and universally understood metrics for value, and are beneficial in the design process to stress the potential success of investments [59]. This quantification process in the arena is driven by the implementation of Net Present Value (NPV) and Surplus Value (SV) from the Value Driven Design (VDD) literature [60]. Different models, which exploit a probabilistic approach using Monte Carlo simulation, are then developed and ‘called’ in the MDDA to generate the necessary data for the NPV function to be populated. Importantly, separate models are developed to account for alternative PSS business model types. NPV and SV are eventually calculated by computing the difference between cash inflows and outflows over a period of time considered relevant by the cross-functional team, and by applying a relevant discount rate to determine the present value of such flows.

Quantification presents several challenges, mostly in terms of data availability and trustworthiness of the monetary models. A complementary approach is that of adopting a more qualitative approach, with the aim of assessing the ‘goodness’ of a design for a given set of value-related criteria. The introduction of a Multi-Criteria Decision Analysis (MCDA) module is then seen as a pragmatic approach to account for value aspects in the decision process, which are hard to quantify with precision in economic terms (and that might mislead decision-makers).

The value criteria for the MCDA exercise are derived from a framework that considers customer and provider perspectives separately. The definition of value criteria is guided by the Feasibility-Viability-Desirability (FVD) from Design Thinking research [61] and by the Triple Bottom Line (TBL) model [62]. Analytical Hierarchical Process (AHP) is used as the principal method to rank-weight the value criteria. The Technique for Order Preference by Similarity to Ideal Solution (TOPSIS), the VlseKriterijumska Optimizacija I Kompromisno Resenje (VIKOR), the (ELimination Et Choice Translating Reality) ELECTRE, and PROMETHEUS are the main approaches in the engineering toolbox to qualitatively assess the value of solutions at an early stage. The decision about what method shall support the MCDA exercise is driven by considerations on team size, experience with MCDA, and information availability. More advanced methods, such as Concept Design Analysis (CODA) [63,64], are applied when the team needs to better capture the rationale behind the assessment, and to document richer lessons learned that can be exploited in future projects.

3.6. Visualization

Figure 5 shows the current prototype of the MDDA environment and displays how the schematic layout presented in Figure 1 was realized in the physical space. The example featured originated from previous work conducted in the road construction sector and focused on the development of Discrete Event Simulation models for double drum asphalt compactors [65].

The video wall is used to visualize the results of the simulation for a specific design concept, maintaining the link with specific features of each hardware sub-system. It is then possible for the MDDA users to interact with the multi-touch screen to navigate through the generated concepts and compare their performances. Noticeably, this means being able to navigate through an abundance of data, across a complex hierarchy of attributes, ranging from the top-level attribute of value down to basic functional attributes of the concept design.

A critical aspect in design decision-making is to relate component-level features with the behavior of systems and sub-systems in operation, to explore cause and effect relationships. Analysis of variance [66] is used to predict the trends in the simulated response data, to then generate response surfaces that approximate the input-output relationship between design variable and results.

However, even if the outcome of the data analysis stage contains the necessary information to support sought decision, it is still hard for a diverse group of stakeholders to navigate through and make sense of the generated data. Key enablers for exploration and negotiation in a multi-stakeholder decision scenario are constructs and practices aiding interaction with model-generated data. A major challenge in this exercise is how to exploit human judgement to deal with situations where the data set is both very large but also incomplete and inconsistent. In this situation, the visualization strategy shall consider the need to empower the human component and augment its ability to recognize patterns and relationships in the data set. The MDDA interface is designed to be flexible and able to accommodate a large number of data visualization approaches. Previous research [67] has explored the development of tailor-made visualization constructs, such as color-coded CAD models, to be used in conjunction with more traditional scatter plots, parallel coordinates, radar charts, and histogram plots. The main factor pushing ‘flexibility’ as a requirement for data visualization is the need to improve the ability of individuals from different disciplines to ‘play’ with the results of the different models. Knowledge-sharing and collaborative decision-making are at the core of the MDDA concept; hence the visualization interface shall invite all users to test different assumptions, varying the input data, assessing changes, and evaluating options.

4. Case Study

The MDDA was applied and tested in a case study related to the design of an innovative battery-driven, zero-emission double-drum asphalt compactor in collaboration with Company A. The main goal of the investigation was to assess the value generation opportunity linked to each design concept in classical one-sale transactions, as well as in a product-oriented and use-oriented PSS model [68]. In the case of product-oriented PSS, the compactor was sold to a unique customer together with additional services, such as extended warranties and training. In the use-oriented PSS, the machine was leased/rented on demand to several different customers.

4.1. Application of the MDDA Workflow for Asphalt Compactor Design

The application of the schematic workflow presented in Figure 3 moved from the development of a fully parametric 3D representation of the compactor ‘platform’. The latter is intended as a generic, flexible, fully customizable and rule-based description of the equipment, which is based on the 3D CAD model originally proposed by Bertoni et al. [65]. This new representation includes refined geometry and improved parametric capabilities, together with a complete set of APIs to enable automatic data exchange in the environment.

The authors initially shortlisted a set of design variables to be varied in the DOE. The descriptive study at Company A pointed out the need to assess the ability of different types of lithium-ion batteries to complete an entire day of intense road construction work. The dimension battery technology was chosen as the first parameter in the DOE, together with battery capacity. Efficiency, range, and reliability of the asphalt compactor were also found to be dependent on the motor type. Several electric motors, which differed in terms of nominal power, number of poles, and bearings types, were inputted in the DOE. The volume of the water tank, together with the geometrical dimensions of the machine along the x-y-z axes, were further selected to calculate weight, speed, acceleration, and power consumption of each generated concept. These data were then imported into the DES environment, in a similar way to that explained by Bertoni et al. [65], to track the battery state of charge while the machine was moving in the simulated road construction site. Three main application scenarios were considered at this stage: pothole compaction, sidewalks, and parking lots. These applications differ mainly in terms of activation patterns and propulsions modes, which affect energy consumption, component wear, machine efficiency, and more. For instance, the parking lot application was the one featuring the longest run of the machine in vibration mode. This was not only the most energy consuming mode, due to the drums of the machine vibrating to ensure more effective compaction of the asphalt particles, but it was also the most demanding from a wear perspective. Ad-hoc state variables were added to the model to keep track of start-and-stop events in the usage phase, which were later used as proxy to calculate Mean Time Between Maintenance (MBTM), Mean Time Between Failure (MTBF), and other service/maintenance related aspects.

Machine productivity (measured in square meters of compacted surface per hour) and availability (measured percentage of the time the machine was actively working in the scenario) are two examples of the output of the simulation that were used to calculate the TCO of each design configuration. This model was built on available information associated with energy and water consumption, logistic and transportation costs, labor costs, acquisition cost for the equipment, maintenance and repair costs, as well as disposal cost. This model was complemented by a revenue-based model, whose objective was to calculate the revenue-generation opportunity related to the use of the equipment for tasks not fully suitable for diesel-driven machines, such as during the night (due to noise requirements) or indoors (due to emission requirements). The revenue-based model was designed to map all positive cash flows for the customer of the asphalt compactor during a 10-year period. Noticeably, different machine configurations were characterized by different cash flows, due to their specific abilities to deliver productivity and availability in the scenarios.

The results of the monetary evaluation were cross-checked with the outcomes of a more qualitative assessment model. The latter aimed to raise awareness on the more intangible aspects of value creation related to the proposed design configurations—from noise to operator comfort—which were difficult to monetize in the monetary models. The results of both the quantitative and qualitative investigation were presented in the video wall of the MDDA to the representatives of Company A, for further evaluation and selection. By interacting with the multi-touch screen, the design team was invited to review benefits and drawbacks of each proposed design. This triggered a cross-disciplinary discussion on how the different design concepts were expected to react to changes in the input and boundary conditions of the different models used in the workflow. The analysis was iterated several times for the same set of design configurations, under different assumptions, to eventually point out a machine configuration for further investigation in the detailed design stage.

4.2. Testing and Verification with Industrial Practitioners

Five practitioners from Company A were invited to participate in an experimental session aimed at verifying the ability of the MDDA to leverage a common understanding of the design situation in a cross-functional team setting. The experiment was staged as an early design gate. It involved a team composed of five individuals from different disciplines and with different responsibilities, including product development, customer operations, marketing, and finance.

The experiment featured two main iterations, the first one lasting 45 min and the second one lasting for about 1 h. After introducing the MDDA functionalities, the team was initially asked to interact with the environment to identify the most valuable combination of battery technology, battery capacity, and electric motor type for the electric asphalt compactor, in a scenario where the machine was used to compact both potholes and sidewalks. Functional and geometrical requirements (e.g., power, weight, and volumes) represented main constraints in the exercise, limiting the opportunity to propose radically innovative architectures. Each design configuration generated at this stage was imported in a performance and cost model, which guided trade-off analysis and resolution. These models were used to calculate how long a battery charge would last under changing environmental conditions, as well as to forecast acquisition and lifecycle cost of each concept. This information was used by the team to select the range of values associated with the three dimensions presented above, selecting the compactor configuration that maximizes value added for the customer.

In the second iteration, the team was asked to refine their choice by introducing even more machine properties in the design of experiment, such as the size of the water tank and the length of the middle joint. The data generated from the DoE were later imported in the cost and revenue model to identify the most valuable design option. At this stage, it was also possible for the design team to modify some of the input data for the cost/value calculation (e.g., in terms of fuel cost), and to select alternative customer profiles.

Both sessions were video recorded and facilitated by the authors, who helped the team in moderating the discussion and in manipulating the modeling environment. The video recordings were later transcribed and analyzed, to measure the extent to which individuals from different functions and roles were able to negotiate the features of the PSS hardware in both sessions. The verbatim comments were codified into sub-themes, to highlight the extent to which the team was able to negotiate the features of a solution, showing rationale, origin, and connections between different sources of information.

Given the focus on the earliest stages of design, the analysis focused mainly on the first iteration of the experiment. The results displayed in Figure 6 show that the time spent discussing the feature of a new electrical machine was almost equally distributed among the design team members. A similar pattern was observed when analyzing the number of times people intervened during the experiment to analyze a need, discuss a product feature, or negotiate a constraint, indicating the successful use of the arena as boundary object [69].

In order to triangulate these initial findings, a follow-up session was organized at the end of the second iteration of the experiment to collect more qualitative feedback from the team of practitioners. The latter expressed a positive judgement towards utilizing the models and workflow featured in the MDDA to raise awareness about the long-term consequences of a design decision. Furthermore, they considered the physical setup of the arena to be ‘inviting’ when it comes to stimulating cross-functional discussion and negotiation during decision gates. They further pointed out the value of conducting quick what-if analysis in an early stage, mainly to explore the long-term, systemic consequences of hardware-based decisions on the higher-level dimensions of customer satisfaction. The opportunity to exploit the workflow presented in Figure 3 is believed to provide more robust solutions, that are less prone to rework in the detailed design phase.

5. Discussion

The results from the verification activities conducted so far, including quantitative experimentation and qualitative feedback from practitioners, provide partial confirmation of the initial hypothesis upon which the MDDA concept was developed. The model-based environment is acknowledged to be able to widen the horizon of the envisioned product alternatives when applied at the highest levels of the design process. In particular, the MDDA is recognized to take the existing state-of-the-art a step forward when it comes to aggregate information on customer, users, market, scenarios, resources, and materials, to foster a more systemic view when developing the PSS embryos. The practitioners agree that the MDDA is able to foster a working process where all the members of the cross-functional team—in a collaborative way—are able to identify a problematic situation and develop an actionable solution, supporting each other in negotiating a possible way forward. The MDDA is further acknowledged to leverage sustainability considerations in the early stage design. Engineers and designers feel more confident to introduce environmental and social sustainability aspects in trade-off analysis, mostly because the model-based approach allows quantification of the long-term consequences linked to sustainable vs. unsustainable behavior.

The ability of the MDDA to foster a process where the PSS design team is able to ‘learn’ about a design vs. to merely ‘verify’ it is highly dependent on the way uncertainty and ambiguities are dealt with in the early stages of the design process. The proposed model-based environment relies on external tools, such as MATLAB and the 3D CAD software, to provide trustable answers for decision-making. Conceptual design activities are dominated by uncertainties and unknowns, and the ability to understand limitations of used models is crucial. Due to their abstract nature, which becomes even more pronounced in a hybrid multi-model environment, it is important to inform decision-makers of the maturity and impact of models used in a specific decision situation. Both the verification activities and the feedback received during the course of the research point to Model Maturity Level (MML) [70] as a promising concept to deal with the uncertainty of the knowledge base in early PSS design. MML computes the distance between the current and ideal value of ‘maturity’ to be expected from a given model. This is displayed using a five-level scale, from low to high maturity. The notion of impact is further used to assess the degree to which such lack of maturity will impact the development process activity. The idea is to have a dimension that represents a spread of different modeling situations and contexts, where two different contexts might render the same model sufficient or insufficient. For instance, a high-impact level means that the aspect that is modeled is critical for the product, and thus the model needs to produce results with a high chance of certainty. Stakeholders are then advised to approach this decision situation with caution. Conversely, a low-impact level means that the potential impact is negligible and thus there is not a need for further scrutiny or to improve the quality of the model in relation to this topic.

Several technical challenges also emerged during the development of the MDDA, the main one being related to speed of execution. The results of the simulation models need to be communicated to the design team almost instantaneously to trigger discussions and reflections. However, in most cases, this was not attainable, and this was found to negatively impact knowledge sharing in the team. The discussion with the industrial partners pinpointed an issue with the lack of a “real-time experience” when playing with the model-based environment. This was not only to be attributed to an issue of pure computing power, but rather to the need of developing efficient schemes to produce, manage, and visualize data with a sufficiently fast pace. A way forward is that of creating surrogate models to reduce execution time when working with computationally heavy simulations, such as stress and deformation analysis. Another issue is the lack of flexibility of the current prototype. Interlinking models is a labor-intensive activity that requires specific skills and expert knowledge. The development of a standard approach in model communication is of foremost importance to seamlessly exchange inputs-outputs between models and make the approach successful.

6. Materials and Methods

The development of the MDDA concept was driven by the Design Research Methodology (DRM) framework [71] and further based on a multiple case study approach [72]. After the initial Research Clarification (RC) stage, the work shortlisted four cases studies, from which empirical data were gathered during Descriptive Study I (DS-I), and for which ad-hoc demonstrators were proposed and verified during the Prescriptive Study (PS) and Descriptive Study II (DS-II) stages (Figure 7).

The cases originated from different industrial sectors—following a logic of ‘literal replication’ [73]—but shared many similarities. The first case was conducted in collaboration with a multinational engineering manufacturer of mobile compactors for road surfaces (Company A). The second one involved a world-leading total-solution provider in the construction sector (Company B). The third case involved a multinational company in the food packaging sector (Company C), while Company D—a design-make supplier to major aero-engine manufacturers—provided the fourth case. An important aspect in case study selection was that all companies were active in the business-to-business sector and were familiar with the notion of PSS as part of their portfolio. Furthermore, they were all influenced in their day-to-day engineering work by the same macro-trends, such as digitalization, connectivity, artificial intelligence, and sustainability. Last but not least, they had long been working with cross-functional teams to design product-service bundles and had grown lessons learned on the need to facilitate a participatory process in the design.

Semi-structured interviews were used throughout the four studies as the main data collection method. The sample covered a variety of roles, both at managerial and engineering level. The main aspect of interest in the interviews was to understand current motivators, enablers, and hindrances for collaborative decision-making (e.g., involving expertise for marketing, engineering, aftermarket, service solutions) in the organization today. In line with what suggested by Ritchie et al. [45] for small-scale, in-depth studies, respondents were located by means of non-probability sampling, i.e., they were selected “with a purpose”. In this case, experience with modeling and simulation and with design decision gate meetings were considered the main criteria for purposive selection.

All interviews were audio-recorded, transcribed, validated by the respondents, and later analyzed on the basis of some of the coding schemes proposed by Miles et al. [74]. The analysis of internal company documentation and regular debriefing activities (bi-weekly virtual meetings) served as a triangulation method. Individual reports were produced for all cases, and cross-company conclusions were drawn by conducting co-located workshops with process owners and other practitioners from all four manufacturers. In these workshops, the authors compiled visual representations of the emerging modeling concepts, which were verified to identify critical topics for modeling. In the prescriptive study phase, ad-hoc demonstrators were developed, emerging from a common conceptual and technological platform. These demonstrators featured the same model-based approach and were customized for the specific system being studied. Co-located demonstration and experimentation sessions with practitioners, stakeholders, and process owners further aimed at verifying the feasibility and applicability of the proposed process and technological enablers in the Descriptive Study II phase. The lessons learned from these activities were collected and fed back to the initial stages of the DRM process. Co-located research workshops provided an additional opportunity to iterate models, to verify the demonstrators with a broader set of industrial practitioners, and to jointly elaborate on the main areas of improvement for the MDDA.

7. Conclusions

This paper presents initial findings related to the development of a model-driven environment for collaborative decision-making in early engineering design, named Model-Driven Decision Arena. The main motivation for its development shall be found in the new way of working triggered by the transition towards Product-Service Systems, which requires the design team to tap into new, original knowledge to guide the development of innovative solutions (in contrast to mere products). The paper described the development of the arena concept, its working mode, and proposed functionalities. These were exemplified in a case study in the road construction sector, which provided the basis for testing some of the initial assumptions related to development of such an environment. Noticeably, the MDDA was found to support the design team in negotiating and converging on the most appropriate quantification strategy for the sustainability concept. In turn, this was found to mitigate the risk of discussing sustainability requirements exclusively in design, without a clear understanding of how “sustainability compliance” (both at environmental and social level) was expected to impact the technical specifications and cost dimension of the PSS. The MDDA was observed to help the design team in treating “sustainability” at a level comparable with other design parameters, providing a more complete picture of the overall value of a solution—which is a main proxy for market success and profitability.

Importantly, the main ability of the MDDA is not only to facilitate decision-makers in exploring the design space using models, but also to support negotiation in the cross-functional team, to facilitate the sharing of tacit, contextual knowledge about the product/service being designed. Due to the complex nature of design problems, combined with the vast amount of data generated in the proposed exploration scheme, data analysis and visualization are key success factors in realizing the proposed DSS. The emerging research field of visual analytics intersects with the MDDA and will be the subject of further research, mainly with regards to how to display the modeling results to facilitate negotiation in a multi-stakeholder decision scenario.

Future research work will also focus on issues related to validating both the physical environment and the proposed decision-making process. A major activity concerns testing decision scenarios in the proposed environment with practitioners. Efforts will also be put into further standardizing model interfaces and simulation procedures to attain a versatile environment able to encompass new scenarios and design problems with limited efforts. Another recognized challenge in operating the MDDA is how to populate models in the early stages of engineering design due to the lack of trustworthy data. This might be mitigated by advances in data mining and related research fields. An identified hindrance in developing the MDDA is the general lack of interoperability of simulation software. Today, this integration is realized through in-house developed code, and future work will be dedicated to the introduction of a more standardized approach based on an object-oriented paradigm.