mar/content/discussion.tex

%&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.}