mar/content/improvements.tex

%&tex
\chapter{Improved Design Method}
\label{chap:improvements}
    \rro{Introduce}
    \rroi{Preliminairy design required complete new approach}
    \rroi{Better tooling}
    \section{System Baseline}
        The preliminary design phase is not a competent approach for the initial design of a physical system.
        In the waterfall-like approach each step is completely wrapped up before moving to the next step.
        Every subsequent step provides more and more information about the design.
        The information gives often insight in what could have been done better.
        Although it is possible to review previous completed steps, there is quite a barrier to revise these steps.
        Redoing previous work is demotivating and will be avoided as much as possible.
        \rrotodo{Fix these citations}
        This \emph{cost of change} is an inherent problem of the waterfall model \autocite{alshamrani, adenowo, petersen}

        The development was confronted with this decision during the feature definition step in \autoref{sec:featuredefinition}.
        The term feature is used for the different characteristics of the system.
        Were these features map adequately to specifications and software, it does not represents hardware components.
        Taking the following items from a single branch in \autoref{fig:robmosys}:
        \begin{enumerate}
        \item Draw a tweet on a whiteboard
        \item Writing
        \item Write a char at position
        \item Move Marker on board
        \item SCARA
        \end{enumerate}
        The first four items are characteristics of the system, where the first item is an abstract description of the complete system.
        The subsequent items become more specific with each step.
        The links between each subsequent item could be described "to perform this feature it is required that system can".
        These items are derived from the design specification, but are also useful as software.
        Item 4 would be the software implementation of the motor driver.
        This motor driver is called by the arm controller that is implement for item 3.
        The outlier in this list is the SCARA, it is not a sub-feature of \emph{Move marker on board}.
        The SCARA has motors, mechanical linkage, sensors, as sub-components, but it is not a feature.

        This was a known shortcoming during the case study.
        One of the solutions that was discussed was to build a feature dependency tree with an iterative approach.
        Each iteration of the design process would only cover one level of the dependency tree.
        The first iteration would thus deliver specifications, initial design, order of operations, and tests for the mission level: "Draw a tweet on a whiteboard".
        Followed by the second level which would repeat everything for \emph{Writing} and \emph{Wiping}.
        This approach would probably be better that the current approach in the feature definition.
        It would however require to review all the previous steps and rewrite most of the design method.
        Furthermore, it was estimated that the additional effort required to restart the design process would negatively impact the overall evaluation of the design method.
        Nevertheless is it required to find an improved design method.

        The iterative design would help generate a better method, but it still generates a single dependency tree.
        Therefore can only cover one type of dependency.
        \textcite{kordon_model-based_2007} presents their \ac{mbed} that is used for two development projects within NASA's Jet Propulsion Lab.
        The \ac{mbed} introduces a system hierarchy that separates the dependencies over three trees: specifications, functions, and components.
        Additionally it adds interfaces, that connect different sub-components, and operational scenarios to this hierarchy.
        The hierarchy is constructed iterative where each iteration generates a new level of sub-specifications, sub-functions and sub-components.

        





        
        
        




        The term feature was used as a universal concept for design features, hardware features and software features.

        This led to problems while creating a list of features.
        This led to problems during the feature definition step.
        The aim of the approach was to create a list of features.
        Due to the different nature of the features it was impossible to create a single list of features.
        Making a list for each group of features would result in problems with the selection of the features.

        The problem with the features became apparent during the feature definition step in \autoref{sec:featuredefinition}.


        Another problem is the waterfall-like approach.
        
        A possible solution that was discussed during the feature definition step in \autoref{sec:featuredefinition}.
        The current steps are strongly detached from each other. 
        

        

        
        
        \rro{In general, I underestimated the importance of the preliminary research}
        \rroi{\textcite{broenink_rapid_2019} also skips this part.}
        \rroi{As the focus of that paper was on the actual implementation, the preliminary phase was over looked}
        \rroii{However, bringing a system into being, the preliminary design phase is extremely important}
        \rro{For validation \textcite{garrett_322_2000} suggests:}
            \rroi{Looking at comparable systems' specifications}
            \rroi{Use of best engineering judgements}
            \rroi{Apply early simulation results for feedback}
            \rroi{A holistic view is required for validation of the initial design/specifications}
        \rro{Without mechanical experience is difficult}
        \rro{Better specification document is a team effort}
            \rroi{A team with engineers in their own specific field that is included in the design}
        \rro{\textcite{sheard_718_1998} discusses:}
            \rroi{Mechanical requirements are directly derived from and bounded by physics}
        \rro{Result: Mechanical specifications are easier to change}
            \rroi{More room for initial simulations, before making concrete specs}
    \section{Feature Separation}
        \rro{During the case study, the planned approach was not possible}
        \rro{Result: Improvised a structure that was loosly based on Robmosys}
        \rro{Proposed Improvement: Split layout for requirements, functions and components from State Analysis \textcite{kordon_model-based_2007}.}

        \rro{Instead of trying to start with a feature, a holistic model of essential elements should be created}
        \rroi{In the holistic basic model, review the features/components on their feasibility}
        \rroii{How likely is it that this specific component is going to work: And if not, what are the consequences? What do we need to change?}
        \rroi{Then add detail to the different subcomponents of that model}

    \section{Tooling}
        \rro{20-sim lacks an object oriented approach}
            \rroi{Adding detail to a submodel that is used more than once is a PITA}
            \rroi{Every model is a deepcopy}