|
|
|
@@ -6,79 +6,114 @@ |
|
|
|
This physical system is often a system of mechanical components which are deeply intertwined with the software components. |
|
|
|
Automobiles, robots, medical devices and even the smart grid are examples of \ac{cps}. |
|
|
|
The complexity of \ac{cps} has gone from an embedded system that improved the fuel consumption of a car engine to a fully self-driving vehicle. |
|
|
|
Although the complexity opens up more design possibilities, improved efficiency, and beter safety, it has downsides. |
|
|
|
The problem with the increasing complexity is the resulting increased developing cost and the decreasing reliability. |
|
|
|
Within the research topics that focus on \ac{cps}, lies the development of new design methods that deal with this complexity problem. |
|
|
|
The \emph{design method} by \textcite{broenink_rapid_2019} is one of these new design methods and focusses on the rapid development of embedded control software. |
|
|
|
The rapid development is a design technique that splits the development into small individual steps, which are implemented and tested separately. |
|
|
|
Testing each individual step creates feedback on a short interval, with the goal to detect errors made during the development as early as possible. |
|
|
|
Although the complexity opens up more design possibilities, improved efficiency, and beter safety, it has downsides as well. |
|
|
|
A major downside with the increasing complexity is the resulting increased developing cost and the decreasing reliability. |
|
|
|
\textcite{broenink_rapid_2019} introduce a new design method for \ac{cps} that aims to deal with the downsides of the complexity. |
|
|
|
Throughout this thesis, the term '\acl{ridm}' or abbreviated to \acs{ridm}, is used to refer to the design method by \textcite{broenink_rapid_2019}. \acused{ridm} %Set acronym to used. From here only small is set. |
|
|
|
The \ac{ridm} adopts a design technique called rapid development that splits the development process into small individual steps |
|
|
|
Where each of these steps are implemented and tested separately. |
|
|
|
Testing each individual step creates feedback on a short interval, finding errors in the design as early as possible. |
|
|
|
In the worst case scenario, the time and resources spent on development from the error being made till the error being detected are lost. |
|
|
|
The sooner an error is found, the less time and resources are wasted. |
|
|
|
|
|
|
|
As part of the research, Broenink and Broenink performed a small case study. |
|
|
|
In this case study, they have designed a controller, and implemented the controller in software for a physical off-the-shelf system. |
|
|
|
However, developing \ac{cps} incorporates both the computational software side, as well as the development of the physical dynamic side, although the latter is not covered by Broenink and Broenink. |
|
|
|
For this design method to be suitable for a complete design of \ac{cps} it has to be applicable to the physical part as well. |
|
|
|
Developing \ac{cps} incorporates the computational software side and the physical dynamic side. |
|
|
|
However, the case study by Broenink and Broenink only covers the software side of a \ac{cps}. |
|
|
|
For this design method to be suitable for a complete design of \ac{cps} it must apply to the physical part of the system as well. |
|
|
|
|
|
|
|
%%In this thesis, the proposed design method is applied and evaluated in the context of the physical part of a \ac{cps}. |
|
|
|
%%This is done in a case study, where a \ac{cps} is designed from scratch. |
|
|
|
\section{Research Objective} |
|
|
|
\textcite{broenink_rapid_2019} present a case study for software in their paper and state that "this [case study] does not mean that the same techniques cannot be applied to the physical part of the system." |
|
|
|
In this thesis, I will research whether this design method applies to the physical part of a \ac{cps}, to come to a design method that can be applied on both the physical and cyber (software) part of a \ac{cps}. |
|
|
|
From the start of this research, it was clear that a direct copy of the design method is not possible. |
|
|
|
It is therefore necessary to analyse which design techniques cannot be used and thus how to replace or improve them. |
|
|
|
The research is summarized in the following two research questions: |
|
|
|
\textcite{broenink_rapid_2019} present a case study in their paper, developing a software based control system following the \ac{ridm}. |
|
|
|
About the result of that case study they state that "this [case study] does not mean that the same techniques cannot be applied to the physical part of the system." |
|
|
|
In this thesis, I will research whether the \ac{ridm} applies to the physical part of a \ac{cps}, to come to a design method that can be applied on both the physical and cyber (software) part of a \ac{cps}. |
|
|
|
However, the paper makes no attempt to offer a comprehensive design method to be used out of the box. |
|
|
|
The \ac{ridm} does not provide information about bringing a system into being, it does not address problem definition, specifications or initial design steps. |
|
|
|
Another weakness is that the \ac{ridm} gives no explanation of how the design steps are executed, only specifying that they are used. |
|
|
|
The design method would have been more useful if the authors had made a complete design method available to accompany their paper. |
|
|
|
To ensure that the \ac{ridm} can be assessed as a design method for \ac{cps}, I have the following research objectives: |
|
|
|
\begin{itemize} |
|
|
|
\item Extend the \ac{ridm} with a preliminary design phase. |
|
|
|
This makes it possible develop a system for a given problem or idea, using this design method. |
|
|
|
\item Refine the \ac{ridm} to make the execution of the different design steps explicit and unambiguous. |
|
|
|
\item Develop and perform a case study that tests and evaluates the \ac{ridm}. |
|
|
|
\end{itemize} |
|
|
|
Based on the results of the case study I will answer the following research questions: |
|
|
|
\begin{itemize} |
|
|
|
\item Which design techniques of the design method by \textcite{broenink_rapid_2019} can be applied developing the physical part of \ac{cps}? |
|
|
|
\item Which adaptations are required to make the design method by \textcite{broenink_rapid_2019} suitable for developing the computation and physical part of \ac{cps}? |
|
|
|
\end{itemize} |
|
|
|
|
|
|
|
\section{Approach} |
|
|
|
Within this thesis, the design method by \textcite{broenink_rapid_2019} is evaluated in a case study. |
|
|
|
The case study performs a development process according to the design method and evaluates the result. |
|
|
|
However, there are a couple of steps required prior to the start of the case study (see \autoref{fig:approach}). |
|
|
|
The goal of this thesis is to evaluate the \ac{ridm}, a design method by \textcite{broenink_rapid_2019}. |
|
|
|
Their design method is evaluated in the form of a case study. |
|
|
|
The case study consists of a \emph{design process}, developing a \ac{cps} according to the \ac{ridm}. |
|
|
|
Based on the results of the design process, the \ac{ridm} is evaluated. |
|
|
|
However, there are a couple of steps required prior to the start of the case study. |
|
|
|
%To perform the case study reproducible, it requires a design plan, a subject of design and a evaluation protocol. |
|
|
|
%The \emph{design plan} is a refined version of the design method by \textcite{broenink_rapid_2019}, extended with a design method from \ac{se}. |
|
|
|
The first step is to produce a concrete \emph{design plan} based on the design method. |
|
|
|
The concrete design plan improves the evaluation of the design techniques. |
|
|
|
The design method is presented in an abstract form which leaves room for interpretation. |
|
|
|
This hampers the evaluation process, because it is impossible to point out flaws in something that was not specific in the first place. |
|
|
|
Therefore, I will assess the design method and add detail to get a concrete design plan. |
|
|
|
This abstract form hampers the evaluation process, as the ambiguity of the design method makes it difficult to point out flaws in the design method. |
|
|
|
Therefore, I will assess the design method and add detail to make a more concrete design plan. |
|
|
|
Because the design method focusses on the rapid development principles and modelling techniques, it does not cover the design steps outside of that focus. |
|
|
|
These steps, like problem definition and system specifications, are a crucial part of the design process and are added to create the concrete design plan. |
|
|
|
The added steps are based on the steps in a \ac{se} approach. |
|
|
|
The added steps are based on the steps from the \emph{\ac{se}} approach. |
|
|
|
\begin{figure} |
|
|
|
\centering |
|
|
|
\includegraphics[width=9cm]{graphics/approach.pdf} |
|
|
|
\caption{A graph that shows the interconnection of the different steps that are required to prior to the start of the case study.} |
|
|
|
\caption{The case study is consists of something to be designed (subject of design), how to design that something (design plan), and how to evaluate the design process. |
|
|
|
The design plan itself is a combination of the \ac{ridm} and \ac{se}.} |
|
|
|
\label{fig:approach} |
|
|
|
\end{figure} |
|
|
|
|
|
|
|
With a design plan to use in the case study there are two steps of preparation left. |
|
|
|
The first step is to develop an evaluation plan to ensure complete and consistent feedback during the case study. |
|
|
|
The evaluation plan consists of a list of questions that have to be evaluated for each design step. |
|
|
|
There are specific questions that evaluate the definition, or the execution of the design step. |
|
|
|
The other step is to provide the \emph{subject of design} to develop in the case study. |
|
|
|
The first step is to develop an \emph{evaluation protocol} to ensure complete and consistent feedback during the case study. |
|
|
|
The evaluation protocol consists of a list of questions that are evaluated for each design step. |
|
|
|
The protocols contains questions about the design method itself, thus evaluating the instruction of each design step. |
|
|
|
Other questions are about the design process, covering the execution of the instructions. |
|
|
|
%There are questions that evaluate the design plan and there are questions that evaluate the design process. |
|
|
|
The other step is to provide the \emph{subject of design} to develop in the case study, essentially defining a problem that has to be solved. |
|
|
|
How all these components combine into the case study is shown in \autoref{fig:approach}. |
|
|
|
|
|
|
|
Normally, the design process focusses on delivering the end product in the most effective manner. |
|
|
|
However, the goal of this research is to use the design process to evaluate the design method, not to develop a product. |
|
|
|
A possible pitfall is that during the design process a simple solution is found, such that the design techniques to deal with the increased complexity are left untouched. |
|
|
|
Choosing to develop a very complex subject ensures that the case study covers all the design techniques. |
|
|
|
Unfortunately, the limited time budget of a master's thesis makes it impossible to perform a case study for a complex subject. |
|
|
|
One of the requirements for the possible subjects is therefore a minimum level of complexity, forcing the developer to not go with the simplest solution. |
|
|
|
Some other requirements, based on practical decisions like budget, tools, and time were defined as well. |
|
|
|
Based on these requirements, the subject of choice is "Writing a tweet on a whiteboard". |
|
|
|
|
|
|
|
With something to develop, a method to develop, and a method to evaluate, the case study is executed. |
|
|
|
Even though the case study was terminated due to the limited amount of time available, it resulted in a partial prototype of a whiteboard writer and a significant amount of evaluation. |
|
|
|
The results made it possible to propose improvements to the design method, not only for the physical part of \ac{cps} but also the cyber part. |
|
|
|
A possible pitfall is that during the design process the developer finds a simple solution, such that the design techniques to deal with the increased complexity are left untouched. |
|
|
|
Therefore, it is important to guarantee a minimum level of complexity. |
|
|
|
Instead of setting a problem that is very complex, I decided to require a minimum complexity to the solution. |
|
|
|
This makes the design process complex enough, without requiring an excessive amount of development time or compromising the quality of the evaluation. |
|
|
|
Together with some other practical requirements, the best subject of design found is "Writing a tweet on a whiteboard". |
|
|
|
The subject of design is interesting because it has multiple design solutions that are complex but not unpractical. |
|
|
|
Furthermore, it has some interesting dynamics, requires a control law, and can easily be constructed in to a prototype. |
|
|
|
|
|
|
|
With a subject of design that requires a solution in the form of an object incorporating both physical and cyber parts to develop; |
|
|
|
a design plan which describes how to develop this solution; |
|
|
|
and a protocol to evaluate the design plan and the development of the solution; |
|
|
|
the case study is executed. |
|
|
|
From the results of the case study I propose multiple improvements to the design method, not only for the physical part of \ac{cps} but also the cyber part. |
|
|
|
|
|
|
|
\section{Notes on Terminology} |
|
|
|
Design method is a commonly-used notion throughout the different papers and research used in this thesis. |
|
|
|
\textcite{broenink_rapid_2019} refer to their design method as 'the methodology', which is to generic for this thesis. |
|
|
|
To ensure distinct terminology throughout this thesis, their methodology is named \acl{ridm} and is abbreviated as \acs{ridm}. |
|
|
|
The more concrete version of the design method that is tested in the case study, is referred to as the 'design plan'. |
|
|
|
The object or system that is going to be designed during the case study is referred as 'subject of design'. |
|
|
|
%\section{Notes on Terminology} |
|
|
|
% Design method is a commonly-used notion throughout the different papers and research used in this thesis. |
|
|
|
% \textcite{broenink_rapid_2019} refer to their design method as 'the methodology', which is to generic for this thesis. |
|
|
|
% To ensure distinct terminology throughout this thesis, their methodology is named \acl{ridm} and is abbreviated as \acs{ridm}. |
|
|
|
% The more concrete version of the design method that is tested in the case study, is referred to as the 'design plan'. |
|
|
|
% The object or system that is going to be designed during the case study is referred as 'subject of design'. |
|
|
|
|
|
|
|
\section{Structure} |
|
|
|
The refinement of the design method and adding design steps is done in \autoref{analysis} to define a concrete design plan. |
|
|
|
The evaluation plan and subject of design is defined in \autoref{case_method}. |
|
|
|
The case study is executed in \autoref{case_experiment}, based on the design plan, evaluation plan and subject of design. |
|
|
|
The execution of the case study is evaluated in \autoref{case_evaluation}. |
|
|
|
In \autoref{reflection} the evaluation of the case study and the results are reflected back on the design plan. |
|
|
|
Based on the reflection and the evaluation, an improved design method is proposed in \autoref{improved_design}. |
|
|
|
And finally, the research is concluded in \autoref{conclusion}. |
|
|
|
The overall structure of the study takes form of 8 chapters. |
|
|
|
The first two chapters introduce the used design methods. |
|
|
|
\autoref{chap:background} gives a background of the \ac{ridm} and \ac{se} approach and how this is combined into the design plan. |
|
|
|
The design plan is presented in full detail in \autoref{chap:analysis}, where each step is explained. |
|
|
|
|
|
|
|
\rrot{De rest van deze sectie is nog niet af!} |
|
|
|
The next three chapters cover the method, execution, and evaluation of the case study. |
|
|
|
\autoref{chap:case_method} is concerned with the methodology of the case study, introducing the subject of design and the evaluation protocol. |
|
|
|
\autoref{chap:case_experiment} documents the execution of the case study, showing the development during the design process. |
|
|
|
All the questions and observations that were administered by following the evaluation protocol during the case study are analysed in \autoref{chap:case_evaluation}. |
|
|
|
|
|
|
|
The last three chapters will reflect on the design plan that is evaluated in this research. |
|
|
|
\autoref{chap:reflection} uses the evaluation results of the case study to reflect on the design plan in this thesis. |
|
|
|
Based on these reflections, a number of improvements on the design is presented in \autoref{chap:improved_design}. |
|
|
|
And finally, the research is concluded in \autoref{chap:conclusion}. |