diff --git a/content/designcycle.tex b/content/designcycle.tex new file mode 100644 index 0000000..407bce1 --- /dev/null +++ b/content/designcycle.tex @@ -0,0 +1,265 @@ +%&tex +\chapter{System Design Method} +\label{chap:systemdesign} +\section{Introduction} + This chapter explains the design method that will be used. + The design method is build around the rapid-development methodology by \textcite{broenink_rapid_2019}. + The rapid-development methodology consists of a structured way of implementing features consecutively. + %proposes a methodology where features are implemented consecutively. + The goal of the preparation phase is a list of feature definitions that are ready for implementation. + However, it is expected that some features are not ready for implementation initially. + Implementing the features that are ready, will generate more information about the design direction. + Therefore, the feature definitions will be reviewed during the development, each time the implementation of a feature is completed. + During the review, feature definitions are updated with the additional gained information until ready for implementation. + + \autoref{fig:flowgraph} shows the different steps in the design flow. + In this chapter the different steps are explained except for the feature implementation step, which is covered in the next chapter. + \autoref{sec:preparation} explains the problem definition, system requirements and initial design. + In \autoref{sec:featuredefinition} the feature definition step is explained. + Then the system testing is introduced, followed by feature selection, as the test-cases will influence the feature selection. + + \begin{figure} + \includegraphics{graphics/flowgraph.png} + \caption{Flow graph for the design steps. After a successful system testing the feature is completed and specifications are updated. Then the next feature is selected and implemented.} + \label{fig:flowgraph} + \end{figure} + +\section{Preliminary Design} +\label{sec:preparation} +The preliminary design is the first step of this design method. +The steps in the preliminary design are expected to only be executed once. +However, any mistakes made, could require a review of one or more steps of the preliminary design. + \subsection{Problem definition} + The first step of the design cycle is to describe the problem that has to be solved. + A clear and concise problem definition increases a successful design process. + It gives a better basis for the system requirements. + Therefore, lowering the number of reviews required for the system requirements. + Furthermore, good definitions help determining overall feasibility of the project in an early stage. + + \subsection{System Requirements} + The system requirements are derived from the problem definition. + As the features will be derived from these system requirements, the goal is to define the requirements without any ambiguity, vagueness or complexity. + The requirements will be written according to \ac{ears} \autocite{mavin_easy_2009}. + \ac{ears} was chosen for this design method due to its simplicity, which is is deemed suitable for the scope of this research. + If issues, like ambiguity, are not dealt with correctly, these issues can propagate into the sub-requirements that will be defined for each feature. + Solving these issues in a later stage of the design could require a redesign of features that were already completed. + + + \subsection{Initial Design} + At the start of a development the final solution for the problem is unknown. + It is important to explore the different solutions and design space. + The goal of this initial design is to create an overview of these possibilities. + Due to the scope of this research, the choice of design solutions is made for a design that is expected to fit this research, instead of determining the optimal solution. + + However, in an actual design case, this step is crucial and can even be extended. + A problem can be solved with more than one design. + It is expected that these design solutions contain identical features. + For example, take a cube that has to be moved. + Each design has a grab feature that picks up the cube. + Instead of choosing a specific initial design, we could start by implementing the grab-feature. + If the grab feature proofs to be infeasible, we know that we have to choose a different design. + Would the grabber be a success, then the feature is already implemented for the designs that use it. + + This can reduce the risk during the design by implementing features first that have overlap in other design solutions. + First of all, it can help select a suitable design solution. + If a initial design fails in a later stage, switching to a different design can be cheaper as some features are transferable. + +\section{Features Definition} +\label{sec:featuredefinition} + The characteristics of the system under design are the system features, which will be implemented into the model. + To implement the features one by one it is important that all the features are defined prior to the design cycle. + A subset of the system requirements will be assigned to the feature and will be referred to as the feature requirements. + The best division of requirements varies strongly with the domain of the system. + Therefore, the best engineering judgment of the developer is needed to divide the requirements. + The sum of the feature requirements cannot exceed the overall system requirements. + However, during the design phase it is possible to change the requirement division between features. + + It is expected that the division will be updated multiple times during the development. + To efficiently change the division during the development without mistakes, good administration is key. + \autoref{tab:subreq} shows an example to create overview. + Each row contains one requirement. + If a requirement is updated, the division can directly be reviewed. + Would a feature change, then only one column has to be reviewed. + However, the final organization of the different feature requirements is more complex than this example. + Partially because not all requirements can be split up in simple numbers. + + \begin{table}[] + \caption{System requirements and the division of these requirements for features.} + \label{tab:subreq} + \begin{tabular}{ll|lll} + & System & Feature 1 & Feature 2 & Feature 3 \\ \hline + \multicolumn{1}{l|}{Weight} & 3 kg & 1 kg & 1.2 kg & 0.5 kg \\ + \multicolumn{1}{l|}{Power} & 100 W & 25 W & - & 60 W + \end{tabular} + \end{table} + + \subsection{Dependencies} + \label{sec:feature_dependencies} + Different features combined represent the complete system under design. + How these features interact with each other is depending on the system design. + For example, take a robot system that has to grab something. + Looking at the two core features of the robot arm that moves, and the gripper that grabs. + The specifications of the gripper could depend on the robot arm, as the gripper has to be compatible with the robot arm. + However, this also applies the other way around. + We could also specify a robot arm that is compatible with the developed gripper + + To ensure that the features are compatible with each other, the developer has to specify the dependency of the features. + Especially in what direction the dependency should apply. + Including extra system specifications to the robot arm example can result in a different dependency direction. + If the specification is to lift an object with specific mass, the robot arm becomes dependent on the gripper. + Because the robot arm has to be able to lift the mass of the gripper and object combined. + If the specification would be a confined working area, the size of the robot arm is the leading factor. + Which limits the remaining weight or size specifications for the gripper. + If both specifications would apply, the developer has determine the dependency direction carefully. + It is possible that the weight specification and space limitation combined lower the feasibility of the project. + The developer should choose a direction which can determine the feasibility as early as possible. + + This example used only two features. + However, it is certain that the actual development contains more than two. + \autoref{fig:featuredependency} shows an example of a dependency graph with five features. + It can be seen that features 2, 3 and 4 are depending on feature 1. + Where 4 is also depending on 3. + + \begin{marginfigure} + \begin{tikzpicture} + [node distance=5mm,feature/.style={rectangle,draw}] + \node at (0,0) [feature] (F1) {Feat. 1}; + \node (F2) [feature,right=of F1] {Feat. 2}; + \node (F3) [feature,below=of F2] {Feat. 3}; + \node (F4) [feature,right=of F3] {Feat. 4}; + \node (F5) [feature,below=of F1] {Feat. 5}; + \path (F1) edge[->] (F2) + (F1.east) edge[->] (F3.west) + (F3) edge[->] (F4); + \end{tikzpicture} + \caption{Simple dependency graph for features.} + \label{fig:featuredependency} + \end{marginfigure} + + A crucial task in the design cycle is updating the feature specification accordingly with the dependency. + At the point that the gripper is finished, the specifications of the robot arm can be updated. + Not only does it improve the specification, it can also help in determining the feasibility. + In this chapter we also introduce the method which selects the next to implement feature. + This method does rely on the feasibility and dependency of features, making the update even more important. + +\section{System Testing} + \label{sec:systemtesting} + The system and features are tested during each iteration against the system requirements. + This is to make sure that the design still performs as expected. + During the preliminary design phase of the development the system tests are defined. + The system test are derived from the system requirements and cover the global performance. + However, at this point there is no model yet to test against. + During the design cycle these test cases will become valid as more behavior of the system model is implemented. + For each test it is assessed what features are required to complete the test. + + %Although an automatic testing method is presented by \autocite{broenink_tooling_2020}, the testing will performed manually. + %The tooling is still experimental and yet suited for use in a design method. + The tests that will be done cover the physical part of the system. + These tests will be performed manually as tooling for automated testing is still in the experimental phase. + \rrot{@Tim, I like to cite the paper on AMT but that one is not yet published?} + However, a design of a cyber-physical system is guaranteed to contain software. + As the focus of this Thesis is on hardware design, the software testing will not be part during this research. + +\section{Feature Selection} + This section explains the selection criteria which determines the next feature that will be implemented. + During the development it is expected that problems and issue occur. + The consequences of these issues are that a system requires a (partial) redesign. + Worse, the problem cannot be solved and the development is cancelled. + The selection method is designed to reduce the risk of these issues during the development. + + \subsection{Dependency} + \autoref{sec:feature_dependencies} introduced the dependencies of features. + By the fact that child features are missing information from the parents implementation, the parents shall be implemented first. + Even if the child is not relying on parent information, the parent should still be implemented first. + If the parent feature is not feasible, any implementation of the child becomes obsolete. + + Parent-features with multiple children have priority. + As the implementation gains new knowledge that is relevant for multiple features. + This helps to get all the specifications defined in an early stage of the development, which reduces the risk. + + \subsection{Test Completion} + Each function has a set of requirements which are tested during the development. + This is a subset of the system requirements. + \autoref{sec:systemtesting} explained the system tests, where the system tests can span over multiple features. + Passing these test is crucial for the design method, as finding flaws in an early stage is very important. + Therefore, features that can make a requirement testable can be selected by the developer to be implemented first. + + \subsection{Risk Assessment} + It is important to clear the risks in a development in the shortest amount of time. + If a development runs into problems near the end of its completion all investments are lost. + All features will be ranked on their feasibility and time required for implementation. + With that it is possible to sort the features such that most risk is cleared in the least amount of time. + %Remaining features from both selection criteria are sorted on risk and implementation time. + %When features are implemented and test are complete the risk of them failing is gone. + Therefore, features that are quick to implement could have priority, as the risk can be cleared in an early stage. + However, there is a trade-off to be made with risk involved of the implementation itself. + Features with a low feasibility are a risk to the whole development. + Especially if the feature has low feasibility and a large implementation time, a large risk remains at the end of the development. + Combining time and risk factors gives a method for eliminating the highest risk per time of development. + + In \autoref{tab:risktimetable} a situation of four features is shown. + It can be seen that feature 1 has the highest risk. + However, by prioritizing features 3 and 4 over feature 1 we can clear 40\% of the risk in halve the implementation time of feature 1. + \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:risktimetable} + \begin{tabular}{l|l|l|l|} + \cline{2-4} + & Time (days) & Risk (\%) & Risk per time \\ \hline + \multicolumn{1}{|l|}{Feat. 1} & 6 & 45 & 7,5 \\ \hline + \multicolumn{1}{|l|}{Feat. 2} & 3 & 15 & 5 \\ \hline + \multicolumn{1}{|l|}{Feat. 3} & 1 & 15 & 15 \\ \hline + \multicolumn{1}{|l|}{Feat. 4} & 2 & 25 & 12,5 \\ \hline + \end{tabular} + \end{table} + + \subsection{Combining} + \rro{Example of a selecting features with the three methods given above} + +\section{Feature Implementation} + This section will explains the methodology for the development of a single feature. + The methodology is based on the variable detail model simulation methodology \autocite{broenink_variable_2018}. + +\subsection{Initial design} + Implementing a feature starts with an initial design. + The initial design gives a rough idea on how to implement the feature. + This is important because there are multiple ways to implement a feature. + For example, moving a carriage along a rail can be done by a belt drive, hydraulics, rack and pinion, or any other form of transmission. + + \rrowip{General Note: This part of the method never felt like I could fit it in. Now that I have applied the method in general it does make even less sense...} + From the initial design the structure of the model is determined. + The structure of the model specifies different sub-models in the system and how they are interconnected. + \textcite{broenink_variable_2018} explains how to split the model into sub-models. + Broenink's methodology also introduces different categories for the elements. + Where the first step is to implement only the essential elements. + However, which elements are essential has a strong dependency on the type of feature. + + + +\subsection{Testing} + To make sure the design of the feature stays within the specifications, the model is tested continuously. + The test-cases are based on a set of system specifications that was assigned to the feature. + \rrowip{Although AMT would be really nice it was not feasible to implement/use it. Therefore, it was done manual and I have to remove this part.} + Similar to the system testing in \autoref{sec:systemtesting} the test are performed with \ac{amt}. + It is important that the feature specifications are tested. + However, the test should also cover the physical behavior like parasitic elements. + It is obvious that we have to test this, but no clue on how to actually test. + + Making the test cover all the physical behavior is expected to be impossible. + However, without a coverage case for physical behavior it is possible to create a model that checks all the tests. + For example, by leaving out the parasitic elements and only using ideal elements. + This does not mean that the model is competent, but it shows that a model can ignore the laws of physics. + So the challenge is to complete all the tests with a model that remains a realistic implementation. + Therefore, modeling a realistic behavior is task of the developer. + And this is eventually validated with a physical prototype. + +\subsection{Model detail} +\rrowip{This part is a bit minimal, needs more content} + The initial idea was to start with an ideal model as first implementation. + It is expected that implementing only the essential elements of the system does not represent a valid behavior. + At least not with the categorization that is introduced by \textcite{broenink_variable_2018}. + Maybe in a simple motor model, but not in a system with some kind of feedback. + As the feedback is normally based on the state of a storage element. + + The order of implementation is difficult to define. + Therefore, it should be the developer that decides on the minimal implementation of the model. diff --git a/graphics/flowgraph.png b/graphics/flowgraph.png new file mode 100644 index 0000000..194d97b Binary files /dev/null and b/graphics/flowgraph.png differ diff --git a/graphics/risktimegraph.png b/graphics/risktimegraph.png new file mode 100644 index 0000000..a4409ad Binary files /dev/null and b/graphics/risktimegraph.png differ diff --git a/include b/include index d1cdc15..addd9d0 160000 --- a/include +++ b/include @@ -1 +1 @@ -Subproject commit d1cdc15516e9746c0229d390e13b62f350b6d09e +Subproject commit addd9d0ce841ab33a93d1d618e72637fcfc30817 diff --git a/report.tex b/report.tex index 1869478..c2baee3 100644 --- a/report.tex +++ b/report.tex @@ -1,4 +1,4 @@ -\documentclass[final,english,titlepage,nomath]{siltex-report} +\documentclass[english,titlepage,nomath]{siltex-report} \include{include/preamble} \title{Title} @@ -16,17 +16,234 @@ \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} -\rro{This is context.} -\section{Problem Statement} -\rro{This is the problem statement.} -\section{Research Objective} -\section{Approach} - -%\include{introduction} + \section{Context} + \section{Problem Statement} + \section{Research Objective} + \section{Approach} + +\chapter{Analysis} + \section{Design Methods} + \subsection{Rapid development} + \rro{Explain the design method of \textcite{broenink_variable_2018} and \textcite{broenink_rapid_2019}} + \subsection{Systems Engineering} + \rro{Explain the general idea of systems engineering} + + \section{Testing} + \subsection{Automatic Method Testing} + + \section{CAD tools} + \subsection{20-sim} + \rro{20-sim will be used for the portbased modeling of the dynamics} + \rroi{Gives the posibility to simulate what I want} + \rroi{And i'm very familiar with it} + \subsection{openSCAD} + \rro{3D drawing software} + + \section{Case Studies} + \rro{This section will be taken from the project plan} + \subsection{Coverage} + \subsection{Tweet on a Whiteboard} + \subsection{Sensor Calibration Rig} + \subsection{Peg-in-Hole Robot} + \subsection{Decision} + +%\chapter{Design Method} + \rro{This chapter is the project plan with feedback} + \include{content/designcycle} + +\chapter{Case Study: Whiteboard writer} + \section{Monitoring} + \rro{Use forms to evaluate the method} + \rroi{Questions answered before and after each step} + \rroi{Forms are also updated during the design} + \section{Preliminary Design} + \subsection{Specifications} + \rro{Present Specifications for Case} + \subsubsection{Evaluation} + \rro{EARS is a good method} + \rro{Expected walk in the park} + \rro{Was difficult to validate} + \subsection{Initial Design} + \rro{Research on Existing Systems} + \rroi{Cable bot} + \rroii{Cable Tensioning, helps avoid oscillations} + \rroi{Cartesian-coordinate robot} + \rroi{SKARA} + \rroi{Polar-coordinate robot} + \rroi{Combination of the different systems} + \rro{Choice of system} + \rroi{Combine Cable bot with SCARA} + \rroii{Combination gives more dimensions of freedom to system} + \rroii{Otherwise it is expected that modeling is too easy} + \subsubsection{Evaluation} + \rro{Difficult to validate if the system is working} + \rro{Design stays very rough} + \rroi{Not sufficient detail to communicate to other engineers} + \rroi{Lack in experience.} + \rro{Tested: Discussed and reviewed with daily-supervisor} + \subsection{Feature Definition} + \rro{Goal: define features that can be implemented one by one} + \rroi{Additionally, division of system requirements} + \rro{Expected: A list of features, with corresponding dependencies} + \rro{Could define features, but non of them described mechanical components that could be implemented.} + \rro{Result: Improvised a structure that was loosely based on Robmosys} + \rroi{The lose features:} + \rroii{End-effector} + \rroii{SCARA} + \rroii{Carriage} + \subsubsection{Evaluation} + \rro{Multiple problems:} + \rroi{Specifications were to broad or to specific} + \rroi{Taking the following steps in to account, none of the features made sense} + \rroii{None of the features were something that could be modeled} + \rroii{Type of motor was depending on the forces required} + \rro{Inspired from RobMoSys we made a tree structure} + \rroi{The mission, task, skill etc separation helped a lot in structuring} + \rroi{For now, this solution suffices to continue the case study} + \rro{Mid-way Conclusion: Preliminary requires large changes} + \subsection{System Test Specification} + \rro{Specify tests for the different specifications} + \rro{Made a document with tests} + \rroit{Should this document be included in the report?} + \rroi{Each test covers one or more specs} + \subsubsection{Evaluation} + \rro{Was quite easy to perform} + \rroi{Difficult due to specs and features not working out as expected} + \rroi{Most features could not be tested as the subsystem needs to be completed first} + \rro{Tested by peer-review} + \rroi{Found that a review without all the project information is difficult} + \section{Detail Design} + \subsection{Feature Selection: First Iteration} + \subsubsection{Selection} + \rro{Compared: Dependency, tests coverage and risk/time ratio} + \rroi{First Feature/system to implement is End-effector.} + \rroii{Due to dependency and high risk/time} + \subsubsection{Implementation} + \rro{Plan: Model a gripper} + \rroi{Result: Underestimated Complexity} + \rroii{No debugging options for collisions in 3D-ME} + \rroii{Crash with software resulted in corrupted model} + \rro{Conclusion: not feasible in scope of case study} + \subsubsection{Evaluation} + \rro{Result is not as expected} + \rro{Risk/time factor proofed itself useful} + \subsection{Feature Selection: Second Iteration} + \subsubsection{Selection} + \rro{Scara is next in selection} + \rroi{Covers more tests and has higher risk/time factor than carriage} + \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} +\chapter{Improvements} + \section{Specifications} + \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} + \rro{Without mechanical experience is difficult} + \rro{Better specification document is a team effort} + \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}.} + +\chapter{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} + + \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} \printbibliography \end{document}