1 Introduction

The products of mechanical engineering and related industrial sectors, such as the automobile industry, are often based on the close interaction of mechanics, electronics and software engineering, which is aptly expressed by the term mechatronics. The conceivable development of communication and information technology opens up more and more fascinating perspectives, which move far beyond current standards of mechatronics: mechatronic systems having an inherent partial intelligence. Therefore, we use the term “self-optimization”. Self-optimization enables mechanical engineering systems that have the ability to react autonomously and flexibly on changing operation conditions. The design of such systems is a challenge. In that case, established design methodologies of conventional mechanical engineering, e.g. the engineering design by Pahl/Beitz (Pahl et al. 2007), and also methodologies of mechatronics, e.g. the VDI-guideline 2206 “Design methodology for mechatronic systems” (VDI 2004), are no longer adequate to the task—especially in the early design phases of “planning and clarifying the task” and “conceptual design” which result in the so-called “principle solution”.

The principle solution determines the basic structure and the operation mode of the systems and, subsequently, it is the basis for further concretization. How to specify the principle solution has not been fixed for the field of mechatronics and self-optimizing systems by now. Within the Collaborative Research Centre (CRC) 614 “Self-Optimizing Systems and Structures in Mechanical Engineering” of the University of Paderborn, a set of specification techniquesFootnote 1 in order to describe the principle solution of self-optimizing systems has been worked out. By using this specification technique, the system that is to be developed will be described in a holistic domain-spanning way. In the beginning, this contribution defines the active paradigm of “self-optimization”. It continues on analyzing the challenges of the development of self-optimizing systems and points out the need for action according to further development of the specification technique in the early phases of the development process. The main focus will be on the explanation of the specification technique. Eventually, there will be demonstrated how the different specifications will be established during the conceptual design and which role they play within the following concretization.

All the works by the CRC 614 use the “Neue Bahntechnik Paderborn/RailCab” as a demonstrator. All examples throughout the contribution refer to that project. RailCab is an innovative railway system which is realized on a test track at a scale of 1:2.5. Autonomous vehicles (shuttles) that supply transport for both passengers and cargo, establish the core of the system (Fig. 1). They drive on demand and not by schedule. The shuttles act in a pro-active way, e.g. in order to reduce the required energy by forming convoys. The actuation is realized by a contact-free dual-feed electromagnetic linear drive (Zimmer and Schmidt 2005; Zimmer et al. 2005). The stator of the linear drive is situated between the track and the rotor within the shuttle. The three-phase winding in the stator forms a magnetic field which moves asynchronous along the tracks and propels the vehicle with it. By the magnetic dynamic effects between the stator and rotor magnetic fields’, the vehicle is accelerated and also slowed down. The dual feed allows variable adjustment of the vehicle’s magnetic field. Consequently, several shuttles can be operated on the same stator section with different velocities. The linear drive allows power to be supplied to the vehicle without overhead lines or contact rails. The supporting and guiding of the shuttle take place by using wheel/track contact that allows the usage of already existing railway tracks. With an active tracking module, based on an independent axle chassis with loose wheels, the choice of direction by passing over a switch can now take place vehicle-sided. In that case, the switches work in a passive way, in contrast to the conventional rail. An active spring technology with an additional tilt technology results in a high travelling comfort. The shuttle’s basic technology is placed in the plain-built undercarriage on which the chassis for passengers or cargo will be set upon.

Fig. 1
figure 1

Shuttles of the project “Neue Bahntechnik Paderborn/RailCab”

Full size image

2 Self-optimization

In this contribution, all the regarded future intelligent systems of mechanical engineering rely on mechatronics. The CRC 614 took up the hierarchical structure of complex mechatronic systems suggested by Lückel and added the aspect of self-optimization (Fig. 2) (Lückel et al. 2001). The basis consists of so-called mechatronic function modules (MFM) that comprise a mechanical basic structure, sensors, actors and a local information processing, which contains the controller. MFMs that are connected by information technology and/or mechanical elements result in autonomous mechatronic systems (AMS). They also feature information processing. Within this information processing, superior tasks are being realized, such as monitoring, fault diagnosis and maintenance decisions. Additionally targets for the local information processing of the MFM are being generated. AMS form the so-called networked mechatronic systems (NMS). NMS are produced just by connecting the AMS parts via information processing. Similar to the AMS, the information processing of the NMS is realizing superior tasks. If the terms are to be transferred in the vehicle engineering, the spring and tilt module would be considered to be a MFM, the shuttle itself with an active chassis an AMS and a convoy a NMS.

Fig. 2
figure 2

Structure of a complex mechatronic system with inherent partial intelligence

Full size image

In this structure it is possible, on every level, to complement the controller by the functionality of self-optimization. By this, the regarded system’s elements (MFM, AMS, NMS) gain inherent partial intelligence. The behavior of the whole system is formed by the communication and cooperation of the intelligent system’s elements. From an information processing point of view we consider these distributed systems to be multi-agent-systems.

Against this backdrop, we understand a system’s self-optimization as endogenous adaptation on changing operating conditions, as well as a resulting target-oriented adaptation of the parameters and, if necessary, of the structure and therefore the behavior of the system (Frank et al. 2004). Regarding this, the self-optimization process goes far beyond conventional control and adaptation strategies. Self-optimization indeed enables systems that have inherent “intelligence”. They have the ability of acting and also reacting autonomously and flexibly on changing operating conditions.

The key aspects and the mode of operation of a self-optimizing system are depicted in Fig. 3. Using the influences as a basis, the self-optimizing system determines the internal objectives that have to be pursued actively. These internal objectives are based on external ones, whereas those are set from the outside, e.g. by the user or other systems, and also on inherent objectives that reflect the design purpose of the system. Inherent objectives of a driving module can be for example: saving of the driving functions and a high efficiency. If we below talk about objectives, we refer to the internal ones, because those are part of the optimization. Low energy demand, high travelling comfort and low noise emission belong to internal objectives of a shuttle. The adaptation of objectives means, for instance, that the relative weighting of the objectives is modified, new objectives are added or existing objectives are discarded and no longer pursued.

Fig. 3
figure 3

Aspects of a self-optimizing system—influences on the system result in an adaptation of the objectives and an according adaptation of the system’s behavior

Full size image

Thus, the adaptation of the objectives leads to an adaptation of the system’s behavior. The behavior’s adaptation is achieved by an adaptation of the parameters and, if necessary, of the structure itself. An adaptation of the parameters means an adaptation of the system’s parameters, e.g. the adaptation of a controller parameter.

Adapting the structure, concerns the arrangement and relations of the system’s elements. We differentiate between reconfiguration and compositional adaptation. It is reconfiguration, if the relations of a fixed quantity of elements are changed. Compositional adaptation means the integration of new elements in the already existing structure or the subtraction of elements from the structure. Self-optimization takes place as a process that consists of the three following actions, called the self-optimization process:

  1. 1.

    Analyzing the current situation: the regarded current situation includes the current state of the system as well as all observations of the environment that have been carried out. Observations can also be made indirectly by communication with other systems. Furthermore, a system’s state contains possible previous observations that are saved. One basic aspect of this first step is the analysis of the fulfillment of the objectives.

  2. 2.

    Determining the system’s objectives: the system’s objectives can be extracted from choice, adjustment and generation. By choice we understand the selection of one alternative out of predetermined, discrete, finite quantity of possible objectives; whereas the adjustment of objectives means the gradual modification of existing objectives, respectively of their relative weighting. We talk about generation, if new objectives are being created that are independent from the existing ones.

  3. 3.

    Adapting the system’s behavior: the changed system of objectives demands an adaptation of the behavior of the system. As mentioned before this can be realized by adapting the parameters and, if required, by adapting the structure of the system. This action finally closes the loop of the self-optimization by adapting the system’s behavior.

The self-optimizing process leads, according to changing influences, to a new state. Thus a state transition takes place. The self-optimizing process describes the system’s adaptive behavior. This can occur on every hierarchy level of a self-optimizing system shown in Fig. 2. The realization of complex, mechatronic systems with inherent partial intelligence requires an adequate concept of structure as well as architecture for the information processing. To make this possible, a new concept has been developed: Operator–Controller-Module (OCM) Frank et al. (2004). From an information processing point of view, it corresponds to an agent. Figure 4 shows its architecture. As a result, an OCM can be structured into three levels (Controller, Reflective operator and Cognitive operator) which will be examined closer in the ongoing text.

Fig. 4
figure 4

Architecture of the Operator–Controller-Module (OCM)

Full size image

  • The Controller level stands for the control loop with direct access to the technical system. As a matter of course the software at this level operates continuously under hard real-time conditions. The controller itself can be made up of a number of controller configurations with the possibility of switching between them. The changeover takes one step; necessary cross-fading mechanisms and the like are summarized, in turn, into one controlling element.

  • The Reflective operator supervises and regulates the controller. It does not access directly the actuators of the system but it modifies the controller by initiating parameter changes or changes of the structure. If changes of the structure do appear (e.g. as in reconfigurations), not just the controllers will be replaced but also corresponding control and signal flows will be switched within the controller itself. Combinations that consist of controllers, circuit elements and corresponding control or signal flows are described as controller-configurations. Figure 4 shows controller-configurations in the controller, exemplified by the blocks A, B and C. The controlling of the configurations, realized by a state machine, defines which state of the system uses which kind of configuration. It also determines under which circumstances it is necessary to switch between the configurations. The reflecting operator mostly works event-oriented. The close connection with the controller requires a mode of operation in the so-called hard real-time. The reflecting operator offers an interface (working as a conjunctional element to the cognitive level of the OCM) between the elements operating not in real-time or soft real-time and the controller. It filters the arriving signals and takes them to the levels underneath. Moreover, the reflecting operator is responsible for the real-time communication between the OCM, which together constitute a composed self-optimizing system.

  • The Cognitive operator is the highest level of the OCM-architecture. Here the system uses knowledge on itself as well as on its environment in order to improve its own behavior by using varied methods (such as learning methods and model-based optimization). The main emphasis is put on the cognitive abilities for carrying out of the self-optimizing process. Model-based processes allow a predictable optimization that is, to a large extent, decoupled from the underlying levels while the system is in operation.

Based on the OCM-architecture, the actions of the self-optimizing process [(1) analyzing the current situation, (2) determining the system’s objectives and (3) adapting the system’s behavior)] can be realized in various ways. When the self-optimizing adaptation needs to fulfill real-time requirements all three actions are carried out in the reflective operator. Systems that do not have to run the self-optimization in real time can use more elaborate methods, which are settled within the cognitive operator. In that case, the behavior’s adaptation is carried out indirectly, relayed by the reflective operator, which needs to synchronize the instructions of the behavior’s adaptation with the controller’s real-time course. In addition, there might occur mixtures within one single OCM. There are also hybrid forms that occur within a single OCM, when the two described forms of self-optimization take place simultaneously and asynchronously.

3 Challenges during the development of self-optimizing systems

A new and powerful paradigm, such as self-optimization, naturally calls for new development methods as well as development tools. There is the question, of how the design methodology of mechanical engineering needs to be fundamentally extended. The basic question especially affects the early phases: “Planning and clarifying the task” and “Conceptual design”. For these phases applies that the basic structure (formulation of the requirements, definition of the functions and searching for active principles for the realization of the tasks) is also valid for mechatronics and self-optimization (Pahl et al. 2007). By looking into this more deeply, it soon becomes clear that an extension of the design methodology is urgently necessary. This appears, for instance, in the use of solution patterns as well as in the necessity of modeling the environment, application scenarios and the system of objectives.

Developers usually fall back on standard solutions—in areas such as mechanics, electrical engineering as well as control engineering and software technology and, hence, in the conceptual design of self-optimizing systems. Thus the structuring of the solution patterns that have been used during the development process works as an important fundament for the further development of the system. The works of the CRC 614 show that, in particular, the construct “active principle” needs further development. The term “active principle”, deriving from the field of mechanical engineering, has been generalized in that way that it covers up the participating domains within the development of self-optimizing systems. We use “pattern” or “solution pattern” as a general term. A pattern describes a reoccurring problem and also the solution’s core of the problem (Alexander et al. 1977). Taking this as a starting point, it results in the classification shown in Fig. 5. We differentiate between solution patterns that rely on physical effects and between patterns exclusively serving the data processing. The design methodology of mechanical engineering describes the first group as active principles; they describe the principle solution for the realization of a function. The course of development concretizes active principles to material components and patterns of information processing to software components. The relations between active principles and components are of the type n:m; the characteristic depends on the basic method of embodiment design (differential construction method and integrated construction method). Within the integral construction, several active patterns are realized by one component; whereas in the differential construction several components fulfill one active pattern. This is exactly the same in the field of information processing. Basically, a definite modern mechanical engineering system consists of a construction structure that means an arrangement of shape-marked components within a space and their logic aggregation to assemblies and products, and a component structure that means the compound of software components.

Fig. 5
figure 5

Classification of solution patterns

Full size image

In the design methodology of mechanical engineering, the active structure forms the root of the principle solution. The active structure describes the action’s coherence of active principles—usually by having an interconnection of principles with material, energy and information flows. Both, the construction structure as well as the component structure derive from the active structure. We introduced the construct “system element” in order to model the active structure. In the course of concretization, system elements form an intermediate step between solution patterns on one side and shape-marked components or rather software components on the other side.

Next to well-established active principles, software patterns and active patterns of control engineering, we defined an additional active pattern of self-optimization (Schmidt 2006; Gausemeier et al. 2007c). They find their usage in the realization of the self-optimizing process. Such active patterns of self-optimization fulfill functions for the self-optimization, such as autonomous planning, cooperation, acting and learning. The active patterns’ spectrum comprises the whole self-optimizing process [(1) analyzing the current situation, (2) determining system’s objectives and (3) adapting the system’s behavior] or even just parts of the process. It is of fundamental importance that changeovers of the system’s state are initiated and supported by autonomous and intelligent behavior.

In the need for action on the way to a design methodology for the described systems, the main emphasis is on a holistic integrative specification of the principle solution. The gap between the list of requirements, which is more or less a rough specification of the total system and, hence, leaves much space for interpretation, and well-established specification techniques of the involved domains needs to be closed (compare Fig. 6). The lack of an early cross-domain specification of the entire system is the reason, why the engineers run in deep trouble when they have to integrate their results. The specification of the principle solution represents the basis for all the experts’ communication and cooperation in the course of the further concretization. During this concretization the different domains work in parallel.

Fig. 6
figure 6

Central challenge: a new specification technique for the description of the principle solution of a mechatronic, respectively, self-optimizing system

Full size image

In particular, the addressed specification technique has to fulfill the following requirements.

  1. 1.

    Holistic depiction of the principle solution: all product data of the system to be developed, describing the structure, the mode of action and the appropriate processes, have to be specified in a coherent way. Especially aspects like autonomy, pro-activity and reconfiguration have to be taken into account.

  2. 2.

    Intuitive graphical modelling: by using adequate semiotics, syntax and semantics the specification technique should encourage an intuitive work of domain-spanning teams.

  3. 3.

    Encouragement of the conceptual design: the specification technique has to encourage the particularities (levels of abstraction, decomposition, integration, use of solution patterns) of the conceptual design of the described systems.

  4. 4.

    Equality of the domains: the specification technique has to treat the involved domains as equal.

  5. 5.

    Mastering complexity: approved concepts for structuring like hierarchies and modularisation have to be encouraged by the specification technique.

  6. 6.

    Consistency: the results of the development phases, “Planning and clarifying the task” and “Conceptual design” have to be continuously described by the specification technique. Furthermore, it serves as a fundament for deducing of domain-specific concretization tasks (conception, development).

  7. 7.

    Extensibility: besides the domains mechanics, electrical engineering/electronics, control engineering and software engineering, other domains (e.g. micro electronics, optics, hydraulics, pneumatics, etc.) can be involved in the development of the described systems. It has to be possible to extend the specification technique by the characteristics of these domains.

4 State-of-the-art in research

In the following text, exclusive works are going to be characterized which lead to the direction of the desired specification technique. Many approaches take up the system’s idea. They model the system from an abstract level to a concrete one, which consists of elements and their relations to each other. The Axiomatic design by Suh, for example, is a theory for the development of various kinds of systems, e.g. mechanical engineering, software and mechatronic systems. The systems are specified by their system architecture, compound diagrams and flow diagrams (Suh 1998, 2004).

Main emphasis of Buur’s work is on the modeling of mechatronic systems by functions, in dependence of the system’s current state. According to him, an entire function specification consists of a description of the states and of the transition states of the system as well as of transformation functions and also purpose functions. Those transformation functions describe the converting and transferring of energy, material and information by the system. The so-called purpose functions make necessary effects available so that the system can carry out the required transformations. The active transformation and purpose functions are assigned to the current state (Buur 1989, 1990).

Within the BMBF-key project “iViP—integrated virtual product development”, a prototype has been realized, for the early phases of the product development, which supports Function-oriented design (FOD). This software consists of a modeler for the requirements, the functions and the component structure and of a constraint-manager (Krause 2002). This approach focuses on the view “shape” of mechatronic systems.

Albers’ approach “Element Model” is also shape-orientated (Albers et al. 2004; Albers and Mattiesen 2002). The idea behind the element model is that functions of technical systems result out of the interaction of working surface pairs and the following guiding principle structure. The modeling of the technical system takes place with working surfaces, limiting surfaces, working surface pairs, function contacts, guiding principle structures, carrying structures and remaining structures. In consideration of boundary conditions and the system’s environment, the shape of the system can be deduced from the depiction of the working surface pairs and the guiding principle structures.

Other approaches give the priority to the physical mode of action of a system. The Bond Graphs are one example for that (Thoma 1990; Schweiger and Meerkamm 2002). They depict energy and performance flows between the components (elements) of a system. General equations for performance, impulse and displacement are fundamental to the specification with Bond Graphs.

Block diagrams, deriving from the field of control engineering, are used to specify mechatronic systems. They portray the described system as a block and specify their input and output parameters (Föllinger 1994). The system transforms the input parameters into output parameters. The transformation can be concretized by mathematical models. The blocks are further described as transfer elements; their behavior is called: transfer behavior. Complex systems could be modelled by the assembly of easier blocks.

If the hardware of a mechatronic system is in the focus of description, e.g. very high speed integrated circuit hardware description language (VHDL)–analog and mixed signal extension (AMS) will be used (IEEE 2002, 2007). This is a hardware description language that is based on the 1987 as IEEE Standard 1076 standardized hardware description language VHDL. VHDL serves as specification of digital circuits. VHDL–AMS enhances VHDL by analog and mixed-analog-digital constructs for modeling analog procedures. Considering structure and behavior, VHDL–AMS specifies digital and mixed- analog- digital bridges on their formal and text-based level. The structure’s view describes the components of the system and their topological connections. In the behavior’s view, mixed-analog-digital procedures are modeled by concretizing the input and output behavior of the components.

Within the framework of the ESPRIT project: “Simulation in Europe Basic Research Working Group”, the object-based language Modelica has been developed. This language models physical heterogeneous systems. It is further developed and marketed by the Modelica Association. Modelica aims at unifying modeling languages, such as Dymola, VHDL–AMS and ObjectMath. The language supports the domain and tool spanning exchange of modeling data and the reuse of models themselves. The modeling with Modelica takes place on the component and equation level (Elmqvist et al. 1999; Otter and Elmqvist 2001; Mattsson and Elmqvist 1998).

Considering the software domain, statecharts are being used and extended (in the frame of Unified Modeling Language, UML) in order to model logic behavior of mechatronic systems. Statecharts describe states and state transitions and also the events causing a state transition (Drusinsky 2006).

Mechatronic UML is an extension of the UML for the purpose of the modeling of the software within self-optimizing systems (Giese et al. 2004). It provides the UML 2.0 by the means of the specification of continuous and real-time behavior, having regard to high safety requirements. The models, created by Mechatronic UML, form the basis for both, the verification of the system during the conceptual design and also for an automatic code generation.

A board of the Object management group (OMG) developed the Standard SysML. It is a further development of the UML 2.0 for the purpose of system engineering. SysML supports the ISO AP-233 data exchange format for tools of the system engineering. It is a semiformal, graphic language for the modeling, analysis and verification of systems. Furthermore, it implies an amount of diagrams that are used to describe the views: requirements, parameters, structure and behavior. In contrast to UML, SysML is able to portray physical flows and continuous functions as well as input and output parameters (SysML Partner 2004; Weilkiens 2006). By using SysML, technical systems can be described continuously from their requirements up to their conceptual design, whereas the focus strictly remains on the software technology. Moreover, behavior changes by parameter or structure adaptation cannot be displayed. Latest software products, such as Artisan Studio® by Artisan Software Tools Inc., already support the SysML Standard (http://www.artisansw.com).

Beyond that, there are works that pick up, combine and enhance already existing techniques. Schön, for example, specifies the behavior of mechatronic systems by combining bondgraphs and statecharts (Schön 2000, 2000a). He models the continuous time behavior of the technical elements of a system by using Bond Graphs. The event-oriented behavior of the IT-supported elements is specified by statecharts. The assistance system AssMePro supports the developers during the specification and simulation of the system to be developed.

Schemebuilder Mechatronics, developed at the University of Lancaster, is a tool for the development and simulation of concepts for mechatronic systems (Porter 1998, 1998). Starting from functions, concepts are gradually developed by accessing knowledge bases. Bond Graphs and block diagrams specify the system’s behavior. They serve as a basis for the modeling of the system in Matlab/Simulink.

Another tool for the integrative development of concepts is ModCoDe (Bludau and Welp 2001; Welp et al. 2001). The concepts are shown by active complexes. In order to describe the behavior, we make use of block diagrams, statecharts and bond graphs. They are the basis for the simulation of the system with Matlab/Simulink.

Other tools within this category are: the Mechasoft Modeller (MeSoMod) Zäh (2002, 2004), being developed within the project MECHASOFT, and the modeling and simulation tool 20-sim (Schweiger and Meerkamm 2002).

Within the industrial sector, first specifications of the assembly and the mode of operation of mechatronic systems take place in texts and schematic diagrams. Some companies already use the above mentioned techniques. Some producer of systems, having a high portion of electronics and software, orient themselves more and more by the paradigm of function-oriented design. The focus is on the system’s operation procedures and its communication structures. Some companies develop their own specification techniques and software tools. Bosch, for example, created an arrangement concept with CARTRONIC in order to rule and document complex control systems. It structures the functional components of the control systems within a vehicle and specifies their physical intersection points. During the analyzing phase, the system is concretized by the modular architectures (views): function, safety and electronics. All architectures are described by components and the communication relations between the components in structure diagrams. By changing over into the design phase, the CARTRONIC specifications are concretized with UML diagrams (Bertram et al. 2000; Hermsen et al. 2001; Kraft 2006). CARTRONIC is appropriate to describe control systems. Other domains of mechanical engineering are not to be considered.

The analysis of the current state of the art shows that there are a lot of approaches on specifying mechatronic systems. One part of the approaches focuses on kinematic, dynamic and controlling behavior. Other approaches give priority to communication relations, operating procedures of the system and state transitions. All of the analyzed approaches just fulfill a single part of the requirements on the addressed specification technique, stated in Sect. 3. This applies especially for the aspect of a holistic description of the principle solution. Furthermore, the analyzed approaches do not provide a widespread transition from the domain-spanning specification towards the domain-specific concretization. Table 1 shows in detail how far the analyzed approaches fulfill the requirements on a holistic domain-spanning specification technique. Summing up, the in Sect. 3 addressed need for action, concerning a specification technique for the description of the principle solution of mechatronic systems, is put in focus position.

Table 1 Evaluation of the state-of-the-art
Full size table

5 Specification of the principle solution

In the following, we present the specification technique for the description of the principle solution of a self-optimizing system, which has been developed within the CRC 614. It includes mechatronic systems. The specification technique is based on the research of Frank (2006), Gausemeier et al. (2001) and Kallmeyer (1998). Already at the beginning of the work, it became clear that a comprehensive description of the principle solution of a highly complex system needs to be divided into aspects. Those aspects are, according to Fig. 7: requirements, environment, system of objectives, application scenarios, functions, active structure, shape and behavior. The behavior consists of a whole group because there are different kinds of behavior, e.g. the logic behavior, the dynamic behavior of multi-body systems, the cooperative behavior of system components, etc. The mentioned aspects are mapped on computer by partial models. The principle solution consists of a coherent system of partial models because the aspects are in relationship with each other and ought to form a coherent system. It is necessary to work alternately on the aspects and the according partial models although there is a certain order.

Fig. 7
figure 7

Partial models for the domain-spanning description of the principle solution of self-optimizing systems

Full size image

The description of the environment, the application scenarios and requirement serve as the starting point. They are usually followed by the system of objectives, the function hierarchy and the active structure. The active structure represents the core of the principle solution in conventional mechanical engineering. The modeling of states and the state transitions and also the impacts on the active structure play a decisive role in the specification of a self-optimizing system. This kind of modeling takes place within the group of behavior models. There is an example given in Sect. 5.3. The following sections explain the partial models, the relationships between the partial models and the specific characteristic of the specification of self-optimizing systems.

5.1 Partial models

Environment

This model describes the environment of the system that has to be developed and its embedding into the environment. Relevant spheres of influence (such as weather, mechanical load, superior systems) and influences (such as thermal radiation, wind energy, information) will be identified. Disturbing influences on the system’s purpose will be marked as disturbance variables. Furthermore, the interplays between the influences will be examined. We consider a situation to be one consistent amount of collectively occurring influences, in which the system has to work properly. We mark influences that cause a state transition of the system as events. Catalogues, that imply spheres of influences and influences, support the creation of environment models. Figure 8 shows, in detail, the specification of the shuttle’s environment. The users and the cargo affect the driving behavior of a shuttle, e.g. by their weight. Influences of the environment, such as wind, snow, ice and leaves, affect both, the shuttle’s driving behavior as well as the state of the track sections and switches. Track set errors of track sections also influence the shuttle’s driving behavior as the abrasion of the shuttle itself. The example concretizes the amount of influences I 2 in the influence table (Fig. 8).

Fig. 8
figure 8

Modeling of the shuttle’s environment (cut-out)

Full size image

Application scenario

Application scenarios form first concretizations of the system. They concretize the system’s behavior in a special state and a special situation and furthermore, what kinds of events initiate a certain state transitions. Application scenarios characterize a problem, which needs to be solved in special cases, and also roughly describe the possible solution. One detail of the application scenario “optimizing the efficiency” is shown in Fig. 9.

Fig. 9
figure 9

Application scenario for the example “optimizing the efficiency” (Gausemeier et al. 2007b)

Full size image

Requirements

This aspect considers the computer-intern representation of the requirements. The list of requirements sets up its basis. It presents an organized collection of requirements that need to be fulfilled during the product development (such as overall size, performance data). There is a distinction between demands and wishes Pahl et al. (2007). Every requirement is verbally described and, if possible, concretized by attributes and their characteristics. There are checklists that assist the setting up of requirements, see for example Pahl et al. (2007), Roth (2000) and Ehrlenspiel (2003).

System of objectives

This aspect includes the representation of external, inherent and internal objectives and their connections (see Sect. 2). A cut-out of the system of objectives of the shuttle is shown in Fig. 10. The external and inherent objectives are represented as a hierarchical tree. The hierarchy relations are specified by logical relations with declarations of the hierarchy criterion “is part-objective of”. The potential internal objectives derive from the external and inherent objectives. The impact between the objectives will be expressed by an assisting influence matrix. The matrix shows if the objectives work in mutual support, if they influence each other negatively or if they are in a neutral relationship. The system is able to follow such systems simultaneously and without any problems, which work mutually and also those systems that have neutral relations. But if the systems influence each other in a negative way, this is an indication for the need of optimization. Instead of an influence matrix, graphs that model objectives and their interplays can be used.

Fig. 10
figure 10

The shuttle’s system of objectives (cut-out)

Full size image

Functions

This aspect concerns the hierarchical subdivision of the functionality. A function is the general and required coherence between input and output parameters, aiming at fulfilling a task. For the setting up of function hierarchies, there is a catalogue with functions which is based on Birkhofer (1980) and Langlotz (2000). This catalogue has been extended by the functions which especially describe self-optimization. Functions are realized by solution patterns and their concretizations. A subdivision into sub functions is taking place until useful solution patterns have been found for the functions.

Active structure

The active structure describes the system elements, their attributes as well as the relation of the system elements. It is the target to define the basic structure of a self-optimizing system, including all system configurations which can be thought ahead. Figure 11 visualizes a cut-out of a shuttle’s active structure. The active structure consists of system elements, such as drive and break modules, air gap adjustment, operating point control, tracking modules, spring- and tilt modules, energy management and their relations. Furthermore, incoming parameters are described, such as comfort, costs and time, which are external objectives of the user. The system is structured by logic groups in order to improve the necessary clearness. In this case, for example, the system elements of a driving module are combined. The system elements, which deal with the determination of system objectives of the self-optimization process, are marked by a slanting arrow (here: operating point control and air gap adjustment).

Fig. 11
figure 11

Active structure of a shuttle (cut-out)

Full size image

Shape

This aspect needs to be modeled because first definitions of the system’s shape have to be carried out already in the phase of the conceptual design. This especially concerns working surfaces, working places, surfaces and frames. The computer-aided modeling takes place by using 3D CAD systems.

Behavior

This group of partial models comprises several kinds of behavior. Basically, what is needed to be modeled are the system’s states with the connected operation processes and the state transitions with the adaptation processes. The adaptation processes represent the definite realization of the self-optimizing process. If there are several systems taking part in the self-optimizing process, the interplay of these systems needs to be described. Depending on the development task, more kinds of behavior, such as kinematics, dynamics or electro-magnetic compatibility of the system’s components need to be specified.

  • The partial model Behavior-States defines the states and state transitions of a system. All of the system’s states and state transitions, which can be thought ahead and thus, need to be considered, as well as the events initiating a state transition need to be described. Events can be characteristic influences on the system or already finished activities.

  • The partial model Behavior-Activities describes the mentioned operation processes, that take place in a system’s state, and the adaptation processes, which have the typical features of self-optimization. All in all, the processes are modeled by activities. Determine fulfillment of current objectives or select adequate parameters and configuration, etc. are examples of such activities. Figure 12 introduces a cut-out of the self-optimizing process of the application scenario “optimizing the efficiency”. The self-optimizing process is structured by logic groups in the analysis of the situation, the determination of objectives and the behavior adaptation. Within the analysis of the situation, the track data, the shuttle inputs (such as force, efficiency and safety) and information of the energy management module are being interrogated. Furthermore, a continuous determination of the degree of fulfillment of the current objectives takes place. The analysis of the situation happens in soft real time. Based on certain information, the air gap adjustment forms a new system of objectives within the determination of the objectives themselves. Right in the beginning of the behavior’s adaptation, the identification of the air gap’s course concerning the track section takes place. Out of that air gap’s course, useful parameters and accordingly configurations (for the self-optimizing air gap adjustment) are chosen in connection with the new system of objectives. Those parameters do not just find their use as an optimization result in the shuttle. Because they can be sent back to the shuttle’s according track section control, they will be reused for future shuttles when they pass over a track section.

    Fig. 12
    figure 12

    Behavior-Activities for the application scenario “optimizing the efficiency (cut-out)”

    Full size image

  • The partial model Behavior-Sequence describes the interaction of several system elements. The activities, being carried out during the interaction of the system elements, and the inter-changed information, are modeled by a chronological order.

5.2 Interrelations between the partial models

The partial models represent the different aspects of the principle solution of the self-optimizing system. Of high importance are the interrelations between the partial models which describe the coherence of the partial models. Those interrelations are built up between the constructs of the relating partial models. There are, for example, functions (construct of the partial model functions) that are realized by system elements (construct of the partial model active structure). These system elements perform activities (construct of the partial model behavior-activities), whereas the activities might result out of the functions of the partial model functions. There could also be the achieving of a certain temperature (construct influence of the partial model environment) as an event (construct of the partial model behavior-states) that causes the activation of a new state (construct of the partial model behavior-states) and other activities. Table 2 shows a couple of interrelations between the partial models. The interrelations are shown directed to the right, i.e. in the table’s left side there are the constructs which cause correlation, on the table’s right side there are the constructs affecting the connections. For example, in the third line in Table 2 a system element within the partial model active structure takes up a state in the partial model behavior- states. Optional interrelations are marked by (opt.). Taking the information in Table 2 as a basis, a so-called integration model is created, which complements all the already described partial models.

Table 2 Interrelations between the partial models (cut-out)
Full size table

5.3 Particularities within the specification of self-optimizing systems

Section 2 already pointed out that the self-optimizing process initiates a new state of the system. The system is transformed from one configuration into another. The partial model behavior-states displays all relevant states of the system. It also contains all the events initiating a state transition. The configuration of a system in a specific state is described by its active structure. That means, the active structure can be differently shaped in different states, for example, if different elements of the system (controllers, sensors) are being used for the execution of the self-optimizing process. A system’s behavior in a certain state is described by its operation process. Operation processes are for example the acquisition of information about the environment, the derivation of adequate control interactions, and the controlling itself. State transitions are realized by adaptation processes, i.e. by self-optimizing processes. The operation and adaptation processes are modeled in the partial model behavior-activities.

In order to describe the self-optimizing process, all of the three partial models need to be considered simultaneously (see Fig. 13). Every state of the partial models behavior-states is assigned to an operation process of the partial model behavior-activities, which is operating actively in that state. Moreover, every state is related to a configuration of the active structure, which also actively operates. One example: The state S5, the respective operation process and the configuration of the active structure are emphasized by light grey colored, logical groups. The operation process takes place in a periodic way.

Fig. 13
figure 13

Cooperation of the partial models active structure, behavior-states and behavior-activities in order to describe the self-optimization (simplified visualization of the principle)

Full size image

Now—when event E7 appears, an adaptation process is triggered. Therefore, the necessary system elements are activated. Both, the adaptation process and the configuration of system elements, are assigned to the event E7 (see medium grey background in Fig. 13). After performing the adaptation process, the system takes over the new state S6. A new operation process and a new configuration of system elements are activated. They are colored in a dark grey within Fig. 13. The adaptation process and the used system elements are no longer activated.

6 Conceptual design of the principle solution

The basic procedure in the conceptual design phase is divided into sub phases, see Fig. 14. In the following text those phases will be described into detail.

Fig. 14
figure 14

Process of conceptual design of self-optimizing systems

Full size image

Planning and clarifying the task

This process step identifies the design task and the resulting requirements on the system, which has to be developed, will be worked out in here. The results are the list of requirements, the environment model, the recommended product structure type and the design rules for this as well as the application scenarios.

Conceptual design on the system’s level

Based on previously determined requirements on the system, solution variants will be developed for each application scenario. The best ones will be chosen and consolidated to a principle solution on the system’s level. Afterwards, an analysis takes place which looks for contradictions within the principle solution of the system and which contradictions might be solved by self-optimization. We define self-optimizing concepts for such contradictions, which contain the three basic steps of self-optimization [(1) analyzing the current situation, (2) determining the system’s objectives and (3) adapting the system’s behavior)]. The principle solution of a self-optimizing system on the system’s level is the result of that phase.

Conceptual design on the module’s level

The principle solution on the system’s level describes the whole system. It is necessary to have a closer look at the solution, in order to give a statement on the technical and economical realization of the principle solution. For that purpose, the system is modularized and a principle solution for each single module will be developed. The procedure corresponds to the conceptual design on the system’s level, starting out with planning and clarifying the task. This phase’s result is presented by the principle solutions on the module’s level.

Integration of the concept

The module’s principle solutions will be integrated into a detailed principle solution of the whole system. There is an analysis in order to find contradictions within the principle solutions of the modules. Again it will be checked if these contradictions can be solved by self-optimization. Concluding, a technical–economical evaluation of the solution is taking place. The result of that phase is a principle solution of the whole system that serves as a starting point for the subsequent concretization. This concretization is carried out parallel in the specific domains (mechanical engineering, electrical engineering, control engineering and software engineering). Section 7 gives further information on this.

On the basis of an example, the phases planning and clarifying the task as well as conceptual design on the system’s level will be described into detail. There will not be any further consideration of the conceptual design on the module’s level because it operates by analogy with the conceptual design on the system’s level. The integration of the concept has also been explained and is not being discussed anymore.

In the phase “planning and clarifying the task” (Fig. 15), the task is being abstracted in the first step (analyzing the task) and the core of the development task is identified. This is followed by an analysis of the environment which investigates the most important boundary conditions and influences on the system. The external objectives emerge next to disturbances. Beyond that, there are formed consistent combinations of influences which are called situations. By the combination of characteristic situations with system states, application scenarios occur that describe a part of the whole functionality of the system, which has to be developed. By using the structuring procedure by Steffen it is possible to identify an adequate product structure type for the system (Steffen 2007). The results of the first phase are documented by demands and wishes within the list of requirements.

Fig. 15
figure 15

Conceptual design phase “planning and clarifying the task”

Full size image

In the phase “conceptual design on the system’s level” (Fig. 16), the main functions are developed out of the requirements and set into a function hierarchy. Then, a solution will be developed for every single application scenario. The function hierarchy needs to be modified according to the respective application scenario, i.e. irrelevant functions will be removed and specific sub-functions will be added. Afterwards, there will be a search for the solution patterns in order to realize the documented functions of the function hierarchy, which will be inserted into a morphologic box. In many times, there are already existing, well-established solutions which we call solution elements. If there are such solution elements, they will be chosen instead of the abstract solution patterns. The searching for solution patterns is supported by a solution pattern catalogue. We use the consistency analysis in order to determine useful combinations of solution patterns of the morphologic box (Köckerling 2004). As a result, there will be consistent bunches of solution patterns, with a solution pattern for each function.

Fig. 16
figure 16

Conceptual design phase “conceptual design on system’s level”

Full size image

The consistent bunches of solution patterns form the basis for the active structure, which has to be developed. In this step, the concretization of the solution patterns to system elements takes place as well. Based on the active structure, an initial construction structure can be developed because there are primal details on the shape within the system elements. In addition, the system’s behavior is roughly modeled in this step. Basically, this concerns the activities, states and state transitions of the system as well as the communication and cooperation with other systems and subsystems. The analysis of the system’s behavior produces an imagination of the optimizing processes, running within the system. Eventually, the external, inherent and internal objectives can be defined.

The solutions for the application scenarios need to be combined. It is important that there are created workable configurations which, actually, make a reconfiguration of the system possible. Keeping this information in mind, it needs to identify if there is a containing potential of self-optimization at all. There is a potential for self-optimization if the changing influences on the system require modifications of the pursued objectives and the system therefore needs to adjust its behavior. In case there is potential for self-optimization, the function hierarchy needs to be complemented by self-optimizing functions. In particular, solution patterns of self-optimization are applied to enable self-optimizing behavior (Schmidt 2006; Gausemeier et al. 2007b). The resulting changes and extensions of system structure and system behavior need to be included appropriately.

In preparation of the self-optimization concept, the self-optimization processes will be eventually defined, the freedom of conflict of the self-optimization process will be analyzed and the boundary conditions, in which the self-optimization has to be working in, will be defined as well.

The presented procedure is not to be considered as a stringent result of single processing steps but it is marked off by numerous iterations which are not shown in the figure. The amount and order of the iterations is depending on the object’s design, organizational boundary conditions and the developer’s individual behavior as well as on the specific use of methods. During the processing, the content of the principle solution is gradually developed and specified until there is a final, specified principle solution in the end of the design.

7 The role of the principle solution during the concretization

The principle solution forms the concretization’s basis. The term “concretization” describes thereby the domain-specific design, based on the principle solution, of a technical system. The aim of the concretization is the definite and complete description of the system by using the construction structure and the component structure of the software. In order to develop such structures, the principle solution is divided up into modules, in consideration of system relevant aspects. Especially for self-optimizing systems, the already mentioned structuring procedure by Steffen is useful for advanced mechatronic systems Steffen (2007). It respects the characteristics and relations of the system’s elements as well as the reconfiguration processes in order to adapt the system’s behavior. The result of the process is a development-oriented structure of the product. It assorts the system’s elements by their different relation aspects into modules and integrates the two basic and mostly contradictious views of a shape- and function-oriented structure of the product. The process of concretization is planned by the structure of the product. According to the hierarchy of self-optimizing systems presented in Sect. 2, the identified modules are assorted to the different levels. The modules on the NMS- and AMS level mostly consist of information processing components, whereas the modules on MFM-level primarily consist of shaped components.

The module’s concretization runs in a parallel way in the participating domains (Fig. 17). An example: the concretization of the module air gap adjustment has four participating domains. These domains make use of well-established methods: mechanics/mechanical engineering, e.g. (Pahl et al. 2007), electronics, e.g. (Bleck et al. 1996), control engineering, e.g. (Föllinger 1994) and software engineering, e.g. (Sommerville 2006). The simplified design processes in Fig. 17 are described by the process specification technique OMEGA (Gausemeier et al. 1999). Usually, the design activities in the single domains need to be co-ordinated beyond the domain’s limits. This is shown by the upright lines.

Fig. 17
figure 17

Concretization of a self-optimizing system

Full size image

An example: if a controller is set up, the dynamic kinetic behavior of the mechanical basic system as well as the transmission time of the signals need to be properly considered to determine the maximum allowed transient oscillation time (compare process steps “PS 3.1-7”, “PS 3.1-8” and “PS 3.1-9” in Fig. 17). The design structure matrix (DSM) by Eppinger (Ulrich and Eppinger 1995) helps to identify the dependencies between the different process steps. By using the DSM, sequential, parallel as well as coupled and coordinating process steps can be determined. Finally, the interfaces with other domains will be identified. The totality of the information offers a complete description of a domain-specific development task.

Furthermore, the information, based in the principle solution, serves as a fundament for deducing of domain-specific concretization tasks. In a first step, the system elements of a domain and their relations within the active structure will be identified. After that will be analyzed what kind of domain-specific functions are fulfilled by the system elements, which requirements they have to comply and which behavior is appropriate in certain situations. Following this, it will be checked if domain-specific requirements need to be added. In case of a software engineering, the necessary software components of the component structure, including the input- and output parameters, can be deduced by the system elements of the active structure (Fig. 18). In turn, it can be checked if the concretized component structure is appropriate to the system elements and their information processing relations (Gausemeier et al. 2007a).

Fig. 18
figure 18

Deriving of domain-specific information of the principle solution in order to develop software (Gausemeier et al. 2007a)

Full size image

In case of changes occur during the domain-specific concretization, which affect the system’s operation mode, those changes have to be transferred back into the principle solution. This happens for example if there will be identified additional internal objectives during the course of concretization of a self-optimization process (in the frame of the determination of objectives). The aim is to keep the principle solution and also the domain-specific models consistently.

8 Résumé

The paradigm of self-optimization will enable fascinating perspectives for the future development of mechanical engineering systems. These systems rely on the close interaction of mechanics, electrical engineering/electronics, control engineering and software engineering, which is aptly expressed by the term mechatronics. At present there is no established methodology for the conceptual design of mechatronic systems, even less for self-optimizing systems. Concerning the conceptual design of such systems, the main challenge consists in the specification of a domain-spanning principle solution, which describes the basic construction as well as the mode of operation in a domain-spanning way. The presented specification technique offers the possibility to create a principle solution for advanced mechatronic systems, with regard to self-optimizing aspects, such as “application scenarios” and “system of objectives”. Simultaneously it outperforms classic specification techniques by appropriately encouraging the conceptual design process. It is fundamental to the communication and cooperation of the participating specialists and enables them to avoid design mistakes, which base on misunderstandings between them. It has been described in what way the according concretization, which takes place parallel to the participating domains, is going to be structured and coordinated on the basis of the principle solution. The practicability of the specification technique and the appropriate methodology was demonstrated by the example of a complex railway vehicle.