Technical systems are often classified according to their functions, which enable designers’
to address the constructional part structures of products more easily. A function or a combination of functions is designed to fulfil the purposeful mode of action, transforming the operand state (Hubka & Eder 1988).
Here, the purposeful behaviour of a product, function, is defined to include all necessary and relevant functions that fulfil a user’s need with regard to the transformation process.
Function in this context has a meaning in two dimensions; primarily it defines the realization of a transformation process by means of properties, but it also defines how the state change of the operand is performed and meets the user values.
The evolution and development of technology has enabled the wide utilization of programmable control systems. However, the historically strong distinction between professional disciplines has been a hindrance to true multi-disciplinary product development. Despite many exercises with multi-disciplinary teams, the consequence has been more a layered or modularized technology architecture with products.
Modern machines consist of multiple systems that interact and impact with each other.
Function cannot be considered only to be delivered by the mechanical structure, because the control system plays a key role in how function is realized in bringing together product performance, and external and internal effects. The function of a technical system is strongly dependent on the integrations between technological disciplines. Consequently, function cannot be improved by changes within only one technological discipline.
Lehman (1985) presented the basic signal flow functions in micro-electronics. Regardless that this operational schema was suggested for use with modular elements in functional structure, it may also be acknowledged as illustrating the interface and interactions between the user and the technical system. Today, the operation principle of multi-
91 disciplinary products with programmable logics may be presented in a similar way [Figure 8.1].
Figure 8.1 Basic signal flow functions used in micro-electronics. Control unit processes the information and defines the further mode of action. Adopted from Lehman (1985).
An important finding for product developers in this schema is that functions do not directly interact with the user, mechanism and environment because there is always a control unit which processes in a pre-determined way the operating commands and detects status information before activation and indication. However, the common approach of discipline-oriented product developers is to consider that the “Activate” sequence strictly follows the “Operate” command and that such function is the result of the mechanism according to the defined product requirements and specification.
The predecessors of the modern Programmable Logic Controllers (PLC) were capable of replacing hard-wired connections and relays while performing the function or mode changes in technical systems. Consequently controllers enable automatic sequences and conditional jumps, by giving the advance of autonomous operation of repetitive tasks and reducing the need for manual work by decoupling one task and dedicated resource. Today, the controllers are more like computers and capable of performing more complex calculations, functions and tasks through structured languages, state diagrams and analogue or digital I/Os.
Although machine controls have become more versatile and complex, product development can no more solely rely on conventional methods followed by functional decomposition and structure. Specifically within incremental development, the approach is focused more on understanding about the impacts and consequences of some function through the execution chain used.
The challenge with any development activity is still cross-disciplinary communication and understanding how to enable opportunities for technology integration.
A product’s function, which is physically and visually identified, is the result of a multi- disciplinary impact chain within the product. The function execution event activity of a PLC controlled machine may be described by a scheme, where the user impact is interpreted by the control system, forwarded to the power train system and finally to the mechanical part structure delivering the purposeful behaviour [Figure 8.2].
92
Figure 8.2 Product function is the result of the functional execution chain through different disciplines, which will be identified as system behaviour.
For a product developer, it is essential to understand that function is the result of intertwined events occurring in a technical system. Hence, it is clear that even if the different disciplines are separated, they still impact upon each other. The weak point of generic product development methods is how to model and manage the existence of this event chain and its interactions, as well as enable communication between specialists to cope with sub-systems design.
A typical industrial design process is separated into professional disciplines at early stages after the specification is defined. This may be a result of functional organizations, product specifications or unmanaged distributed design activities. The separation of professional disciplines leads to a situation where the functional requirements and characteristics of a product are mainly defined by the mechanical system. A project manager or mechanical chief engineer manages the system co-ordination. However, depending on the complexity of the system, the level of detail, which results in the behaviour of a system, cannot be adequately controlled.
Product development is typically managed as a project where the purpose is to create a product defined by a product specification. The product specification interprets customer requirements into the language of engineering i.e. functional requirements and properties.
The presentation of requirements and properties may come in various formats and is typically presented by descriptions, charts, verbal lists of characteristics and attributes (Pahl & Beitz 1996).
Concerns with regard to this general approach that uses specifications for multi- disciplinary development may be raised from the following viewpoints:
• The product specification, functional structure and description define the result and realization of the transformation process, but not the qualitative.
• The transformation process of a technical system is assumed to be ideal, where the function may consist of independent consecutive sub-functions.
• A division into sub-systems leads to partial optimization within each sub-system because interfaces are defined according to ideal transformation processes.
• Sub-systems are not independent of each other, they have interactions which may not be acknowledged in the specification or appear during the functional decomposition.
93 From the design point of view, system behaviour is the result of a much wider interaction of the product systems than just the properties and attributes within each sub-system.
During a transformation process, a technical system is in interaction with its user and environment, but this interaction is not expressed in development documents. However, it is the total system which defines how function is delivered. For this purpose, the definition of experienced behaviour is introduced.
8.2.1 Experienced behaviour
The definition of customer-experienced functionality has been introduced into software development to describe the properties of system functions apparent to the customer (Chapin et al. 2001). A similar type of approach may be used with technical systems to describe a qualitative viewpoint on transformation processes.
While the organ and parts structure focuses on what and with which kind of solutions the transformation process is realized, the experienced behaviour aims to capture how the function effects are delivered and what the activity chains involved are. Activity chains are consecutive events arising from function activation that allow the physical execution to transform an operand to the desired state. With the activity chain, the focus is on improving the understanding about the function and its consequences, specifically during the mode of action or status changes. Typically the status and mode changes introduce dissatisfying system behaviour, e.g. properties like delays, displacements and vibrations.
These phenomena are easily ignored during the conceptual design phase when assuming an ideal transformation process.
The principal hindrance with functional decomposition during conceptual design is its static nature while the function is dynamic. Consequently, due to the lack of a dynamic approach, the time entity, relative dimensions, inertias, action state and its changes are not adopted into the functional structure or any conceptual model. However, describing the function and its response may thus enable an approach to a problem by introducing the realized, wanted and unwanted properties. These properties may be used to identify which integrations in and between the systems interact in the activity chain.
The prerequisite for enabling the use of an experienced behaviour approach is the feedback of the product from the real operation on its environment. This information and experience have been partly utilized for product improvements. Typically methods like value or QFD analysis have been used, whereby product improvements can be based on identified parameters that influence on the selected properties. Alternatively, dynamic simulation tools provide an efficient method of analysis to improve dedicated properties, but require accurate physical and mathematical modelling. During the conceptual design phase, these methods are too concrete and do not support innovativeness or opportunity identification.
The quest in industry is to identify opportunities for improvements and developments in products. This stage of a product development process can be identified as conceptual design, and it occurs before any division into technological disciplines has taken place. A retrospective industrial case study is presented to describe how an incremental innovation led to the creation of a new solution providing a value improvement for the user and manufacturer. The case study is then used to further develop and introduce a new methodology for the incremental innovation process.
94