The RMIModelServer is used to remotely allocate a series of [_HardwareEmulators_](https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/hardware_emulator), which can load different autopilots generated with [_EMAM2CPP_](https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/generators/EMAM2Cpp).
The RMIModelServer is used to remotely allocate a series of [_SoftwareSimulators_](https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/hardware_emulator), which can load different softwares generated with [_EMAM2CPP_](https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/generators/EMAM2Cpp).
## Requirements
...
...
@@ -25,20 +25,17 @@ __NOTE:__ _MontiSim_ is the directory, in which MontiSim-belonging projects shou
To just compile the `jar`, use
mvn clean install -s settings.xml
To compile and copy the server to the local `install` folder, use the `scripts/compile_install` scripts.
__NOTE:__ New versions of the _HardwareEmulator_ must be copied into the `install` folder. This folder is used in a maven test to verify RMIModelServer/HardwareEmulator integration.
This will export the resulting jar in the `install` folder
## Running the RMI server
The `install` folder contains a sample setup for running the RMIModelServer.
The RMIModelServer jar must be in the same directory as the [HardwareEmulator](https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/hardware_emulator) library it will use (_HardwareEmulator.lib_ or _HardwareEmulator.so_ for Windows or Linux).
The `run` script starts an instance of the RMIModelServer. It uses the `config` script to provide a way of changing the port or the autopilot folder used. The port defaults to 10101, and can be changed to start multiple RMIModelServers.
The `install` folder contains an exemplary setup to start the server.
The `run` script starts an instance of the RMIModelServer. It uses the `config` script to provide a way of changing the port or the softwares folder used. The port defaults to 10101, and can be changed to start multiple RMIModelServers.
The autopilot folder is a folder path (absolute or relative to the RMIModelServer) in which the RMI server will look for autopilot programs.
The softwares folder is a folder path (absolute or relative to the RMIModelServer) in which the RMI server will look for programs to run inside a SoftwareSimulator.
These programs are the EmbeddedMontiArc models compiled with EMAM2CPP (or a project using EMAM2CPP such as [EMAM-showcase](https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/EMAM-showcase) or [EMAStudio](https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/utilities/EMAStudioBuilder)).
The `autopilots` folder in the `install` folder contains the sample autopilot from `EMAM-Showcase`.
The `softwares` folder in the `install` folder contains the sample autopilot from `EMAM-Showcase`.
## Docker
...
...
@@ -63,49 +60,3 @@ Or, for example with port 5000:
```
$ docker run --name=rmi-server -p 5000:10101 --rm rmi-server
```
# Dev Documentation
## Emulator configuration
The [emulator_configuration](docs/emulator_configuration.pdf) document shows the configuration possibilities for the autopilot emulators.
## HardwareEmulator JNI interface
The interface of between the RMIModelServer and the HardwareEmulator works with _Java Native Interface (JNI)_. In case of an update
of the interface (file: [src/main/java/simulator/integration/HardwareEmulatorInterface.java](src/main/java/simulator/integration/HardwareEmulatorInterface.java)),
the corresponding C header has to be generated.
Currently, this happens in the [hardware_emulator](https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/hardware_emulator) project under the `jni` folder,
where the HardwareEmulatorInterface.java has to be copied. `generate.bat` shows how to update the interface on Windows.
The java file has to be adapted to compile without its dependencies, since the JNI header will only
be generated from compilable java files. Since the actual header file only depends on the `native` functions from the java file, the other dependencies can
be safely deleted. The resulting header file then has to be renamed `emulator_server.h` and placed in the `hardware_emulator/src/emulator` source folder.
The corresponding implementations of the C interface have to be updated in `hardware_emulator/src/emulator/emulator_server.cpp`.
A better approach would be a script in the RMIModelServer project generating the header and copying it to the *hardware_emulator* project.
## New autopilot EMA port types
To communicate with the ports from the autopilot, an _AutopilotAdapter_ encapsulates the EMA model. For new port data types,
the *EMAM2CPP* generator and the *hardware_emulator* have to be updated to handle the new data type.
In the EMAM2CPP project, the `de.monticore.lang.monticar.generator.cpp.viewmodel.AutopilotAdapterDataModel` class is responsible to create the _AutopilotAdapter_.
In its `addInput` and `addOutput` functions, the new function definition and declarations for the data type have to be defined.
In the *hardware_emulator* projects, three places require updates for new data types.
1. The `hardware_emulator/src/emulator/function_values.h / .cpp` files need to updated with the new data type (`enum class VALUE_TYPE`), buffer entry (`struct FunctionValue`) and type name (`FunctionValue::get_type()`).
2. The `call_input()` and `call_output()` functions from the `HardwareEmulator` structure (`hardware_emulator/src/emulator/hardware_emulator.h`) must be updated. They need to know how to pass the arguments to the emulated autopilots.
3. The `Java_simulator_integration_HardwareEmulatorInterface_add_1one_1input()` and `Java_simulator_integration_HardwareEmulatorInterface_query_1outputs()` functions need to know how to pass and read port data to and from Java. (`hardware_emulator/src/emulator/emulator_server.h`)
## Unsupported autopilot functionalities.
The emulator used in this RMIModelServer only implements features encountered in previous autopilots.
New autopilots might trigger new unsupported features:
* Unsupported system calls (enable `debug=unsupported_syscalls` flag for the autopilot emulator). These are operating system functions for which no current emulation is implemented. These have to be added and registered in the `hardware_emulator/src/os_linux/linux_calls.h / .cpp` files for Linux and in the `hardware_emulator/src/os_windows/windows_calls.h / .cpp` files for Windows.
* Unsupported instruction time value. The time table (currently `hardware_emulator/src/timetable/skylake.txt`) describing the number of CPU cycles for every instruction is manually filled. It currently only contains entries (!=0) for encountered instructions. It can be filled with elements from the `hardware_emulator/docs/instruction_time.txt` file (which contains entries from the instruction_tables.pdf file).
To make sure the autopilot emulation is correct, allocate an autopilot emulator with the `test_real` flag. When loading an autopilot with the same OS as the RMIModelServer, the emulator will compare the outputs of the emulated autopilot with the outputs of the actual autopilot program.
morekeywords={component, port, in, out, inv, package, import, connect, autoconnect}
}
% Seite einrichten
\setlength{\voffset}{-1in}
\setlength{\hoffset}{-1in}
\setlength{\topmargin}{2.5cm}
\setlength{\headheight}{0cm}
\setlength{\headsep}{0cm}
\setlength{\oddsidemargin}{3,3cm}% innen ein wenig mehr Rand für die Klebebindung
\setlength{\evensidemargin}{2,7cm}% dafür außen ein wenig weniger
\setlength{\textwidth}{15cm}
\setlength{\textheight}{23,5cm}
\setlength{\parindent}{0cm}
\newcommand{\emptyLine}{{\LARGE ~\\}}
\begin{document}
\setcounter{page}{1}
\pagenumbering{arabic}
\section{Configuration}
\label{emuconfig}
The HardwareEmulator and the EmulatorManager support a simple fail-safe way of configuring them and making queries to them. A message is made of a String where each line (separated by a newline character) is a name followed by optional parameters.
The syntax is whitespace insensitive and as follows:
\begin{verbatim}
name = param1, param2, param...
or
name
\end{verbatim}
Whitespace is optional, and the only separating characters are the equal sign ($=$), the comma (,) and the newline character (\texttt{\textbackslash n}).
\subsection{Configuration}
The current settings supported when allocating an emulator are shown in Table~\ref{tab:emuconfig}.
\begin{table}[!htb]
\begin{tabularx}{\textwidth}{ | X |}
\hline
\texttt{autopilot=name}\\
Name of the autopilot program file, without extension.\\\hline
\texttt{os=name}\\
Name of the operating system used. Currently \texttt{linux} or \texttt{windows}. This implies the extension of the autopilot file searched. If the os command is not given, the Emulator will search for any autopilot with the given name in the search folder. \\\hline
\texttt{debug=flag1,flag2,\dots}\\
Enable the debugging outputs for the specified flags, where the flags are any of \texttt{mem}, \texttt{regs}, \texttt{reg\_update}, \texttt{syscalls}, \texttt{unsupported\_syscalls}, \texttt{code} or \texttt{call}. \\\hline
\texttt{cpu\_frequency=value}\\
The CPU frequency in Hertz used to evaluate the computation time. \\\hline
\texttt{memory\_frequency=value}\\
The RAM frequency in Hertz used to evaluate the computation time. \\\hline
Where \texttt{name} is \texttt{IL1}, \texttt{DL1}, \texttt{L2} or \texttt{L3}.
This setting enables and sets the parameters of the named cache layer. Set \texttt{size} to 0 to disable this cache level. The ticks refer to the CPU ticks.\\\hline
\texttt{no\_time}\\
Disables the delaying of the autopilot in the simulation. \\\hline
\texttt{test\_real}\\
If the RMIModelServer and the autopilot are of the same operating system type, this flag makes the emulator load the autopilot directly as a library (not emulated) and uses its outputs to validate those of the emulated instance. \\
\texttt{export}\\
Enables the \texttt{HardwareEmulator} to export the deviation from the planned trajectory and the evaluated execution time of the autopilot. Data is currently exported for the first 60 seconds of the simulation. The output files are \texttt{autopilot\_dist.txt} and \texttt{autopilot\_time.txt}.
\\\hline
\end{tabularx}
\caption{HardwareEmulator Configuration}
\label{tab:emuconfig}
\end{table}
The \texttt{EmulatorManager} itself also supports a config string on initialization. Table~\ref{tab:managerconfig} shows the supported config.
\begin{table}[!htb]
\begin{tabularx}{\textwidth}{ | X |}
\hline
\texttt{autopilots\_folder=folder}\\
Sets the folder in which to look for autopilot programs.\\\hline
\end{tabularx}
\caption{EmulatorManager Configuration}
\label{tab:managerconfig}
\end{table}
\subsection{Queries}
The query system uses the same presented syntax, but also sends a response for every query, using the same syntax.
Queries supported by the \texttt{EmulatorManager} are shown in Table~\ref{tab:managerqueries}.
\begin{table}[!htb]
\begin{tabularx}{\textwidth}{ >{\em}l | X |}
\cline{2-2}
Query &\texttt{get\_error\_msg}\\
Response &\texttt{error\_msg=msg}\\
& Returns the last error message that occurred while allocating an autopilot emulator. \\\cline{2-2}
