alexandernahr / arduino_team_pmes_ws2016 Goto Github PK

Überarbeitung der derzeitigen Softwarearchitektur mit den bisher gesammelten Erkenntnissen.

Die Softwarearchitektur muss nachgezogen werden.
Welche Module/Klassen und Funktionen/Methoden benötigen wir und was machen Sie.
Welche Parameter und Returnvalues haben die Funktionen/Methoden?

Vieles von der Architektur gibt es schon. Jeder hat sich mit einem ganz bestimmten Thema beschäftigt.
Iza kennt sich mit den Timern aus Mario hat das WiFi Modul implementiert und auch Dokumentiert.

Entscheidet jetzt welche Funktionen ihr verwendet und erstellt daraus die Feinarchitektur des Arduino Programms.

Sollen wir uns hierzu nochmal treffen? Jeder bereitet seinen Teil vor und dann erstellen wir die Architektur gemeinsam. (z.B. mit Skizzenprogramm von Alex gemeinsam erstellen. Einer Zeichnet die anderen geben Input)

Der Große Vorteil an einem gemeinsamen Treffen wäre, dass alle an Bord sind und so die Infos nicht nochmal über irgend einen Kanal fließen müssen.

Das muss ASP geschehen.

Eigentlich gehts hier nur um eine Einigung ob wir es so umsetzten oder nochmal etwas anpassen.

Terminierung
Derzeit arbeiten wir mit:
Startzeichen "["
Endzeichen "]"
UART Sendeterminierung "%"

Eine äußerst wichtige Frage die noch zu klären wäre ist die Thematik mit einer möglichen Mehrfachanmeldung. Bekommen wir es technisch in den Griff z.B. einen Telnehmer abzuweisen wenn sich bereits ein Client auf dem WLAN-Modul eingeloggt hat?

Beispiel:

Protokolldefinition

Integration der aktuellen WiFi Service Klasse in den Integrationsbranch unter Berücksichtigung der
Codierungsrichtlinien

Empfangener Bestellstring und ggf. bereits entschlüsselter Bestellstring auf Auftragsstapel an Factory senden und an das dafür vorgesehene Interface der Factory anbinden.

Lt. Herr Schubert ist das durch das abschicken des Strings über das entsprechende Interface erledigt.
ggf. muss noch ein weiteres Interface dafür in betrieb genommen werden.
Ich habe noch keine Informationen wie die Factory genau kontaktiert ist.

Die Aufgabe erledigen wir vor Ort.

Bitte bereinigt die Struktur im Code Ordner.

Ein Ordner für Spikes und ein Ordner für die lauffähige Version des aktuellen des Arduinocodes.

Beim auschecken sollte der aktuelle Arduinocode in dem das Gesamtprojekt realisiert ist lauffähig sein weil alle Teammitglieder und evtl. auch Team APP daran interessiert ist.

Wie im letzten Sprintreview vereinbart, wollen wir den Integrationsbranch sterben lassen und den Code in den Master mergen um Verwechslungen zu vermeiden.

UART Schnittstelle gemäß der Modulplanung implementieren.

Das Modul soll aus einem oder auch mehren *.c und *.h Modulen bestehen und per #include in
die Basisapplikation integriert werden können. Das Modul soll erweiterungsfähig sein.

• Erweiterungsfähige Basisimplementierung UART

Kleines Tutorial für GitHup Desktop von der Erstelleung eines Branches über commit bis hin zum Merge.

Kläreung ob und wie wir parallel mehrere Clients handlen können.

Erst nach Refactoing des Codes beginnen.

Systemtest mit kleinem Testplan der zu Präsentationszwecken verwendet werden kann.

Es geht darum zu Dokumentieren, dass unser System sich nach Aussen genauso verhält wie wir im Protokoll definiert haben.

Vielleicht kann man mit Hercules eine Logdatei anfertigen oder wir arbeiten mit Screenshots.
Weltklasse aber nicht unbedingt notwendig wäre, wenn wir die Tests leicht wiederholen könnten ohne alles
manuell durchzuprobieren.

Wenn exzesiv versucht wird sich auf dem System anzumelden, wird der Anmeldevorgang nach 3 Fehlversuchen durch einen Timer ausgebremmst. 3 Fehlversuche in einem Sinnvoll zu konfigurierenden Zeitraum soll eine ebenfalls zu definierende Anmeldeblockade zur Folge.

Abnahmekriterien:
Anmeldeblockade soll vorgeführt werden. Simulation reicht.

Rückmeldung an Tobias Schubert anfang nächster Woche

Unser System muss in der lage sein, alle validen Aufträge zu speichern und mit innerhalb der Vorgegeben Taktraten abzuarbeiten.

Hierzu ist ein Modul zu erstellen, dass diese Aufgaben bewälltigt.

Kernfunktionalitäten:

• Schnittstelle um Aufträge in das System aufzunehmen und abzuarbeiten.
• Timergesteuerte Abarbeitung von Aufträgen die sich bereits im System befinden
• Abfrage vpn Statusinformationen die aufschluss über den Momentanen Auftragsbestand und verbliebende Abarbeitungs zeit liefern
• Kapselung in eine Klasse/Modul

Bekannte Bedingungen:

• Die Abarbeitungsintervalle betragen 3 Minuten
• Die Obergrenze für die Speicherung sind 20 Aufträge
• Bevor sich eine neue Session Bestellaufträge entgegen nehmen kann, müssen alle ausstehenden Aufträge der Vorherigen Session abgearbeitet sein.
• Für jede neue Session gilt aber wieder die Obergrenze von 20 Aufträgen.

Abnahmekritereien:

• Planungszizze im Wiki
• Implementierung
• Dokumentation der Schnittstellenfunktionen

Wir haben derzeit noch keinen wirklich sicheren Ansatz für eine Verschlüssellung der gesendeten Datenstrings.
Anfangs können wir das Protokoll auch gerne ohne eine Verschlüssellung umsetzten allerdings würde ich mir eine Verschlüssellung der gesendeten und empfangenen Datenstrings wünschen.
Im Raum stand eine einfache "Caesar" Verschlüsselung. Das bedeuted einen Offset auf jedes Zeichen aufaddieren. Zum dekodieren wird der Spieß umgedreht.

Ich stelle mir eine Encode und eine Decode Funktion vor die dann im Applikationscode über empfangene Strings gelegt wird. So können wir den Algorithmus hinter den Funktionen theoretisch auch leicht austauschen.

FRAGE: Was passiert mit dem Terminierungszeichen? Ich vermute die müssen wir aus der Verschlüsselung herausnehmen oder?

Welche Softwaremodule benötigen wir. Wie sehen die Querverbindungen aus? Ziel ist ein einfacher Architekturplan der gesamten Software um einen Überblick für alle Projektbeteiligten zu gewährleisten.

Ziel ist ein Softwarearchitekturdokument das für alle Projektbeteiligten zum Überblick dient und die Zusammenhänge auf einen Blick visualisiert. Das Softwarearchitekturdokument ist die Basis für alle SW-Planungsdokumente. Eine verbindung zu anderen SW-Planungs Dokumente wäre sehr sinnvoll.

• Code bereinigen
• Bugfixes
• Plausibilitätscheck ob Buffergrößen ausreichen

Issue um den Meilenstein in unserer Planung sichtbarer zu machen.
Wir können das Issue schließen sobald wir den Meilenstein erreicht haben.

Also Loopbackkommunikation mit der Testapp die uns vom anderen Team zu Verfügung gestellt wurde.

In den Modes der Klasse "String Complete" und "Prepare for next String" werden keine Zeichen eingelesen. D. h. wenn zwei String kurz hinter einander gesendet werden (innerhalb ~1s), wird u. U. nur der erste
String erkannt.

Klärung ob das okay ist, oder ein Problem für die Anwendung darstellt

• Schnittstelle mit Team App

Implementierung eines Moduls oder einer Klasse die sich um den empfangenen String kümmert, der von der WiFiService Klasse zu Verfügung gestellt wird.

Dieses Modul trifft die entscheidung welche Systemreaktion auf eine empfange Nachricht folgt. Sie steuert quasi unsere Statemachine.
Die Hauptaufgabe des Moduls ist das Stringparsing des empfangenen UART-Strings. Sie entfernt ggf. nicht erwünschte Zeichen aus dem empfangen String (OPEN, CLOS...) und initiiert mit einem geeigneten Returnvalue die Systemreaktion.

Beispielsweise musss nach einer Order der Orderstring an die Auftragsverwaltung weitergeleitet werden und die definierte Ackknowlegemeldung an das App verschickt werden.

Beispiel:

.
.

rxString = WiFiGetString();
retVal = Stingverarbeitung(rxString);

switch(retVal)
{
	case APP_LOGIN:
		doStuff1();
	break;
	case APP_ORDER:
		doStuff2();
	break;
	default:
		Error();
	break
}

.
.

Die UART Schnittstelle ist für die Kommunikation zum WLAN Modul verantwortlich.

Der Modulaufbau soll in diesem Arbeitspaket geklärt werden.

• Wie Funktioniert die Schnittstelle?
• Was muss beachtet werden?
• Wie arbeitet das Modul ? (z.B. Interrupt oder polling)
• Wie könnte die Schnittstelle (API) zu diesem Modul aussehen?

Derzeit gehe ich davon aus, dass wir die WLAN empfangenen Strings 1 zu 1 vom WLAN Modul über die UART Schnittstelle weiterleiten. Können wir diesen Ansatz verfolgen oder gibt es noch spezielle Dinge die wir in diesem Zusammenhang bedenken müssen? (String Terminierung oder z.B. spezielle Steuerbefehle die für das WLAN Modul notwendig sind?

• Modulplanungsdokument
• PIKESOLUTION: UART Kommunikation mit beliebigen Empfänger ind GIT einchecken.

• Je nach entscheidung von Branch Pullrequest #86 Char oder String einbeauen.
• Code aufräumen
• Speicheroptimierung
• Bugfix
• Tests

@Einigt euch im Team darauf, dass ihr in einer einheitlichen Codesprache arbeitet. Ich denke es wird auf C hinauslaufen. Stellt Codierungsrichtlinien auf die für das Team verbindlich sind. Einrückung, Tabs, Dokumentationsstyle und weitere Dinge die Ihr als Team wichtig findet.

Verbindliches Dokument das vom Team akzeptiert ist und die Codierungsspielregeln festhält.

WLAN muss durch die PO's definiert werden. Das Protokoll wird dann durch das Team umgesetzt.

Protokollschaubild bzw. Definition muss durch die PO's zur Verfügung gestellt werden.

Der Integrationsbranch soll auf dem Arduinosystem lauffähig sein und stabil funktionieren.

Hola! @ElBartscho has created a ZenHub account for the AlexanderNahr organization. ZenHub is the only project management tool integrated natively in GitHub – created specifically for fast-moving, software-driven teams.

How do I use ZenHub?

To get set up with ZenHub, all you have to do is download the browser extension and log in with your GitHub account. Once you do, you’ll get access to ZenHub’s complete feature-set immediately.

What can ZenHub do?

ZenHub adds a series of enhancements directly inside the GitHub UI:

• Real-time, customizable task boards for GitHub issues;
• Multi-Repository burndown charts, estimates, and velocity tracking based on GitHub Milestones;
• Personal to-do lists and task prioritization;
• Time-saving shortcuts – like a quick repo switcher, a “Move issue” button, and much more.

Add ZenHub to GitHub

Still curious? See more ZenHub features or read user reviews. This issue was written by your friendly ZenHub bot, posted by request from @ElBartscho.

Das Protokoll soll mit diesem Meilenstein Funktionieren.

Unsere Applikation soll auf alle Schnittstellenbefehle des APP antworten und eine stabile Kommunikations gewährleisten.
Die Funktionalitäten im Hintergrund der Arduinoapplikation müssen zum erreichen des Meilensteins noch nicht fertig sein. Es geht um die reine Kommunikation zwischen APP und Arduino

Das Handling der WLAN Schnittstelle soll in diesem Arbeitspaket geplant werden.

• Wie genau Funktioniert die Kommunikation des µCs mit dem WLAN Modul?
• Was muss softwareseitig bereitgestellt werden um das WLAN Modul korrekt zu initialisieren?
• Wie loggt sich ein externes Gerät in das Gerät ein?
• Können wir ein eingeloggtes Gerät eindeutig identifizieren?
  Wenn nein, was brauchen wir um sicherzustellen, das nur ein und das selbe Gerät zugriff auf das System hat?

Abnahmekriterien:
Implementiert ein Prototyp bzw. eine "Pikesolution" für das WLAN Modul mit der ihr nachweiset, das eine Kommunikation mit einem externen Gerät funktioniert.
Ferner wird ein Modulplanungsdokument für die Abnahme benötigt.

• Modularchitekturdokument
• Funktionsbeschreibung (Was/Wann/Warum tun)
• PIKESOULUTION: Loopbackmodus für ein beliebiges Gerät im WLAN impelentieren.

Mit dem anderen Team ist vereinbart, das wir einen Loopbackmodus implementieren der empfangene Strings an den Sender zurück schickt.

Die Aufgabe ist es eine erste Basis der Zielapplikation aufzubauen.
Hier verschmelzen alle Erkenntnisse und dieses *.ino File soll wachsen bis schließlich die
Zielapplikation am Ende des Projekts vollständig ist.

Ich habe das Gefühl das jeder für sich zwar seine Aufgaben abarbeitet, aber das ganze nicht richtig zusammenwächst. Wir haben jetzt schon mehrere *.ino-Files die immer eine bestimmte Aufgabe erledigen.

Wir müssen darauf hinarbeiten, dass wir die Aufgaben miteinander verschmelzen.
Das Ziel ist, Module mit fertigen (oder fast fertigen und lauffähigen) Einzelfunktionalitäten in diese Applikation einzubinden.

Die Problematik hat bereits Herr Hanser Angesprochen. Es geht quasi um die Rolle des Integrationsingenieurs der alle Erkenntnisse miteinander verheiratet.

Mir ist die Aufgabe sehr wichtig um bereits im Vorfeld Integrationsprobleme oder Fehler durch unbeabsichtigte Quereinflüsse zu vermeiden. Ich glaube es besteht die Gefahr das wir uns sonst verzetteln.

Ein einfaches blanko Projekt wird mir nicht reichen. Ihr habt euch mit der Architekturplanung ja bereits mit dem Programmaufbau auseinandergesetzt. Genau das soll hier Stück für Stück wiedergespiegelt werden. Module die bereits fertig(oder fast z.B. WiFi) sind, sollen eingebunden werden.

Jedem Teammitglied sollte klar sein, dass alle anderen auf dieses *.ino-File angewiesen sind wenn finale Tests zu einer Funktionalität gemacht werden. D.H. nur luaffähigen und compilierbarer Code committen.

Außerdem möchte Team App von uns einen funktionierenden Code mit dem Sie auch etwas herumspielen können. Das macht dann richtig Sinn, wenn WiFi zuverlässig funktioniert.

• Code aufräumen
• Bugfix
• Tests

Wir benötigen ein flexibles Timermodul auf das während unterschiedlichen Aufgaben zurückgegriffen werden muss und den Programmfluss entscheidend beeinflust.

Zu den Aufgaben gehören u.A.

• Zeitlich gesteuerte Abarbeitung von gestapelten Bestellungen
• Anmeldeverzögerung im Angriffsfall
• Timeoutüberwachung WLAN Kommunikation

Im Raum steht ein Timermodul dafür vorzusehen mit dem quasi ein kleiner "minischeduler" gebaut wird der das Timing der Gesamtapplikation regelt.

Bei Besseren Ideen können wir gerne in die Disskusion gehen aber ich denke es ist kalr das wir eine Lösung für die oben genannten Aufgaben benötigen.

Abnahmeartefakt ist ein Konzept, oder ein Planungsdokument (z.B. Modulskizze oder Schaubild) aus dem klar hervorgeht wie die der zeitliche Ablauf der Applikation geregelt wird und mit welchen Schnittstellen es arbeitet.

Wir sollten irgendwie Tracen können mit welche Version der Firmware wir gerade arbeiten nach dem Sie kompiliert wurde.
Es wäre schön wenn wir unsere Tests darauf referenzieren könnten

Kommunikation mit externen Geräten ist grundsätzlich möglich. Es besteht die Möglichkeit einen Empfangenen String wieder zurück an den Sender

Das WLAN-Protokoll definiert das Systemverhalten bei eintreffenden Nachrichten. Plant die Protokollimplementierung so, dass es möglichst leicht ist, eine neue Protokollnachricht aufzunehmen. Beispielsweise durch einen switch(msg)-Block der leicht erweitert werden kann.

Protokolldokument

• Protokollumsetzung
• Tests für alle eingehenden Nachrichten. Es ist nicht unbedingt Testcode die Tests und deren Ergebnisse müssen Dokumentiert werden.
• Dokumentation der wichtigen Schnittstellenfunktionen des Moduls

Werft als Team ein Auge auf das Protokoll. Bitte erledigt das bis spätestens Freitag 16.12.2016 Ich muss das mit dem anderen PO noch komplett durchsprechen!

Hola! @AlexanderNahr has created a ZenHub account for the AlexanderNahr organization. ZenHub is the only project management tool integrated natively in GitHub – created specifically for fast-moving, software-driven teams.

How do I use ZenHub?

To get set up with ZenHub, all you have to do is download the browser extension and log in with your GitHub account. Once you do, you’ll get access to ZenHub’s complete feature-set immediately.

What can ZenHub do?

ZenHub adds a series of enhancements directly inside the GitHub UI:

• Real-time, customizable task boards for GitHub issues;
• Multi-Repository burndown charts, estimates, and velocity tracking based on GitHub Milestones;
• Personal to-do lists and task prioritization;
• Time-saving shortcuts – like a quick repo switcher, a “Move issue” button, and much more.

Add ZenHub to GitHub

Still curious? See more ZenHub features or read user reviews. This issue was written by your friendly ZenHub bot, posted by request from @AlexanderNahr.

Welche Hardwaremodule werden wir benötigen. Wie interagieren diese miteinander.

Ziel ist ein Hardwarearchitekturdokument, dass für alle Projektbeteiligten zum Überblick dient und die Zusammenhänge auf einen Blick visualisiert. Dieses Dokument ist die Basis für die Hardwareplanung und quasi die Wurzel für alle anderen Dokumente. Es wäre schön wenn wir alle Hardwaredokumente hier zusammenführen könnten.

µC Inbetriebnahme und Einarbeitung in das System. Das Ziel ist das Teammitglied an das System heranzuführen. Eine kleine Applikation sollte frei durch den Entwickler lauffähig sein.

Abnahme:
Programm mit blinkender LED würde mir an dieser Stelle schon reichen.

Ausbau der WiFi-Klasse

Die reine BEschränkung auf definierte Strings muss aufgehoben werden. Die Klasse soll so ausgebaut werden, dass Sie in der Lage ist, alle möglichen Strings von der UART Schnittstelle empfange und auch zu versenden.

Die Klasse ist vollkommen gekapselt stellt Interfacefunktionen Bereit, die das Empfangen und Senden von Strings auf einfache Art und Weise ermöglichen.

Wichtige Schnittstellenbefehle sind im Wiki zu dokumentieren.

GIT/SVN einrichten und Templateprojekt als Grundlage für alle Projektmitglieder bereitstellen.

Der PO muss in der lage sein das Projekt auschecken und das Template auf den Arduino zu flashen. (z.B. LED Blinkt) Achtet darauf das das Archiv frei von lokalen Abhängigkeiten ist. (Includepfade …) Es Funktioniert dann bei euch, aber bei anderen Teammitglieder nicht. :-(

Epic... Was macht man damit genau

Eine Session dient der Verwaltung eines angemeldeten externen Gerätes. Mit jeder erfolgreichen Anmeldung im System (über Smartphone-App) , wird eine neue Session erzeugt.
Vielleicht schafft man dafür eine Struktur und packt alle relevanten Daten hinein.
Eine Session ist immer nur für ein Gerät und genau einmal gültig. Die Session ist nur für eine einzige IP gültig. Geräte mit anderen IPs können keine Befehle absetzen.

Es ist maximal eine einzige Session aktiv. Sobald das externe Gerät die Verbindung verliert oder sich abmeldet, wird die Session geschlossen. Eine neue Anmeldung erstellt eine neue Session. Während einer Session, kann das extern verbundene Gerät maximal 20 Aufträge abschicken. Danach gehen wir davon aus, dass das Lager leer ist und schicken einen Fehler an das externe Gerät.
Während einer offenen Session, wird die Verbindung zum System durch das APP zyklisch abgefragt.
Das Arduinosystems prüft ebenfalls mit einem Timeout, ob das APP noch eingelegt ist. Nach dem der Timeout abgelaufen ist, wird die Session geschlossen.
Während eine Session geöffnet ist, ist eine Anmeldung durch ein weiteres Gerät nicht möglich. Dennoch antwortet das Gerät mit einem dafür vorgesehenen Schnittstellenbefehl.

Ist ein neues Gerät eingeloggt, wird immer davon ausgegangen, das die Lager der Smart Factory wieder voll gefüllt sind. Eventuell ist es einem neu eingeloggten Gerät nicht unmittelbar möglich eine Bestellung abzuschicken, weil noch Restaufträge im System sind die abgearbeitet werden müssen.

Wie können wir sicherstellen, dass wir nur ein Smartphone mit der Smart Factory verbinden bzw. Ordern lassen). Es darf kein anderer Teilnehmer dazwischenfunken.

-> z.B. MAC-Adresse des Teilnehmers abfragen und für die Session speichern?

Das WLAN Modul kann nach jedem empfangen Befehl mit show z überprüfen, welche IP das Paket gesentet hat!

Mögliche Abnahmekritereien:

• Sinnvolle Datenstruktur für Session definieren
• Session initialisieren/erstellen
• Mehrfachanmeldung blockieren
• Timeoutfunktionalität für Verbindungsabbruch
• 20 Aufträge pro Session.
• Bestellungen blockieren wenn noch Restaufträge im System sind

Im Protokolldokument ist bereits eine Braodcast funktion hinterlegt.
Es geht darum, dass die APP Factories im Umkreis suchen kann und anschließend alle freien Factories in einem Dropdownmenü oder ähnlichem darstellen kann.

Das APP-Team stellt sich das so vor, dass sie einen IP bereich oder ein Subnetz Systematisch nach Accesspoints absuchen und die bereits definierte BROADCAST MESSAGE an den Accesspoint schicken.

Im Grunde müssen wir nur auf die eingehende Nachricht reagieren und entsprechend antworten.
Durch eine Erweiterung des Parsers sollte das relativ schnell implementiert werden können.

Als Problem auf der Seite des Apps sehe ich die evtl. viel zu lange Verbindungszeit die sich natürlich aufsummiert wenn man durch die Teilnehmer iteriert.

Hardwaremäßige Inbetriebnahme des WLAN Moduls. Dokumentation der Verdrahtung.
Wie Funktioniert das Modul auf was ist zu achten.

Dokumentation der gesammelten Erkentnisse

Implementierung des globalen Timingkonzeptes der Applikation.

Timerablauf vorführen. Beispielsweise anhand von irgendwelchen Aktoren, direkt in Verbindung der Anmeldung oder der Abarbeitung von Aufträgen. Gerne auch auf eine andere Art und Weise.

• Code aufräumen
• Bugfixes