master-thesis
/
mar
1
0
Vork 0
Code Kwesties 0 Pull-aanvragen 0 Publicaties 16 Wiki Activiteit
Bladeren bron

update report

rro
Wouter Horlings 5 jaren geleden
bovenliggende
5fedfb9e9c
commit
eec83808ef
6 gewijzigde bestanden met toevoegingen van 443 en 224 verwijderingen
Zij-aan-zij weergave
Diff Options
Show Stats Download Patch File Download Diff File
  1. +60
    -59
      content/analysis.tex
  2. +123
    -47
      content/casestudy.tex
  3. +59
    -0
      content/conclusion.tex
  4. +134
    -0
      content/discussion.tex
  5. +22
    -22
      content/improvements.tex
  6. +45
    -96
      report.tex

+ 60
- 59
content/analysis.tex Bestand weergeven

@@ -1,71 +1,72 @@
%&tex
\chapter{Analysis}
\label{chap:analysis}
\section{Design Methods}
\rro{Introduce the three design methods}
\rroi{Our design method is based on rapid development}
\rroi{Rapid development also introduces variable detail method}
\rroi{Where both methods lack we will fall back to Systems Engineering}
\subsection{Rapid Development}
\textcite{broenink_rapid_2019} presented an approach for rapid development of embedded control software.
The approach can be split in to two parts.
The first part consists of an cycle for rapid development.
Where the features of a system are implemented based on agile software development.
This cycle for rapid development aims to shorten the length of the development cycles.
The second part consists of rapid development techniques.
These techniques focus on dividing the development of a single feature in the system in small steps.
Each step in the implementation adds detail to the implementation of the feature and is tested individually.
The short cycles, small steps, and intermediate testing produce periodic feedback about the performance and validity of the system.
This feedback helps to detect and fix faults in the development of the system immediately.
%\section{Design Methods}
%\rro{Introduce the three design methods}
% \rroi{Our design method is based on rapid development}
% \rroi{Rapid development also introduces variable detail method}
% \rroi{Where both methods lack we will fall back to Systems Engineering}
% \subsection{Rapid Development}
% \textcite{broenink_rapid_2019} presented an approach for rapid development of embedded control software.
% The approach can be split in to two parts.
% The first part consists of an cycle for rapid development.
% Where the features of a system are implemented based on agile software development.
% This cycle for rapid development aims to shorten the length of the development cycles.
% The second part consists of rapid development techniques.
% These techniques focus on dividing the development of a single feature in the system in small steps.
% Each step in the implementation adds detail to the implementation of the feature and is tested individually.
% The short cycles, small steps, and intermediate testing produce periodic feedback about the performance and validity of the system.
% This feedback helps to detect and fix faults in the development of the system immediately.

Combining the two parts with a preparation and evaluation phase creates the bases of the methodology.
The rapid development cycle becomes the outer cycle and the small step implementation is the inner cycle.
The preparation step divines the different features and their corresponding levels of detail.
The order of implementation of the features is important as features can depend on and influence each other.
\rrot{Explain the different steps}
\rroit{Do I want to 'copy' the steps from the paper? Do I even want to explain this?}
\rrot{Insert figure from paper}
\rro{Explain the design method of \textcite{broenink_rapid_2019}}
\rro{RDM is forms the base of the design method in this thesis}
\rroi{Order and split features and levels of detail as preparation}
\rroi{Implement features one by one}
\rroii{Each feature is implemented with increasing detail}
\rroii{Begin with a basic implementation}
\rroii{Increase detail in every step}
\rroii{Repeat until tests are completed}
% Combining the two parts with a preparation and evaluation phase creates the bases of the methodology.
% The rapid development cycle becomes the outer cycle and the small step implementation is the inner cycle.
% The preparation step divines the different features and their corresponding levels of detail.
% The order of implementation of the features is important as features can depend on and influence each other.
% \rrot{Explain the different steps}
% \rroit{Do I want to 'copy' the steps from the paper? Do I even want to explain this?}
% \rrot{Insert figure from paper}
%
% \rro{Explain the design method of \textcite{broenink_rapid_2019}}
% \rro{RDM is forms the base of the design method in this thesis}
% \rroi{Order and split features and levels of detail as preparation}
% \rroi{Implement features one by one}
% \rroii{Each feature is implemented with increasing detail}
% \rroii{Begin with a basic implementation}
% \rroii{Increase detail in every step}
% \rroii{Repeat until tests are completed}

\rro{Expected difficulty is that the hardware features do not always overlap with hardware components}
\rro{Features are based on the initial design. However, the initial design has space for changes}
\rroi{Therefore, it is difficult to 'order' the features as they are not fully determined}
\subsection{Variable Detail}
The previous section covered the design method for rapid development.
Part of that is the addition of detail in small increments.
\textcite{broenink_variable_2018} proposed an approach to organize these different levels of detail.
The approach starts with evaluating the different signals of the system parts.
Then based on these signals the interface and model structure is defined.
% \rro{Expected difficulty is that the hardware features do not always overlap with hardware components}
% \rro{Features are based on the initial design. However, the initial design has space for changes}
% \rroi{Therefore, it is difficult to 'order' the features as they are not fully determined}
% \subsection{Variable Detail}
% The previous section covered the design method for rapid development.
% Part of that is the addition of detail in small increments.
% \textcite{broenink_variable_2018} proposed an approach to organize these different levels of detail.
% The approach starts with evaluating the different signals of the system parts.
% Then based on these signals the interface and model structure is defined.

\rro{Explain the design method of \textcite{broenink_variable_2018}}
\rro{Proposes to begin with basic. and build up gradually}
\rro{Basic model composed of only essential components}
\rroi{Followed by hard limitation}
\rroi{Followed by parasitic elements}
\subsection{Systems Engineering}
\rro{Explain the general idea of systems engineering}
\rro{Quote Wikipedia: Systems engineering is an interdisciplinary field of engineering and engineering management that focuses on how to design, integrate, and manage complex systems over their life cycles.}
% \rro{Explain the design method of \textcite{broenink_variable_2018}}
% \rro{Proposes to begin with basic. and build up gradually}
% \rro{Basic model composed of only essential components}
% \rroi{Followed by hard limitation}
% \rroi{Followed by parasitic elements}
% \subsection{Systems Engineering}
% \rro{Explain the general idea of systems engineering}
% \rro{Quote Wikipedia: Systems engineering is an interdisciplinary field of engineering and engineering management that focuses on how to design, integrate, and manage complex systems over their life cycles.}

\section{System Validation}
\rro{An aspect of the design method, which is very important, is the validation of the design.}
\rro{All design methods contain testing}
\rro{Method developed to run physical behavior tests}
\rroi{Does interpret simulation results not only end-values}
\rroi{Used to validate behavior}
\rro{Is currently in very experimental state}
\rroi{If not this tool would have been used}
\rroi{Thus, we will do it manually}
%\section{System Validation}
%\rro{An aspect of the design method, which is very important, is the validation of the design.}
% \rro{All design methods contain testing}
% \rro{Method developed to run physical behavior tests}
% \rroi{Does interpret simulation results not only end-values}
% \rroi{Used to validate behavior}
% \rro{Is currently in very experimental state}
% \rroi{If not this tool would have been used}
% \rroi{Thus, we will do it manually}
%
\section{Case Studies}
\rro{This section will be taken from the project plan}
\rrog{This section will be taken from the project plan}
\subsection{Requirements}
The goal is to find a case study that can be used to evaluate the design method within a Master's Thesis.
Some requirements are defined to help the selection of a suitable case study.


+ 123
- 47
content/casestudy.tex Bestand weergeven

@@ -627,7 +627,7 @@
\end{tabular}
\end{table}

\subsection{SCARA}
\subsection{SCARA implementation}
At the end of this implementation the SCARA is able to write the first characters
This will be achieved by working through different levels of detail.
Where each level adds more detail to the model.
@@ -644,51 +644,127 @@
This mainly describes the different level of physics detail.
Together with the physics model there will be a solid 3D CAD model.
The CAD model helps to check with dimensions and possible collisions of objects.
\subsubsection{Basic kinematics model}
The goal of a very simple basic kinematics model is to work out the dimensions and kinematics.
The model consists of two submodels: An inverse and a forward kinematics model.
The inverse kinematics model calculates the angle of the two arms for a specific setpoint.
This model will be used throughout all the following models.
To visualize the behavior of the inverse kinematics a forward kinematics model will generate the joint positions from the angles.
Plotting these positions allows for inspection and validation of both models.

\subsubsection{Basic Physics model}
In this step the forward kinematics model is replaced with basic 2D physics behavior.
Implementing this behavior provides information about the energy in the system.
The joints can be powered with ideal motors which makes the whole design very simple.
The ideal nature of the model makes it difficult to say something about the energy as the ideal motors deliver an infinite amount of power to the system.
However, in the next steps where the motors will be implemented the dynamics become very useful.

\subsubsection{Basic Motor Behavior}
The two ideal effort sources will be replaced with DC motor models.

\subsubsection{Basics}
\begin{marginfigure}
\centering
\begin{tikzpicture}
\tikzstyle{arrow} = [-latex,ultra thick]
% draw roof
\fill[pattern = north east lines] ($ (0,0) + (-1,0) $) rectangle ($ (0,0) + (1,0.5) $);
\draw[thick] ($ (0,0.5) + (-1,0) $) -- ($ (0,0.5) + (1,0) $);
%draw arm and joints
\fill (0,0.5) circle (0.2);
\draw[thick] (0,0.5) to node[midway,right,draw=none] {$a$} (-1.5,3.5);
\fill (-1.5,3.5) circle (0.2);
\draw[thick] (-1.5,3.5) to node[midway,above,draw=none] {$b$}(1.51,4.26);
%draw mass
\draw (1.7,4.32) circle (0.2) node {$m$};
%draw arc
%\draw[dashed,gray] (-1.5,3.5) -- ++(2.5,0);
%\draw (1,0.5) arc (0:116:1cm) node[above,midway] {$\theta$};

%\draw [arrow] (c.south) -- +(0,-1cm) node[midway,right,draw=none] {$F_{g} = m \cdot g$};
\end{tikzpicture}
\caption{Basic kinematics of the SCARA}
\label{fig:scaraarm}
\end{marginfigure}
The first four detail steps are just creating the basics dynamics of the SCARA as shown in \autoref{fig:scaraarm}
It start with the kinematics model that is used to test the forward and inverse kinematics of the design.
It gave a general idea of angles and arm lengths that are required in the design.
The second detail iteration adds the basic physics of the model.
This model was in the form of a double pendulum, with to powered joints.
The ideal motors in the joints made it that it could move with almost infinite speed.
To get a better idea of the forces in the model, the ideal motors are replaced with a beter motor model.
As the system did not operate with infinite gain anymore it the path planning was updated as well.
A simple PID controller was implemented to make SCARA follow a square path.
Now that the model forms a basic with the non-ideal motors, basic physics and a controllaw, it can be used to make some estimates.
The model followed the required path in the specified amount out time.
With this, the minimum required torque could be calculated.
Which is then used to dimension the motors.

\subsubsection{Advanced Model}
The basic model contains all elementary components and detail can be added for different components.
The first step was to improve the motor models.
Up to now it was a primitive model with a source of effort, resistance and gyrator in series.
For the design it was decided to go with a stepper motor.
The advantage of a stepper motor is the holding torque, such that the motor can be forced in a certain angle.
With the new motors the controller was updated, to accommodate for the behavior of the steppers.

The next step was to upgrade the model to a full three dimensional dynamics.
Although the SCARA model itself is valid in only two dimensions, having the SCARA suspended from wires required the full dimensions.
The dynamics of the SCARA are based on a serial link structure \autocite{dresscher_modeling_2010}.
This allowed for a simple, yet quick implementation of the dynamics.

\subsubsection{3D modeling}
With a full dynamics model in 20-sim, the next step was to design the system in OpenSCAD.
Although 20-sim has a 3D editor, it is significantly easier to build components with OpenSCAD.
Furthermore, for prototyping the OpenSCAD objects can be exported for 3D printing.
The model made it possible to check component clearance and get an idea of size.
The model is shown in \autoref{fig:scad_carriage}.
\begin{figure}
\centering
\includegraphics[width=0.8\linewidth]{graphics/scad_carriage.png}
\caption{Rendered 3D model of the SCARA}
\label{fig:scad_carriage}
\end{figure}

\subsubsection{Evaluation}


\subsubsection{Implementation}
\rrot{Should this be here? Maybe in an appendix?}
\rro{Starting with very abstract model}
\rroi{Forward and inverse kinematics}
\rro{Increasing model detail}
\rroi{2D physics model}
\rroi{Simple Motor model}
\rroi{Path planning}
\rroi{Stepper motor}
\rroi{3D physics arm}
\rroi{Marker lift (torque on joint)}
\rroi{Marker lift (Servo)}
\rro{Used 20-sim for dynamic behavior}
\rroi{Could determine physical limits}
\rro{Used openSCAD for geometric design}
\rroi{Could easily avoid collision between parts}

\rro{Implementation went smooth}
\rroi{Order of increase in detail more in line with Koen den Hollander.}
\rroi{Stepwise detail increase gives loads of feedback}
\rroi{Dynamics model gave feedback on required stepper torque}
\section{Testing}
\rro{Testing was difficult with only one finished component, however}
\rroi{Able to run draw three characters in 2 seconds}
\rroi{Able to draw a square in 1 second}
\section{Result}
\rro{Created a model in 20-sim and openscad}
\rro{Build a physical prototype}
%\subsubsection{Basic kinematics model}
% The goal of a very simple basic kinematics model is to work out the dimensions and kinematics.
% The model consists of two submodels: An inverse and a forward kinematics model.
% The inverse kinematics model calculates the angle of the two arms for a specific setpoint.
% This model will be used throughout all the following models.
% To visualize the behavior of the inverse kinematics a forward kinematics model will generate the joint positions from the angles.
% Plotting these positions allows for inspection and validation of both models.

%\subsubsection{Basic Physics model}
% In this step the forward kinematics model is replaced with basic 2D physics behavior.
% Implementing this behavior provides information about the energy in the system.
% The joints can be powered with ideal motors which makes the whole design very simple.
% The ideal nature of the model makes it difficult to say something about the energy as the ideal motors deliver an infinite amount of power to the system.
% However, in the next steps where the motors will be implemented the dynamics become very useful.

%\subsubsection{Basic Motor Behavior}
% The two ideal effort sources will be replaced with DC motor models.

%
%\subsubsection{Implementation}
% \rrot{Should this be here? Maybe in an appendix?}
% \rro{Starting with very abstract model}
% \rroi{Forward and inverse kinematics}
% \rro{Increasing model detail}
% \rroi{2D physics model}
% \rroi{Simple Motor model}
% \rroi{Path planning}
% \rroi{Stepper motor}
% \rroi{3D physics arm}
% \rroi{Marker lift (torque on joint)}
% \rroi{Marker lift (Servo)}
% \rro{Used 20-sim for dynamic behavior}
% \rroi{Could determine physical limits}
% \rro{Used openSCAD for geometric design}
% \rroi{Could easily avoid collision between parts}

% \rro{Implementation went smooth}
% \rroi{Order of increase in detail more in line with Koen den Hollander.}
% \rroi{Stepwise detail increase gives loads of feedback}
% \rroi{Dynamics model gave feedback on required stepper torque}
% \section{Testing}
% \rro{Testing was difficult with only one finished component, however}
% \rroi{Able to run draw three characters in 2 seconds}
% \rroi{Able to draw a square in 1 second}
% \section{Result}
% \rro{Created a model in 20-sim and openscad}
% \rro{Build a physical prototype}


+ 59
- 0
content/conclusion.tex Bestand weergeven

@@ -0,0 +1,59 @@
%&tex
\chapter{Conclusion}
\label{chap:conclusion}
The goal of this thesis is to investigate if the design method by \textcite{broenink_rapid_2019} can be applied on a mechanical design.
During the case study, the design method was used to design a whiteboard writer.
The case study resulted in a working prototype of a subsystem.
The experience and evaluation of the case study are used to answer the questions of \autoref{chap:introduction}.
\emph{Which techniques of the design method can be applied in the development of hardware?}\\
The design method in this thesis is split in two parts: the preliminary design and the detail design.
In summary, the preliminary design is not suited for mechanical design.
With the core of the problem being that the design method focusses on implementing the mechanical features separately from each other.
However, the interconnection of the energy states makes the system tightly coupled.

The detail design phase is a good technique for implementing a mechanical design.
Provided that there is a basic model with all elementary components.
All interfaces in the dynamics of the system constitute as power connections.
A more detailed motor shall always output a torque or velocity.
This makes it easy to switch sub-models.

%With the core of the problem being that it assumes that mechanical components can be implemented separately from each other.
%This leads to implementation difficulties for each preliminary design step.
%Another aspect that hinders the design flow are the dynamic states, because these states are tightly coupled.

\emph{Which adaptations are required to create a design method that is suitable for the development of hardware?}\\
The preliminary phase requires a full overhaul to be suitable for the development of hardware.
The current approach is comparable with the waterfall-model.
The waterfall-model focusses on avoiding design changes, as these become more expensive during the development process.
But the modeling and simulation tools make changes to a dynamic system inexpensive.
As changes are inexpensive and the system is tightly coupled an iterative design approach for the preliminary design phase is more beneficial.

Some other lessons that could be drawn from the case study is that software and hardware require a radically different approach.
The production of software starts with the first line of code, but the production of hardware starts when the first system comes from the production line.
The costs of change for software is a directly related to the lost labor of developers.
The hardware design is finished before production giving more room for change before big investments are made.

\section{Recommendations}
% Although this research only focussed at the physical part of a \ac{CPS}, there are still some valuable recommendations for the overall design of a \ac{cps}.
% The
To improve the future development of a design method for \ac{cps} it is recommended to further investigate the following:
\begin{itemize}
\item State Analysis: Although this research focussed on the hardware, there is a clear suggestion that the difference in design approach depends on the type of state.
Software is based on states in memory, which are often defined by the developer. Furthermore, these states only change when an instruction access that memory value.
For a mechanical system, the energy states interact. How these states interact with each other depends on the definition of the state itself, not on a code instruction.
Somewhere in the \ac{cps}, these states interconnect. And both sides require a different design approach, thus where do these interfaces fit in the design method.
\item Software integration: Early in the case study it was clear that software would be an important part of the system. The current design method does not take the software integration into account.
However, software has a crucial part in a \ac{cps}. From what moment in the development has, or can, the software to be taken into account?
\item Design Team: A common note in the case study evaluation was the lack of interaction. Brainstorming about features, components and solutions could have improved the preliminary phase.
However, a team could also be counterproductive due to miscommunication between within the team. To ensure the effectiveness of a design method it is important to develop an approach for team interaction.
\end{itemize}






+ 134
- 0
content/discussion.tex Bestand weergeven

@@ -0,0 +1,134 @@
%&tex
\chapter{Discussion}
\label{chap:discussion}
\section{Complexity}
The goal of this thesis is to investigate how the design method for the embedded software in a cyber-physical system can be applied to the physical part.
The setup of the design method and applying that method in the case study pointed out that there is an enormous difference between the cyber and physical part.
This difference in presents itself in development cost and system complexity.

\subsection{System States}
Almost every complex system that is produced today contains software.
Software is often the reason that the complex system can exist in the first place.
Where software can have millions of states, configurations and variables, hardware is often limited to a dozen of states.
It is possible to say that the concept of scale does not exist for software as it does for hardware.
For example, for a traffic simulation in software can be done with ten or one thousand cars.
If the code is number of cars is specified in a variable, the developer only has to replace 10 with 1000 and restart the simulation.
Scaling that simulation in hardware from ten to even twenty cars probably doubles the cost of the project.
And it is not even close to one thousand cars.
The software can be scaled until the simulation runs out of resources, which is a hardware limitation.

% \textcite{tanenbaum_structured_1984} states: "Hardware and software are logically equivalent.
% Any operation performed by software can also be built directly into the hardware [and] any instruction executed by the hardware can also be simulated in software.
% The decision to put certain functions in hardware and others in software is based on such factors as cost, speed, reliability, and frequency of expected changes."
% As the size and cost scale proportionally with the complexity of the hardware i.e. the simulation needs an additional 990 physical cars, complexity is often moved to software.

For the current case study, the complex part is also moved to the software.
Building a controller is possible in hardware, but significantly more difficult.
Especially as the SCARA includes path planning.
Even this relatively small project resulted in a software with more than 100 states.
A large part of the software design is to decided how the states are represented in memory.
And while developing the software is created based on these decisions.
This is why design method incorporate short feedback cycles, changes in the design could result in rewriting of code.

Looking at the mechanical states of the SCARA.
In the basic implementation there are only six states.
Each of these states are energy states, and can be represented with SI-units.
Similar to software it is possible to change this representation, but it is preferred to stay close to the laws of physics.
The biggest difference with software states is that the energy states exchange energy bi-directional.
The system becomes tightly coupled and adding new states to the system does change its behavior.
This makes it that the dynamic system has to be modelled and designed as a whole.
The behavior of software is deterministic, a certain input always results in the same output.
Any other part of the software that used that output does not change the behavior of the software that wrote the output to memory.
This means that the system, in contrary to the dynamic system, is not tightly coupled.
The design methods do also use this to their advantage as it is possible to implement and test the software in parts.

%This is also apparent in the case study.
%There are about 6 mechanical states for the SCARA.
%In general, these mechanical states are represented in SI-units.
%With that the units corresponding directly to a energy state in the physical system.
%The control software for the SCARA contains easily more than 100 states.
%In the most basic representation these states are just values in memory.
%How these values are interpreted is a design decision.
%This makes a design method that accounts for these fast number of states a necessity.

% On the other hand, \textcite{folkertsma_energy-based_2017} shows that good understanding of hardware states can make a system less complex.


\subsection{Cost of Change}
The cost of change is also something that has some interesting differences.
The "soft" in software gives the impression that it is easier to change \autocite{sheard_718_1998}.
This does not mean that rewriting the software is cheap.
Depending on the design change it is likely that the costs for software are higher than for a change in a hardware prototype.
Making a hardware change on every already produced units is off course enormous.
But if hardware design changes are done before production starts there is not the problem of scale.
It is therefore also very common that a design process incorporates multiple prototypes\footnote{This does not imply that multiple prototypes is efficient or cheap.}, but the software is seldom completely rewritten.

It often occurs that a proof of concept for hardware design is mocked up from existing components.
And are often constructed with 3D-printers, tape, laser cutters and other rapid prototyping.
Updating a motor is just replacing the old one.
Exchange the stepper driver on the breadboard is done in minutes.
However, the corresponding software driver has to be updated or replaced.
This can be hours of work.

The cost of change in software is directly dependent on the change.
If the change is performed it can be rolled out to all other instances of the software for free.
It does not scale with the number of systems.
For the traffic simulation example from the previous section, any upgrade of the cars has to be done only once in software.
If all there are actual cars that have to be updated ten, twenty or a thousand times, the cost are enormous.

\subsection{Difference in Design method}
Both of the previous sections give an example of strong differences between the approach for software and hardware.
The different nature of hardware and software dictate a different design philosophy.
For hardware it is important to understand the interaction between the energy states.
For software it is important to define the representation of the memory states.
Maybe hard- and software are not the correct definitions here.
A system with energy states should be observed and simulated as a holistic system.
Where the level of detail can be increased throughout the design phase.


\section{Design Flow}



\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.}

+ 22
- 22
content/improvements.tex Bestand weergeven

@@ -32,9 +32,9 @@
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.
The SCARA has motors, mechanical linkage, sensors, as components; it is not a feature, it is a system.

This was a known shortcoming during the case study.
Trying to combine features and systems in a single hierarchy was a known shortcoming of the design 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".
@@ -64,21 +64,21 @@



The term feature was used as a universal concept for design features, hardware features and software features.
% 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.
% 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}.
% 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.
% 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.

@@ -101,15 +101,15 @@
\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{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}


+ 45
- 96
report.tex Bestand weergeven

@@ -18,31 +18,32 @@
\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.
%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}
\label{chap:introduction}
\section{Context of this Thesis}
%Wat is het probleem?
% Cyber Physical systems worden steeds complexer.
@@ -59,11 +60,11 @@ Daaruit komt eingelijk ook het discussiestuk aan het einde waarbij ik best een a
% 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.
% 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.
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.
@@ -111,10 +112,10 @@ Daaruit komt eingelijk ook het discussiestuk aan het einde waarbij ik best een a
% 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}
\rrog{Adapt the design method for hardware development}
\rroig{Current design method gives an initial foundation for development}
\rroig{However, lacks detail in some parts}
\rroig{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.
@@ -138,16 +139,16 @@ Daaruit komt eingelijk ook het discussiestuk aan het einde waarbij ik best een a


\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}
\rrog{Define a case study to test the design method}
\rroig{To actually test the method we have to design something}
\rroig{From multiple options we chose the whiteboard writer}
\rroiig{Complex enough}
\rroiig{Fits within the scope}
\rrog{Perform the case study}
\rroig{The case study does not focus on the best product.}
\rroig{Some design decissions are made to aid the evaluation of the design method}
\rroig{Run continuous evaluation during the case study, to improve the design method}
\rrog{Use feedback to propose design method for the development of hardware}

\section{Structure of this Thesis}
\autoref{chap:analysis}
@@ -162,68 +163,16 @@ Daaruit komt eingelijk ook het discussiestuk aan het einde waarbij ik best een a
\include{content/casestudy}

\include{content/improvements}
\include{content/discussion}

\include{content/conclusion}





\chapter{Discussion}
\label{chap:discussion}
\section{Complexity}
The goal of this thesis is to investigate how the design method for the embedded software in a cyber-physical system can be applied to the physical part.
The setup of the design method and applying that method in the case study pointed out that there is an enormous difference between the cyber and physical part.
This difference in presents itself in development cost and system complexity.

\subsection{Complexity}
Almost every complex system that is produced today contains software.
Software is often the reason that the complex system can exist in the first place.
Where software can have millions of states, configurations and variables, hardware is often limited to a dozen of states.


\subsection{Cost}


\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}

\appendix
\input{content/system_test_specification.tex}


Schrijf Voorbeeld
Laden…
Annuleren
Opslaan