39 focusing on the creation of the technical system, the recognition of the task type influences how the work shall be managed. Consequently it should also offer advice, if the development process varies; e.g. can a similar type of systematic process be followed for all variations.
The complexity of the design task has been acknowledged with mechatronic engineering, whereby the implications of high integration become difficult to predict because of the lateral influences that dominate the hierarchical relationships [Figure 4.7] (Calvano &
Philip 2004).
Figure 4.7 The impact of lateral dominance in highly integrated system (B) compared with hierarchical dominance (A). The interactions in highly integrated system may be different kinds compared with a hierarchical system. Adopted and modified from Calvano & Philip (2004).
The interactions with a hierarchical structure are the result of functional decomposition and mainly present the physical relationship, which is also often constrained within one discipline. In a highly integrated structure, the physical interactions are complemented with a causal type of relationships over the hierarchical structural sections, or even between single elements in sections.
Similar conclusions with regard to unexpected interactions have been made with the development of multi-disciplinary products as the early separation into technological domains may become a hindrance to understand and estimate the impacts and connections of a highly integrated system (Reunanen 1993).
Industrial practitioners face the development problematic between static and dynamic concepts and mostly focus on their resources towards the incremental development of sub- systems within existing products (Pugh 1991). However, the methodology of this development process has not received great attention. Another aspect in industry is that, although originality in the concept and/or function is becoming more difficult to find, the pressure to use new technology applications is its natural consequence. However, even though multi or cross-disciplinary design teams have been acknowledged for a long time, it is recognized that each professional discipline still utilizes their own dedicated methodology to meet their own purposes and obligations during the design process.
40
Eppinger 2003, Pahl & Beitz 1996). When the design process continues from abstract structures towards more concrete ones, the separation into technological disciplines may take place.
Each discipline has a long tradition through distinct education systems and has developed their own methodologies to focus on specific design problems. Bernardi et al. (2004) presents a comparison of development processes and their sequences [Table 4.2].
Table 4.2 Product development guideline for different disciplines. Basic development process phases between disciplines Adopted from Bernardi et al. (2004).
The sequences with different disciplines cannot be compared as such; each of them has their own development history and dedication to their relevant design process stages. If we study the different approaches of each discipline and how the basis for the development is defined, it is significant that the functional aspect is drawn out only in mechanics.
Consequently, the specifications for electronics and software engineering follow or are adapted from the mechanics. However, as the functional execution is controlled by software in mechatronic systems, the development is parallel thus separate and integration takes place during testing or commissioning.
As such, it is apparent that each discipline relies on the specification and early break-down of requirements for each of them. The known consequence is that integration into a final product cannot be successfully completed at once, which leads to corrective iterations and/or modifications.
The decomposition of the functional structure is followed by the development of the solution principles, which in generic product development processes ignores the multi- disciplinary view focusing mainly on a product’s mechanical working principles. When the functional structure has been built, the development process, aiming to reduce complexity, splits the solutions into discipline dependent specifications and interfaces between disciplines [Figure 4.8].
41 Figure 4.8 Product entity as whole consisting of several disciplines (Disp. 1...n) before (A) and after (B) decomposition into discipline specific design specification and tasks during the development process.
The more developed design process models like the VDI 2206 (2004) for mechatronic systems, introduce the V-shaped process adopted from software engineering. The process suggests concurrent methodology during design phases and integration at three levels;
micro and macro cycles, and a process module. A cross domain solution concept is intended to describe the main physical and logical operating characteristics of the future product. As the design is divided into phases, the model emphasises the design validation and verification to be carried out in each design phase [Figure 4.9].
Figure 4.9 The basic principle of the mechatronic product design process.
Decomposition and validation according to the level of hierarchy. Adopted from VDI 2206 (2004).
The main difference with sequential and linear processes is the verification during the phases and not only at the end of the full system integration, which decreases the probability of integration problems. However, the challenge with this model is how to develop the right verifiable requirements for the different levels of systems and elements.
The links between the system, segment, element, sub-system and component level requirements may become an artificial hindrance to developers to cope with.
As a prerequisite for modern technical system engineering, professionals within different disciplines are taught to be more aware of other methodologies and realization means in the early stages of the design process. During the conceptual phase the crucial decisions on functions and properties are made, which are realized and integrated into the final product
42
resulting in the experienced behaviour. The management of this integration in industry is often given to the mechanical chief engineer, who is responsible for the whole technical content of the product.
The generic product development processes approach the technical system as a hierarchical entity. Within the functional structure, the different technological areas are acknowledged, but their role and effect is assumed to be on other sub-systems or on the lower level in the structure. In an architectural aspect, the different disciplines are divided into their own entities or modules, which in turn lead to further sub-optimization within the module boundaries and interfaces.
The functional structure creates the principles for the product architecture, as the functional elements are identified and positioned into the physical product’s structure. Once the separation into disciplines has taken place, it is a rather natural continuation that the physical structure is proposed in the form of blocks or modules involving the elements required for the function. This results in a set of assembled components within a greater entity, but having the nature of a single discipline.
As the disciplinary separation has taken place, all the following design activities are then consequences of earlier decisions. Each discipline follows the specification and pre- defined interfaces, naturally aiming for an optimized result. However, seldom is that any interaction or consensus exists between design teams, or is even encouraged by the engineering management. The general difficulty exists when a design problem calls for iteration because the borderlines separating the disciplines very effectively prevent communication, mainly because the iteration increases complexity and disturbance within the specification.
Product development processes have evolved and followed technology and social development, and during recent decades several systematic methodological approaches may be identified (Pahl & Beitz 1996):
• Need or problem oriented development, stepwise approach with continuous testing and balancing of contradictory requirements.
• Task division into subtasks and solution set reduction through evaluation, the introduction of abstract functions.
• Technical and economic criteria, function principles, problem definition towards solution variations, sub-functions, functions means, discipline integration.
• Problem formulation towards functional and embodiment phases, concurrent engineering.
• Integrated product development; multiple driver or stakeholder acknowledgement e.g. safety, reliability, environment, Design for X approaches.
The scope of systematic product development methodology has changed and expanded, but still a request for an improved methodology exists in industry; the speed of the technology development has increased and advanced solutions have become more and more attractive cost wise, which are taken into use when developing existing concepts and specifically multi-disciplinary products. As a general approach, the new development process shall be more focused on drivers such as product value elements and experienced behaviour in addition to functions and properties.
43 In conclusion, it is claimed that the primary causes which make the generic product development processes adaption linear and limit their application among industrial practitioners include:
• Development project management process strives to freeze the technical solution prior to actual development which leads to manage product architecture through the creation of physical single discipline blocks or modules.
• Professional disciplines and their development processes that aim to manage complexity by separating functional structures into different disciplines and defining interfaces between them. This directs design activities to partial optimization within the borderlines of each discipline.
• Development process approach aims to associate one-directional logic of requirements-specification-properties-characteristics whereby the purposeful behaviour is achieved later when physical integration of part structure is assembled.
This is in contradiction to the principal approaches to complex systems which consist of large numbers of parts that have many interactions, and in such systems the whole is more than the sum of parts (Simon 1996).
The implementation of several disciplines within one product concept is challenging and is followed by principal concerns on traditional product development processes.
The realization of functions is no longer only the result of mechanisms, the definitions and modelling of function structure, product architecture and organ structure as well as part structure has to be reconsidered.
In consequence, it is obvious that the creation of innovative solutions may need to be initiated in a different way.