*Article* **Digital Development Process for the Drive System of a Balanced Two-Wheel Scooter**

**Kevin Holder 1,\*, Sven Schumacher <sup>2</sup> , Matthias Friedrich <sup>3</sup> , Markus Till <sup>2</sup> , Ralf Stetter <sup>2</sup> , Walter Fichter <sup>3</sup> and Stephan Rudolph <sup>4</sup>**


**Abstract:** Graph-based design languages have received increasing attention in the research community, because they offer a promising approach to address several major issues in engineering, e.g., the frequent manual data transfer between computer-aided design (CAD) and computer-aided engineering (CAE) systems. Currently, these issues prevent the realization of machine executable digital design processes of complex systems such as vehicles. Promising scenarios for urban transportation include an interconnection of mass transportation systems such as buses and subways with individual vehicles for the so-called "last mile" transport. For several reasons, these vehicles should be as small and light as possible. A considerable reduction in weight and size can be achieved, if such vehicles are tailored to the individual size, weight and proportion of the individual user. However, tailoring vehicles for the individual characteristics of each user go beyond a simple building set and require a continuous digital design process. Consequently, the topic of this paper is a digital design process of a self-balanced scooter, which can be used as an individual last-mile means of transport. This process is based on graph-based design languages, because in these languages, a digital system model is generated, which contains all relevant information about a design and can be fed into any simulation tool which is needed to evaluate the impact of a possible design variation on the resulting product performance. As this process can be automated by digital compilers, it is possible to perform systematic design variations for an almost infinite amount of parameters and topological variants. Consequently, these kinds of graph-based languages are a powerful means to generate viable design alternatives and thus permit fast evaluations. The paper demonstrates the design process, focusing on the drive system of the respective balanced two-wheel scooter and highlights the advantages (data integration and possibility for machine execution).

**Keywords:** digital design process; urban vehicles; balanced two-wheel scooter

### **1. Introduction**

Vehicles for the so-called last mile are an essential component for individual mobility in inner-city logistics concepts (compare [1]). In the case of individual mobility, users can ideally switch directly between different means of transport—one possibility for this is a lightweight, balanced two-wheeled scooter. This paper is based on the thesis that a considerable reduction of size and weight could be achieved, if certain products are tailored to the weight, size and proportion of the user. For instance, within a usual population, a difference in size of 25% and in weight of more than a 100% is present. Obviously, a linear relationship between those parameters and the size and weight of a product, which these

**Citation:** Holder, K.; Schumacher, S.; Friedrich, M.; Till, M.; Stetter, R.; Fichtner, W.; Rudolph, S. Digital Development Process for the Drive System of a Balanced Two-Wheel Scooter. *Vehicles* **2021**, *3*, 33–60. https://doi.org/10.3390/ vehicles3010003

Received: 31 December 2020 Accepted: 19 January 2021 Published: 20 January 2021

**Publisher's Note:** MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.

**Copyright:** © 2021 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https:// creativecommons.org/licenses/by/ 4.0/).

persons use, cannot be postulated. However, for lightweight transportation products such as bikes and scooters, a strong connection is probable. It is important to note that tailoring these kind of products for the individual size, weight and proportion of the user requires a continuous digital design process (compare [2]). Consequently, the focus of this paper is a requirement-oriented digital design process of a certain vehicle for last-mile transport—a self-balanced scooter. Through cross-domain modeling, the user individual requirements can be mapped throughout the entire design process. To create a digital and executable process, the individual steps are defined and domain specific data, such as product design, geometry creation, drive design and production planning are stored in a central data model, using an innovative approach applying graph-based design languages in combination with a design compiler. The scope of the research presented this paper are the requirements, the geometry synthesis and simulations (Figure 1).

**Figure 1.** Scope of the presented research.

The following steps and domain models are integrated in this process: drive train rough estimation via SIMULINK (drive train simulation model—SIMULINK is a software from The MathWorks, Natick, MA, USA), gear-specific model (gear set oriented drive train model), geometry model, control design models, detail model for simulation of the vehicle and of its controller function and code generation from the simulation model. Determining a suitable solution to a given design problem essentially can be understood as an continuous interplay between reasoning about required properties and functions and the particular combination of solution elements which will be provided for this, as well as simulations of their behavior (compare [3,4]). This leads to an iterative process consisting of analyzing and gradually synthesizing the potential solution. It should be noted that some of the solution features or constraints might necessitate a partial or complete redefinition of the problem [5]. Such iterations are not limited to individual design stages, but carry through the entire design process. These iterations have to go hand-in-hand with a continuous update of the models, which represent the respective information [6]. Graph-based design languages offer a promising approach to address the issues of laborious manual transfer and incomplete, inconsistent linking. Such languages generate a digital meta- or system model, storing all relevant information about a design and feed this into any relevant computer-aided engineering (CAE) tool as needed to simulate and test the impact of any design variation on the resulting product performance. As this can be automated in digital compilers to perform systematic design variation for an almost infinite amount of parameters, such graph-based languages are a powerful means to generate viable design alternatives—and thus permit fast comparison and selection—much faster than any design team manually could. This paper investigates the underlying challenges and proposes a digital design process.

The main focus of this paper is on the digital design process. The object of this process is a drive system for a balanced two-wheel scooter. Due to the need to balance the vehicle and simultaneously to follow a given path, the use of two individual actuators on each wheel and an elaborate control system with a continuous tracking of the inclination angle is inevitable. Due to many aspects such as simplicity, the choice of electrical motors as actuators is logical. An initial design step was needed in order to determine whether a gear system is necessary and which transmission ratio would be beneficial for certain configurations. It became apparent that designs which use a transmission are more beneficial for the given set of requirements (including system costs), leading to the general drive system configuration shown in Figure 2.

**Figure 2.** Scooter drive system—overview.

Visible in the cross-section shown in Figure 2 are one of the two electrical motors, a coupling and the shafts of the transmission system. Together with the inclination sensor and the control system, they represent the key technologies of the balanced two-wheel scooter. The chosen drive system is also similar to drive systems in mobile two-wheel applications (compare [7]). The integration of alternative technical solutions in the digital design process is discussed in the reflections section. The main research goal was the development of a digital design process for this and similar vehicles. This process is realized by applying graph-based languages. The underlying concept of graph-based design languages is described in the next section. Methods and tools for the continuous management of requirements are the contents of Section 3. In Section 4, an approach for functional representation is explained. The concrete dimensioning of the motor and transmission of the balanced two-wheel scooter is discussed in Section 5. Based on the

general dimensions and detail, dimensioning of the transmission was possible; this is described in Section 6. One main challenge of balanced two-wheel scooters is the control system—the model-based development is explained in Section 8. In Section 9, the digital design process is reflected and advantages and challenges are discussed. The final section of this paper presents a conclusion and an outlook to further research topics and activities.

### **2. Graph-Based Design Languages**

Graph-based design languages provide a powerful engineering framework through their automated, systematic variation and calculation features, and have the capability to feed into any relevant CAE tool. They map product information into vocabulary and rules typically based on the Unified Modeling Language (UML). These languages permit machine execution and the reuse of design and manufacturing knowledge, through automated model generation, calculation and simulation. They allow the generation of a large number of design alternatives based on parameter variation across multiple simulation tools, in a fast and automated manner [8–14]. Figure 3 shows some successful applications of graph-based design languages.

**Figure 3.** Successful applications of graph-based design languages.

In graph-based design languages, the geometry can be abstracted to its parts and their abstract geometry. The parts can be organized into the class diagram which represents the vocabulary of the design language. This vocabulary can be used together with rules in order to generate the geometrical model of the product. One important objective of the application of graph based languages is to accelerate innovation. A second central goal is to develop knowledge representations and, through this, to enable a processing of the product lifecycle that allows for more human-independent technological process integration, thereby improving knowledge transfer. The basic concept of a graph-based design language is illustrated in Figure 4.

**Figure 4.** Concept of a graph-based design language.

Individual components of a graph-based design language are UML classes, which represent the objects of the product (vocabulary). These components can be arranged in ontologies (an ontology is an organized, annotated, related and/or hierarchical arrangement of engineering entities, which may represent aspects of engineering knowledge). These classes are connected in the UML class diagram by different associations and are instantiated via UML model transformations (rules). A sequence of such rules is modelled in an activity diagram. A central element of the digital design process is the Design Compiler 43™ (DC43 for short, see www.iils.de for details). DC43 uses the different sources of information to create the design graph. From this central meta- or system model, further models (for example computer-aided design (CAD) geometry models, simulation models like FEM (finite element method) or multi-body-simulation (MBS) models, descriptions of abstract physics, function representations, a bill of materials, etc.) can be generated in a fully automatic manner. In the balanced scooter project, several generic models could be generated in Figure 5.

The design compiler can process design languages on all abstraction levels to the full detail of the simulation models. This leads to a completely automated process within a unified framework. The design compiler executes the design rules and automatically derives the analysis models of the respective design domains (CAD, CFD (computational fluid dynamics), FEM, etc.). The information content is not limited to geometry, but can also include information concerning physical loads, materials, functions, etc. The work on "DesignCompiler43" is ongoing, but many important functionalities are already available in the current version. The starting points of the digital development process are requirements; their management is the topic of the subsequent section.

**Figure 5.** Design graph with digital models.

### **3. Requirements Management**

Requirements are a decisive factor in system development projects in industry (compare e.g., [15]). Studies [16,17] show that four of ten top risks in projects are strongly connected with requirements and that only 52 percent of the originally intended requirements appear in the final released version of the product. An enormous amount of literature concerns requirements management and requirements engineering; a good overview can be found in [18–20]. Additionally, international standards exist: the ISO standard 29148 "Systems and software engineering—Life cycle processes—Requirements engineering" [21], the ISO standard 15288 [22] "Systems and software engineering—Systems life cycle processes" and the quality management norm ISO 9001 [23]. Today, several tools for requirements management are currently available; a comprehensive overview is given in [24]. Additionally, open source products are available, which can provide extensive functionality, such as the Eclipse (Eclipse is an open-source programming tool for developing software of various types which is managed by the Eclipse Foundation, Ottawa, Canada, a nonprofit corporation with the mission to manage the Eclipse open source community and its projects)-based tool "ProR"; Figure 6 shows an example of the requirements of the balanced two-wheel scooter modelled in ProR.

In earlier research, a concept for model-based requirements management was developed [25]. The central objectives of the research were to demonstrate an integration of this model-based requirements management with a development process of gear systems by means of applying graph-based design languages. For the innovative approach, two models were developed—one model for generating various gear system design variants and a second model for requirements management (RM), which includes state of the art RM know-how. The RM-model, as well as the model for product design variants, has been implemented by means of graph-based design languages that are based on UML (Unified Modelling Language). For the explicit digital mapping, the definition of an interface between both models ("requirements" and "geometry synthesis and simulation") is needed. The model-based requirements management has, in very general terms, three main aspects, which could also be understood as dimensions (Figure 7).

**Figure 6.** Requirements management with Eclipse "ProR"—example.

**Figure 7.** Product classes linked to requirement classes.

The first dimension consists of the model for generating gear system design variants (right blue frame). The second dimension consists of the model for requirements management (left green frame) and the third dimension consist of the linking of requirements to the product graph. This linking is represented by a red association link. For this, attribute "RelatedToPart" is introduced within the structuring of requirements. This expansion of the framework of graph-based languages allows a concrete assignment from a certain requirement to its related product, module or part. The next section discusses how functional representations can be included in this framework.

### **4. Functional Representation**

The domain of product functions describes the solution concept of a product on an abstract level and supports the description and synthesis of complex, multi-domain products. This section describes possibilities to expand the applicability of graph-based design languages into the domain of product functions. These possibilities allow one to cohesively link integrative function modelling to product structures and intend to close the gap between the early, abstract stages and the systematic, concrete design generation and validation with relevant simulation tools. The approach is based on the integrated function modelling framework (IFM [26]), which is intended to provide development engineers with an integrated, cross-disciplinary approach for modelling system functionality. In this context, a function is defined as an intended or already perceivable behavior of a technical system to fulfil a specific task. The respective function information is presented in associated views; an example for the use case "drive balanced scooter" is given in Figure 8.

The state view (upper left) represents the states of operands, as well as their changes associated with related processes. The process flow view (upper right) qualitatively visualizes the flow of sequential or parallel (interaction or transformation) processes related to a specific use case. The interaction view (lower left) maps the bilateral impacts between actors and operands and represents the structure of the system. The actor view indicates the involvement of one or more actors in the realization of individual processes. For linking this approaches with the concept of graph based design languages, the class diagram of IFM has been re-modelled in UML in order to be able to use it in a design language [27]. The respective class diagram can be seen in Figure 9.

The entities, as they are represented in the IFM framework, are integrated with the classes and instantiations represented/modelled in DC43. Different from the IFM, for instance, DC43 can be used for requirements engineering as well. Consequently, the class "Requirement" has been added in Figure 5. The requirements are directly linked to use cases. This means, it is possible to identify, which use case fulfils which requirement and which requirements are not covered yet by any use case [25]. Furthermore, some links and interfaces had to be expanded and updated to match the DC43 UML environment. The existing UML model including requirements and functions could be used for the further steps—the dimensioning of motor and transmission as well as the design of the gear system and the control of the drive system.


**Figure 8.** Associated views in the IFM framework.

**Figure 9.** UML Class Diagram for Function Modelling in DC43.

### **5. Dimensioning of Motor and Transmission**

For the synthesis of the drive system of the balanced two-wheel scooter, a process with steps shown in Figure 10 is implemented. The blue-colored steps are part of an automatic process chain which is implemented in a graph-based design language (GBDL). Each process step is linked to the main requirements of the vehicle or sub requirements derived from them and from the information, and therefore parameters from the previous process.

**Figure 10.** Process of drive train synthesis with validation.

For the design of the drive train of the self-balanced scooter, the following requirements could be identified out of the (main) vehicle requirements:


To achieve this, a drive system consisting of an electric motor and a gearbox is chosen. This chapter is about the characterization of the main performance features of the motor and the transmission. Because of the focus of the research, a suitable electric motor will be purchased and not designed. Therefore, a database with 49 motors from various manufacturers is available as the basis, containing all relevant motor data, such as armature resistance [Ohm], torque constant [Nm/A], armature inductance [H] etc. To evaluate a motor and transmission combination, a substitution model for the scooter is built. The ratio of the gear system is the parameter with the greatest influence on the dynamics of the vehicle and will be identified. Each motor is combined with different gear ratios via a single-track vehicle model, see Figure 11. The single-track simulation model contains a drive train, which consists of an electric machine (blue) with a gearbox (green) and a vehicle with traction wheel (red). This model includes basic driving resistances due to acceleration and rolling friction. When running the simulation, the vehicle mass is accelerated. The gear ratio of the drive is varied in the range from *i* = 8 to *i* = 24 in an adjustable step size. In the specific use case, this results in 7840 simulation runs with a step size of ∆*i* = 0.1. The step response of the system with regard to a voltage jump is determined for each simulation.

**Figure 11.** Step response as early dynamic evaluation approach.

The step response is evaluated with regard to the following criteria, which are assessed as relevant with regard to the requirements mentioned:


The step responses can be used to compare the various motors with their different gear ratios and to make a decision for a suitable combination. The result is the best performing motor with its appropriate gear ratio. Due to the substitution model, an overall ratio of *i* = 17.5 in combination with a low price BLDC motor "Turnigy Aerodrive SK3" [28] could be determined as an acceptable solution. After the precise design of the transmission geometry in Section 7, it is only then possible to assess the dynamics behavior in Section 8.

### **6. Detail Dimensioning of the Transmission**

The process presented in this chapter generates a preliminary transmission design from the desired overall gear ratio and the drive train performance data. The process is divided into the following sub-steps:


For this purpose, the following compound requirements could be generated from previous process and the vehicle as a system:


There are further requirements for the design of the gear set, including parameters such as desired safety values, application factors, etc. For the synthesis of the gear geometry using GAP (Getriebeauslegungsprogramm—German for gear system dimensioning program) [29], a design criterion must also be defined, here, e.g., the requirement for a minimum mass of the gear set is used. Via GAP, the gear geometry is generated in an explicit way according to the requirements and stored in the graph. For this purpose, an interface for commanding GAP and feeding back the data from the gear set to the central data model is implemented. The design of the gear set is repeated for several parameters, a design space is fully factorial scanned. The geometric parameters are shown in Figure 12.

**Figure 12.** Geometrical parameters at a two-stage gear system.

The variable parameters for the exploration of the two-stage gear set scheme are the ratio distribution of the overall ratio to the two stages and the center distances of the two individual stages. When dividing the overall ratio, the ratio of the first stage *i*<sup>1</sup> is varied and the ratio of the second stage *i*<sup>2</sup> results from the interrelation:

$$
\dot{i}\_2 = \frac{\dot{i}\_{\text{ges}}}{\dot{i}\_1} \tag{1}
$$

The two center distances of the gear stages (*a*<sup>1</sup> and *a*2) are varied in the range of 40–90 mm for the scooter gear system use case. The size of a bearing system for the shafts limits the minimal distance of the shafts at 40 mm. The upper bound of 90 mm is estimated in terms of the number of variants. In addition, a valid total center distance of 112.5 mm can only be achieved if the following geometrical relationship is given:

$$a\_{\mathcal{S}^{\rm es}} \le a\_1 + a\_2 \tag{2}$$

The geometrical relation of the deflection *h* of the two-stage gear set can be formulated as follows with regard to the maximum height of the triangle ABD.

$$a\_{\rm ges} = \sqrt{a\_1^2 + h^2} + \sqrt{a\_2^2 + h^2} \tag{3}$$

Formula (3) solved for *h*:

$$h = \pm \frac{\sqrt{a\_2^4 - 2a\_1^2 a\_{\rm ges}^2 - 2a\_1^2 a\_2^2 + a\_{\rm ges}^4 - 2a\_{\rm ges}^2 a\_2^2 - a\_1^4}}{2a\_{\rm ges}}\tag{4}$$

with *ages* 6= 0.

If the radius of the larger wheel of the intermediate shaft is added to the *h*, the result is *hges*, whereby the requirements for every valid design must apply *hges* ≤ *hmax*. These mentioned boundary conditions must be fulfilled for all generated variants in order to be eligible. By integrating the gear synthesis into the graph-based design language, the model can be used for subsequent design steps and further evaluations of the drive train. A simple geometry model is created for all generated gear sets, and the shaft-hub connections between the wheels and their shaft is calculated using a simplified approach referred to [30]. In addition, the bearing lifetime is calculated using an approach based on [31]. All the determined properties are saved in the central data model in the form of a graph. Figure 13 visualizes the central data model of a design in a simplified manner.

**Figure 13.** Design graph as a central data model for the drive train.

The properties of the gear set mass and the power loss are shown for the generated variants in Figure 14. The investigation for the scooter gearbox produces 13,892 valid geometrical variants of the gear set.

The left-lower limit of the variant point cloud represents the so-called pareto-front (orange) with regard to the two evaluation parameters (power loss and gear set mass). The selection of one progressed design variant happened from a procurement perspective. The gear geometry needed to be adapted to the on market available gears, as no gear

production was possible within the scope of the research, see red point Figure 14. The parameter configuration of the final design is *i*<sup>1</sup> = 5 ; *i*<sup>2</sup> = 3.5 and *a*<sup>1</sup> = 60 mm; *a*<sup>2</sup> = 67.5 mm. This preliminary design with its central data model, including the evaluation it contains, is used to create a manufacturable design, this is presented in Section 7.

**Figure 14.** Design exploration and its evaluation according to power loss and gear set mass.

### **7. Design of the Gear System**

This section describes the detail design of the gear system with the housing ready to be manufactured. Due to the results of the automatic modelled and dimensioned motor and transmission unit, a detailed CAD model of the electric drivetrain is designed. Of the very many requirements, including manufacturing requirements, only a few requirements are mentioned here:


Subsequently, the derivation of load cases and the associated evaluation is shown; also, the final design of the balanced two-wheel scooter drivetrain is presented. Due to the target weight of the scooter and a maximum carrying capacity of about 100 kg, and an overall weight of 145 kg as a main vehicle requirement it is possible to elaborate sub requirements for load cases. Besides the installation space model, the critical load cases are very important for the ongoing drivetrain design. One critical load to evaluate the mechanical integrity is the curbstone crossing. The structure of the housing and mountings should withstand such a curb crossing at a driving speed of 20 km h−<sup>1</sup> . It is assumed that the vehicle passes over a curbstone with a height of 80 mm. According to the following Equation (5) mentioned in [32], the peak vertical acceleration *a<sup>z</sup>* during the curb crossing is calculated by the traction wheel radius *r*, the height of the curb *h* and the velocity of the vehicle *v*:

$$a\_z = \frac{2}{2r - h}v^2\tag{5}$$

The calculation leads to 13 g peak acceleration during the curb crossing. After considering the damping effects of the tire, the peak acceleration is reduced to approximately 10 g. Including the mass of the scooter and the estimated peak acceleration, a maximum vertical force has been calculated as the critical force caused by driving the scooter. The second

critical load is referenced to the weight and torque of the electric motor. In order to be able to install and remove the drive system as a complete module, the motor is supposed to be connected to the transmission housing. According to the motor specification, the motor has an overall weight of 0.84 kg and a peak torque of 4 N m [28]. This means that the design of the drive unit has to support the torque and weight. The weight of the motor, similar to the total weight of the scooter, has to be held up with a permissible deformation for a curb crossing of 10 g. As shown in Figure 1, the previously mentioned requirements are taken into the design and verified and optimized by simulations. 2*r* − *h* The calculation leads to 13 g peak acceleration during the curb crossing. After considering the damping effects of the tire, the peak acceleration is reduced to approximately 10 g. Including the mass of the scooter and the estimated peak acceleration, a maximum vertical force has been calculated as the critical force caused by driving the scooter. The second critical load is referenced to the weight and torque of the electric motor. In order to be able to install and remove the drive system as a complete module, the motor is supposed to be connected to the transmission housing. According to the motor specification the motor has an overall weight of 0, 84 kg and a peak torque of 4 N m [28]. This means, that the design of the drive unit has to support the torque and weight. The weight of the motor, similarly

calculated by the traction wheel radius *r*, the height of the curb *h* and the velocity of the

2

*v* 2

(5)

*a<sup>z</sup>* =

*Vehicles* **2021**, *1* 15

vehicle *v*:

According to the vehicle requirements, an installation space model for the drive unit is generated. The model shown in Figure 15 presents three different views, including the possible installation space for the drive unit (yellow marked geometry), which absorbs the previously specified interfaces to the gear set, such as the connection to the wheel hub and the attachment points of the frame. According to the requirements, it should be possible to install the drive unit on both sides of the balanced two-wheel scooter. For this reason, special care was taken to ensure that the attachment points and the motor, as well as the output shaft, are arranged symmetrically to each other. Based on the automatically generated gear set and the defined interfaces, a first model of the gearbox housing is created, limited by the installation space. The detailed model is created in the design software Creo Parametric 5.0. A finite element method (FEM) simulation is generated in Creo Simulate to verify the required load cases (Creo Parametric 5.0 as well as Creo Simulate are software tools of the PTC Inc. from Boston, MA, USA). After the boundary conditions are transferred into the model, the mesh size is investigated by a convergence and divergence study. For the studies shown in Figure 9, the elemental stresses are investigated according to von Mises. The divergence study is used to check the mesh size in the border areas and the convergence study of the mesh fineness in the unbounded area [33]. For each of the studies, one element is tested with different mesh sizes (visible in Figure 16). to the total weight of the scooter, has to be held up with a permissible deformation for a curb crossing of 10 g. As shown in Figure 1, the previously mentioned requirements are taken into the design and verified and optimized by simulations. According to the vehicle requirements, an installation space model for the drive unit is generated. The model shown in Figure 15 presents three different views including the possible installation space for the drive unit (yellow marked geometry), which absorbs the previously specified interfaces to the gear set, such as the connection to the wheel hub and the attachment points of the frame. According to the requirements, it should be possible to install the drive unit on both sides of the balanced two-wheel scooter. For this reason, special care was taken to ensure that the attachment points and the motor as well as the output shaft are arranged symmetrically to each other. Based on the automatically generated gear set and the defined interfaces, a first model of the gearbox housing is created, limited by the installation space. The detailed model is created in the design software Creo Parametric 5.0. An finite element method (FEM) simulation is generated in Creo Simulate to verify the required load cases (Creo Parametric 5.0 as well as Creo Simulate are software tools of the PTC Inc. from Boston, Massachusetts, USA). After the boundary conditions are transferred into the model, the mesh size is investigated by a convergence and divergence study. For the studies shown in Figure 9, the elemental stresses are investigated according to von-Mises. The divergence study is used to check the mesh size in the border areas and the convergence study of the mesh fineness in the unbounded area [33]. For each of the studies, one element is tested with different mesh sizes (visible in Figure 16).

**Figure 15.** Space Model for the drivetrain view form front, side and above. **Figure 15.** Space Model for the drivetrain view form front, side and above.

**Figure 16.** Convergence and divergence behavior for different mesh sizes.

The divergence study shows that no valid analysis of the stresses in the border areas can be achieved with a grid fineness of less than 10. The convergence study shows that no significant change in the stresses in the unbounded area can be detected from a mesh size of less than 25. Accordingly, a mesh size of 10 is used for the more detailed analysis of the load cases. A further advantage of this mesh size is the computing time, which is kept to a minimum. This is decisive for the optimization process, in order to simulate a high value of different geometries by achieving valid results. The above-mentioned optimization of the component geometries mainly concentrated on the component displacement, as the element stresses in all components are consistently lower than the critical material parameters allow. The comparison shown in Figure 17 represents the deflection of the drive unit in the Z-direction viewed from the side.

**Figure 17.** Displacement with the first design (**left**) and the optimized geometry (**right**).

On the left-hand side, the simulation result of the first created geometry is shown. On the right-hand side, the finally selected and optimized geometry is shown. During the optimization process, the component displacement could be reduced by about 60%. For stiffening the individual parts, for example, ribs are inserted between the individual bearing seats of the transmission housings. To increase the stiffness at equal weight, it is necessary to thicken the mounting plate to 10 mm and remove material according to the load paths. To further reduce the overall weight and costs, a geometry for additive manufacturing with polylactic acid (PLA) is designed. Therefore, a topology optimization is implemented for the motor connector. For the topology optimization and the following FEM simulation the structure is simulated considering the maximum motor torque and the impact of the motor weight during the curb crossing. Figure 18 shows the results of the FEM simulation.

**Figure 18.** FEM simulation of the topology optimized motor connector—load case curb crossing.

The motor is coupled to the input shaft of the transmission with a flexible coupling. Therefore, two criteria can be defined to investigate the component. On the one hand, the critical material parameters of PLA are not allowed to be exceeded and on the other hand the displacement of the connection may not exceed the maximum possible flexible coupling deflection (max. angle of 5 ◦ ) [34]. Otherwise, bending loads could damage the coupling and increase bearing loads. As shown by the simulation results, neither of the two criteria are reached or even exceeded by the critical loads.

Another crucial aspect was the supply of lubricant in the gear system. The requirements for the oil system included sealing, as well as ensuring a sufficient supply of lubricant to the gears and bearings. The first one is realized by using an O-ring seal cord and proper radial shaft seals. The second is checked by a fluid simulation. The purpose of the simulation is to determine the amount of oil required for reliable operation of the drive train and how well the individual bearings and gears are supplied with lubricant. Figure 19 shows a screenshot from the simulation set up in the software PreonLab. PreonLab is a fluid simulation tool developed by the FIFTY2 Technology GmbH from Freiburg, Germany. Based on the results of the simulation, a filling level of 50 mL is determined to be appropriate for the safe operation of the transmission.

**Figure 19.** Analysis of the splash lubrication system by using the software PreonLab.

The resulting drive system with its components can be seen in Figure 20.

**Figure 20.** Drivetrain module of the scooter.

After the entire drivetrain is designed, verified and optimized according to the requirements, a detailed centre-of-gravity (COG) model is derived. This model includes the vehicle COG and the rotational moment of inertia of the drive train. These data are transferred back to the central model to be used as parameters for the automated controller configuration.

### **8. Control of the Drive System**

In order to guarantee the functionality of the above derived scooter design, the dynamic properties stated in the product requirements must be checked. Typical requirements for the balanced two-wheeled scooter are, on the one hand, stability of the attitude dynamics and, on the other hand, a firmly defined transfer behavior of disturbances introduced by the human driver on the translational velocity of the scooter. These properties can be concretized in the design of the control system in the form of overshoot width ∆*o*, overshoot time *t<sup>o</sup>* and settling time *t<sup>s</sup>* of the system for appropriately selected step responses, as show in Figure 21. The settling time refers to the case in which the setpoint remains within a specified value range ∆*<sup>s</sup>* .

**Figure 21.** Schematic of a step response and its characteristics.

In case of the proposed scooter design, four different cases of simulation scenarios are proposed to define the dynamic behavior of the scooter. The first and most crucial specification is a demand on the stability of the attitude dynamic, thus stabilizing an unstable pole describing a pitch movement of the platform body around its rotation axis. The second specification specifies the suppression of input disturbances created by the human driver based on a shift of his center of gravity. The last two specifications make demands on the tracking behavior of the control system. They specify the dynamic properties of the tracking of a commanded velocity *v<sup>c</sup>* and the tracking of the yaw rate *ψ*˙ *c*. A detailed listing of the specifications can be seen in Table 1.



In order to check these requirements, the closed loop behavior of the scooter is simulated. This leads to a knowledge of the control variables, and thus the drive system defined above can be validated with respect to the required demands. Firstly, the dynamic model used to simulate the balanced two-wheeled scooter is introduced. A schematic of the plant model is shown in Figure 22.

**Figure 22.** Schematic of the segway model with a heading *ψ* = 0.

As can be seen in Figure 22, a minimal set of independent variables *q* can be given by

$$\boldsymbol{\mathfrak{g}} = \begin{pmatrix} \mathbf{x} & \boldsymbol{y} & \boldsymbol{\psi} & \boldsymbol{\theta} \end{pmatrix}^{T} \tag{6}$$

consisting of the position coordinates *x* and *y* and the yaw angle *ψ* and pitch angle *θ*. The dynamic system consists of three bodies, the main platform with the passenger and the two wheels. The two wheels are mounted on an axle with a length 2*a* and the center of mass of the wheel bodies lie in their respective rotation axis, thus the inertia tensor of each wheel is invariant to rotation around their respective rotation axis. The length of the lever of the center of gravity of the platform body with respect to its rotational degree of freedom is described by the parameter *l*. A simplification made in the modeling is that the wheels can only move in the body fixed x direction, thus narrowing the degrees of freedom in the derivatives of the independent variables ˙*q*, as depicted in Equation (7):

$$\boldsymbol{\dot{q}} = \begin{pmatrix} \boldsymbol{v} & \boldsymbol{\psi} & \boldsymbol{\theta} \end{pmatrix}^{\mathrm{T}}.\tag{7}$$

Thus, for this problem, the kinematic description of the wheel movement of the reference point *PRe f* in the center of the wheel axle based on [35] can be given in the form

$$\mathbf{r}\_{\rm I} \dot{\mathbf{r}}\_{\rm Ref} = \begin{pmatrix} v \cos \psi \\ v \sin \psi \\ 0 \end{pmatrix} \tag{8}$$

with the help of the translational velocity *v* and the heading *ψ* of the scooter. Based on the translational velocity of the reference point *PRe f* , depicted in Equation (8), the translational velocity ˙*rw*,*<sup>n</sup>* of the n-th wheel body can be expressed in the inertial frame:

$$\mathbf{q}\dot{\mathbf{r}}\_{w,n} = \mathbf{q}\dot{\mathbf{r}}\_{Ref} + \underbrace{\mathbf{q}\mathbf{T}\_{\text{RR}}\dot{\mathbf{l}}\_{w,n}}\_{=\mathbf{0}} + \mathbf{T}\_{\text{R}}[\_{\text{R}}\boldsymbol{\omega}\_{r}]\_{\text{x}}\mathbf{l}\_{w,n}.\tag{9}$$

The vector *lw*,*<sup>n</sup>* used in Equation (9) describes the position of the wheel with respect to the reference point and only depends on the axle length *a*, if described in the R-frame. The transformation matrix <sup>R</sup>*T*<sup>I</sup> describes the transformation of the inertial frame to the R-frame and can be fully defined by a elementary rotation with the angle *ψ* around the <sup>I</sup>*z* axis. In order to describe the change in the orientation of the R-frame with respect to the body fixed frame, the angular rate *ω<sup>r</sup>* is introduced as show in Equation (10).

$$\prescript{}{R}{\boldsymbol{\omega}}\_{\mathcal{V}} = \begin{pmatrix} \boldsymbol{0} & \boldsymbol{0} & \boldsymbol{\psi} \end{pmatrix}^{\boldsymbol{T}}.\tag{10}$$

Similar to the translational velocity of the wheels, the translational velocity *r*˙ *<sup>p</sup>* of the platform can be formulated with respect to the reference point *Pre f* , as shown in Equation (11).

$$\dot{\mathbf{r}}\_{1}\dot{\mathbf{r}}\_{p} = \mathbf{i}\_{1}\dot{\mathbf{r}}\_{Ref} + \underbrace{\mathbf{I}\_{\text{I}}\mathbf{T}\_{\text{PP}}\dot{\mathbf{l}}\_{p}}\_{=\mathbf{0}} + \mathbf{I}\_{\text{P}}\left[\mathbf{p}\omega\_{p}\right]\_{\text{x}}\mathbf{l}\_{p}.\tag{11}$$

The vector *l<sup>p</sup>* describes the position of the center of mass of the platform body, which only depends on the arm length *l* and is a time invariant quantity, if described in the P-frame. The transformation matrix <sup>P</sup>*T*<sup>I</sup> describes the orientation of the inertial frame with respect to the P-frame and is defined by two sequential elementary rotations. The first rotation describes a rotation with the angle *ψ* around the <sup>I</sup>*z* axis and the second rotation describes a rotation with the angle *θ* around the *y* axis of the new coordinate system. In order to fully define the translational velocity of the platform depicted in Equation (11), the rotational velocity *ω<sup>p</sup>* is needed

$$\mathbf{^0p}\boldsymbol{\omega}\_p = \begin{pmatrix} \mathbf{0} & \boldsymbol{\theta} & \mathbf{0} \end{pmatrix}^T + \mathbf{\_P}\mathbf{T\_R} \begin{pmatrix} \mathbf{0} & \mathbf{0} & \boldsymbol{\psi} \end{pmatrix}^T \tag{12}$$

which describes the change of orientation of the platform system with respect to the inertial frame. To fully describe the motion of the individual bodies of the scooter, it is necessary to link the translational velocities *v* and the yaw rate *ψ*˙ with the rotational velocity *α*˙ *<sup>n</sup>* of the wheel bodies. Based on the fact that the scooter does not experience any slip, this relationship can be expressed in the following equations:

$$v = -\frac{r}{2}(\mathbb{A}\_1 + \mathbb{A}\_2) \tag{13}$$

$$
\dot{\psi} = -\frac{r}{2a} (\dot{\mathfrak{a}}\_2 - \dot{\mathfrak{a}}\_1). \tag{14}
$$

Based on the above introduced Equations, (13) and (14), the rotational velocity of the wheel can be expressed as illustrated in Equation (15).

$$\begin{pmatrix} \frac{1}{R}\boldsymbol{\omega}\_{\boldsymbol{w},\boldsymbol{n}} = \begin{pmatrix} 0 & \boldsymbol{\omega}\_{\boldsymbol{n}} & \boldsymbol{\psi} \end{pmatrix}^{T} = \begin{pmatrix} 0 & -\frac{1}{r}\boldsymbol{v} + \frac{\boldsymbol{a}}{r}\boldsymbol{\psi} & \boldsymbol{\psi} \end{pmatrix}^{T} \tag{15}$$

In order to describe the dynamic model based on d'Alemberts principle, the whole momentum of the system needs to be in a state of equilibrium, thus leading to the following relationship:

$$\begin{aligned} \boldsymbol{J}\_{\mathrm{T},p}^{\mathrm{T}} \left( \mathbf{1} \boldsymbol{\dot{\boldsymbol{\nu}}}\_{p} - \mathbf{1} \boldsymbol{f}\_{\varepsilon,p} \right) + \sum\_{n=1}^{2} \boldsymbol{J}\_{\mathrm{T},w,n}^{\mathrm{T}} \left( \mathbf{1} \boldsymbol{\dot{\boldsymbol{\nu}}}\_{w,n} - \mathbf{1} \boldsymbol{f}\_{\varepsilon,w,n} \right) + \dots \\ \left( \dots + \boldsymbol{J}\_{\mathrm{R},p}^{\mathrm{T}} \left( \mathbf{1} \boldsymbol{\boldsymbol{\nu}}\_{p} - \mathbf{1} \boldsymbol{\tau}\_{\varepsilon,p} \right) + \sum\_{n=1}^{2} \boldsymbol{J}\_{\mathrm{R},w,n}^{\mathrm{T}} \left( \mathbf{1} \boldsymbol{\dot{\boldsymbol{\nu}}}\_{w,n} - \mathbf{1} \boldsymbol{\tau}\_{\varepsilon,w,n} \right) = 0 \end{aligned} \tag{16}$$

In order to describe the momentum *p*˙ *p* of the platform, the mass *m<sup>p</sup>* of the platform and the translational acceleration in the inertial frame are needed, which can be easily calculated based on Equation (11). Similarly, the momentum *p*˙ *<sup>w</sup>*,*<sup>n</sup>* of the n-th wheel can be expressed based on its mass *m<sup>w</sup>* and the time derivative of its translational velocity in the inertial frame depicted in Equation (9). To describe the rotational momentum of the platform ˙ *l<sup>p</sup>* or of the n-th wheel body ˙ *lw*,*<sup>n</sup>* in its respective body fixed frame, the inertial tensor **Θ***<sup>p</sup>* of the platform and **Θ***w*,*<sup>n</sup>* of the wheel and their angular acceleration in the body fixed frame are needed. These can be evaluated based on the description of their angular velocities described in the Equations (12) and (15). The Jacobian matrices, *JT*,*<sup>p</sup>* , *JT*,*w*,*<sup>n</sup>* , *JR*,*<sup>p</sup>* and *JR*,*w*,*<sup>n</sup>* , describe, with respect to the choosen independen variables, the directions in which the systems body is allowed to move. They can be expressed by the partial derivatives of the translational and rotational velocities of each body with respect to the

vector *q*˙ . To describe the external influences on the system, the external forces and moments acting on the system needs to be defined as follows:

$$\mathbf{f}\_1 \mathbf{f}\_{\varepsilon, p} = m\_{p1} \mathbf{g} + {}\_1 \mathbf{T}\_{\text{PP}} \mathbf{f}\_{a, p} \tag{17}$$

$$\mathbf{r\_1}f\_{\varepsilon,w,n} = m\_{w1}\mathbf{g} \tag{18}$$

$$\mathbf{p} \cdot \mathbf{r}\_{\varepsilon, p} = \begin{pmatrix} 0 & \tau\_{\mathbf{M}, 1} + \tau\_{\mathbf{M}, 2} & 0 \end{pmatrix}^T \tag{19}$$

$$\mathbf{r}\_{\mathbf{R}}\mathbf{r}\_{\mathbf{c},\mathbf{w},\mathbf{n}} = \begin{pmatrix} \mathbf{0} & -\boldsymbol{n}\_{r}\boldsymbol{\pi}\_{\mathbf{M},\mathbf{n}} & \mathbf{0} \end{pmatrix}^{T}. \tag{20}$$

The moments produced by the two motors are taken into account by the quantities *τM*,*n*. The dynamic model depicted in Equation (16) can be reformulated in the mass matrix form:

$$\mathbf{M}(\mathbf{q})\ddot{\mathbf{q}} + \mathbf{g}(\mathbf{q}, \dot{\mathbf{q}}) = f. \tag{21}$$

The external torques acting on the platform system and on the wheels mainly consist of the torques *τM*,*<sup>n</sup>* produced by the n-th motor of the scooter. Taking the dynamic properties of the motor into account [36], the full dynamic model reads

$$
\begin{pmatrix}
\dot{\boldsymbol{q}} \\
\ddot{\boldsymbol{q}} \\
\ddot{\boldsymbol{t}}
\end{pmatrix} = \begin{pmatrix}
\begin{pmatrix}
\boldsymbol{v}\cos\boldsymbol{\psi} & \boldsymbol{v}\sin\boldsymbol{\psi} & \boldsymbol{\psi} & \boldsymbol{\theta}
\end{pmatrix}^{T} \\
\mathbf{M}(\boldsymbol{q})^{-1}(\boldsymbol{f} - \mathbf{g}(\boldsymbol{q}, \dot{\boldsymbol{q}})) \\
\frac{1}{\mathcal{L}}\left(\boldsymbol{\mu} - \boldsymbol{\psi}^{\*}\left(\boldsymbol{\theta}\begin{pmatrix}\boldsymbol{1} & \boldsymbol{1}\end{pmatrix}^{T} - \dot{\boldsymbol{\mu}}\right) - \dot{\boldsymbol{\mathcal{R}}}\right)
\end{pmatrix} \tag{22}
$$

with the state vector

$$\mathbf{x} = \begin{pmatrix} q & \dot{q} & \dot{\mathbf{i}} \end{pmatrix}^T. \tag{23}$$

Parameters of the motor model are the electrical resistance *R*, the inductivity *L* and the magnetic flux *ψ* ? of the motor. In order to automatically generate the simulation model, the inertia properties and the positions of the center of masses of the different bodies with respect to the reference point need to be extracted. This can be easily done with the help of a random CAD-Kernel. A possibility to model a multibody system in a design language is shown in Figure 23.

The central class of this library is the "Body" class, which inherits a set of inertia properties needed for a multibody simulation and each body can be disassembled into an infinite set of elements to be able to represent different assemblies, which can be combined to one body in the sense of a multibody simulation. To take care of the coordinate sytems in which the different quantities are expressed, the "Frame" class is introduced. It describes the rotation and translation to the inertial coordinate frame, thus all quantities can be expressed in a frame which is chosen with regard to the topology of the multibody model. The interface class to the geometric representation is the "Component" class, a class originating from a DC43 library which represents instances with a geometric shape. In this development process, the automated design process is inturrepted in the detailed design of the gear system, which is depicted in Section 7. If this design process could be automated too, the multibody simulation could be triggered automatically based on the model proposed in the class diagram shown in Figure 23.

**Figure 23.** Class diagram of a multibody library.

The last step of the design process would be the closed loop simulation of the plant model. For this purpose, Matlab/Simulink was used. The controller design chosen for the scooter design is depicted in Figure 24.

**Figure 24.** Schematic of the closed loop model.

The controller is based on a simple output feedback controller for the pitch and velocity dynamic and a separated state feedback controller for the yaw dynamics. This controller design and its decoupled nature between the pitch and the yaw dynamic is extensively discussed in [37–41]. The output vector *y* consists of the output *y<sup>v</sup>* for the pitch and velocity controller and the output *yψ*˙ for the yaw rate controller. Similar to this, the gain matrix *K* is a block diagonal matrix consisting of the vector *k T <sup>v</sup>* of the pitch and velocity controller and the vector *k T <sup>ψ</sup>*˙ of the yaw rate controller. In order to map the torques calculated in the two decoupled controllers on the actual actuators, a simple allocation scheme

$$\begin{aligned} \boldsymbol{\tau}\_p &= \boldsymbol{\Gamma} \boldsymbol{\tau}\_M\\ \begin{pmatrix} \boldsymbol{\tau}\_v\\ \boldsymbol{\tau}\_\psi \end{pmatrix} &= \begin{pmatrix} 1 & 1\\ -a & a \end{pmatrix} \begin{pmatrix} \boldsymbol{\tau}\_{M,1} \\ \boldsymbol{\tau}\_{M,2} \end{pmatrix} \end{aligned} \tag{24}$$

is used, which is uniquely defined for all combinations. To define the gains of the control system in order to fit the specified requirements, a linear design model based on a subset of the nonlinear model depicted in Equation (22) is used. It reads

$$
\dot{\mathfrak{x}}\_{\upsilon} = \mathbf{A}\_{\upsilon}\mathfrak{x}\_{\upsilon} + \mathbf{b}\_{\upsilon}\mathfrak{u}\_{\upsilon} \tag{25}
$$

$$\mathbf{y}\_v = \mathbf{c}^T \mathbf{x}\_v \tag{26}$$

with the state vector *x<sup>v</sup>* and the output vector *y<sup>v</sup>*

$$\mathbf{x}\_{\mathcal{D}} = \begin{pmatrix} e\_{\mathcal{D}} & \theta & v & \theta & e\_i & i\_v \end{pmatrix}^T \tag{27}$$

$$\mathcal{Y}\_v = \begin{pmatrix} e\_v & \theta & v & \theta \end{pmatrix}. \tag{28}$$

In this design model, the dynamic of the current controller of the motor is taken into account too, because in order too stabilize the unstable pole of the pitch dynamic, a very fast response is needed and thus unwanted coupling effects with the motor dynamic should be avoided. The control law for the current controller reads

$$i\_{\upsilon} = k\_{i}(i\_{\upsilon,\mathfrak{c}} - i\_{\upsilon}) + k\_{\mathfrak{e}\_{i}}e\_{i} \tag{29}$$

which creates a current output *iv*. It can be seen that the model is extended by the state *e<sup>i</sup>* , which describes the integrated current error of the controller. The output feedback control law for the pitch and velocity dynamic reads

$$i\_{\upsilon,\varepsilon} = \frac{1}{\psi^\star} \tau\_\upsilon = \frac{1}{\psi^\star} k\_\upsilon^T y\_{\upsilon\prime} \tag{30}$$

which generates a commanded value *iv*,*<sup>c</sup>* based on the state of the pitch and velocity dynamic. In order to achieve steady state accuracy, the integrated error of the velocity command is taken into account by the state *ev*. The control laws shown in Equations (29) and (30) combined with the simplified linear design model of Equation (25) can be used for pole placement [42] to achieve the specified dynamic properties. The poles are placed in order to satisfy the condition

$$\det\left(s\mathbf{I}\_{6\times6} - \left(\mathbf{A}\_{\upsilon} - \mathbf{b}\_{\upsilon}\mathbf{k}\_{\upsilon}^{T}\mathbf{c}\_{\upsilon}\right)\right) = \left(\mathbf{s}^{2} + 2\zeta\_{\upsilon}\omega\_{\upsilon}\mathbf{s} + \omega\_{\upsilon}^{2}\right)^{3},\tag{31}$$

thus specifying the eigenfrequency *ω<sup>v</sup>* and damping *ζ<sup>v</sup>* of the closed loop model. If the chosen controller does not satisfy the required dynamic properties in the nonlinear simulation, the eigenfrequency and damping of the system can be adapted automatically. Similar to velocity and pitch dynamic, the yaw rate controller can be designed. In this case, the motor dynamic is neglected. Thus, a simple linear model for the design of the controller can be expressed by

$$
\dot{\mathfrak{x}}\_{\psi} = A\_{\psi} \mathfrak{x}\_{\psi} + b\_{\psi} \mathfrak{x}\_{\psi} \tag{32}
$$

$$
\mathfrak{y}\_{\psi} = \mathfrak{x}\_{\psi} \tag{33}
$$

with the state vector *xψ*˙

$$\mathbf{x}\_{\psi} = \begin{pmatrix} e\_{\psi} & \psi \end{pmatrix}^{T}. \tag{34}$$

The state feedback control law reads

$$\pi\_{\psi} = \mathbf{k}\_{\psi}^{T} \mathbf{x}\_{\psi} \tag{35}$$

and generates a torque command *<sup>τ</sup>ψ*˙ based on the state *<sup>ψ</sup>*˙ and the integrated error *<sup>e</sup>ψ*˙ of the yaw rate. The pole placement [42] can be achieved by satisfying the following condition

$$\det\left(s\mathbf{I}\_{2\times 2} - \left(\mathbf{A}\_{\psi} - \mathbf{b}\_{\psi}\mathbf{k}\_{\psi}^{T}\right)\right) = s^2 + 2\zeta\_{\psi}\omega\_{\psi}s + \omega\_{\psi'}^2\tag{36}$$

with the help of the eigenfrequency *ωψ*˙ and the damping *ζψ*˙ of the yaw rate dynamic. Similar to the pitch and velocity dynamic, the controller can be tuned to satisfy the specified dynamic properties, by changing the damping and the eigenfrequency in the design model if the nonlinear validation model does not show the desired effects. In Figure 25, the critical

case for the motor design is shown, which is depicted by an error in the pitch angle for the here chosen dynamic properties shown in Table 1.

**Figure 25.** Simulation data of the stability specification.

An initial estimate for the maximum motor moment or current input was done in Section 5 in order to design the transmission. It can be seen that the trajectories of the pitch angle satisfy the conditions of the max overshoot, overshoot time and settling time for the case of a passenger of 70 kg and 90 kg, but in the second case, the maximum motor current *i*max = 80 A is violated. For the second case, a redesign of the scooter is necessary; for the first case, a valid scooter design is found, which satisfies all requirements. With the second case, a redesign could be done by using the maximal needed current of the closed loop model as an input in the transmission design.

### **9. Reflection of the Digital Design Process**

The described control system design process is an integral part of the digital design process of the balanced two-wheel scooter, which was realized by means of an integrated engineering framework based on graph-based design languages. All stages are fed with updated input information from a model based requirements management. The processes, operands and states are identified and connected in an integrated function model and actors are connected to the modular product structure under development. Crucial for the developed scooter is the dimensioning of the motor and transmission of the drive system. For the determination of the main performance features of the motor and transmission, an automated synthesis process with integrated validation was presented. The synthesis led to a choice of motor and transmission ratio—this was subsequently the input information for the detail dimensioning of the transmission. This detail dimensioning consists of an automatic synthesis of the gear set using parameter variation and pareto-front-based selection. The concrete design of the gear set included detailed finite element and lubrication analyses. For all kinds of balanced vehicles, the control system will determine the general usability and the driving comfort and safety. A detailed close loop behavior simulation was carried out, based on a controller design with a simple output feedback controller for the pitch and velocity dynamics and a separate state feedback controller for the yaw dynamics.

The central advantages of the presented digital design process in comparison to conventional design process is the possibility for machine execution, i.e., all steps can be carried out in an automatic manner. This allows the synthesis and analysis of a large number of possible solutions and increases the probability of generating and choosing an optimum solution. Additionally, compliance with all product design requirements can only be verified after the design is complete. This applies in particular to the evaluation of the dynamic properties of the closed-loop and the realizability of the control commands. Based on the fully automated design process presented in this paper, a suitable product design can be found by manipulating the input data without additional development work. Another important advantage is that through a large part of the design process a central model can be used in the engineering framework. This reduces the risk of inconsistencies. In the opinion of the involved design engineers, the resulting design process is more robust in case of design changes.

The main challenge in the application of this engineering framework is the necessity of a paradigm shift; the design engineers are, during a large share of the process, not designing a single product, but programming a product variety. In the early stages, a larger investment in terms of working hours and critical thinking is necessary, but the involved engineers tend to believe that the advantages merit this investment.

One common issue in the application of automated design processes is the question of whether innovative solution concepts are possible within this process. One may ask the critical question, if this kind of process limits creativity and will exclude solution possibilities, which are different from an initial concept. This risk is reduced by the possibility to integrate alternative configurations in this engineering framework, which goes beyond digital building blocks, as they are present in conventional design automation systems. The engineering framework allows mutual interdependent components, as well as a large solution variety on functional and physical levels. For the balanced two-wheel scooter example, solutions with completely different transmission systems could still be part of a consistent product family.

### **10. Conclusions and Recommendations for Further Research**

This paper demonstrated several stages of the digital design process of a balanced two-wheel scooter. An integrated engineering framework based on graph-based design languages serves as back-bone for this process. The result of the digital development process is the scooter shown in Figure 26.

The main advantages of the presented process are the linking of synthesis and analysis steps and the high degree of interconnected, model-based processes on different levels of abstraction and concerning different domains. The engineering framework based on graph-based design languages avoids double inputs, independent generic models and inconsistencies. Conventional tools are mostly only used to evaluate manually defined designs; very few can also be used to generate the models (synthesis). The process shown in this paper still has some gaps in automation, but represents a closed requirements-driven development chain. The gaps in the automation capability are particularly due to the sheer number of requirements—especially in the area of the geometry of the housing. Still, a primarily digital requirement driven design process and an enrichment of requirements along the design process could be demonstrated. Future work is aiming at a further increase of the automation level and the application for even more complex systems. Further possibilities for presenting abstract physics will be included in the engineering framework, and simulation possibilities, as well as synthesis possibilities such as topology, will be expanded. Additionally, the scientific foundation for a stronger integration with model-based system engineering systems will be addressed.

**Figure 26.** Build balanced two-wheel scooter

**Author Contributions:** Conceptualization, K.H., M.T., R.S., W.F. and S.R.; methodology, R.S.; design and dimensioning, S.S.; simulation, K.H. and M.F.; control design, M.F.; analysis and evaluation, K.H., S.S. and M.F.; writing—original draft preparation, K.H., S.S., M.F. and R.S.; writing—review and editing, M.T., W.F. and S.R. All authors have read and agreed to the published version of the manuscript.

**Funding:** This research was funded in the scope of the Digital Product Life Cycle (ZaFH) project (information under: https://dip.rwu.de/), which is supported by a grant from the European Regional Development Fund and the Ministry of Science, Research, and the Arts of Baden-Württemberg, Germany (information under: https://efre-bw.de/).

**Institutional Review Board Statement:** Not applicable.

**Informed Consent Statement:** Not applicable.

**Data Availability Statement:** The data presented in this study are available on request from the corresponding author.

**Acknowledgments:** The authors wish to thank the administrative and technical staff of the Ravensburg-Weingarten University (RWU), for the continuous support and all involved students for their immense contribution.

**Conflicts of Interest:** The authors declare no conflict of interest.

### **References**


**Raphael Mieth 1,2, Frank Gauterin 1,\* , Felix Pauli <sup>2</sup> and Harald Kraus <sup>2</sup>**


**Abstract:** Vehicle drive systems are often oversized for common customer operation in order to cover the high demands of rare driving events such as towing a trailer, high acceleration or steep inclines. This high torque and power requirement affects the efficiency map and the highest efficiency is around the area of increased torque and speed. However, in everyday use, drive systems are mostly driven by customers at low speed and load, and therefore are not operating in the most efficient area. Designing a drive system that only covers the area of highest customer operation can increase efficiency by moving the sweet spot of efficiency to the relevant area, and thus reduce energy consumption. Therefore, customer data need to be analyzed in order to identify customer requirements and to localize the area of greatest operation. The method presented in this paper analyzes customer data in order to identify design-relevant parameters for a customer-specific drive system design. The available customer data results from event-based counts and are submitted as a statistical frequency distribution. These statistics are compared with discrete time series recorded during test drives in order to derive representative time series that correspond to customer behavior. By applying the time frame-based load analysis to these relevant time series, the desired design-relevant parameters are pointed out.

**Keywords:** statistical customer data; design-relevant parameters; design of vehicle drive systems

### **1. Introduction**

Increasing the efficiency of vehicle drive systems is one of the highest goals in the automotive industry. By reducing energy consumption, further benefits such as an increase in electric range or reduced vehicle mass can be realized. Since drive systems are occasionally oversized in terms of performance for the actual requirements, efficiency can be increased by adjusting the performance [1–4]. This increase in efficiency can be achieved by reducing the performance of a drive system to the requirements that customers mostly need in daily operation. Furthermore, a second drive system is required in order to enable high demands, which occur rather rarely.

As part of a dissertation, this publication gives an insight into the method for analyzing customer-relevant driving requirements and converting them into relevant target values for the design of overall drive systems. In the context of the dissertation, an overall drive system is designed which combines increased efficiency by focusing on the core area of customer needs with high functionality by covering high requirements.

**Citation:** Mieth, R.; Gauterin, F.; Pauli, F.; Kraus, H. Transfer of Statistical Customer Data into Relevant Parameters for the Design of Vehicle Drive Systems. *Vehicles* **2022**, *4*, 137–144. https://doi.org/ 10.3390/vehicles4010009

Academic Editors: Ralf Stetter, Udo Pulm and Markus Till

Received: 25 January 2022 Accepted: 8 February 2022 Published: 10 February 2022

**Publisher's Note:** MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.

**Copyright:** © 2022 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https:// creativecommons.org/licenses/by/ 4.0/).

### **2. Methods**

This paper is divided into two methodical approaches as shown in Figure 1: first, time series data (TS) from endurance testing are compared with statistical customer data (CLC) with regard to identifying customer-relevant time series. In the second step, the root mean square (rms) is calculated for different widths of time frames and the time frame-based analysis (TFBA) is used to derive design-relevant parameters for the overall system design.

**Figure 1.** Scheme of the methodological structure.

The following Sections 2.1–2.3 explain the first methodical approach, shown on the left side in Figure 1. Sections 2.4 and 2.5 are then dedicated to the second approach.

### *2.1. Database*

The first approach is based on two types of data, namely time series and customer load collective. The available time series data are records of various signals from endurance testing, from which the relevant load variables that are required for the drive system design must be selected. The main design-relevant parameters are the mechanical power and the torque on the wheel. In addition, the vehicle speed, respectively the wheel speed as well as the acceleration, is also used to identify representative time series. Dependent on the available customer data, other parameters may be considered.

The available customer data are the results of event-based counts in the control unit of the customer vehicles, so-called *customer load collective*. These counts provide information about the frequency distribution, i.e., how often certain events occur. They are shown in Figure 2 using the example of the vehicle speed and acceleration distribution while the drive system is active. The color scheme represents the accumulation of the customer's driving behavior. According to the color bar, the vehicles in customer operation actually do not drive at all about 25% of the time despite the ignition being switched on.

The largest accumulation in these statistical distribution matrices of around 95% covers the range between approximately 0 and 130 kph as well as <sup>−</sup>2 and 2 m/s<sup>2</sup> . This conspicuity is also reflected in [5], where the driver behavior of the 34 participants is analyzed based on recorded real drives over a distance of around 35,000 km. The evaluation shows that the highest accelerations actually driven in the speed range up to approximately 100 kph are below 1.5 m/s<sup>2</sup> and at speeds of up to 140 kph are mostly not higher than approximately 1.0 m/s<sup>2</sup> . The limitation of the speed range to a maximum of 130 kph is derived from [6]. According to this report, the average top speed on German highways without speed limit is between 110 and 130 kph. Abroad, this value is lower due to speed limits. Based on these findings, accelerations between <sup>−</sup>2 and 2 m/s<sup>2</sup> and speeds of up to 130 kph can initially be assumed to be customer relevant. Consequently, this area can be identified as the focus of customer driving operations and used as the basis for a customer-specific drive system design.

### *2.2. Comparison of the Data Bases and Derivation of Representative Time Series*

After selecting appropriate, design-relevant signals from the time series data and determining the focus of customer driving operations, the next step is to merge these two databases. For this purpose, distribution matrices for all time series are created analogous to the customer data. The aim is to describe the time series statistically by transferring them into heat maps such as acceleration versus vehicle speed, as shown above in Figure 2, as well as motor torque versus motor speed with the same clustering as the CLC data.

The deviation of these matrices from the CLC data is the measure of the customer relevance of the time series. First, the cell-specific deviation |*Xi,j*| as absolute value of the cell-by-cell difference between time series *cellTS* and *CLC* data *cellCLC* is calculated according to Equation (1).

$$\left|X\_{i,j}\right| = cell\_{TS} - cell\_{\mathbb{CLC}} \tag{1}$$

The relevance of each time series is evaluated based on the mean total deviation. In this respect, the time series, whose deviation is the smallest, represents the best approximation to the customer distribution matrices. As shown in Equation (2), the arithmetic mean of the total deviation *X* is the sum of all cell-specific deviation values |*Xi,j*| divided by the number of all cells *n* in the above-mentioned area of greatest customer operation.

$$\overline{X} = \frac{1}{n} \sum\_{i=1}^{n} |X\_{i,j}| \tag{2}$$

This approach allows the time series to be sorted in ascending order by their total mean deviation. According to the method of [7], time series are combined with one another to minimize the total deviation, starting with those two, whose deviation is the lowest. Increasing the number of combined time series leads to a decrease in the mean deviation, as shown by the blue curve as well as the yellow trend line in Figure 3. The red markers highlight exactly that time series whose combination leads to the smallest deviation of the key area pointed out in Section 2.1.

In this case, 1000 time series are evaluated, of which the combination of all 45 redmarked time series shows minimal total deviation. In other words, combining exactly these 45 out of the 1000 time series, which the markers indicate, reduces the deviation the most and leads to the minimum of 3.13 in mean deviation.

**Figure 3.** Exemplary regression curve: mean deviation versus number of time series.

Following the steep drop, the slope decreases with an increasing number of time series and the mean deviation decreases only slightly. Due to the trade-off of reducing the mean deviation as much as possible while at the same time minimizing the computational effort, the red regression curve shows several optima displayed by the dashed black lines. According to these, considering 12 specific time series, indicated by the first 12 markers from the left, would lead to the first big decrease in the mean deviation from about 3.7 to 3.3. The second and third dashed lines show the consideration of 17 and 28 time series, respectively, with a decrease in the mean deviation to 3.25 as well as 3.18, respectively. In this respect, considering these numbers of time series represents optimums regarding computational effort and deviation in order to describe customer behavior in the best possible way.

### *2.3. Validation of the Purposed Method*

This methodological approach must take into account that the derivation of certain time series from statistics such as CLC data is ambiguous due to the lack of the time reference. In this case, the statistical frequency distribution can only be approximated by selecting suitable time series. In contrast, the reverse method of statistical representation of a time series represents a clear correlation.

Despite the lack of unambiguity, the procedure is admissible, as this method aims to approximate, rather than exactly represent, customer requirements by combining several time series.

In order to ensure the plausibility of the method, a given time series is first transferred into a distribution statistic for unambiguous assignment. In the next step, the method from [7] is used to analyze imported time series, one of which is the given one, with the aim of deriving the initial time series. The result of this analysis was a calculated deviation of zero. This shows that the procedure is able to re-identify the originally read-in time series, thus proving its functionality. To further check the plausibility, this process is repeated twice on top of that. Both different as well as the same time series are combined several times with one another and the method is applied, leading to the same result both times.

In addition, the available customer data represent a solid database due to the extensive amount of data. Using the example of an investigated model series, the data contains more than 15,000 vehicles with a total mileage of more than 100 million km. These selected vehicles all have a certain minimum mileage to evaluate only representative customer driving profiles. Reverse driving is also taken into account. This signifies a meaningful statistic, both in terms of different customer types and markets.

Furthermore, as already pointed out in Section 2.1, the entire heat map of customer data is not of equal interest, but rather the focus of the research is on the area of greatest accumulation.

### *2.4. Time Frame-Based Analysis (TFBA)*

The second methodological aspect introduces the time frame-based analysis according to [8]. This method is used to identify design-relevant loads based on time-dependent criteria and to further evaluate their intensities, durations and frequencies, which is necessary for the design of drive system components.

For illustration, Figure 4 schematically shows two loads, z<sup>1</sup> and z2, which are identical with respect to their classic statistical properties such as the root mean square (rms) zrms, the minimum value zmin and maximum value zmax as well as their distribution functions.

**Figure 4.** Comparison of two statistically equal loads. Modified from [9], Technische Universität Dresden, 2016.

Since these parameters do not provide any time-related information such as duration and frequency or the time interval between specific loads, the characteristics of these two loads cannot be compared. This circumstance is illustrated by the different temperature curves ϑ<sup>1</sup> and ϑ2, which leads to different temperature gradients and thus, different thermal stresses on the components.

Therefore, the time frame-based load analysis is needed, in which time frames *τtf* with continuously increasing width are defined and shifted over the time series [9]. According to Equation (3), the maximum rms value is calculated for each time frame width.

$$Z(\tau\_{tf}) = \max\left(\sqrt{\frac{1}{\tau\_{tf}} \cdot \sum\_{t}^{t+\tau\_{tf}} z(t)^2 \cdot \Delta t}\right) \tag{3}$$

For this purpose, the conditions pointed out in Equation (4) need to be considered: The time frame width *τtf* must be at least equal to the time step width **∆***t*. Additionally, the overall time series length *T* must be extended to length *ttotal* to ensure considering sufficient values for the largest time frame *τtf,max* at the last time step *t* = *T*. Finally, the time frame is moved over the whole time series from *t* = 0 to *t* = *T*.

$$\begin{array}{c} \mathsf{r}\_{tf} \geq \Delta t\\ T + \mathsf{r}\_{tf,\max} \leq t\_{total} \\ \mathbf{0} \leq t \leq T \end{array} \tag{4}$$

Figure 5 shows the resulting time-related continuous load curves for the two loads mentioned above. The diagram displays the maximum values for both loads z<sup>1</sup> and z<sup>2</sup> and each time frame width, which indicates that the respective rms value is demanded at least once for that frame.

**Figure 5.** Exemplary time-weighted continuous load curves. Modified from [9], Technische Universität Dresden, 2016.

As expected from the temperature curves ϑ<sup>1</sup> and ϑ<sup>2</sup> above, the comparison between the two signals at *τtf* = 3 s indicates that the rms value z<sup>1</sup> is greater than z2. This leads to the envelope curve zmax, which represents the overall highest value of all loads. These highest values indicate maximum thermal load and are therefore crucial for the system design.

This method allows the analysis of different time series, regardless of their length. However, only those physical quantities that are directly proportional to the losses of a component can be analyzed [9]. With respect to the design of drive systems, power and torque are suitable quantities.

### *2.5. Frequency of Time Frames*

Finally, the analysis of the frequency of time frames evaluates the correlation of duration and frequency of occurrence. By displaying the time frame frequency over the time frame width, as shown in Figure 6, different loads can be compared by evaluating how often and for how long certain loads occur.

The curves visualize the duration and frequency of the rms value of both loads z<sup>1</sup> and z2. First of all, the black graph shows that all rms values are positive for both loads, so, as expected, the frequency of the rms value is 100%. Additionally, the figure displays the curves for an exemplary threshold value of 60, so the curves show the rms values zrms ≥ 60. In this case, zrms,1 is greater than zrms,2, both in terms of duration and frequency. This not only means that the time frame *τtf*,1 for this specific rms value is longer, but also the frequency of occurrence in this load has a higher share in the overall process. This leads to z<sup>1</sup> being critical for the system design. With the help of these analyses, loads of different duration, intensity and characteristics can be compared and design-critical loads can be identified.

**Figure 6.** Exemplary frequency of time frames.

### **3. Conclusions and Future Work**

The method introduced in this work allows the derivation of relevant parameters for the design of vehicle drive systems based on statistical customer data. For this purpose, time series are analyzed by comparing them with customer data. The aim is to identify customer-representative time series. Furthermore, these representative time series are investigated using the time frame-based load analysis. This procedure of describing the time-dependent characteristics of a time series allows the detection of design-critical loads and generates relevant parameters for the system design.

These relevant parameters such as peak values and continuance values for torque and power as well as working points and sweet spots represents the input for the design of overall drive systems. By limiting this input to the most frequently required customer needs, the efficiency of the overall system can be increased.

**Author Contributions:** Conceptualization, methodology, software, validation, formal analysis, investigation, resources, data curation, writing—original draft preparation, writing—review and editing, visualization, project administration, funding acquisition, R.M.; supervision, F.G., F.P. and H.K. All authors have read and agreed to the published version of the manuscript.

**Funding:** This research is funded by the Publication Fund of the Karlsruhe Institute of Technology.

**Institutional Review Board Statement:** Not applicable.

**Informed Consent Statement:** Not applicable.

**Conflicts of Interest:** The authors declare no conflict of interest.

### **References**

