View Excerpts
  View Full Text
InVino1

In Vino Veritas | How to build a Raspberry PI Cluster

If you have to need to build a Cluster – in this case for test runs – it makes sense to find an appropriate boxing. So in a supermarket – hey it is easter – I found a nice box – it looks like one of the first Apple Computers doesn’t it :)

Content:
* a wooden box
* a switch with DDS support
* 3 Raspberry PI Model B
* 4 Raspberry PI Model B+
* 1 Raspberry PI 2 (as Controller of the MultiTouch Device and as VNC Viewer)
* 1 MultiTouch Device
* 1 Keyboard with included TouchPad (just to be sure to have an appropriate way of entering something)
* some cables – well – a lot of cables and power supplies (I removed the cables for photos just to give you an cleaned up Impression :) )

Here we go:
InVino1

InVino2

InVino3

InVino4

Klassendiagramme werden überbewertet

Wenn ich mich manchmal mit Leuten unterhalte und sie nach UML frage, kommt öfter einmal die Antwort, das seien doch die Klassendiagramme. Auch vor allem in älteren Büchern zu dem Thema kann man teilweise den Eindruck gewinnen, die UML-Klassendiagramme wären das allerwichtigste Diagramm der Modellierungssprache.

Nach 15 Jahren Anwendung von modellbasierter Entwicklung kann ich inzwischen sagen, dass UML und auch SysML viel mehr ist als Klassendiagramme – oder Blockdefinitionsdiagramme in SysML. Sie sind zwar wichtig und nützlich für Daten- und Klassenmodellierung, jedoch ist dies nur ein kleiner Teil, wenn es darum geht modellbasiert eine Software oder ein System zu spezifizieren und zu beschreiben. Klassendiagramme sind vom Abstraktionsgrad nah an der Implementierung dran. Für einen Softwareentwickler hat daher das Klassendiagramm auch nur eine untergeordnete Bedeutung, da er meist sowieso täglich in seiner Entwicklungsumgebung seine Klassen vor Augen hat und diese auch gut überblickt.

Viel wichtiger als Klassendiagramme sind eigentlich die Diagramme, die eine größere Struktur eines Softwaresystems aufzeigen und beschreiben. Dazu zählt zum Beispiel das Komponenten-, Kompositionsstruktur- oder Deploymentdiagramm in UML oder das Interne Blockdiagramm in SysML.

Außerdem extrem hilfreich in der Praxis sind die Verhaltensdiagramme, mit denen man das Verhalten von Komponenten oder des Gesamtsystems beschreiben kann. Vielen Anwendern der UML und SysML kaum bewusst, ist dass man die strukturellen und die dynamischen (Verhaltens-)Aspekte in einem Modell wirklich richtig formal koppeln kann. Dies unterstützt die Definition von UML von Hause aus und es wird durch die Modellierungswerkzeuge – zum Beispiel in Sparx Systems Enterprise Architect – auch umgesetzt.

Mann kann also durch geschicktes Kombinieren von strukturellen und Verhaltensdiagrammen eine Software so genau spezifizieren, das ein Codegenerator aus einem solchen Modell komplett ausführbare Software generieren kann.

LieberLieber kann Sie dabei unterstützen modellbasierte Entwicklung schrittweise weiterzuentwickeln, damit Modellsimulation, Codegenerierung und noch vieles mehr möglich wird. Den Klassendiagrammen werden Sie dabei zwar ab und an auch noch begegnen, aber eher am Rande.

sainsmart

Raspberry PI 2 | Not Ready for real-life-embedded Apps (March 2015)

sainsmart

 

Raspberry PI (Raspberry Pi is a trademark of the Raspberry Pi Foundation) is not only used as a learning plattform – it is already used in productive environments, too. So a lot of embedded systems are based on that plattform already. And we also have some data collecting systems based on R-PI.

R-PI is not really real-time, but good enough for a lot of use cases.

So we have some in productive systems and research projects already in use.

Our latest tests showed us, that Model B and B+ are very reliable and stable – but R-Pi 2 Model B is not.

This is our test scenario:

* SainSmart 8-Kanäle RelaisModul Brett 5V Für Arduino PIC AVR MCU DSP Relay Module, Raspberry PI Model B+ (of course with an ULM2803A module in the middle and some cable), Raspian

* SainSmart 8-Kanäle RelaisModul Brett 5V Für Arduino PIC AVR MCU DSP Relay Module, Raspberry PI 2 Model B (of course with an ULM2803A module in the middle and some cable), Raspian

This is the python script we use for our tests (simple: initialize – on – off – cleanup) and runs endless (via bash script) – results:

* PI 1 Model B+: just stopped after 10 days non stop switching relais

* PI 2 Model B: first run: 242 switches – turned off, 5200 switches – turned off, 542 switches – turned off

That means for such applications PI 2 is not recommended by us nowadays – even if it is really amazing hardware – of course we go on working based on PI2 but going productive on PI1-B+ only.

Here our small python test routine:

import RPi.GPIO as gpio
import time
# peter ports = [6,12,13,19,16,26,20,21]

# port list
"""
#     GPIO-6  ==> relay 1
#     GPIO-12 ==> relay 2
#     GPIO-13 ==> relay 3
#     GPIO-19 ==> relay 4
#     GPIO-16 ==> relay 5
#     GPIO-26 ==> relay 6
#     GPIO-20 ==> relay 7
#     GPIO-21 ==> relay 8
"""
ports = [6,12,13,19,16,26,20,21]

#set pins to BCM mode
gpio.setmode(gpio.BCM)

#setup all pins for output
for port in ports:
gpio.setup(port, gpio.OUT)


#set all pins to high (relay close NO, open NC)
print("high")
for port in ports:
gpio.output(port, gpio.HIGH)


time.sleep(0.1)

#set alls pins to low (relay open NO, close NC)
print("low")
for port in ports:
gpio.output(port, gpio.LOW)
# free gpio pins
gpio.cleanup()

 

Axt schärfen!

Eine kleine Metapher: Sagt ein Holzfäller zum anderen: „Sagen Sie mal, warum um alles in der Welt, schärfen Sie nicht mal zuerst ihre Axt, die ist doch ganz stumpf?“ Der Mann gab, ohne auch nur eine Sekunde von seiner Arbeit aufzusehen, zur Antwort: „Sehen Sie denn nicht, was ich hier zu tun habe? Ich muss Bäume fällen. Ich habe jetzt keine Zeit die Axt zu schärfen“.

So ähnlich ist es auch mit der Modellierung und Planung von Software bzw. Software Architektur: Zuerst das Werkzeug herrichten und dann die Bäume fällen.

Dummerweise ist das nicht das einzige Heilmittel: es gibt leider auch Werkzeugfanatiker, die die Axt so lange schärfen – bis kein Beil mehr da ist.

Das richtige Mittelmaß zu finden bzw. das richtige Werkzeug zur richtigen Zeit in der richtigen Schärfe – das ist die eigentliche Herausforderung.

Anforderungsintegration mit ReqIF

Die Datenintegration zwischen mehreren Werkzeugen stellt heute für viele Projekte ein zu lösendes Problem dar. Das Requirements Interchange Format (ReqIF) wurde entwickelt, um Anforderungsdaten zwischen verschiedenen Werkzeugen austauschen zu können.

LieberLieber bietet mit dem LieberLieber Connector ReqIF eine Lösung an, um Anforderungen per ReqIF beispielsweise mit Sparx Systems Enterprise Architect zu integrieren. Dabei erfolgt eine echte Synchronisation, dass heißt, dass bereits bestehende Daten nur aktualisiert werden, anstatt erneut angelegt zu werden. Zudem werden alle Änderungen protokolliert, um eine sogenannte Impact Analyse zu ermöglichen.

Das folgende Demonstrationsvideo zeigt die Funktionsweise der Software:

 

LieberLieber ist darüber hinaus in der Lage Ihnen beliebige Werkzeugintegrationen zu erstellen. Kontaktieren Sie uns gerne – wir lösen auch Ihr Datenintegrationsproblem!

Automatisiertes Variantenmanagement rechnet sich bereits ab wenigen Varianten

Der Einsatz von Featuremodellen und automatischer Variantengenerierung rechnet sich bereits nach wenigen generierten Varianten im Vergleich zu manueller Variantenbildung.

Die folgende Grafik illustriert diesen Zusammenhang. Dies entstammt empirischen Daten eines großen Industriekonzerns, der für seine Produkte Featuremodell-basiertes Variantenmanagement eingeführt hat. Das Featuremodell umfasst dabei über 2000 Features.

VariantManagementEffortCompare

Zu Beginn muss natürlich initialer Aufwand in die Erstellung des Featuremodells und die Vorbereitung der Arbeitsprodukte gesteckt werden, aus denen dann die Varianten erzeugt werden sollen. Danach beginnt die Kosten- und Zeitersparnis durch die automatisierte Variantenbildung. Für weniger komplexe Systeme oder Produkte kann sich die Amortisierung auch noch um einiges weiter nach vorne verlagern.

LieberLieber bietet Variantenmanagement-Lösungen an, um auch Ihr Variantenmanagement zu automatisieren. Kontaktieren Sie uns gerne, wenn Sie Fragen oder Bedarf an einer Demonstration haben: sales(at)lieberlieber.com