Im Labor fu¨r Datentechnik, FB Elektrotechnik der Hochschule Ostfalia, wurde fu¨r die Vermittlung von Hardwareprogrammierung durch die Programmiersprache ABEL ein Versuch abgea¨ndert. Hierbei wurden bestehende Toolbook-Versuche auf die automatische Bewertung und Vermittlung mittels LON-CAPA und Praktomat umgestellt. Gru¨nde fu¨r eine Erneuerung des Versuches sind zum einen, den alten Versuch plattformunabha¨ngig zu gestalten. Zum anderen soll gleichzeitig die Verwendung neuester Webtechnologien ermo¨glicht werden. Probleme mit Windows-Updates sorgten in der Vergangenheit fu¨r einen erho¨hten Aufwand bei der Sicherstellung der Funktionstu¨chtigkeit des Laborversuches. Die Evaluation der Studentinnen und Studenten sollte ebenfalls erleichtert und eine Alternative zu den hohen Lizenzkosten des alten Versuchs gefunden werden. In diesem Paper wird gezeigt, wie die Umsetzung erfolgt und welche Vorteile dieser Umstieg mit sich bringt. Im Folgenden werden die Funktionsweise und der Ablauf des Labors vorgestellt. Das Labor, in dem der Versuch durchgefu¨hrt wurde, befindet sich im Elektrotechnik Hauptstudium. Ein Team aus zwei Studierenden fu¨hrt einmal pro Woche einen praktischen Versuch durch. Die Versuche sollen den Studentinnen und Studenten einen einfachen Zugang in verschiedene Bereiche vermitteln. Diese bestehen aus Grundlagen in Assembler Programmierung, der Logikanalyse, des Synthetisieren eines FPGAs und der Hardwareprogrammiersprache ABEL. Die jeweiligen Versuche bestehen aus drei Teilen: dem Grundlagenteil, mit anschließendem Abfragen des Wissens, dem Programmierteil, zum Erlernen der Sprache und dem anschließenden Projekt zum Programmieren mit ABEL zu einem bestimmten Hardware- Aufbau. Der Laborversuch zur Vermittlung von ABEL wurde 1994 im Rahmen einer Diplomarbeit erstellt. Teilweise wird fu¨r die Durchfu¨hrung eine DOS-Umgebung beno¨tigt. Die Einfu¨hrung der Studierenden in die Thematik wurde mittels Toolbook2 durchgefu¨hrt. Nicht nur die Pflege und Korrigierbarkeit der Toolbook-Versuche sondern auch die Bereitstellung der Programmierumgebung ist durch Betriebsystem-Updates immer schwieriger geworden. 1 Fakulta¨t Elektrotechnik / Zell, Ostfalia HS 2 Toolbook ist eine kostenpflichtige e-Learning Software die seit 1990 am Markt ist. Sie wird bis heute gepflegt und durch die Firma SumTotal Systems weiterentwickelt.
Im Anschluss an den Grundlagenteil zur ABEL-Programmierung steht eine gro¨ßere Programmieraufgabe an. In dieser sollen die Studierenden einen PLD (Programmable Logic Device) programmieren und einen vorhandenen Aufbau mit ihrer erstellten Logik versorgen. Im alten Versuch wurden die Einreichungen mit Hilfe von Batch-Skripten kompiliert. Anschließend erfolgte ein Vergleich der Pru¨fsummen des Kompilates (JDEC-Datei) mit der Musterlo¨sung, um die fachliche Richtigkeit der Aufgabe sicherzustellen. Die Anforderungen an das neue System sind sehr unterschiedlich, es soll: als Alternative zu den Toolbook-Versuchen dienen, den Abel-Compiler fu¨r eine automatische U¨ berpru¨fung nutzen, die einfache Pflege der Aufgaben gewa¨hrleisten, keine Lizenzgebu¨hren beinhalten, besser unter Verwendung freier bzw. offener Software laufen, und bestehende Infrastruktur der Hochschule nutzen.
Im Kapitel 2 werden die verwendeten Systeme und deren technischer Ablauf beschrieben. Folgend wird im Kapitel 3 dessen Ergebnis ausgewertet und die Evaluation der zwei Testgruppen diskutiert. Abschließend folgt in Kapitel 4 der Ausblick. 2
Mit LON-CAPA steht an der Hochschule bereits ein kostenfreies Lern-Management-System zur Verfu¨gung. LON-CAPA ist quelloffen und wird sta¨ndig weiterentwickelt. Daru¨ber hinaus bietet es eine Vielzahl von Aufgabentypen (z.B. Multiple-Choice, Click-in-Bild). Weitere Arbeitsmittel bestehen beispielsweise aus Stundenpla¨nen, vielen Kommunikationswerkzeugen (E-Mail, Chat und Foren) aber auch Mo¨glichkeiten, innerhalb von Kursen Informationen zum Selbstlernen bereitzustellen. Eine wichtige Sta¨rke ist zudem die Fa¨higkeit der Wiederverwendung und des Austausches von Aufgaben zwischen den Dozenten und verschiedenen Einrichtungen innerhalb des LON-CAPA Netzwerkes (vgl. [Ko08]). Die Toolbook-Versuche konnten erfolgreich in LON-CAPA u¨bertragen werden. Die Vermittlung von Inhalten mit anschließender U¨ berpru¨fung durch Multiple-Choice-Fragen wurde beibehalten. Hierbei ist darauf geachtet worden, dass die Auswahl an Antworten auf drei beschra¨nkt wird. LON-CAPA wa¨hlt dabei per Zufall aus einer gro¨ßeren Anzahl von Antworten fu¨r die jeweilige Frage aus. Einfache Betrugsversuche des Abschauens und des Auswendiglernens von Antworten sind somit nur noch unter gro¨ßerem Aufwand mo¨glich. Eine automatische U¨berpru¨fung der Programmieraufgabe ist mittels LON-CAPA nicht mo¨glich. Fu¨r diesen spezialisierten Anwendungsfall kam das Bewertungssystem Praktomat 3 zum Einsatz. Der Praktomat ist ein eigensta¨ndiges, webbasierendes und modulares 3 https://github.com/KITPraktomatTeam/Praktomat Weiterentwicklung vom Karlsruhe Institute of Technology (KIT) Bewertungssystem. Es unterstu¨tzt verschiedene Programmiersprachen wie Java, Python und C++. An der Ostfalia HS wurde eine Schnittstelle zwischen LMS (LON-CAPA) und Grader (Praktomat) entwickelt und eingesetzt (vgl. [PJR12a]). Im Rahmen des Projektes wurden nur Formative Evaluation in den Programmiersprachen Java und Python verwendet.
Eine der Hauptschwierigkeiten bei der Umstellung des Laborversuchs lag in der Umsetzung eines automatisierten Testverfahrens fu¨r die U¨berpru¨fung der ABEL-Programmieraufgabe. Die modulare Struktur der Tests (Checker) im Praktomaten ermo¨glichten es, einen eigensta¨ndigen ABEL-Test zu schreiben. Der ABEL-Kompiler und die Batch-Skripte beno¨tigen jedoch eine DOS-Umgebung. Diese wurde auf dem Praktomaten mittels DOSBox 4 emuliert.
Der Fokus der DOS-Umgebung wurde in erster Linie auf das Spielen gelegt und nicht auf den Serverbetrieb. Eine Anpassung der Konfigurationsskripte ermo¨glichte den Betrieb auch ohne Windows-System. Der Bedarf an Arbeitsspeicher und CPU-Zeit konnte somit verringert werden.
Die DOSBOX la¨uft ohne Administratorenrechte und kann als Benutzerprozess aufgerufen werden. Die einzelnen Tests werden im Praktomaten immer in einer eigenen Benutzerumgebung aufgerufen. Somit ist die Sicherheit des Gesamtsystems durch Fehler in der DOSBox nicht gefa¨hrdet.
In der Abbildung 1 ist eine Aufgabe aus dem umgesetzten Laborversuch gezeigt. Nach einer Beschreibung der Aufgabe sind die Studierenden aufgefordert ihre Lo¨sung in einem HTML-Textfeld zu entwickeln. Die Studentinnen und Studenten sollen bei dieser Aufgabe aus dem Programmierbeispiel lernen und das angeeignete Wissen anschließend in einer Transferaufgabe umsetzen.
Die Abbildung 2 veranschaulicht in Form eines Sequenzdiagramms den Ablauf einer studentischen Einreichung. LON-CAPA sendet die studentische Einreichung mit der zugeho¨rigen Identifikationsnummer der Aufgabe (TaskId) an den Praktomaten. Dieser startet den Grading-Prozess in welchem alle no¨tigen Programme wie Kompiler und BatchSkripte in den Arbeistordner, zu der eingereichten Datei, kopiert werden. Der Ordner wird anschließend in der DOSBox gemountet um Zugriff darauf zu erhalten. Mit Hilfe von Batch-Skripten wird die Einreichung kompiliert. Anschließend erfolgt ein Vergleich der Pru¨fsummen des Kompilates (JDEC-Datei) und der Musterlo¨sung. Dies stellt die fachliche Richtigkeit der Aufgabe sicher. Das Ergebnis (GradingResult) wird an LON-CAPA zuru¨ckgesendet. Die Studierenden bekommen eine nicht bearbeitete Ausgabe des Kompilers zuru¨ck, wodurch sie Fehler im Programm-Code finden und korrigieren ko¨nnen. 3
Die Umsetzung des Versuches auf LON-CAPA und Praktomat ermo¨glicht nun eine All-inone-Lo¨sung fu¨r die Studierenden. Sie ko¨nnen ihre Fragen direkt in LON-CAPA bearbeiten. 4 http://www.dosbox.com/information.php
Abb. 1: Ausschnitt einer Abel-Programmieraufgabe aus dem LON-CAPA-Kurs Bei der vorherigen Lo¨sung musste ein weiteres Programm herangezogen werden um die Aufgaben zu lo¨sen. Die vielseitigen Mo¨glichkeiten von LON-CAPA erleichtern das Verschmelzen von erlerntem und anschließend angewandtem Wissen. Dem Kursleiter bietet sich eine Vielzahl an Mo¨glichkeiten das Lernerlebnis der Studenten positiv zu gestalten. Der Versuch wurde bereits an zwei studentischen Gruppen getestet. Dabei stellte sich heraus, dass die Anzahl der Versuche zur Beantwortung der Multiple-Choice-Fragen aus dem Grundlagenteil, mit einem Antwortversuch pro Frage, etwas knapp gewa¨hlt ist. Die Studierenden sollen die Mo¨glichkeit erhalten, ihre falsche Antwort zu korrigieren nachdem sie den Teil noch einmal in den Grundlagen nachgelesen haben. In LON-CAPA la¨sst sich die Anzahl der Versuche schnell anpassen.
Eine Gruppe von Studierenden hatte wenige Wochen zuvor den alten Versuch absolviert und war von den Neuerungen angetan. Die Gruppe wies darauf hin, dass sie es als sto¨rend empfinde die Parameter der Programmieraufgabe jedes mal neu eingeben zu mu¨ssen. Dies ließ sich schnell umsetzen und wird, sofern es sich bei weiteren Versuchsdurchla¨ufen als positive Hilfe erweist, beibehalten oder entfernt, falls nicht.
Abb. 2: Sequenzdiagramm der Kommunikation zwischen LON-CAPA und Praktomat Ein weiterer Hinweis bezog sich auch auf die Programmieraufgabe. Wenn die Programmieraufgabe erfolgreich absolviert wurde, ist der Inhalt der JDEC-Datei im Textfenster angezeigt worden. Der Inhalt musste umsta¨ndlich in eine Textdatei eingefu¨gt werden. Mittels Javascript und einem HTML5-Downloadlink wurde dieser Aufwand eingespart. Die Gruppe kann die Datei nach erfolgreicher Kompilierung herunterladen und im Anschluss ihren Baustein programmieren.
Wa¨hrend des Hardwareprogrammierteils kam es im Rahmen dieser Arbeit zu einer enormen Erleichterung der Administrierung des Versuches. Die Entwicklungsumgebung auf den Laborarbeitspla¨tzen konnte eingespart und der Versuch kann von einem beliebigen Arbeitsplatz durchgefu¨hrt werden. Ein Update des Betriebssystems fu¨hrt nicht mehr dazu, den Versuch im Anschluss auf dessen Funktion u¨berpru¨fen zu mu¨ssen. Die Integration einer DOS-Umgebung konnte ebenfalls erspart werden.
In LON-CAPA ist zusa¨tzlich eine IP-Begrenzung eingestellt worden, damit die Bearbeitung nur im Labor stattfinden kann. Dies dient einerseits der Sicherheit vor Angriffen auf den Versuchsumgebung. Andererseits ko¨nnen die Studierenden so die Antworten auf die Fragen nicht aus dem Antwortpool herausarbeiten. Bei Schwierigkeiten oder Fragen steht ihnen im Labor immer ein Laborbetreuer zur Verfu¨gung.
Aus der DOSBox heraus gibt es keine direkte Mo¨glichkeit die Ausgabe eines Fehlers z.B. beim Kompilieren in LON-CAPA auszugeben. Beim Aufruf des Batch-Skriptes wird die Ausgabe des DOSBox-Fensters in einer Textdatei gespeichert. Diese Datei wird durch den Praktomaten an LON-CAPA weitergeben und angezeigt. Der Praktomat besitzt die Funktion, einen Log-Eintrag zu erstellen und die Ausgabedatei darin ausgegeben. Auch im Falle einer fehlerfreien Kompilierung erscheint eine Ausgabe u¨ber den Log-Eintrag. Die Studierenden bekommen somit eine Ru¨ckmeldung ob eventuell der Syntax oder die Pinbelegung falsch ist.
Es werden zwei Batch-Skripte verwendet, die den Kompilierungsvorgang steuern. Das erste Skript u¨berpru¨ft, ob der Dateiname, der zu kompilierenden Datei, dabei ist. Bei einem Fehler erfolgt eine Ausgabe in der DOSBox mit einem konkreteren Fehlernamen. Im Falle eines fehlerfreien Durchlaufens wird AHDL2PLA.exe aufgerufen. Es kompiliert die Datei und fu¨hrt gleichzeitig eine Syntaxpru¨fung (vgl. [Ko01]), sowie eine Expansion der Macros durch. AHDL2PLA.exe reagiert auf Direktiven und synthetisiert das Design. Zuna¨chst wird die Datei in das intern verwendete PLA-Format konvertiert. Darauf folgend wird die zweite Batch-Skript aufgerufen in der die weiteren Programme aufgerufen werden. In der Reihenfolge wird anfangs PLAOPT.exe, dann FUSEASM.exe und letztlich JEDSIM.exe von dem Batch-Skript gestartet. PLAOPT.exe fu¨hrt eine Logikminimierung durch, die bei Hardwareprogrammierung anzuwenden ist, um die Gro¨ße des Hardwareaufwands so gering wie mo¨glich zu halten. FUSEASM.exe erzeugt eine Dokumentationsdatei und zusa¨tzlich eine JEDEC-Datei, die zur Programmierung des PLDs genutzt wird. Darauf folgend wird mit JEDSIM.exe die Simulation der JEDEC-Datei durchgefu¨hrt und mit eventuellen Testvektoren getestet.
Sollte bei den Vorga¨ngen ein Fehler auftauchen, wird dieser in dem Log-Eintrag von LON-CAPA ausgegeben. Bei einem erfolgreichen Durchlauf wird die JEDEC-Datei in eine Textdatei umbenannt und vom Checker des Praktomaten nach einer einzigartigen Checksumme durchsucht. Diese Checksumme ist bei einer einzelnen Programmieraufgabe immer gleich, da bei Hardwareprogrammierung die Minimierung der Logik stets fu¨r die kleinstmo¨gliche Hardwarezusammenstellung sorgt. Beim Erstellen einer Aufgabe muss diese Checksumme ha¨ndisch generiert und im Praktomaten, in ein dafu¨r eingerichtetes Feld des Checkers, eingetragen werden. 4
Durch die Verlagerung des Laborversuches von einem lokal installierten System hin zu einer Onlinelo¨sung, ist es gelungen, den Versuch zu konservieren und noch einige Jahre plattformunabha¨ngig zu nutzen. Fu¨r den kleinen Rahmen des Labors und der geringen Komplexita¨t der Aufgaben, reicht die beschriebene Lo¨sung vollkommen aus. Als Ausblick erscheint eine externe Entwicklungsumgebung fu¨r Abel zum U¨ ben und Probieren fu¨r interessierte Studentinnen und Studenten sinnvoll. Die implementierte Lo¨sung ko¨nnte auch im Rahmen eines reinen Selbststudiums genutzt werden. Hierfu¨r mu¨sste der Kursaufbau und die erlaubte Anzahl von Einreichungen angepasst werden. Ein zusa¨tzliches Feedback um den Umgang mit dem Kompiler zu erleichtern wa¨re mo¨glich, ist derzeit jedoch nicht erwu¨nscht, weil die Studierenden mit den Kompilermeldungen umgehen lernen sollen und bereits Erfahrungen mit anderen Programmiersprache haben. Eine genaue Analyse von Lasttest ko¨nnte bei einer ho¨heren Nutzung des Versuches von Interesse sein. Durch die Verwendung von DOSBox fu¨r jeden Bewertungsprozess gibt es auch klare Anforderungen an die virtuelle Maschine auf der der Praktomat la¨uft. Im Rahmen des Labors mit einer maximalen Anzahl von zwei Gruppen, die gleichzeitig den Versuch bearbeiten, ist ein Lasttest von geringerem Interesse.
Die Verwendung des Aufgabenformates ProFormA (vgl. [St15]) wu¨rde den Austausch und die Wiederverwendung des Programmieranteils sicherstellen. Viel Aufwand wa¨re hierfu¨r nicht notwendig, da der Praktomat mit LON-CAPA bereits zu den Unterstu¨tzen Systemen geho¨rt. Diese Umstellung wu¨rde auch den Konfigurationsaufwand auf dem Praktomaten reduzieren (vgl. [PJR12b]).
[Ko01] [Ko08]