Der herstellerübergreifende OpenSource IoT Anbieter mit Security DevOps Kompetenz
- Herstellerübergreifend
- Skalierbar
- Interoperabel
- Sicher
- OpenSource
Produktevolution
2006: kleinster Computer der Welt
2010: 5e Software Factory Security DevOps
2011: Mitentwicklung Tizen für Linux Foundation und GENIVI Alliance
2015: 5e Cloud Management Plattform
2018: IoT & Industry 4.0 OpenSource Plattform
Unser Team entwickelte 2006 den kleinsten Computer der Welt. Durch eine einfache Steckfunktion zu einem gewöhnlichen Fernsehbildschirm, wird dieser selber zu einem Computer mit Triple Play Funktionalität. Darüber hinaus unterstützte der Nabjac interaktives Fernsehen (HDTV) und multilinguale Spracheingabe und Telefondienste (VoIP).
2010 entwickelte die 5e die plattformübergreifende, automatisierte Software Factory für Software Lifecycle Management. Dieser Cycle unterstützt die Integration, Herstellung und das Testen von Software mit Sicherheitskomponente. Das System bietet eine Erweiterung für License Scans von FOSS-basiertem Source- und Binarycode. Die Software Factory basiert unter anderem auf dem von uns mitentwickelten OpenSource Projekt Open Build Service (OBS).
2011 entwickelten wir das Linux-basierte Tizen Betriebssystem für TV, Mobilgeräte und Automotive mit der Linux Foundation und der GENIVI Alliance. Zurzeit befindet sich die Technik vor allem in Smartwatches, sowie Fernsehern oder Kameras. Tizen und das Tizen DevOps nutzen Teile von 5e und SUSE.
2015 entwickelten wir in Kooperation mit der InContinuum Software den CloudController Platform Builder (CCPB). Diese Cloud Management Plattform dient zur einfachen und herstellerübergreifenden Paketierung, Erstellung und Verteilung von Server Software Plattformen und DevOps Umgebungen.
Seit 2018 unterstützen wir die Industry Fusion durch Systemintegration bei dieser Open Source Vernetzungslösung zwischen Smart Products und Smart Factories. Diese schafft eine interoperable Verknüpfung zwischen Mensch, Maschine und Cloud.
5e Software Factory Secure DevOps
Begonnen hat die Entwicklung der 5e Software Factory mit der initialen Version von 2010. Die Implementierung des DevOps Paradigmas soll den Bruch zwischen Erstellung und Betrieb überwinden. Vor allem wurde dieser Prozess durch die Evolution von Mobilgeräten, die Prozessorentwicklung im ARM Bereich, die Cloudrevolution und die Zunahme der Wichtigkeit von Packages im Embedded Bereich beeinflusst. Auch entscheidend war die massenhafte Ausbreitung von OpenSource im Bereich Automotive, Verbraucher, Cloudsysteme und traditioneller IT.
Die Komplexität von „kleinen“ Anwendungen ist rasant gewachsen. Ein Beispiel hierfür ist TV. Heute können sich komplette Multimedia Stacks in Fernsehern befinden.
Produktzyklen werden kürzer, Stückzahlen im Konsumenten Bereich steigen und die ausgerollte Zahl von Cloudinstallationen gibt den Maßstab für die zu treffenden Qualitätsmaßnahmen und den Automatisierungsgrad vor. Gleichzeitig steigen die Anforderungen an Sicherheit und die Notwendigkeit in diese zu investieren. Die Ausmaße und Ausbeute von Hacker-Raubzügen werden größer. Dadurch entsteht eine Rüstungsspirale zwischen ausgefeilten Angriffen auf IT Systeme und deren Gegenmaßnahmen.
Diese Entwicklung spiegelt sich in der 5e Software Factory und den zu Grunde liegenden OpenSource Projekten wider.
Die 5e Software Factory ist mehr „evolutionär“ als „revolutionär“ entstanden.
Evolutionär, weil wir alle gängigen und eines bestimmten Qualitätsstandards entsprechenden OpenSource Projekte in die Factory eingepflegt haben, um so lauffähige Versionen von Code zu produzieren. Die Nutzung von vielen Standard Werkzeugen soll die sanfte Migration von Bestandssystemen ermöglichen. Mehrere offizielle Paketbasen von Linuxdistributionen sind verfügbar und Änderungen können automatisch verfolgt werden. Dies befreit den Programmierer davon, sich um die Wartung von Standartpaketen kümmern zu müssen.
Es gibt einen permanenten Druck zu mehr Automatisierung. Automatisierung und Reproduzierbarkeit soll die Fehlerquote verringern und sporadische Fehler, die bei der Behandlung von großen Mengen von Software entstehen, eliminieren. Dies wird dadurch realisiert, dass man sich ein ganzes Netzwerk von Checks, Tests und anderen Qualitätsmanagementmaßnahmen bis hin zur Abbildung von Entwicklungsprozessen schafft, um so das Niveau stückweise zu steigern. Die vollständige Speicherung von Journalen und Änderungen soll den schwierigen Langzeitsupport (> 5 Jahre) mancher Softwareprodukte ermöglichen.
Man sollte nicht immer die gleichen Fehler machen, die Auswahl ist doch groß genug.
– Robert Lembke –Â