mar/report.tex

%&tex
\documentclass[english,titlepage,nomath]{siltex-report}
\include{include/preamble}

\title{Title}
\subtitle{Thesis Report}
\course{}
\faculty{\large Electrical Engineering, Mathematics and Computer Science}
\supervisor{%
	Dr. ir. J.F. Broenink \\
	Ir. T.G. Broenink
}
\author{%
    Wouter Horlings
}

\begin{document}
\maketitle
\makerro
\chapter{Samenvatting}
Dit is nu een eerste opzet van de structuur van mijn verslag.
De eerste hoofdstukken komen goed overeen met mijn orinele projectplan.
Dan is er een hoofdstuk over de casestudy zelf.
Daarin ben ik tegen best wel veel dingen aangelopen.
Vooral omdat de methode toch direct was afgeleid van een meer softwarekant.
Al vrij snel kwam ik er achter dat een dynamisch model een interactie tussen powerports.
Waar software een duidelijke input en output heeft.
Het grote verschil komt hier dus ook een volgend "blokje" aan je output hangen wel gevolgen heeft voor je dynamische systeem en niet voor je software.

Features los van elkaar beschouwen is dus niet haalbaar in een dynamisch systeem.
Als je dit terugbrengt tot subsystemen dan kom je een heel eind verder.
Maar dan wordt het implementeren van een onderdeel gelijk een tijdverslindende stap.

In de stap zelf was het toevoegen van detail in kleine stukjes wel erg succesvol.
Maar dit komt ook in een aantal andere papers naar voren.

Ik heb een verzameling van dingen die beter kunnen in het process.
Maar het is nog wel interessant om te bespreken of een "hardware-only" systeem onwikkelen nog wel van deze tijd is.
Enige complexiteit is nu vaak uberhaupt mogelijk omdat er embedded software in kan.

Daaruit komt eingelijk ook het discussiestuk aan het einde waarbij ik best een aantal punten kon aandragen waarom dit zo veel belangrijker is voor software dan hardware.

\tableofcontents
\include{include/acronyms}
\chapter{Introduction}
    \section{Context of this Thesis}
        %Wat is het probleem?
        %    Cyber Physical systems worden steeds complexer.
        %    De complexiteit bemoeilijkt de ontwikkeling significant.
        %Hoe proberen we dat op te lossen?
        %    het paper introduceerd een gestructureerde design methode voor CPS.
        %    De methode breekt de ontwikkeling op in kleine stukken die elk individueel getest kunnen worden.
        %    Hierdoor kunnen in een vroeg stadium fouten in de ontwikkeling worden gedetecteerd.
        %    De methode is ontworpen rondom de ontwikkeling van embedded control software.
        %    Het dynamische model en de control law worden aan de hand van deze methode ontwikkeld.
        %    De case in het paper baseerd het dynamische model aan de hand van bestaande hardware.

        %    Maar ontwikkeling van een nieuw CPS betekent dat er ook het fysieke deel van het systeem ontwikkeld moet worden.
        %    Of de voorgestelde ontwerpmethode geschikt is voor het ontwikkelen hardware dan ook het doel van dit onderzoek.

        %    
        %    Als de methode gebruikt gaat worden voor de ontwikkeling van een CPS from scratch moet er onderzocht worden of deze methode past bij het ontwikkelen van nieuwe hardware.
        %    
        %    Maar Cyber Physical systems zijn multi disciplinair waarvan embedded control software een is.
            
        Design methodology for \ac{CPS} is one of the research topics within the department of Robotics and Mechatronics.
        A design method for rapid development of embedded control software is proposed by \autocite{broenink_rapid_2019} as part of this research topic.
        The design method in the paper is used to design a control system on an existing hardware system.
        The presented result shows a working control system for a small segway. 
        Broenink and Broenink emphasize that "this [result] does not mean that the same techniques cannot be applied to the physical part of the system."
        This thesis will analyse if these techniques can be applied to the development of a physical system.

        %The goal of this thesis is to present a method that is suitable for designing the physical part of a system.
        %The method is based on the rapid development design method.
        %Initially, 
        %to analyse which techniques are suitable to a physical system development.





        




    \section{Research Objective}

    In the basis this research started with the question if the design method can be applied to the physical part of a system.
    That answers is a quick no.
    In the early stage of the research it was found that some techniques cannot be copied from a software development into a hardware development.
    It is necessary to analyse which techniques cannot be used and replace or improve them.
    Otherwise, it is impossible to present a design method that can be applied in a hardware development at the end of this thesis.
    The research can be summarized in the following two research questions.
    \begin{itemize}
        \item Which techniques of the design method can be applied in the development of hardware?
        \item Which adaptations are required to create a design method that is suitable for the development of hardware?
    \end{itemize}
    
    
    


        %\rro{Which techniques of the design method can be applied in the development of hardware?}
        %\subsection{Which techniques of the design method can be applied in the development of hardware?}
        %    The starting point of this research is the design method by \autocite{broenink_rapid_2019}.
        %    Their design method consists of multiple techniques, in the form of different cycles and steps.
        %    Each of these techniques will be analysed to determine if they are applicable for the physical component of the design.
        %    %For any technique that is not applicable, we w
        %\subsection{Which adaptations are required to create a design method that is suitable for the development of hardware?}
        %    Techniques that are not applicable have to be improved or replaced.
        %\rro{Which adaptations are required to create a design method that is suitable for the development of hardware?}
    \section{Approach}
        \rro{Adapt the design method for hardware development}
            \rroi{Current design method gives an initial foundation for development}
            \rroi{However, lacks detail in some parts}
            \rroi{System Engineering will fill in the blanks}
            The first step is to create a concrete design method.
            The design method by \autocite{broenink_rapid_2019} is in an abstract form.
            It often leaves room for interpretation about how certain steps should be performed.
            However, this does not help the evaluation of the test method.
            If a step is not written down, it is difficult to point out flaws during the evaluation.

            By performing a case study where a physical system will be developed, the design method can be evaluated.
            However, the type of physical system strongly influences the success of the evaluation.
            On the basis of testing requirements, it was decided to develop a Whiteboard Writer.
            Implementing this system ensures sufficient complexity but still fits in the scope of this thesis.

            The next step is to perform the case study.
            Setting up evaluations forms ensures consistent feedback for each step in the case study.
            During the case study all the design method steps are performed one by one.
            Although the development of the Whiteboard writer was not completed.
            The result of the case study is a physical prototype of a subsystem and a substantial amount of feedback.
            Based on the feedback from the case study, an improved design method is proposed.
            



            

        \rro{Define a case study to test the design method}
            \rroi{To actually test the method we have to design something}
            \rroi{From multiple options we chose the whiteboard writer}
                \rroii{Complex enough}
                \rroii{Fits within the scope}
        \rro{Perform the case study}
            \rroi{The case study does not focus on the best product.}
            \rroi{Some design decissions are made to aid the evaluation of the design method}
            \rroi{Run continuous evaluation during the case study, to improve the design method}
        \rro{Use feedback to propose design method for the development of hardware}

    \section{Structure of this Thesis}
        \autoref{chap:analysis}
        \autoref{chap:systemdesign}
        \autoref{chap:casestudy}
        \autoref{chap:improvements}
        \autoref{chap:discussion}
        \autoref{chap:conclusion}

    \include{content/analysis}
    \include{content/designcycle}
    \include{content/casestudy}


\chapter{Improvements}
\label{chap:improvements}
    \section{Specifications}
        \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}

\chapter{Discussion}
\label{chap:discussion}
    \section{Complexity}
        \rro{\textcite{sheard_718_1998} discusses:}
            \rroi{Mechanical solutions are inherent simpler than software solution}
            \rro{Huge difference in states}
            \rroi{Mechanical part of prototype has 3 states}
            \rroii{2 angles, 1 marker angle (given that is still operating correctly)}
            \rroii{Double it for each angular velocity: making it 6}
            \rroi{Each embedded part of the stepper drivers have more than 30 states}
            \rroii{With two drivers it gives it easily 10 times more states already}
            \rroi{Software itself has more than 40 states}

            \rro{Mechanical states are linked}
            \rroi{Software engineer has to implement and link the states}

            \rro{Mechanical states/behavior is always limited by the law of physics.}
            \rroi{We cannot make mechanics al large as we want}
            \rro{Software has almost no scaling limitations}
            \rroi{Can have gigantious amounts of states}
            \rroi{States can be changed separately}
            \rroi{Only limitations are always the computing power}
            \rroi{Real-time limitations are occuring when we want to keep up with physics}
            \rro{Mechanics that reach the same complexity as software where this design method would be usefull is something that never fits in a Thesis.}
            \rroi{Probably only on industrial scale}

            \rro{The "soft" in software is based on that it can be changed, improved, tweaked.}
            \rroi{This does not mean that it is cheap or easy}
            \rroi{During prototyping/development it probably cheaper to make a change to the hardware}
            \rroi{From the point of production, software becomes cheaper to change than hardware}

            \rro{Humans design and build hardware, humans design software but a machine builds it.}
            \rroi{Therefore, any flaws that come to light during hardware build is spotted way easier.}

    \section{Features vs Subsystems}
        \rro{Original method is based on features and implementing them one by one}
            \rroi{Software can implement a single feature, where the output can be tested}
            \rroi{A single hardware feature cannot be tested as connecting another feature changes the output}
            \rroii{Difference between a power-connection and a singal-port}
            \rroi{Smallest division in hardware is a subsystem}

    \section{Interesting concepts}
        \rro{Some features are required for multiple design options}
        \rroi{Implementing them earlier does not contribute to the cost of switching design.}

\chapter{Conclusion}
\label{chap:conclusion}

\printbibliography
\end{document}