312 lines
8.5 KiB
Text
Executable file
312 lines
8.5 KiB
Text
Executable file
#LyX 2.0 created this file. For more info see http://www.lyx.org/
|
||
\lyxformat 413
|
||
\begin_document
|
||
\begin_header
|
||
\textclass article
|
||
\use_default_options true
|
||
\maintain_unincluded_children false
|
||
\language english
|
||
\language_package default
|
||
\inputencoding auto
|
||
\fontencoding global
|
||
\font_roman default
|
||
\font_sans default
|
||
\font_typewriter default
|
||
\font_default_family default
|
||
\use_non_tex_fonts false
|
||
\font_sc false
|
||
\font_osf false
|
||
\font_sf_scale 100
|
||
\font_tt_scale 100
|
||
|
||
\graphics default
|
||
\default_output_format default
|
||
\output_sync 0
|
||
\bibtex_command default
|
||
\index_command default
|
||
\paperfontsize default
|
||
\spacing single
|
||
\use_hyperref false
|
||
\papersize a4paper
|
||
\use_geometry true
|
||
\use_amsmath 1
|
||
\use_esint 1
|
||
\use_mhchem 1
|
||
\use_mathdots 1
|
||
\cite_engine basic
|
||
\use_bibtopic false
|
||
\use_indices false
|
||
\paperorientation portrait
|
||
\suppress_date false
|
||
\use_refstyle 1
|
||
\index Index
|
||
\shortcut idx
|
||
\color #008000
|
||
\end_index
|
||
\leftmargin 2.5cm
|
||
\secnumdepth 3
|
||
\tocdepth 3
|
||
\paragraph_separation indent
|
||
\paragraph_indentation default
|
||
\quotes_language english
|
||
\papercolumns 1
|
||
\papersides 1
|
||
\paperpagestyle default
|
||
\tracking_changes false
|
||
\output_changes false
|
||
\html_math_output 0
|
||
\html_css_as_file 0
|
||
\html_be_strict false
|
||
\end_header
|
||
|
||
\begin_body
|
||
|
||
\begin_layout Title
|
||
\begin_inset ERT
|
||
status open
|
||
|
||
\begin_layout Plain Layout
|
||
|
||
|
||
\backslash
|
||
Huge{Erlang Embedded Simulation Opposition}
|
||
\end_layout
|
||
|
||
\end_inset
|
||
|
||
|
||
\end_layout
|
||
|
||
\begin_layout Author
|
||
Jonatan Pålsson
|
||
\begin_inset Newline newline
|
||
\end_inset
|
||
|
||
Richard Pannek
|
||
\begin_inset Newline newline
|
||
\end_inset
|
||
|
||
Mattias Pettersson
|
||
\begin_inset Newline newline
|
||
\end_inset
|
||
|
||
Niklas Landin
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
Simulating hardware devices in Erlang is a very interesting topic.
|
||
The concurrent nature of Erlang should allow interesting hardware composed
|
||
of several systems, such as industrial robots to be simulated.
|
||
This thesis is valuable for the industry since it is based on an already
|
||
existing industrial experiment (Erlang Embedded), and it is interesting
|
||
to see a tool which can so readily be used in the industry to improve the
|
||
workflow and product quality in the field of embedded devices.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
The abstract is clear and concise, it provides the reader with a good overview
|
||
of the thesis.
|
||
\end_layout
|
||
|
||
\begin_layout Section*
|
||
Unclear points
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
When reading this thesis some questions came to mind:
|
||
\end_layout
|
||
|
||
\begin_layout Itemize
|
||
Is there any research suggesting superiority of simulators over real hardware
|
||
or emulators during the development process?
|
||
\end_layout
|
||
|
||
\begin_layout Itemize
|
||
It is unclear if actual simulators have been developed, or if a re-playing
|
||
software has been developed.
|
||
What makes the software a simulator and not a re-player?
|
||
\end_layout
|
||
|
||
\begin_layout Itemize
|
||
Is a re-playing software also to be considered a simulator, even though
|
||
it can only carry out pre-defined sequences of commands?
|
||
\end_layout
|
||
|
||
\begin_layout Itemize
|
||
It is stated that “recording has a great value for embedded simulation,
|
||
but also elsewhere”, why is this exactly?
|
||
\end_layout
|
||
|
||
\begin_layout Itemize
|
||
Which uses are there of recording, precisely?
|
||
\end_layout
|
||
|
||
\begin_layout Itemize
|
||
Why is recording favoured over emulation, for example? How can recorded
|
||
data be used for simulation and not only for play-back?
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
Specifically:
|
||
\end_layout
|
||
|
||
\begin_layout Itemize
|
||
4.1: What are “simple stubs” and are they really simulators?
|
||
\end_layout
|
||
|
||
\begin_layout Itemize
|
||
4.1: Is hand waving the best approach to analysing the quality of the supervisors
|
||
? Also, what is the “old work flow” in this context?
|
||
\end_layout
|
||
|
||
\begin_layout Itemize
|
||
4.2: This section states a simulation library and support for creating new
|
||
simulators.
|
||
Yet these are not explained like for example the convenience scripts.
|
||
\end_layout
|
||
|
||
\begin_layout Itemize
|
||
5.2: Exactly how is the quality of the simulators measured? Which metrics
|
||
are used? Some metrics are presented here, but not motivated, also results
|
||
are not shown.
|
||
\end_layout
|
||
|
||
\begin_layout Itemize
|
||
7.1: mentions a generic module to support the development of simulators.
|
||
Furthermore the section describes some simulators developed using the gen_fsm
|
||
behaviour.
|
||
Which additional features are provided by the software described in this
|
||
thesis, which are not already present in the gen_fsm behaviour?
|
||
\end_layout
|
||
|
||
\begin_layout Itemize
|
||
According to 7.4, API:s and simulators must be created when they don't already
|
||
exist, why is this not represented in the first flow chart? Does your applicati
|
||
on provide any ways to reduce development time of simulators? The quality
|
||
of a simulator may vary..
|
||
You created three simple device simulators.
|
||
How long did it take to create them? Case studies of developing these could
|
||
motivate the usage of simulators over hardware.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
A future improvement to the project is creating a finite state machine from
|
||
the log files.
|
||
It is unclear to us how this improves the system.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
Also, there are some factual errors; processes do share data, and data is
|
||
shared through message passing.
|
||
Memory is however not shared, perhaps this was what was intended to be
|
||
written.
|
||
PIDs can indeed be converted to lists, using the pid_to_list/1 function.
|
||
\end_layout
|
||
|
||
\begin_layout Section*
|
||
Results
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
What are the results from using the software discussed compared to the old
|
||
technique, of developing straight on the bare metal? Are there any results
|
||
in the terms of speed, reliability, cost effectiveness, usability (hard
|
||
to quantify)?
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
It would be interesting to see a case study of some software developed using
|
||
a simulator versus software developed using the actual hardware.
|
||
In which scenarios are simulators cost effective compared to actual hardware?
|
||
In which scenarios do simulators speed up the development of software?
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
Concerning the actual results, the following points remain unclear:
|
||
\end_layout
|
||
|
||
\begin_layout Itemize
|
||
How long does it take to upload the code to the hardware and how often is
|
||
this done during development, on average?
|
||
\end_layout
|
||
|
||
\begin_layout Itemize
|
||
How long does it take to get to know your system, write the simulators and
|
||
follow the steps you described? Is the workflow more efficient using your
|
||
system?
|
||
\end_layout
|
||
|
||
\begin_layout Itemize
|
||
Did you calculate a difference of time between development on the hardware
|
||
versus in a simulated environment?
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
The graphs provided are inconclusive and lack good descriptive texts.
|
||
It is unclear which metrics are used on each axis, and exactly what is
|
||
being measured; for instance, what is a
|
||
\begin_inset Quotes eld
|
||
\end_inset
|
||
|
||
sample
|
||
\begin_inset Quotes erd
|
||
\end_inset
|
||
|
||
?
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
The accuracy of the simulators was presented in a graph, and it can be seen
|
||
from the graph that the accuracy is not 100%.
|
||
Why is this, and is this not exceptionally alarming for a simulator? Which
|
||
impacts does this have on the simulation?
|
||
\end_layout
|
||
|
||
\begin_layout Section*
|
||
Language
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
The language style in the thesis is not formal as it would be expected in
|
||
an academical paper, such as a bachelor’s thesis.
|
||
Many subject-verb agreement mistakes have been made which makes it rather
|
||
hard to follow.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
Some terms could be introduced better; OTP, Beagle Board, Gumstix, Ångström/Angs
|
||
trom, distro, NAT, OS, Panda Board, VM, stub, public/subscribe, request-response
|
||
, OS variable and SSH.
|
||
Erlang is introduced properly, and the same could perhaps be done for these
|
||
terms as well.
|
||
The structure of function calls (fun/num of pars) is not obvious to the
|
||
reader, perhaps it could be explained.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
It is hard to refer to the figures since they are not numbered.
|
||
\end_layout
|
||
|
||
\begin_layout Section*
|
||
What we would like to see ...
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
It would be interesting to see this system combined with a testing framework,
|
||
like QuickCheck, in order to create a powerful test suite which generates
|
||
tests using real data samples.
|
||
If the data generated by the recorder could be used as input to a testing
|
||
framework, like QuickCheck, a very powerful and random test suite could
|
||
be created.
|
||
\end_layout
|
||
|
||
\begin_layout Standard
|
||
A graphical user interface could be useful to present the simulators in
|
||
a more efficient way to the users of the simulator.
|
||
Providing a framework for creating graphical simulators would be a nice
|
||
improvement.
|
||
|
||
\end_layout
|
||
|
||
\end_body
|
||
\end_document
|