GT ideas - Revision history

Weber at 12:56, 20 October 2021

2021-10-20T12:56:12Z

← Older revision		Revision as of 12:56, 20 October 2021
Line 124:		Line 124:

	Ansprechpartner: [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller]		Ansprechpartner: [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller]


	== MA (Modellbasierte Softwareentwicklung) Prozessbasierte, diskrete Simulation in Rust ==

	In diesem Masterarbeitsthema geht es um die Implementation einer Rust-Bibliothek für prozessorientierte, diskrete Simulatoren, vergleichbar mit dem älteren [https://www.informatik.hu-berlin.de/de/forschung/gebiete/sam/Lehre/tools/odemx ODEMx] für C<tt>++</tt>.

	Dazu sind Konzepte zur Umsetzung aktiver Klassen, der Erzeugung hochwertiger Zufallszahlen, der systematischen Sammlung statistischer Messgrößen sowie deren anpassbare Ausgabe zu entwickeln und umzusetzen. Darüber hinaus müssen wesentliche Synchronisationsstrukturen wie Prozesswarteschlangen, Kanäle, beschränkte und unbeschränkte abstrakte und konkrete Ressourcen implementiert werden.
	Im Gegensatz zu ODEMx wünschen wir uns die Möglichkeit, nicht nur auf zeitbasierte Ereignisse, sondern auch auf zustandsbasierte Ereignisse warten zu können sowie die Umsetzung von Intraprozessparallelität.

	Wichtiger Teil der Arbeit ist auch die Dokumentation, Unit-Tests und Benchmarks typischer Szenarien im Vergleich mit alternativen Lösungen wie [https://www.informatik.hu-berlin.de/de/forschung/gebiete/sam/Lehre/tools/odemx ODEMx] und [http://www.wolverinesoftware.com/SLXOverview.htm SLX].

	Ansprechpartner: Dorian Weber

Jpr: /* Grundsätzliches */

2020-01-20T09:36:18Z

Grundsätzliches

← Older revision		Revision as of 09:36, 20 January 2020
Line 6:		Line 6:
	* Wird das Expose akzeptiert,		* Wird das Expose akzeptiert,
	** wird vom Betreuer umgehend eine Wiki-Seite für die Abschlussarbeit angelegt. Diese enthält einen Link zum Expose, Informationen zum aktuellen Stand der Arbeit (insbesondere Meilensteine/Deadlines) und am Ende die Arbeit als PDF.		** wird vom Betreuer umgehend eine Wiki-Seite für die Abschlussarbeit angelegt. Diese enthält einen Link zum Expose, Informationen zum aktuellen Stand der Arbeit (insbesondere Meilensteine/Deadlines) und am Ende die Arbeit als PDF.
	** wird zeitnah in Vortrag im HotTopics-Seminar gehalten, in dem das Vorhaben vorgestellt wird (ca. 30 Minuten).		** wird zeitnah ein Vortrag im HotTopics-Seminar gehalten, in dem das Vorhaben vorgestellt wird (ca. 30 Minuten).
	** wird innerhalb von 1 Monat ein Zweitgutachter identifiziert und dessen Zustimmung zur Übernahme der Begutachtung eingeholt.		** wird innerhalb von 1 Monat ein Zweitgutachter identifiziert und dessen Zustimmung zur Übernahme der Begutachtung eingeholt.
	** Spätestens einen Monat nachdem das Expose akzeptiert wurde (2 Monate bei Master/Diplomarbeiten) wird die Abschlussarbeit bei Frau Lindner / Frau Weber offiziell angemeldet. Ab da beginnt die in der Studienordnung festgesetzte Frist zu laufen, die den spätesten Abgabezeitpunkt regelt.		** Spätestens einen Monat nachdem das Expose akzeptiert wurde (2 Monate bei Master/Diplomarbeiten) wird die Abschlussarbeit bei Frau Lindner / Frau Weber offiziell angemeldet. Ab da beginnt die in der Studienordnung festgesetzte Frist zu laufen, die den spätesten Abgabezeitpunkt regelt.

Jpr: /* Grundsätzliches */

2020-01-20T09:31:51Z

Grundsätzliches

← Older revision		Revision as of 09:31, 20 January 2020
Line 4:		Line 4:
	* Expose anfertigen und dem Betreuer übergeben (siehe [https://www.informatik.hu-berlin.de/de/forschung/gebiete/wbi/teaching/studienDiplomArbeiten/finished/2016/expose_roessler.pdf Wie schreibt man ein Expose?], [https://www.informatik.hu-berlin.de/de/forschung/gebiete/wbi/teaching/studienDiplomArbeiten/finished/2019/biegel.pdf Ein Beispiel])		* Expose anfertigen und dem Betreuer übergeben (siehe [https://www.informatik.hu-berlin.de/de/forschung/gebiete/wbi/teaching/studienDiplomArbeiten/finished/2016/expose_roessler.pdf Wie schreibt man ein Expose?], [https://www.informatik.hu-berlin.de/de/forschung/gebiete/wbi/teaching/studienDiplomArbeiten/finished/2019/biegel.pdf Ein Beispiel])
	* Wird das Expose vom Betreuer nicht akzeptiert, kann es maximal einmal nachgebessert werden. Wird es auch danach nicht akzeptiert, findet keine Betreuung statt.		* Wird das Expose vom Betreuer nicht akzeptiert, kann es maximal einmal nachgebessert werden. Wird es auch danach nicht akzeptiert, findet keine Betreuung statt.
			* Wird das Expose akzeptiert,
	* ~~Wird~~ ~~das~~ ~~Expose~~ ~~akzeptiert,~~ ~~wird~~ für die Abschlussarbeit ~~eine Wiki-Seite~~ angelegt. Diese enthält einen Link zum Expose, Informationen zum aktuellen Stand der Arbeit (insbesondere Meilensteine/Deadlines) und am Ende die Arbeit als PDF.		** wird vom Betreuer umgehend eine Wiki-Seite für die Abschlussarbeit angelegt. Diese enthält einen Link zum Expose, Informationen zum aktuellen Stand der Arbeit (insbesondere Meilensteine/Deadlines) und am Ende die Arbeit als PDF.
⚫	* ~~spätestens~~ einen Monat nachdem das Expose akzeptiert wurde (2 Monate bei Master/Diplomarbeiten) wird ~~ein Zweitgutachter identifiziert und~~ die Abschlussarbeit bei Frau Lindner / Frau Weber offiziell angemeldet. Ab da beginnt die in ~~Ihrer~~ Studienordnung festgesetzte Frist zu laufen, die den spätesten Abgabezeitpunkt regelt.
	* ~~Zeitnah~~ ~~nach dem Akzepieren des Expose wird~~ ~~ein~~ Vortrag im HotTopics-Seminar gehalten, in dem das Vorhaben vorgestellt wird (ca. 30 Minuten).		** wird zeitnah in Vortrag im HotTopics-Seminar gehalten, in dem das Vorhaben vorgestellt wird (ca. 30 Minuten).
			** wird innerhalb von 1 Monat ein Zweitgutachter identifiziert und dessen Zustimmung zur Übernahme der Begutachtung eingeholt.
	* Bei Masterarbeiten: Sobald die Lösungen für die wichtigsten Fragen der Arbeit bekannt sind, werden diese im HotTopics-Seminar vorgestellt.
		⚫	** Spätestens einen Monat nachdem das Expose akzeptiert wurde (2 Monate bei Master/Diplomarbeiten) wird die Abschlussarbeit bei Frau Lindner / Frau Weber offiziell angemeldet. Ab da beginnt die in der Studienordnung festgesetzte Frist zu laufen, die den spätesten Abgabezeitpunkt regelt.

Jpr: /* Grundsätzliches */

2020-01-20T09:27:10Z

Grundsätzliches

← Older revision		Revision as of 09:27, 20 January 2020
Line 5:		Line 5:
	* Wird das Expose vom Betreuer nicht akzeptiert, kann es maximal einmal nachgebessert werden. Wird es auch danach nicht akzeptiert, findet keine Betreuung statt.		* Wird das Expose vom Betreuer nicht akzeptiert, kann es maximal einmal nachgebessert werden. Wird es auch danach nicht akzeptiert, findet keine Betreuung statt.
	* Wird das Expose akzeptiert, wird für die Abschlussarbeit eine Wiki-Seite angelegt. Diese enthält einen Link zum Expose, Informationen zum aktuellen Stand der Arbeit (insbesondere Meilensteine/Deadlines) und am Ende die Arbeit als PDF.		* Wird das Expose akzeptiert, wird für die Abschlussarbeit eine Wiki-Seite angelegt. Diese enthält einen Link zum Expose, Informationen zum aktuellen Stand der Arbeit (insbesondere Meilensteine/Deadlines) und am Ende die Arbeit als PDF.
			* spätestens einen Monat nachdem das Expose akzeptiert wurde (2 Monate bei Master/Diplomarbeiten) wird ein Zweitgutachter identifiziert und die Abschlussarbeit bei Frau Lindner / Frau Weber offiziell angemeldet. Ab da beginnt die in Ihrer Studienordnung festgesetzte Frist zu laufen, die den spätesten Abgabezeitpunkt regelt.
	* Zeitnah wird ein Vortrag im HotTopics-Seminar gehalten, in dem das Vorhaben vorgestellt wird (ca. 30 Minuten).		* Zeitnah nach dem Akzepieren des Expose wird ein Vortrag im HotTopics-Seminar gehalten, in dem das Vorhaben vorgestellt wird (ca. 30 Minuten).
	* Nach dem Vortrag wird die Arbeit bei Frau Lindner / Frau Netwon angemeldet. Die Bearbeitungszeit ist in Ihrer Studienordnung festgelegt.
	* Bei Masterarbeiten: Sobald die Lösungen für die wichtigsten Fragen der Arbeit bekannt sind, werden diese im HotTopics-Seminar vorgestellt.		* Bei Masterarbeiten: Sobald die Lösungen für die wichtigsten Fragen der Arbeit bekannt sind, werden diese im HotTopics-Seminar vorgestellt.

Weber: Titel korrigiert (MA zu BA)

2019-12-05T14:14:03Z

Titel korrigiert (MA zu BA)

← Older revision		Revision as of 14:14, 5 December 2019
Line 137:		Line 137:


	== MA (Modellbasierte Softwareentwicklung) Programmierung von eingebetteten Geräten ==		== BA (Modellbasierte Softwareentwicklung) Programmierung von eingebetteten Geräten ==

	Dieses Bachelorarbeitsthema soll überblicksartig die Programmierung von eingebetteten Geräten wie Mikrocontrollern, Raspberry-Pi und/oder Grafikkarten (CUDA/OpenCL) in den jeweils dafür üblichen Sprachen (Lua, Python, Rust, C) erklären und für verschiedene Anwendungsfälle miteinander vergleichen.		Dieses Bachelorarbeitsthema soll überblicksartig die Programmierung von eingebetteten Geräten wie Mikrocontrollern, Raspberry-Pi und/oder Grafikkarten (CUDA/OpenCL) in den jeweils dafür üblichen Sprachen (Lua, Python, Rust, C) erklären und für verschiedene Anwendungsfälle miteinander vergleichen.

Jpr: /* BA: (Programming Paradigms) Concurrent Programming in Rust und Go - Performance vergleichen */

2019-10-28T10:06:04Z

BA: (Programming Paradigms) Concurrent Programming in Rust und Go - Performance vergleichen

← Older revision		Revision as of 10:06, 28 October 2019
Line 55:		Line 55:
	Ansprechpartner: Jens-Peter Redlich		Ansprechpartner: Jens-Peter Redlich

	== BA: (Programming Paradigms) Concurrent Programming in Rust und Go - Performance vergleichen ==		== (reserviert bis 1.12.2019 für A.Toth) BA: (Programming Paradigms) Concurrent Programming in Rust und Go - Performance vergleichen ==

	Go ist eine Programmiersprache, die für ihre Fähigkeit zur nebenläufigen (concurrent) Programmausführung oft gelobt wird; insbesondere weil sich daraus ein Performance-Gewinn auf Mehr-CPU-Systemen ergibt.		Go ist eine Programmiersprache, die für ihre Fähigkeit zur nebenläufigen (concurrent) Programmausführung oft gelobt wird; insbesondere weil sich daraus ein Performance-Gewinn auf Mehr-CPU-Systemen ergibt.

Jpr: /* BA; Concurrent Programming in Rust und Go - Performance vergleichen */

2019-10-21T11:07:09Z

BA; Concurrent Programming in Rust und Go - Performance vergleichen

← Older revision		Revision as of 11:07, 21 October 2019
Line 55:		Line 55:
	Ansprechpartner: Jens-Peter Redlich		Ansprechpartner: Jens-Peter Redlich

	== BA; Concurrent Programming in Rust und Go - Performance vergleichen ==		== BA: (Programming Paradigms) Concurrent Programming in Rust und Go - Performance vergleichen ==

	Go ist eine Programmiersprache, die für ihre Fähigkeit zur nebenläufigen (concurrent) Programmausführung oft gelobt wird; insbesondere weil sich daraus ein Performance-Gewinn auf Mehr-CPU-Systemen ergibt.		Go ist eine Programmiersprache, die für ihre Fähigkeit zur nebenläufigen (concurrent) Programmausführung oft gelobt wird; insbesondere weil sich daraus ein Performance-Gewinn auf Mehr-CPU-Systemen ergibt.

Jpr at 11:06, 21 October 2019

2019-10-21T11:06:29Z

← Older revision		Revision as of 11:06, 21 October 2019
Line 55:		Line 55:
	Ansprechpartner: Jens-Peter Redlich		Ansprechpartner: Jens-Peter Redlich

			== BA; Concurrent Programming in Rust und Go - Performance vergleichen ==

			Go ist eine Programmiersprache, die für ihre Fähigkeit zur nebenläufigen (concurrent) Programmausführung oft gelobt wird; insbesondere weil sich daraus ein Performance-Gewinn auf Mehr-CPU-Systemen ergibt.
			Zur Demonstration wird oft das "Sieve of Eratostheneson" (https://play.golang.org/p/9U22NfrXeq) verwendet.
			Rust ist eine Programmiersprache, die von sich behauptet, ebenfalls sehr performanten Code zu ermöglichen (der zusätzlich noch "sicher" ist, z.B. im Hinblick auf die Speicherverwaltung).
			Ziel der Arbeit ist es, die Leistungsfähogkeit beider Sprachen/Laufzeitsysteme zu vergleichen und insbesondere die Implementation in Rust zu optimieren, so dass sie die Go-Variante schlagen kann (falls das möglich ist).

			Ansprechpartner: Jens-Peter Redlich

	== MA (Heimautomatisierung) Integration von KNX und OpenHAB (1) ==		== MA (Heimautomatisierung) Integration von KNX und OpenHAB (1) ==

Jpr: /* vergeben (Mark Spitzner) BA (Heimautomatisierung) Anwesenheitssimulation in OpenHAB */

2019-10-21T10:58:15Z

vergeben (Mark Spitzner) BA (Heimautomatisierung) Anwesenheitssimulation in OpenHAB

← Older revision		Revision as of 10:58, 21 October 2019
Line 29:		Line 29:


	== vergeben (Mark Spitzner) BA (Heimautomatisierung) Anwesenheitssimulation in OpenHAB ==		== vergeben (Mark Spitzner): BA (Heimautomatisierung) Anwesenheitssimulation in OpenHAB ==

	Ziel ist es, die Events in einem OpenHab Heimautomatisierungssytem über einen längeren Zeitraum aufzuzeichnen und mit deren Hilfe eine Anwesenheitssimulation zu ermöglichen. Eine Anwesenheitssimmulation wird aktiv, wenn niemand im Objekt (Haus, Wohnung) anwesend ist. Sie soll nach außen sichtbare Ereignisse selbsttätig auslösen, so dass der sich einem externen Beobachter ergebende Eindruck sich nicht von dem unterscheidet, den er haben könnte, wenn jemand anwesend wäre. Um einen guten Eindruck bekommen, was im Wohnbjekt normalerweise passiert, können Events des OpenHab aufgezeichnet werden. Die Anwesenheitssimmulation ist jedoch sinnvoll anzupassen,		Ziel ist es, die Events in einem OpenHab Heimautomatisierungssytem über einen längeren Zeitraum aufzuzeichnen und mit deren Hilfe eine Anwesenheitssimulation zu ermöglichen. Eine Anwesenheitssimmulation wird aktiv, wenn niemand im Objekt (Haus, Wohnung) anwesend ist. Sie soll nach außen sichtbare Ereignisse selbsttätig auslösen, so dass der sich einem externen Beobachter ergebende Eindruck sich nicht von dem unterscheidet, den er haben könnte, wenn jemand anwesend wäre. Um einen guten Eindruck bekommen, was im Wohnbjekt normalerweise passiert, können Events des OpenHab aufgezeichnet werden. Die Anwesenheitssimmulation ist jedoch sinnvoll anzupassen,

Jpr: /* BA (Heimautomatisierung) Anwesenheitssimulation in OpenHAB */

2019-10-21T10:57:50Z

BA (Heimautomatisierung) Anwesenheitssimulation in OpenHAB

← Older revision		Revision as of 10:57, 21 October 2019
Line 29:		Line 29:


	== BA (Heimautomatisierung) Anwesenheitssimulation in OpenHAB ==		== vergeben (Mark Spitzner) BA (Heimautomatisierung) Anwesenheitssimulation in OpenHAB ==

	Ziel ist es, die Events in einem OpenHab Heimautomatisierungssytem über einen längeren Zeitraum aufzuzeichnen und mit deren Hilfe eine Anwesenheitssimulation zu ermöglichen. Eine Anwesenheitssimmulation wird aktiv, wenn niemand im Objekt (Haus, Wohnung) anwesend ist. Sie soll nach außen sichtbare Ereignisse selbsttätig auslösen, so dass der sich einem externen Beobachter ergebende Eindruck sich nicht von dem unterscheidet, den er haben könnte, wenn jemand anwesend wäre. Um einen guten Eindruck bekommen, was im Wohnbjekt normalerweise passiert, können Events des OpenHab aufgezeichnet werden. Die Anwesenheitssimmulation ist jedoch sinnvoll anzupassen,		Ziel ist es, die Events in einem OpenHab Heimautomatisierungssytem über einen längeren Zeitraum aufzuzeichnen und mit deren Hilfe eine Anwesenheitssimulation zu ermöglichen. Eine Anwesenheitssimmulation wird aktiv, wenn niemand im Objekt (Haus, Wohnung) anwesend ist. Sie soll nach außen sichtbare Ereignisse selbsttätig auslösen, so dass der sich einem externen Beobachter ergebende Eindruck sich nicht von dem unterscheidet, den er haben könnte, wenn jemand anwesend wäre. Um einen guten Eindruck bekommen, was im Wohnbjekt normalerweise passiert, können Events des OpenHab aufgezeichnet werden. Die Anwesenheitssimmulation ist jedoch sinnvoll anzupassen,
Line 42:		Line 42:

	Ansprechpartner: Jens-Peter Redlich		Ansprechpartner: Jens-Peter Redlich


	== BA oder MA (Heimautomatisierung) Automatisierte Erstellung (und Ausführung) von "Plänen" in der Heimautomatisierung ==		== BA oder MA (Heimautomatisierung) Automatisierte Erstellung (und Ausführung) von "Plänen" in der Heimautomatisierung ==