ork focuses on developing a frequency analysis tool suite for OptimumG’snew vehicle dynamics software. Traditionally, no software development methodologies areused for any tool suite development which focuses on implementation using libraries andcode. Though this method ensures successful implementation of the software, it doesnot guarantee an structural architecture or the fact that all stakeholder expectations aresatisfied. The lack of a proper architecture makes it difficult for a new user to understandthe tool suite and might cause hindrance on the future development and advancement.Tofacilitate this, methodologies such as SYSMOD, MDSE, TRIZ and IBM Rhapsody withSysML diagrams are integrated which helps in the development of a software tool suitethat is architecturally sound and easy to maintai

Conclusion

Test Cases

Bode Tes

Quarter Car

tware tool suite

ms 00 mu)( ̈zs ̈zu)+( −FC −FD + mS g + FaeroFC + FD + mug −

Quarter Car Inputs and Outputs

Quarter Car Model Implementation

Hysteresis

β sweeps (Figure 5.14) were performed with the values set to A = 1 and γ = −1.Increase in the value of β leads to larger area under the curve and slight increase in slopeand amplitude.The γ sweeps (Figure 5.15) were conducted using A = 1 and β = 0.1. Increasingthe value of γ results in decreasing slope but more importantly change of direction fromconcave to convex with change in sign of the γ value.Figure 5.15: γ Sweep Hysteresis CurveTable 5.9: Bouc-Wen System ClassificationCase Ω Upper Boundon |z(t)| ClassA > 0 β + γ > 0 and β −γ ≥0 R max(|z(0)|,z0 Iβ −γ < 0 and β ≥0 [−z1,z1] max(|z(0)|,z0 IIA < 0 β −γ > 0 and β + γ ≥0 R max(|z(0)|,z0 IIIβ + γ < 0 and β ≥0 [−z0,z0] max(|z(0)|,z0 IVA = 0 β + γ > 0 and β −γ ≥0 R |z(0)| V

Revised Hysteresis RequirementsThe hysteresis concept was a relatively unknown concept to the thesis author as well as tothe stakeholders, i.e. OptimumG. The initial research carried out to elicit the requirementsregarding the hysteresis was pretty basic. Now, equipped with further understanding of thehysteresis concept, the requirements have changed based on the modelling technique. Thisis a very pivotal tool in using SYSMOD and SysML along with the SDLC framework whichlets the users perform repeat iterations as the model evolves and is made better overtimeor new features are added which helps in maintaining the software for long duration. Thenew Hysteresis Requirements are in the Figure 5.18.Figure 5.18: Modified Hysteresis Requirements

BenchmarkingThe Benchmarking of the FRTS library is done by using the Quarter Car model as the proofof concept. The test cases mentioned in Figure 3.21 are carried out. The benchmarkingof FRTS does not consider any performance metrics or error estimation, because the maingoal of the project is to develop the model and tool suite under a systematic and methodicalprocess rather than pure results.

Quarter Car Coilover Deflection

ned earlier, MATLAB is used as the reference library and for power spectraldensity the “pwelch” function was used. The “cpsd” function is used for Cross powerspectral density. The deviation

pectral density can be seen in Figure 5.25 and Figure 5.26 respectively. Thisis due to the scaling factors that the FFTW3 library introduces for the overlapping andwindowing functionality. This makes the mean curve have a similar shape but the powerof the output is scaled down. Thi

Bode DiagramSimilar to the spectral density the bode diagram is plotted and cross verified with theMATLAB function “tfestimate” to obtain the frequency response for the Quarter Carmodel, as shown in Figure 5.27. The Magnitude tends to have similar mean curve and thephase matches exactly in both the libraries.Figure 5.27: Bode DiagramThe PSD and CPSD have a difference between both libraries, but the transfer func-tion is almost similar. This is because both the CPSD and PSD have a lower magnitudeand power respectively, as explained above, which would have been cancelled out in theTFestimate, since the tfestimate = CPSD/PSD Thus the general shape of the graphsseem similar, the difference could be due to the windowing and the overlapping factors.

FTW3 library does not allow to control the scaling factors of the overlappingand windowing. A different library could be used which gives access to such factors or thewindowing and overlapping functions could be manually coded in by the user

The test cases is made to look at the model holistically and determine the scenarios thatneed to be tested and benchmarked to certify that the model has performance criterionsimilar to pre-existing libraries. The purpose of a test case is to determine if differentfeatures within a system are performing as expected and to confirm that the system satisfiesall related standards, guidelines

MethodologyAs mentioned earlier, various methodologies are integrated in this thesis work. In thischapter, a brief description of each methodology and how they contribute towards the goalis explained.2.1 Model Driven System EngineeringTo engineer large, complex, and interdisciplinary systems, modeling is considered as theuniversal technique to understand and simplify reality through abstraction, and thus, mod-els are in the center as the most important artifact throughout interdisciplinary activitieswithin model-driven engineering processes. Model-Driven Systems Engineering (MDSE) isa systems engineering paradigm that promotes the systematic adoption of models through-out the engineering process by identifying and integrating appropriate concepts, languages,techniques, and tools. A key principle of MDSE is to address engineering with formalmodels, i.e.,machine-readable and processable representations. Based on this foundation,modeling provides a set of advantages for driving the engineering process. The applicationof model validation, testing, verification, simulation, transformation, and execution enablesthe automation of engineering process steps and supports the traceability of engineeringartifacts to improve quality management. The models can be:•Compared to reason about differences between model versions•Merged to unify different versions of a model•Aligned to create a global and integrated representation of the system from differentviewpoints to reason about consistency•Refined to produce platform-specific models from platform-independent models•Translated to other formalism for code generation, verification, and simulationModels are used to explore the structure, behavior, and operational characteristics of

Summary

a software/model involves multiple complex steps. Without a properstructured architecture, there can be a misalignment between the users’ and developers’needs or the end product may sometimes be far from the stakeholders’ expectations. Toresolve this, Model Driven Software

Future RecommendationsThe following can be the possible recommendations as s future work of this thesis:•Requirement analysis for detailed communication between IBM, Visual Studio andMATLAB.•Implementation of a more complex Bouc-Wen equation or using different methodo-logies for hysteresis modeling which contain optimization algorithm for defining thehysteretic curve.•Scaling the Quarter car to a bicycle model and eventually to a full car model.•Coupling of Newmark-β solver with the existing Quarter car model.•Core automation for conversion of the frequency response functions into .dll fileformat which can be directly implemented into the OptimumG software.

FFTThe Fast Fourier Transform of the received data is done using an external library. Thelibrary selected to use was ”FFTW3” for c++. Research was conducted on other librariesas well but the functional complexity along with ease of use made “FFTW3” the FFTlibrary of choice. A FFT plan has to be made alongside the already existing functionsprovided by “FFTW3”. This is shown below.void fft(fftw_complex *in, fftw_complex *out){// create a DFT planfftw_plan plan = fftw_plan_dft_1d(N, in, out, FFTW_FORWARD, FFTW_ESTIMATE);// execute the planfftw_execute(plan);

Data ProcessingThe Quarter Car model in MATLAB & Simulink saves the data in a “.txt” file format withthe required output for the given input and time. This “.txt” file is accessed by the DataProcessing part of the code and is stored in variables with the type, vector < float >. Ituses the getline command to read each line and store it in specified variables.ifstream coeff(file); //opening the file.if (coeff.is_open()) //if the file is open{//ignore first linestring line;getline(coeff, line);

Generally the code could also be implemented under IBM Rhapsody using sequence orstate machine diagrams. This helps to keeps the overall process automated and well struc-tured. But, due to the lack of a vector macro in IBM Rhapsody, the task of coding insidethe diagrams is made almost improbable. In this case, the functionality,i.e. the coding isdeveloped in Visual Studio 2017. The current release of IBM Rhapsody(version 9.2) doesnot support the required macros, but future releases are being developed to support vectormacros. Implementing the code in C++ and visual studio makes the importing of codeinto IBM Rhapsody in future releases relatively straightforward. The rest of the chapter,shows the code developed in Visual Studio. This tool implementation method is shown inFigure 4.1 The main functions in the code are displayed, whereas the rest of the code isgiven in the Appendix E.Figure 4.1: Tool Implementation Flow

lities revealed by the KANO analysis. The test case is modelled asa combination of requirement and use case because it acts as a need as well as a service. Anew stereotype, called test case, was created in IBM Rhapsody to combine the use case andrequirement. This is modelled in a requirements diagram to show and maintain structurein the test cases as well.Figure 3.21: FRTS Test Cases Requirement Diagram

hese functions contain the basic functionality of the system as visualized in the require-ment analysis. These functions fall under the ”Must-have” category of KANO analysis.Based on the structure, shown in section 3.4,

The FRTS tool suite needs to contain certain frequency response functions which are re-quired to study and analyze the effect the of input parameters on the output of the system.Plotting the different frequency response functions of a model helps to gain insight into thecharacteristics of linear model dynamics[11], including the frequency of the peak responseand stability margins. Frequency response plots provide insight into linear systems dynam-ics, such as frequency-dependent gains, resonances, and phase shifts. Frequency responseplots also contain information about controller requirements and achievable bandwidths.Finally, frequency response plots can also help you validate how well a linear parametricmodel, such as a Quarter Car transfer function [18] or a state-space model, captures thedynamics. Another major advantage is to estimate a frequency response from the datausing spectral analysis (non-parametric model), and then plot the spectral analysis resulton top of the frequency response of the parametric models. Because non-parametric andparametric models are derived using different algorithms, agreement between these modelsincreases confidence in the parametric model results. Therefore the following frequencyresponse functions[5] need to be modelled in the software tool suite for a complete analysisof the model:•Frequency Response of the Plant•Bode Diagram– Magnitude– Phase•Spectral Density calculation– Fast Fourier Transform(FFT)– Windowing method– Overlapping method– Power Spectral Density(PSD)

Functional Implementation

of flow into and out of the Block by associating them on the Block with aValue Property. Two flow ports in different blocks are connected using a connector whichlets the variable pass through. Multiple connectors can be connected to/from one flowport. This internal structure in FRTS i

FRTS StructureThis is the system of system architecture that depicts the hierarchy of the system func-tionality. These are created out of the use cases that have been established in the previoussection. Since, use cases cannot be used to build code, the block element in SysML is usedas the structure for each use case functionality. The system architecture is developed usingthe block definition diagram(BDD) in SysML, as shown in the Figure 3.19.Figure 3.19: FRTS System Architecture - Block Definition Diagram3.4.2 Internal FRTS Structure & CommunicationThe internal structure of the system is used as an Internal Block diagram(IBD) in SysMLlanguage. It captures the internal structure of a Block element, in terms of its properties(Ports and Parts) and the connections between those properties. The IBD is an instanceof the Block element, and the Block is the classifier for the IBD. The elements in the IBD

FRTS - System Architecture

The SYSMOD method also states that alongside defining use cases, there must be atraceability between the use case and the requirement it is satisfying, both textually andgraphically. So, a requirement

Use CasesThe next step in SYSMOD methodology is to specify what a system needs to do as aconsequence of the requirements, SysML makes use of Use Cases. Use Case blocks describethe operations within FRTS and the communication between FRTS and its external actorsthat are required to satisfy the requirements. These Use Case blocks are then linked withother Use Case blocks and the external actors in a Use Case diagram to visualize the orderof execution to satisfy the requirements. These Use Case diagrams are further stored underpackages to visualize the order of execution of the overall functionality of FRTS. Each UseCase has a description of functionality and external actors in the following format:•Requirement addressed•Name

The hysteresis requirement is an important aspect in modelling

quarter car model requirements

Project Requirements

n to the intra-requirement dependency inside each major requirement, thereare relations among different requirements that have a cross dependency

nother important factor in this dependency diagram is that the lower priority re-quirements always depend on the higher priority requirements

Bode requirements

Some of the requirements under FRTS has a dependency

System Requirements

Requirement AnalysisIn FRTS, the requirements are divided into two main sub categories:•System Requirements - Features regarding the Frequency Response functions•Project Requirements - Feature regarding the thesis and Quarter Car modelIn addition to sub dividing the requirements itself, a package is added in IBM Rhapsodyto encapsulate the structure provided in the requirements. A package is akin to a folder ina personal computer and a set of packages can be shown using a package diagram. Thisfacilitates a structured hierarchy to requirements engineering and maintaining traceability

Requirements

System Context

The next step to TRIZ analysis is defining the three pillars of MDSE in the context ofthis thesis. The 3 pillars are shown in the Figure 3.1:

establish a solid base to start the SYSMOD part of the softwaredevelopment life cycle process. Each SYSMOD process is described in the sections below.The system is titled as “Frequency Response

Software Development - FRTSAll software tools must tackle 3 major factors: Complexity, Lack of Understanding andCommunication. The methodologies introduced in chapter 2 are used to provide solutionfor these 3 issues. In software development, to counter complexity, the model based systemengineering along with SYSMOD is implemented and is communicated through SysMLlanguage. The lack of understanding at the early stage of software development is tackledusing the TRIZ 9 box diagram.One of the main criterion to begin the thesis is to understand the current system availableto OptimumG. In order to pinpoint the exact system that needs to be worked on as wellas to understand the complexity involved in such a system, a TRIZ 9-box diagram isused. TRIZ helps to uncover the scope of the problem and also helps in derivation of highlevel requirements. TRIZ 9-box is useful to have a holistic view to the overall system.Therefore, in this 9-box diagram not only the Frequency response tools are analyzed butalso the requirement of quarter car model as a proof of concept is taken into account. TheTRIZ 9-box was created in conjunction with OptimumG, as shown in Figure 3.2.Figure 3.1: The Three Pillars of MDSE specific to FRTS

Chapter 5

Scope of ThesisThe Scope of this thesis research is based on the proposed research questions defined insection 1.4 and is confined to five major objectives. Extensive research will be conductedon the following which could be extended to future works. The objectives are describedbelow:•Requirement Analysis of Frequency Response tools•Architectural design of the tool suite.•Develop behavioral or logical algorithmic diagrams for various frequency responsefunctions.•Benchmarking developed system against existing libraries.•Framework for code modularity and maintainability into OptimumG’s future soft-ware, i.e. conversion of framework from SysML to C++ .dll files.The following topics are considered to be out of scope or future works for the thesis:•Scalability of the model to Full Car model.•Modularity validation of the model.•Overall super-system level requirements of the future software.•Usage of commercial benchmarking tools.•Closed-loop frequency response tools.•Optimization or optimization techniques on the developed code or system.

The thesis also depends on a number of human aspects. This is taken into account usinga stakeholder analysis [4]. The stakeholder matrix defines the influence and the interest ofstakeholders in this system as well as the thesis, as shown in Figure 1.1. The stakeholdersare in the order of decreasing power :•OptimumG - The company proposing the project has a high influence as well asinterest in the final product.•Thesis Supervisor & University - In charge of thesis, again has both high influ-ence and interest.•Pre-Existing Libraries - The libraries which are available online majorly affect thecourse of the thesis.•Standards and Legal Regulations - Using the libraries involves working withlegal regulation for use in a proprietary software and also following certain codingand automotive software standards.•Developers - Technical people who work in aspects related to the product have anelevated interest as it effects part of the thesis.•Users - Users are the final consumers of the product. They have moderate interestbut low power to affect the product development.

Project ContextTo simulate a dynamic system, computation of its states at successive time steps over aspecified time span is required. This computation is carried out using numerical solversusing the information provided by the model of the system. The output from these numer-ical solvers needs to be analyzed, which can be done in both time-domain and frequencydomain. It is difficult to analyze the large and complex outputs in time domain since it isbased on differential equations[15]. Whereas in frequency-domain analysis, it is convertedto algebraic equations that are easier to solve[15]. Thus, OptimumG expects to have boththe functionalities implemented on Quarter Car model as a proof of concept [17]. Thoughthe quarter car is a simple vehicle model, it covers a variety of performance metrics thatneeds to be analyzed in a vehicle. The time constraint on this thesis and the complexity in-volved with the full car model makes the quarter car an ideal proof of concept. OptimumGhas already implemented the Time-Domain simulation of the quarter car model. Therefore,

Problem Context

he simplicity of the model is both a strength and a weakness. On the one hand, the smallnumber of parameters all