Enhancing the effectiveness of design tools in synthetic environments
Summary
The use of Virtual Reality (VR) tools during product development processes has already been widely accepted for multiple decades in many industries. Especially in large enterprises, these VR tools are incorporated in custom-made Synthetic Environments (SEs), to provide support in dedicated product development activities. Often, these SEs are inflexible, require high investments and are applicable within limited bandwidths. For companies unfamiliar with SEs, (often SMEs), it is often unclear what the use of a SE can entail. Not only the result of use is hard to predict, also the consequences of implementation are vague. Therefore, more predictable, future-proof, robust, affordable and acceptable SEs are needed. Additionally, more insight in the effectiveness of a SE during product development processes can significantly improve the results of use.
During product development processes, it is of the utmost importance to make optimal use of the expertise of the different stakeholders involved. Efficient and effective communication and collaboration approaches are needed to facilitate these multi-disciplinary and multi-stakeholder development projects. Many design tools are available to support such approaches, all with their own advantages and drawbacks. Many of them aim to provide support in the decision-making process, allowing stakeholders to acquire insight in, and understanding of, the consequences of the decisions on the future product or service. More often than not, such tools have digital or virtual elements to allow for faster iteration and better simulation of the expected result.
A SE can be considered as an enabler for communication and collaboration in multi-disciplinary and multi-stakeholder development projects. To enhance the effectiveness of a SE, the selected (VR) design tools should be optimally integrated in a SE. This research describes the development and use of a support architecture that facilitates the gathering of requirements and preconditions for a SE, taking into account the perspectives of all stakeholders involved. The architecture provides multiple views on the same future targeted SE with different levels of aggregation. The architecture provides insight to make better predictions on the effectiveness of a (new) SE in specific product development phases. In this, the relations and interdependencies between different elements of the SE are more imperative than the selection of individual tools. The use of the architecture provides a better understanding of the consequences of changes and use of a SE, resulting in a more robust SE with a comprehensive flexibility. The threshold for use will become lower, resulting in an increased likelihood of usage, and higher appreciation of the SE.
Similarities are depicted between the preparation of a SE, and production preparation of a physical product. In process planning and factory layout planning, an enormous amount of knowledge is available to prepare and optimise the realisation of products. This knowledge can be used to increase the robustness of the SE, if the relations and interdependencies between individual elements that constitute the SE are known. The goal is to find alignment between the configuration of the used tools and technology and the selection of the functional specifications. Neither is leading in this process; both should be adjusted to one another until there is a purposeful match.
The involved stakeholders are positioned from three perspectives: strategic, tactical and operational. These perspectives are a way of perceiving, filtering, clustering or tagging information from a repository of requirements. Here, uncertainties and ambiguities arise or emerge by combining the perspectives. As such, the perspective ‘strategic’ yields a valid view, and the same applies for e.g. a view from the ‘operational’ perspective; however, this does not necessarily imply that both views conjointly represent a veracious view as well. To provide the stakeholders with an approach to gather and document their requirements to the SE, so-called blueprints are introduced. The blueprints provide a structure to categorise the information required in a SE, while simultaneously providing the stakeholders with a ‘backbone’, a ‘checklist’ and a ‘notebook’ to express any requirements. The blueprints are meant to stimulate all stakeholders to use the same terminology to document their requirements for a desired solution. The categorisation and the different perspectives contribute to the mutual understanding of each other’s insights and opinions.
An architecture for SEs is introduced as the interconnection of blueprints. The architecture allows to review different configuration possibilities to realise a SE. Each of the selected blueprints act as a section in the architecture. The convex hull around the blueprints acts as the common ground and communication layer. This convex hull can be defined as the ‘scouting space’ of the SE. This scouting space is the most rudimentary form of the architecture. This fundament will not change during use, and therefore acts as the basic layer of the SE. On top of this layer, additional overlays can be added to visualise and interpret connections between different elements. The scouting space accommodates the potential of the solution, requiring additional steps to actually instantiate a solution. Subsequently, a discussion space combines all requirements, representing the maximum design freedom for the SE under development. The discussion space forms the basis on which the SE can be developed, and defines the outer-boundaries for this development. This discussion space contains all the blueprints from the stakeholders involved; visualised as a graph. This base graph contains all information ensuing from the blueprints. From this discussion space, a more consolidated space emerges, which contains the minimum information that is necessary to proceed with the construction of the SE. This consolidated space is referred to as the solution space. The solution space is a converging evolvement of the discussion space. The solution space is a sub-graph of the base graph that forms the discussion space. This sub-graph does not aim for adding new elements; it rather aims to converge the space by making decisions. The sub-graph is a consolidated maturation of the base graph.
The combined blueprints, scouting space, discussion space and solution space together project the supporting architecture. This architecture allows for filtering of information to prevent information overloads. Such overloads can occur if similarities between different blueprints are searched, or if the impact of requirements on a specific viewpoint or element is communicated amongst stakeholders.
The use of the architecture is projected on different case studies executed in the past years in the VR-lab of the University of Twente, and is currently utilised in ongoing projects in the research of the department of Design, Production and Management (faculty of Engineering Technology). The case studies show a lot of variation in the stakeholders of a SE, with the direct consequence that the need for collaboration between these stakeholders is one of the main challenges in realising a SE. Furthermore, it became visible that without a supporting architecture many decisions are made based on tacit information; while the results or qualities of the decision are not questioned. The case studies demonstrated that stakeholders explicitly and willingly are interested in solutions that have previously been developed in comparable circumstances or addressed similar aspects of development cycles, but this was considered challenging because the lack of (structured) documentation on the rationale of a SE.
The genericness of the architecture is assessed by reviewing different approaches of common characteristics that emerge in the development of SEs in the different case studies. The case studies substantiated that there is a benefit of not incorporating specific processes or process descriptions in the SE architecture, since this allows for perspective-driven interpretations of support, and therefore can influence the acceptance of it. The resulting architecture is generic; it will steer the process as little as possible, but offers the stakeholders more insight in, and grip on, the most influential characteristics of a SE development process. It supports realising an overview by facilitating a structure, while providing more insight in the complexity of the process. This also helps the stakeholder to learn from previous projects, and to reuse elements from it. Furthermore, it creates stakeholder awareness as concerns the different perspectives and levels of aggregation of the other stakeholders involved, and indicates the necessity of making tacit information explicit. Eventually, this will lead to a more predictable situation, which is flexible in the use, but at the same time robust.
One the key characteristics of the proposed architecture, and one that distinguishes it from the innumerable other available approaches, is the ability to allow each stakeholder to use the shared information repository on different levels of aggregation at the same time. There is no predetermined level of aggregation in this approach, and stakeholders are even allowed to change their level during use. The architecture can always be extended with new theoretical and practical knowledge on techniques, tools, and working methods. The architecture remains flexible, yet structured, predictable and transparent. Multiple researchers can use the tool for various projects, simultaneously complementing the architecture with best practices.
