Kontinuierliche Automatisierung

Automatisiertes Flashen

Gliederung

  1. Einleitung
  2. Manuelles Aufspielen
  3. Automatisierung der Flash-Software
  4. Automatisierung der Hardware-Schaltvorgänge
  5. Fazit

Einleitung

In dem Artikel Automatisiertes VoiceCallBackend habe ich beschrieben, wie wir Tests für den eCall automatisiert haben. In diesem Artikel beschreibe ich nun, wie wir das Aufspielen einer neuen Softwareversion auf das eCall-Steuergerät automatisiert haben.

Dazu werde ich zuerst den manuellen Prozess, wie die Software auf das Steuergerät aufgespielt wird, beschreiben. Dieser Vorgang wird auch programmieren oder flashen genannt. Anschließend erläutere ich, wie das eigentliche Aufspielen automatisiert wurde und zuletzt erkläre ich, wie wir die händischen Schaltvorgänge durch softwaregesteuerte ersetzt haben.

Manuelles Aufspielen

Bevor ich erkläre, wie die Software auf das Steuergerät aufgespielt wird, werde ich grob den Aufbau skizzieren, der dafür notwendig ist.

Das Steuergerät ist über ein sogenanntes Debug-Board mit einem PC verbunden. Dieses Debug-Board hat mehrere Schalter, über die das Steuergerät in bestimmte Modi versetzt werden kann, die zum Aufspielen der Software erforderlich sind.

Kontinuierliche Automatisierung_1

Das Steuergerät hat zwei Prozessoren, für welche die Software mit unterschiedlichen Programmen aufgespielt werden kann.
Der allgemeine Ablauf ist folgender:

  1. Starte Programm zum Flashen des entsprechenden Prozessors
  2. Lege den Schalter auf dem Debug-Board für den Prozessor um
  3. Starte das Steuergerät neu (Reset-Schalter auf Debug-Board oder Strom aus->an)
  4. Starte Flash-Vorgang im Programm
  5. Warte bis Flash-Vorgang abgeschlossen ist
  6. Stelle Schalter auf Debug-Board zurück in Ausgangsposition
  7. Starte das Steuergerät neu

Automatisierung der Flash-Software

Die Programme zum Flashen der Software erfüllen eine wichtige Voraussetzung für die Automatisierung: Sie lassen sich von einer Kommandozeile aus starten und führen dann automatisch den Flashvorgang aus. Auf diese Weise kann der Flashvorgang über Systemaufrufe in eine Testautomatisierungssoftware eingebunden werden. Dabei ist ebenfalls wichtig, dass die zu flashenden Binärdateien entweder über eine Konfigurationsdatei oder direkt als Parameter mit angegeben werden können, so dass dies leicht geändert werden kann, sollte sich an dem Flashvorgang etwas ändern oder es notwendig sein, dass mehrere Binärdateien nacheinander geflasht werden müssen.

Automatisierung der Hardware-Schaltvorgänge

Als nächstes gilt es, die manuellen Schaltvorgänge am Debug-Board zu automatisieren. Dazu wurden die Schalter durch eine vom PC steuerbare Relaiskarte ersetzt. Zusätzlich wurde die Stromversorgung mit der Relaiskarte verbunden, sodass auch das Ein- und Ausschalten des Steuergerätes durch Software automatisiert werden kann. Auf diese Weise können wir nun gezielt softwaregesteuert das Steuergerät ein- und ausschalten und mit der entsprechenden Softwareversion flashen.

Kontinuierliche Automatisierung_2

Zu guter Letzt haben wir ein Programm geschrieben, das diese Steuerung übernimmt und zusätzlich die neueste Version der Softwaretests aus dem Source-Code-Management-Tool auscheckt und kompiliert, sodass die Softwaretests automatisiert gestartet werden können. Ein in das Steuerprogramm integrierter Log-Nachrichten-Parser hat die einzelnen Testergebnisse aus dem Log-Nachrichten-Strom des Steuergerätes ausgelesen und automatisch einen Report in das verwendete Test-Management-Tool durchgeführt.

Fazit

Durch diese letzte Automatisierung konnten wir alle automatisierbaren Softwaretests auf einem extra PC laufen lassen, der von uns angestoßen, die Tests durchgeführt hat. Gegen Ende dauerte das Ausführen aller automatisierten Tests etwa zwei Tage, was durch das Hinzuziehen eines zweiten PCs wieder auf einen Tag reduziert werden konnte. Wenn diese Tests von einer einzelnen Person hätten durchgeführt werden müssen, wäre diese etwa 6 Arbeitstage nur mit der Ausführung beschäftigt gewesen, dabei sind noch nicht die zusätzlichen Zeiten für die manuellen Schritte berücksichtigt worden.

Story Mapping

User Story Mapping als kollaborative Visualisierungstechnik

Klassisches Team-Building

Jeder von uns hatte bestimmt schon das Glück an einem Team-Building-Event teilnehmen zu dürfen.
Jede dieser Veranstaltungen fand in aller Regel außerhalb der Firma statt und sollte bewusst Abstand zum beruflichen Alltag schaffen – an sich eine gute Idee!
User Story Mapping als kollaborative Visualisierungstechnik weiterlesen

Magic_1_Vorschau

Magic Estimation oder wie wir schnell viele User Stories geschätzt und einen Live-Termin prognostiziert haben.

In einem aktuellen Software-Entwicklungsprojekt setzen wir seit dem dritten Sprint Planning Poker ein, um die Größe von User Stories gemeinsam im Team zu bestimmen. Wir befinden uns nun im Sprint 8 und haben mittlerweile ein gutes Gefühl für unsere Velocity (Durchschnittliche Menge an Arbeit, welche vom Team in einem Sprint erledigt werden kann) bekommen.
Magic Estimation oder wie wir schnell viele User Stories geschätzt und einen Live-Termin prognostiziert haben. weiterlesen

Vorschau_eCall

Hohe Softwarequalität durch mocking und massive Automatisierung

Einleitung

Wir haben für einen Kunden den Softwaretest für ein eCall Steuergerät durchgeführt. Der eCall (Emergency Call) soll im Falle eines Unfalls einen Notruf auslösen, damit den Betroffenen schnell und zielgerichtet geholfen werden kann und die Hilfe gerade in entlegenen Gebieten schneller eintreffen kann. (Mehr dazu in der Wikipedia: https://de.wikipedia.org/wiki/ECall)

Da beim Notruf der Anruf zuverlässig funktionieren muss, sind möglichst viele verschiedene Szenarien durchzuspielen, um sicherzustellen, dass die Implementierung der eCall Softwaremodule diese auch erfüllt.
Hohe Softwarequalität durch mocking und massive Automatisierung weiterlesen

Doktorhut_lang

Während des Trainings übergangslos in die Beratung

Kürzlich habe ich für einen Kunden eine zweitägige Inhouse Scrum-Schulung durchgeführt. Der Kunde hatte vor kurzem mit der Implementierung von agiler Entwicklung auf der Basis von Scrum begonnen. Das Ziel war lediglich, die neuen Mitarbeiter, die später dazu gestoßen sind, in die Thematik einzuführen.

Während des Trainings übergangslos in die Beratung weiterlesen

Docker und Google Compute Engine

Die 10-Minuten-Systemumgebung

Wie die Erfahrung zeigt, ist das Aufsetzen von Systemumgebungen in Projekten häufig ein enorm zeitintensives Unterfangen. Es führt nicht selten zu langwierigen Projektvorlaufzeiten und bremst die sonst so agilen Projekten aus. Aber auch im späteren Projektverlauf kann es zum Hindernis werden, wenn beispielsweise kurzfristig eine Umgebung für die Abnahme eines neuen Features beim Fachbereich benötigt wird. Hier kann das Virtualisierungswerkzeug Docker in Verbindung mit Cloud Services Abhilfe schaffen.

Die 10-Minuten-Systemumgebung weiterlesen

Unsere Colenet Coins

Merit Money – Ein neuartiges Bonussystem für unsere Mitarbeiter.

Akkordlohn, Fixgehalt, leistungs- oder bilanzabhängige Boni: Es gibt viele Möglichkeiten Mitarbeiter und Mitarbeiterinnen finanziell zu entlohnen. Viele, wenn nicht sogar alle bisherigen Bonus-Modelle sind jedoch ungerecht und wenig effektiv. Dies belegen Soziologen theoretisch wie auch praktisch. Interessante und anwendungsnahe Beispiele liefert diesbezüglich vor Allem Dan Pink ́s Vortrag „The Puzzle Of Motivation“.  Merit Money – Ein neuartiges Bonussystem für unsere Mitarbeiter. weiterlesen

Stetige Verbesserung von Arbeitsabläufen durch Kanban – Ein Erfahrungsbericht

In einem aktuellen Kundenprojekt setzt Colenet seit 6 Wochen Kanban ein, um Daten und Fakten über den aktuell verwendeten Entwicklungsprozess zu gewinnen.

Ziel ist hierbei die kontinuierliche Verbesserung und Optimierung des eigenen Vorgehens. Bei diesem Kundenprojekt geht es um die Entwicklung von Software-Integrationstests und um die Testautomatisierung im Bereich Embedded Software Engineering.

Stetige Verbesserung von Arbeitsabläufen durch Kanban – Ein Erfahrungsbericht weiterlesen