Qualitätssicherung von Open Source Software am Beispiel ... · MedConf 2014, München, 14. bis 16.10.2014 Axel Berghoff Open Source Automation Development Lab (OSADL) eG PHYTEC Messtechnik

Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-FarmMedConf 2014, München, 14. bis 16.10.2014

Axel BerghoffOpen Source Automation Development Lab (OSADL) eG

PHYTEC Messtechnik GmbH

Qualitätssicherung von Open Source Software am Beispiel der OSADL QA-Farm


Was ist Open Source-Software? (1)

Software wird „Open Source-Software“ genannt, wenn diese von den Rechteinhabern unter eine Lizenz gestellt wurde, die in allen relevanten Eigenschaften die Bedingungen der Open Source Initiative (OSI) für den Lizenztyp “Open Source” erfüllt. Diese Bedingungen heißen Open Source Definition (OSD) und sind online verfügbar (http://opensource.org/osd).


Was ist Open Source-Software? (2)

Wesentliche Kriterien der OSD für „Open Source“ sind:● Uneingeschränktes Recht zur Weitergabe der Software an

jedermann.● Weitergabe in Form von Objektcode muss erlaubt sein. In diesem Fall

muss der Quellcode entweder zusammen mit der Auslieferung oder später auf Anfrage verfügbar gemacht werden.

● Uneingeschränktes Recht, die Software zu verändern.● Uneingeschränktes Recht, veränderte Software an jedermann

weiterzugeben.


Warum ist das Open Source-Betriebssystem Linux so attraktiv für Embeded-Systeme?

● ... weil die Lizenzbedingungen gut geeignet sind. ● ... weil Linux kostenlos ist.● ... weil Linux so wenige Fehler aufweist.● ... weil Linux so weitgehend skaliert. ● ... weil Linux so viele Architekturen unterstützt. ● ... weil Linux bei Studienabgängern so gut bekannt ist.● ... weil Linux nicht abgekündigt werden kann.


Wesentliche Unterschiede zwischen Nicht-Open Source- und Open Source-Software

Nicht Open Source Open Source

Wer garantiert Fehlerbehebung?

Entwickelndes Unternehmen bzw. Vertriebspartner

Nicht der Entwickler, evtl. Vertriebsunternehmen

Wer garantiert Performance?



Wer garantiert Anpassung?




Vertriebsunternehmen fürOpen Source-Software?

Kommerzieller Vertrieb für eine Open Source-Software lohnt sich immer nur dann, wenn eine bestimmte Softwareversion unverändert von einer großen Anzahl an Kunden verwendet wird. Da dies für Embedded-Systeme in der Regel nicht zutrifft, gibt es keine einheitlich vertriebene Standard-Linux-Distribution für alle Embedded-Systeme wie es z.B. für Server der Fall ist:


Qualitätssicherung des Linuxkernels für Embedded-Systeme in der Medizintechnik

Da es keinen allgemein verwendbaren und als Produkt vertriebenen Linuxkernel für Embedded-Systeme in der Medizintechnik gibt, muss jeder Anwender selbst für die erforderliche Qualitätssicherung sorgen – oder sich einer geeigneten Organisation anschließen.


Was ist OSADL?

Das Open Source Automation Development Lab (OSADL) ist eine Interessengemeinschaft für industrielle Anwender von „Open Source“-Software:

OSADL entwickelt, beauftragt, koordiniert, kontrolliert und zertifiziert die Entwicklung von „Open Source“-Software im Auftrag seiner Mitglieder. Dazu gehört in besonderem Maße die Qualitätssicherung des Linuxkernels, wofür die sogenannte “OSADL QA-Farm” betrieben wird.


OSADL-Mitgliederentwicklung

12/2005 12/2007 12/2009 12/2011 12/2013 12/20150

5

10

15

20

25

30

35

40

45

50

Num

ber o

f mem

bers


Branchen der OSADL-Mitglieder

(Maschinen- undAnlagenbauer)

Halbleiter-Hersteller

Hardware-Hersteller

Software-Hersteller

FOSS/Linux-Dienstleister

Industrielle Anwender

Nutzervereinigungen


Die OSADL QA-Farm (1)

OSADL Test-Racks für zur Zeit über hundertindividuelle Systeme

● 8 auswechselbare Tabletts ● Jeweils 220 V Stromversorgung, Ethernet, RS232● 10/100/1000 Mb/s Switch mit Port-Mirroring● 8-fach Fernsteuerung der Stromversorgung● 8-fach Seriell-zu-Netzwerk-Adapter● 8-fach fernsteuerbarer KVM-Switch (optional)● Kontroll-Server für Überwachung und als Lastgenerator

Pro Rack:



Montage der individuellen Systeme auf speziellen Lochraster-Tabletts



Kommunikation zwischen Testsystemen, Datenerfassung und Bedienpersonal

OSADL-Cloud

Testzentrum 1 Testzentrum 2

Datenerfassung

Auswertung,Bedienung


Die OSADL QA-Farm (4)ARMBroadcom● BCM2708 @700 MHz, 32 bit

Freescale● i.MX27 @400 MHz, 32 bit● i.MX35 @532 MHz, 32 bit● i.MX6 @996 MHz, 32 bit

Marvell● SheevaPlug @1200 MHz, 32 bit

Texas Instruments● AM3517 @600 MHz, 32 bit● AM3359 @800 MHz, 32 bit● OMAP3525 @720 MHz, 32 bit● OMAP4430 @600 MHz, 32 bit

Xilinx● Zynq @666 MHz, 32 bit

MIPSICT● Loongson 2F @800 MHz, 64 bit

PowerPCFreescale● MPC 5200 @396 MHz, 32 bit● MPC 8349 @533 MHz, 32 bit● QorIQ 2020 @1200 MHz, 64 bit

x86/x86_64AMD● K6 3D, @333 MHz, 32 bit● LX-800 @500 MHz, 32 bit● Athlon XP 2000+, 32 bit● Athlon 64 2800+, 64 bit● G-Series T56N @1400 MHz, 64 bit● Phenom II X6 @3200 MHz, 64 bit● Opteron X32 @2100 MHz, 64 bit● Kaveri A10-7850K X4 @3700 MHz, 64 bit● Embedded Kaveri X4 @2700 MHz, 64 bit

Intel● Pentium @133 MHz, 32 bit ● Pentium II Klamath @233 MHz, 32 bit● Celeron (Coppermine) @800 MHz, 32 bit

Intel (Forts.)● Atom D510 @1667 MHz, 64 bit● Atom N270 @1600 MHz, 32 bit● Atom Z530 @1600 MHz, 32 bit● Celeron M @1500 MHz, 32 bit● Pentium M @2300 MHz, 32 bit● Xeon (single socket) @2000 MHz, 32 bit ● Xeon (dual socket) @2800 MHz, 32 bit ● Core 2 Duo @2400 MHz, 64 bit● Core 2 Quad @2400 MHz, 32 bit● Nehalem 975 @3333 MHz, 32 bit● Gulftown X980 @3333 MHz, 64 bit● Core i7-2600K @3400 MHz, 64 bit● Core i7-4960X @3600 MHz, 64 bit● Atom E3825 @1333 MHz, 64 bit

VIA● C3 Samuel 2 @533, 32 bit● C3 Nehemiah @533 MHz, 32 bit● C7 @1000 MHz, 32 bit● Nano X2 L4050 @1400 MHz, 64 bit● QuadCore L4700 @1200 MHz, 64 bit


Wer nutzt die Farm wie?

● OSADL-Mitglieder können die Farm je nach Mitgliedslevel ohne Zusatzkosten nutzen.

● Nicht-Mitglieder können die Farm gegen Miete ebenfalls nutzen.● Zwei verschiedene Update-Kategorien

– „Monitoring“ (keinerlei Update)– „Kernel-Development“ (kontinuierliches Update auf aktuelle

Kernelversionen)

● Drei verschiedene Kategorien der Datenveröffentlichung– „Hidden“ (nur der Kunde hat Zugriff)– „Undisclosed” (öffentlich, aber ohne Namensnennung)– „Public” (öffentlich mit Namensnennung)


Was ist das Ziel der OSADL QA-Farm?

● Erkennung von Fehlern des Linux-Kernels (speziell bei von der Industrie benötigen Komponenten)

● Transparente Auswahlkriterien für den am besten geeigneten Prozessors

● Ermittlung individueller Zuverlässigkeitsdaten● Gewinnung von Langzeitdaten für Zertifizierung, z.B.

Echtzeit● „Einfrieren und trotzdem weiterwachsen”


„Einfrieren und trotzdem weiterwachsen“

Einfrieren für Produktion

Weiterwachsenim Testzentrum

2.6.31.12-rt21

3.0.0-rt1Upgrade-Problem(dokumentiertoder behoben)


Gemessene Variablen (1)Benchmarks● GL benchmark gltestperf● UnixBench (multi-core)● UnixBench (single-core)● UnixBench 2D graphics performance

Disk ● Disk IOs per device● Disk latency per device● Disk throughput per device● Disk usage in percent● Disk utilization per device ● File system mount-scheduled checks● File system time-scheduled checks● Filesystem usage (in bytes)● Inode usage in percent● IO Service time● IOstat● S.M.A.R.T values of every drive

Netzwerk● eth0 errors● eth0 traffic● Firewall Throughput● HTTP loadtime of a page● Netstat NFS● NFS Client ● NFSv4 Client

Prozesse● Fork rate ● Number of threads● Processes● Processes priority ● VMstat

Benchmarks● GL benchmark gltestperf● UnixBench (multi-core)● UnixBench (single-core)● UnixBench 2D graphics performance

Disk ● Disk IOs per device● Disk latency per device● Disk throughput per device● Disk usage in percent● Disk utilization per device ● File system mount-scheduled checks● File system time-scheduled checks● Filesystem usage (in bytes)● Inode usage in percent● IO Service time● IOstat● S.M.A.R.T values of every drive

Benchmarks● GL benchmark gltestperf● UnixBench (multi-core)● UnixBench (single-core)● UnixBench 2D graphics performance

Disk ● Disk IOs per device● Disk latency per device● Disk throughput per device● Disk usage in percent● Disk utilization per device● File system mount-scheduled checks● File system time-scheduled checks● Filesystem usage (in bytes)● Inode usage in percent● IO Service time● IOstat● S.M.A.R.T values of every drive

Real-time system● 5-min max. timer and wakeup latency ● 5-min max. timer offsets● 5-min max. wakeup latency● RT Features

Sendmail● Sendmail email traffic● Sendmail email volumes● Sendmail queued mails

Sensoren● Fans● HDD temperature● Power consumption● Temperatures


Gemessene Variablen (2)System● Available entropy● C states● CPU frequency● CPU usage● File table usage● Individual interrupts● Inode table usage● Interrupts and context switches● Kernel version● Load average● Logged in users● Memory usage● Split memory usage● Application memory usage● Swap in/out● Uptime

Virtuelle Systeme● Virtual domain block device I/O● Virtual domain CPU time● Virtual domain memory usage● Virtual domain network I/O

Zeit-Synchronisation● NTP kernel PLL estimated error (secs)● NTP kernel PLL frequency (ppm + 0)● NTP kernel PLL offset (secs)● NTP states● NTP timing statistics for system peer


Markierung von Warnung und Alarm mit Munin

Rot: Alarm, gelb: Warnung, blau: Messung im Normalbereich

Name des Systems Direkter Link zu den Variablen einer Gruppe


Vier verschiedene zeitliche Auflösungen

Tag Woche

Monat Jahr


Ereignis-Verwaltung mit Nagios


Ereignis-Histogramme mit Nagios

Mit Ereignis-Histogrammen lässt sich leicht feststellen, ob bestimmte Fehler z.B. immer zu bestimmten Uhrzeiten, Wochentagen oder

Monatstagen auftreten.


CPU- und Graphik-Benchmarks

Rot: geringe Performance, gelb: mittlere Performance, grün: hohe Performance


Beispiel: Memory-Leak Diagnostik (1)

Normal (kein Leak)


Beispiel: Memory-Leak Diagnostik (2)

System-Leak Applikations-LeakKeilförmiger Anstieg von Speicherbereichen: Alarm!


Beispiel: Stabilitätsmessung (1)

30 Stunden

1,25Tage

Bei jedem Neustart des Systems beginnt die Zählung der Uptime bei 0.


Beispiel: Stabilitätsmessung (2)

13 Monate

437 Tage

5 Wochen

Etablierter single-core ARM Prozessor,Texas Instruments AM3517 @500 MHz

Neustart im April 2013 für Update

Dual-core ARM processor,Texas Instruments Pandaboard @1000 MHz

Livelock Linux Bug


Beispiel: Stabilitätsmessung (3) und Bugfix

5 Wochen 13 Monate

Bugfix

Nach Analyse des Fehlers in der QA Farm wurde von OSADL ein Bugfix bereitgestellt und eingespielt, danach war das System stabil.


Beispiel: Messung von Leistungsaufnahme und Taktfrequenz der CPU


Beispiel: Messung von Leistungsaufnahme und Schlafstadien der CPU

Durch gezielte Maß-nahmen (Taktfrequenz bzw. Schlafstadien der CPU) basierend auf den Daten der QA-Farm lässt sich möglicherweise Energie in erheblichem Maße einsparen.


Beispiel: Prinzip einer EchtzeitmessungExternes Ereignis,

z.B. von einer LichtschrankeStart der Applikation

Im Userspace

Scheduling,Kontext-Wechsel

Interrupt ServiceRoutine

Gesamt-Latenz oder Präemptions-Latenz

IRQ-Latenz

Gatter-Latenz

CPUIRQ

3 3 9 15

6

30

Wie lange dauert es, bis ein externes Ereignis vom System verarbeitet wird und eine wartende Userspace-Applikation dies erfährt?


Beispiel: Ergebnis einer Echtzeitmessung

Fast 100 Millionen Mal sehr schnell (etwa 10 µs)

Ein einziges Mal 55 µs, dies ist die Latenz des Systems


Beispiel: Ergebnis einer Langzeit-Echtzeitmessung (1)

Konsekutive Latenzplots ingemeinsamer Darstellung


Beispiel: Ergebnis einer Langzeit-Echtzeitmessung (2)

Bereits ein einziger Ausreißer in20 Milliarden Messungen kann erfasst und dargestellt werden.


Zusammenfassung (1)

● Lizenzen von Open Source-Software gewähren in sehr großzügiger Weise Nutzungsrechte.

● Allerdings sind in dieser Lizenz keinerlei Zusagen im Hinblick auf Fehler-behebung, Performance, oder Anpassungsarbeiten enthalten. Hierfür ist jeder Anwender zunächst selbst verantwortlich; die eigentlichen Arbeiten sollten aber – genau wie die Entwicklung von Open Source-Software – in einer Community erfolgen. Unter anderem für diesen Zweck wurde das Open Source Automation Development Lab (OSADL) gegründet.


Zusammenfassung (2)

● Die OSADL-QA-Farm (osadl.org/QA) bietet Referenz-Daten für eine große Anzahl von Prozessor-Architekturen und Konfigurationen. Darüber hinaus können (und müssen) die Daten der Farm genutzt werden, um Fehler an der getesteten Hardware und Software zu beseitigen bzw. deren Performance zu verbessern.

● OSADL ist bereit, die Erfahrungen aus dem nunmehr vierjährigen Betrieb der Farm an interessierte Unternehmen weiterzugeben.

Documents

Qualitätssicherung von Open Source Software am Beispiel ... · MedConf 2014, München, 14. bis 16.10.2014 Axel Berghoff Open Source Automation Development Lab (OSADL) eG PHYTEC Messtechnik