diff --git a/content/analysis.tex b/content/analysis.tex new file mode 100644 index 0000000..eb3925e --- /dev/null +++ b/content/analysis.tex @@ -0,0 +1,216 @@ +%&tex +\chapter{Analysis} +\label{chap:analysis} +The previous chapter introduced how two design methods are combined to form the bases for one complete design method. +In this chapter, a design plan is created from this combined design method. +The goal is to have a concrete design plan that is used in the case study. +All of the steps in the design plan must be specific such that each of these steps can be evaluated after the case study is finished. +The first three steps of the design phase are based on the \ac{se} approach and are already described with great extend by \textcite{blanchard_systems_2014}. +As the evaluation of \ac{se} is not in the scope of this thesis, this chapter only covers the minimal description of the design steps in \ac{se}. +The steps that are introduced by \ridm are covered in more detail. + +\section{Systems Engineering} + The goal of the preliminary design is to setup system requirements and an initial design according to the problem definition. + Although these design steps in \ac{se} play a crucial roll in the success of the development, they are, however, very exhaustive. + A major part of this complete design process is the required documentation to ensure agreement about the design between the different stakeholders. + Resulting in a process that can take months or even years, which is not feasible for this thesis. + In this thesis, this design plan is only used for evaluation and has only one stakeholder, the author. + This allows for a simple implementation of the \ac{se} approach, as it not possible to create a false start due to misunderstanding, saving valuable time. + For each of these \ac{se} steps is explained what is involved with a full implementation, and what part of the step is used in the design plan. + + \subsection{Problem Definition} + Before any design process can start, the "problem" has to be defined. + In other words, why is the function of the system needed? + This is described in a \emph{statement of the problem}. + In this statement of the problem it is important to describe "what" has to be solved, not directly "how". + \textcite{blanchard_systems_2014} also note that "defining the problem is often the most difficult part of the process". + It is important to ensure good communication and understanding between the different stakeholders. + Otherwise, it is possible that the designed product is not up to the customers expectations. + It furthermore involves defining the subjects like what are the primary and secondary functions? When must this be accomplished? What is not a function? + For this thesis, however, the problem definition is limited to a short statement of the problem, covering some required functions with corresponding requirements. + + \subsection{System Requirements} + The system requirements are derived from the problem definition, and describe the characteristics of the system. + As these characteristics form the foundation of the system, the requirements must be defined without any ambiguity, vagueness or complexity. + The requirements are written according to the \ac{ears} \autocite{mavin_easy_2009}. + \ac{ears} was chosen for this design method due to its simplicity, which fits the scope of this thesis. + Later in the design, these requirements are divided over the subsystems. + Any issues, like ambiguity, in the requirements, propagate through these subsystems. + This might lead to a redesign of multiple sub-systems when these requirements have to be updated. + + \subsection{Initial Design} + \label{sec:se_initial_design} + In the initial design step, the "what has to be solved", is expanded with a solution on "how it is solved". + To find the best solution it is important to explore the different solutions and design space. + Often, there are many possible alternatives but they must be narrowed down to the solutions that fit within the schedule and available resources. + This step results in one initial design that is used in the next phase of the design. + +\section{Rapid Iterative Design Method} + From this point, the design plan is based on the \ridm and not anymore on the waterfall model. + The first step is the feature definition, which prepares the required features based on the initial design. + The features are defined by splitting the system in such a way that the results of each implemented feature are testable. + The definition of the feature contains a description and a set of sub-requirements which is used to implement and test the feature. + During the feature definition, the dependencies, risks and time resources are determined as well, this establishes the order of implementation in the feature selection step. + + The second step is the feature selection, where one of the features is selected. + This selection is based on the dependencies, risk, and time requirements in the feature definitions. + The third step is the rapid development cycle, which uses the sub-requirements and description of the selected feature to create an initial design, a minimal implementation and tests. + In the last step, the variable detail approach is used to add detail to the minimal implementation over multiple iterations. + The tests are used to determine if the added detail does not introduce any unexpected behavior. + This cycle of adding detail and testing is repeated till the feature is fully implemented. + From this point, the \ridm is repeated from the second step until all features are implemented. + +\subsection{Feature Definition} + \label{sec:featuredefinition} + During the feature definition, the system is split into features as preparation for the rapid development cycle and the variable-detail approach. + The aim of the \ridm is to have short implementation cycles to have early testing feedback. + To achieve this, the features are as small as possible, but can still be implemented and tested individually. + Together with the definition of the features, the requirements are divided along the features as well. + The optimal strategy on splitting features and specifications is strongly dependent on the type of system. + Therefore, the best engineering judgement of the developer the best tool available. + + Sometimes features are dependent on each other, the implementation of one feature influences another. + This dependency can occur in specifications, where strength of one feature dictates the maximum mass of another feature. + Such a dependency can work both ways and can be resolved by strengthening the one feature, or reduce the weight of the other feature. + Another type of dependency is when the implementation influences other features. + In this case, if the implementation of one feature changes, it requires a change in the other features. + An example of this is a robot arm, where the type of actuation strongly influences the end-effector. + When the robot arm approaches an item horizontally, it requires a different end-effector than approaching the item vertically. + + Due to these dependencies it is possible that the division of requirements changes, because the result of the implemented feature was not as expected. + This is not directly a problem, but a good administration of the requirements makes an update of the requirements easier. + +\subsection{Feature Selection} + \label{sec:feature_selection} + The rapid development cycle does not specify which feature is implemented first, even though the order of implementation does change the feasibility of the complete development. + An example that shows the importance of the order of features is the development of a car. + To have a critical damped suspension in a car, the weight distribution of the car must be known. + If the suspension of the car is designed before all the features that determine the weight distribution, it is likely that the suspension design is not up to specifications. + Resulting in a redesign of the suspension feature and thus increasing the overall development cost. + This example is caused by the dependency between different features. + \begin{marginfigure} + \centering + \includegraphics[width=2.9cm]{graphics/feature_dependency.pdf} + \caption{Dependency graph for features.} + \label{fig:feature_dependency} + \end{marginfigure} + \begin{table}[] + \caption{Comparison of features with their corresponding risk and time. + The last column is the risk value divided by the number of days.} + \label{tab:feature_selection} + \begin{tabular}{l|r|r|r|r|r|} + \cline{2-6} + & \multicolumn{1}{l|}{Dependees} & \multicolumn{1}{l|}{Tests} & \multicolumn{1}{l|}{Risk} & \multicolumn{1}{l|}{Time} & \multicolumn{1}{l|}{Risk per time} \\ \hline + \multicolumn{1}{|l|}{Feat. A} & 2 (2, 3) & 2 & 15 \% & 3 days & 5 \\ \hline + \multicolumn{1}{|l|}{Feat. B} & 0 & 3 & 40 \% & 5 days & 8 \\ \hline + \multicolumn{1}{|l|}{Feat. C} & 1 (5) & 5 & 25 \% & 2 days & 12.5 \\ \hline + \multicolumn{1}{|l|}{Feat. D} & 0 & 4 & 15 \% & 1 day & 15 \\ \hline + \multicolumn{1}{|l|}{Feat. E} & 0 & 4 & 45 \% & 6 days & 7.5 \\ \hline + \end{tabular} + \end{table} + + To determine the order of implementation of features, a dependency graph and a comparison table is made. + The dependency graph and the comparison table for a theoretic system is shown in \autoref{fig:feature_dependency} and \autoref{tab:feature_selection} respectively. + The comparison table has dependees column, that describe the number of features that are depending on that specific feature, and are derived from the dependency graph. + The tests column describes the number of tests that are covered by implementing this feature. + The risk per time score for third rule is calculated by dividing the risk score with the time score. + The goal of this score is to eliminate as much risk as possible in the least amount of time. + It seems logic to always implement the highest risk feature first, but it is possible to finish multiple features with a lower risk in the same time period. + This is visible in \autoref{tab:feature_selection}: In a time span of 6 days it is possible to implement feature E or features A, C, and D. + The risk that is cleared by E is 45 \% which is significantly less than the combined 65 \% of A, C and D. + Due to the limited scope of this thesis, it is not possible to give a good metric for determining risk and time. + Nevertheless, it is strongly advised that the developer defines some metric that fits his project best. + + With a completed table, the order of implementation of features is determined by the following rules: + \begin{enumerate} + \item Features that are dependencies of others must be implemented first. + \item Features that complete more system test than other features when implemented have priority. + \item Features with the higher \emph{risk per time} score than other features have priority. + \end{enumerate} + The rules are applied in order, if one rule reduces the set to a single feature to implement the rest of the rules are skipped. + The third rule is a sorting rule, and the feature that fits best is implemented. + In case of a draw or in special cases the developer decides what feature to implement next. + + Looking at an example of 5 features: + As seen in \autoref{fig:feature_dependency}, Features B and C are dependent on feature A. + Feature D does not have any dependency connections, and feature E is dependent on C. + Together with the information in \autoref{tab:feature_selection}, the order of implementation is: + \begin{description} + \item[Feature A:] has two features that are dependent on this feature, more than any other. + \item[Feature C:] has one feature that is dependent on this feature, most dependencies after A is implemented. + \item[Feature D:] has the same number of tests as E, but D has a significant higher risk per time score than E + \item[Feature E:] has the most number of tests. + \item[Feature B:] only one left to be implemented. + \end{description} + Note that this example assumes that nothing changes. + In case of a feature not being feasible during the implementation, the design has to be reviewed. + This also means that the dependency graph and comparison table change, resulting in a different order of implementation. + +\subsection{Rapid Development Cycle} +Each iteration of this rapid development cycle implements one complete feature. +The feature that is implemented is selected in the prior feature selection step. +The goal of this step is to lay the foundation for the development of the feature. +This foundation consists of a basic model, a set of detail elements and a list of tests. +The set of detail elements is a collection of design aspects that are added to increase the detail during the next design step. +These detail elements can represent behavior, parasitic elements, or components. +How these detail elements are implemented and what the basic model consists of is based on the initial design of the selected feature. + +The initial design of the feature is similar to the system wide approach in \autoref{sec:se_initial_design}. +It consists of a design space exploration, but with more detail, which is possible as the feature is significantly smaller than the complete system. +From the design space exploration, the developer selects the optimal design choice for the current feature. +For this design choice, a design document is made that illustrates the rough shape and dynamics of the implementation. + +The basic model and the detail elements are based on an initial design of the feature. +The basic model consists of only the most basic elements of the design. +As the basic elements that make the basic model differ strongly per system, there is not a specific approach. +A good starting point is to identify the interesting energy states of the system. +The energy states of interest can include the energy states that are dominant, but also the states that are chosen by the developer. +These last states could represent the output states or status that have to be measured. +%However, the basic model should at least represent the dominant energy states of the feature. +In the end, the developer decides if states are required and implement them in the basic model. +All the elements that are part of the initial design but are not part of the basic model are the detail elements. + +Lets take a motorized double inverted pendulum for example, which consists of two arms with motorized joints. +Both pendulum arms are dominant energy states. +The electrical motors have also internal states, but store significantly less energy than the pendulum arms. +An basic model would in this case only consists of the arms, possibly even without any dynamic behavior. +The dynamic behavior, motor characteristics, resistance, or gravitational force are examples of detail elements that can be added to increase the detail. + +To finish this step all that is left is to describe a list of tests. +The goal of these tests is to verify if the design meets the specifications of the feature. +The tests have a short description on how to perform the tests and what should be achieved. +It is important that all the specifications are covered by at least one test. +This relatively simple approach of testing is possible due to the limited scope of this thesis. +For a complexer design, the testing needs to be automated. +The \ac{amt} \autocite{jansen_automated_2019} is an interesting method to perform the testing of the models. +However, at the time of writing, the software is in a proof of concept state and not usable for this thesis. + +\subsection{Variable Detail Approach} +With the variable detail approach the basic model is developed into a refined model of the feature. +This is done by implementing the detail elements over the course of multiple iterations. +To determine the order of implementation of these elements the approach for the order of features from \autoref{sec:feature_selection}. +Each iteration produces a new model with more detail than the previous. +The newly added detail is evaluated by performing the tests that were defined during the rapid development cycle. +\begin{figure} + \centering + \includegraphics[width=8.5cm]{graphics/test_flow_graph.pdf} + \caption{Decision flowchart for failed test results.} + \label{fig:test_flow_graph} +\end{figure} +Not all tests are expected to succeed from the start, as not all details are implemented. +For example, if the internal resistance of a electric motor is not yet implemented in the model, the motor can draw an unlimited current, and this would exceed the current draw specifications of the motor. +The decision flowchart in \autoref{fig:test_flow_graph} in determines whether the design must be reviewed or can continue on a failed test. +The decisions are made with the following questions: +\begin{itemize} + \item Passed Before? The current test of the current design failed, but was there a previous detail level where it passed? + \item Expected to fail? Does the test fail as a direct result from the added detail and was that intentional? + \item Expected to pass? Should the added detail to the model result in a pass of the test? + \item Will pass in future? Is there an element that will be implemented that results in a pass of the test? +\end{itemize} +In the case that the implementation of a detail element fails multiple times, the developer has to investigate if implementing the feature is still feasible. +This could result in a redesign of the feature or system. +When and how this decision has to be made differs per situation and is outside the scope of this thesis. +The developer must evaluate if there are feasible alternatives left for this element, feature or system, and apply these alternative if possible. + +When all detail elements are implemented and the basic model has evolved into a refined model of the feature, the design cycle moves back to the feature selection. +In the case that this is the last feature to implement, this concludes the development. diff --git a/graphics/design_flow_analysis.tex b/graphics/design_flow_analysis.tex new file mode 100644 index 0000000..b53c134 --- /dev/null +++ b/graphics/design_flow_analysis.tex @@ -0,0 +1,17 @@ +\documentclass{standalone} +\usepackage{tikz} +\usetikzlibrary {arrows.meta,graphs,graphdrawing,positioning} \usegdlibrary {layered, trees} +\tikzset{nodes={text height=.7em, text width=2.8cm, align=center, +draw=black!50, thick, font=\footnotesize, fill=white}, +>={Stealth[round,sep]}, rounded corners, semithick} + +\begin{document} +\begin{tikzpicture}[on grid,y=1.2cm,x=3.2cm] + \draw[fill=lightgray] (-1.7cm , 1.4cm) rectangle (1.7cm, -4.1cm); + \draw[fill=lightgray] (-1.7cm,-4.3cm) rectangle (5cm, -8.0cm); + \input{design_flow.tikz} + \node (prep)[above=0.7 of pd, draw=none, fill=none] {Preliminary Design}; + \node (b)[right=0.5 of rd,fill=none, draw=none] {}; + \node (ridm)[below=0.7 of b, fill=none, draw=none,text width=5cm] {Rapid Iterative Design Method}; +\end{tikzpicture} +\end{document} diff --git a/graphics/test_flow_graph.tex b/graphics/test_flow_graph.tex new file mode 100644 index 0000000..77def6a --- /dev/null +++ b/graphics/test_flow_graph.tex @@ -0,0 +1,37 @@ +%&tex +\documentclass{standalone} +%\usepackage[]{siltex} +\usepackage{tikz} +\usetikzlibrary {arrows.meta,graphs,positioning,shapes.geometric} +\tikzset{nodes={text height=.7em, text width=1.7cm, align=center, +draw=black!50, thick, fill=white, font=\footnotesize}, +>={Stealth[round,sep]}, rounded corners, semithick} + +\begin{document} +\begin{tikzpicture} + [on grid,y=3.0cm,x=3.0cm, auto, + decision/.style={diamond, text width=4em,align=flush center, inner sep=1pt}, + block/.style={rectangle, minimum height=4em, text width=4em}, + cloud/.style ={draw=red, thick, ellipse,fill=red!20, minimum height=2em}] + + \node[block] (ft) {Failed Test}; + \node[decision] (pb)[below = 1 of ft] {Passed Before?}; + \node[decision] (ep)[below = 1 of pb] {Expected to pass?}; + \node[decision] (ef)[right = 1 of pb] {Expected to fail?}; + \node[block] (cont)[below = 1 of ef] {Continue}; + \node[decision] (fu)[right = 1 of cont] {Will pass in future?}; + \node[block] (res)[below = 0.8 of cont] {Review Design}; + \begin{scope}[nodes={draw=none, fill=none, midway,text width={}}] + \path[->] (ft) edge (pb) + (pb) edge node {no} (ep) + (ep) edge node {no} (cont) + (pb) edge node {yes} (ef) + (ef) edge node {yes} (cont) + (fu) edge node {yes} (cont); + \draw[->] (ep) |- node[near start] {yes} (res); + \draw[->] (ef) -| node[near start] {no} (fu); + \draw[->] (fu) |- node[near start] {no} (res); + \end{scope} +\end{tikzpicture} +\end{document} + diff --git a/report.tex b/report.tex index e9d12c7..a48eb76 100644 --- a/report.tex +++ b/report.tex @@ -26,6 +26,7 @@ \tableofcontents \input{introduction} \input{background} +\input{analysis} \input{case_method} \input{case_experiment} \input{case_evaluation}