Seit gut zwei Jahren ist Hyperstone eine 100-prozentige Tochterfirma von Swissbit. Damit ist das Schweizer Unternehmen in der Lage, komplette sichere Speicherlösungen aus eigener Fertigung für Automotive-Applikationen anzubieten, die Chip-agnostisch sind und neuartige Ansätze ermöglichen. AUTOMOBIL-ELEKTRONIK sprach mit dem Swissbit-CEO und dem Managing Director von Hyperstone darüber, was das für die Automobil-Branche bedeutet und welche Chancen sich so für die Anwender ergeben.
Herr Muschter, wie laufen die Geschäfte?
Silvio Muschter: Wir sind die letzten vier Jahre im Schnitt 25 Prozent pro Jahr gewachsen; es läuft somit sehr gut. 2023 könnte es in der ersten Jahreshälfte ein bisschen schwieriger werden, aber für die zweite Jahreshälfte erwarten wir eine Erholung. Dabei sind wir in vier Märkten aktiv: Industrie, NetCom, IoT und Automotive. Seit etwa acht Jahren sind wir automotive-zertifiziert. Da waren wir in der Vergangenheit stark bei SD-Karten engagiert, so dass wir 20 bis 25 Prozent unseres Umsatzes im Automobilbereich machten, während es jetzt nur noch 10 bis 15 Prozent sind. Jetzt haben wir bei Automotive eine sehr starke Strategie im Bereich e.MMC und NVMe; damit peilen wir an, 2024/2025 wieder ein Viertel unseres Umsatzes zu machen.
Wo liegt der USP von Swissbit?
Silvio Muschter: Unsere klassischen Stärken sind Zuverlässigkeit und Langlebigkeit. Wir bieten unsere Produkte über einen sehr langen Zeitraum hinweg mit stabiler BOM an. Longevity heißt für uns 10 bis 15 Jahre Produktverfügbarkeit. Mit 3D-NAND sind die Innovationszyklen im Flash etwas anspruchsvoller geworden als in der 2D-Welt mit SLC. Wir bieten immer eine aktuelle 3D-Generation auch automotive-tauglich an. Unser Firm- und Hardwarekonzept erlaubt es uns auch, Kunden- oder Use-Case-spezifische Features und Optimierungen flexibel zu integrieren. Darüber hinaus bieten wir eine vollständige vertikale Integration: vom Systemdesign über die Controller-Hardware, die Controller-Firmware bis hin zur Fertigung liegt alles in unserer Hand und in Europa.
Welche Bedeutung hat das Thema Security für Swissbit?
Silvio Muschter: Seit dem Jahr 2014 haben wir das Thema Security systematisch ausgebaut, so dass wir sehr starke Use-Cases in den Bereichen Medical, NetCom und Industrie haben, wo Hardware-Anker im Speicher inzwischen etabliert sind. Swissbit ist da sehr gut aufgestellt und liefert seit Jahren manipulationssichere Datenspeicher im Rahmen der technischen Sicherheitseinrichtung (TSE) für Registrierkassen.
Da gibt es viele verschiedene Möglichkeiten, das auch im Automobil zu verwerten. Man denke nur an das einfache Identity-Management, an automatisierte sichere Online-Updates, an Secure-Boot, Datenverschlüsselung, Manipulationssicherheit etc. Im Prinzip können wir über den Speicher ein typisches TPM oder einen Hardware-Anker ersetzen, der normalerweise noch separat in der Architektur untergebracht werden muss.
Ein gutes Beispiel für die Integration eines sicheren Controllers in den Speicher ist unsere Zusammenarbeit mit Micron bei der Authenta-Technologie, wo wir auch gegenseitig Second-Source sind. Damit lässt sich beispielsweise auch sichere Connectivity ohne SIM-Karte bereitstellen, Stichwort eSIM.
Ausgewählte Swissbit-Produkte sind sowohl gemäß FIPS als auch nach Common Criteria zertifiziert. Da sind wir seit vielen Jahren aktiv im Einsatz. Security hat folglich für uns eine sehr große Bedeutung. Die Security-Thematik hat mittlerweile einen ähnlichen Charakter wie Qualität: So lange es gut läuft, will niemand investieren, aber wenn etwas schiefgeht, dann kommt der große Aufschrei.
Beim Software-definierten Fahrzeug spielen OTA-Updates eine zentrale Rolle. Wie können wir dort die Datensicherheit garantieren?
Silvio Muschter: Grundsätzlich müssen die Software-Architekten im Auto entscheiden, welchen Hardware-Sicherheitsanker sie nutzen. Wir bieten einfach einen Vorteil, zum Beispiel anhand einer e.MMC oder eines NVMe-Speichers, da der jetzt integrierte Hyperstone-Controller die Security-Funktionalität schon mitbringt. So bekommen wir Security by Design, und das bringt einige Vorteile mit sich. Speicher sind ja überall erforderlich – am Edge genauso wie am Zentralcomputer oder am Domänenrechner. Wir bieten hierfür ein einheitliches API über alle Geräte, architekturübergreifende Hardware-Anker. Wir bieten Security in einem einzigen Footprint, ohne dass noch zusätzlich ein TPM erforderlich ist, direkt im Speicher.
Falls es mal nötig sein sollte, könnte man sogar ein Hardware-Update durchführen, wenn das einmal zur Diskussion stehen sollte. Das ist an dieser Stelle in der Industrie durchaus ein Alleinstellungsmerkmal. Und in dieser Kombination mit einer lokalen Supply Chain bietet Swissbit einige Vorteile. So können wir vorkommissionieren, wir können Zertifikate bei uns in der Fertigung hochladen, so dass wir Zero Touch ermöglichen. Gemeinsam mit Partnern unterstützen wir dann auch die Schnittstelle zu der entsprechenden Software im Auto. So können wir Embedded-Security im Controller anbieten – und das alles in einem Gehäuse, so dass ein komplettes Secure Element entsteht, für das wir auch gleich die passende Software anbieten.
Was heißt Lokalisierung hier konkret?
Silvio Muschter: Lokalisierung heißt, an den Fertigungsstandorten auch entsprechende Partner zu haben. Wir haben sowohl den Controller als auch eine vollwertige Halbleiter-Backendfertigung. Wir können ab dem Waferlevel alles im eigenen Hause verarbeiten. Dementsprechend hoch können wir auch integrieren. Zudem machen wir von der Firmware bis zum Testen alles selbst. Unser Backend ist in Berlin, die Security-Experten sitzen in München, die Speichersystem- und Test-Kompetenz in Bronschhofen in der Schweiz, und in Konstanz kümmern wir uns um das ASIC-Design sowie um die Firmware-Entwicklung.
Welche Rolle spielt Hyperstone?
Peter Berns: Hyperstone ist seit Februar 2021 eine 100-prozentige Tochterfirma von Swissbit, das heißt natürlich, dass wir uns bei der Definition der Produkt-Roadmap eng abstimmen und von der jeweiligen Erfahrung und den Synergien profitieren. Darüber hinaus haben wir direkte externe Kunden, für die sich nach dem Zusammenschluss nichts geändert hat. Hyperstone wurde 1990 von Otto Müller gegründet, der damals eine 32-bit-RISC-CPU entwickelt hatte. Anfang dieses Jahrhunderts brachten wir unseren ersten Flash-Memory-Controller auf den Markt, und etwa in 2007/2008 haben wir uns refokussiert Richtung Industrie und Automotive, um die Zuverlässigkeit und Qualität dieser Märkte zu erfüllen.
Unsere Kunden sind zu einem recht großen Teil Firmen, die Module bauen und qualifizieren, um sie dann an Endkunden zu verkaufen. Swissbit war bereits vor der Akquise ein sehr großer Kunde von Hyperstone – seit mittlerweile fast 15 Jahren. Hyperstone beschäftigt sich heute zu 100 Prozent mit Flash-Speichercontrollern. In der Vergangenheit kam dafür die bewährte MCU von Otto Müller zum Einsatz, aber seit dem neusten NVMe-Controller setzen wir auch auf die RISC-V-Architektur.
Wir entwickeln die komplette Firmware hier in Konstanz. Weil wir die gesamte Wertschöpfungskette zu 100 Prozent unter Kontrolle haben, besteht auch kein Risiko, dass irgendwelche Dritte eine Backdoor implementieren. Darin liegt der große Vorteil dieses Zusammenschlusses, denn Swissbit ist damit vollständig vertikal integriert (Silvio Muschter nickt zustimmend).
Noch mal zum Thema Lokalisierung: Wir haben den RTL-Code für die Flash-Controller-ASICs zu 100 Prozent hier in Konstanz entwickelt und unter Kontrolle; das gleiche gilt für die Firmware. Wir haben keine Entwicklungsstandorte außerhalb von Europa. Wenn es um spezifische IP geht, arbeiten wir überwiegend mit europäischen Partnern zusammen, und die nächste Hardware-Generation wollen wir in Dresden bei GlobalFoundries fertigen lassen. Alles, was mit Security zu tun hat – Schlüssel programmieren und mehr – erledigen wir in einem speziell abgeschotteten Bereich unserer Fab in Berlin.
Welche Speicherchips verarbeitet Swissbit in seiner Fertigung?
Silvio Muschter: Wir haben eine wirklich hochmoderne Backend-Fertigung in Berlin inklusive 3D-Packaging, Flip-Chip etc. Derartiges Equipment findet man in Europa nur sehr, sehr selten, weil das Backend über die letzten Jahrzehnte praktisch komplett outgesourct wurde. Wir können über das Package auch gewissen Cyber-Angriffsszenarien auf der Hardwareseite entgegenwirken, was im Rahmen der Security sehr wichtig ist, um Reverse Engineering, Seitenkanal-Angriffe etc. abzuwehren. Je nach Sicherheitslevel ist da sehr viel möglich.
Peter Berns: Wettbewerber im Controller-Bereich designen Controller typischerweise spezifisch für einen bestimmten Flash-Speicher eines einzigen Herstellers. Wir designen die Controller so, dass man flexibel bleibt, denn wir können mit unseren Controllern einen Micron-Flash genauso gut unterstützen wie einen Flash-Speicher aus dem Hause Kioxia, und wir können vor allen Dingen aber auch einen SLC genauso unterstützen wie einen TLC oder demnächst QLC. Damit ändert sich auch bei der Longevity für einen Kunden nicht notwendigerweise immer alles, sondern er kann entscheiden, einen Schritt mitzugehen, um einen billigeren Flash mitzunehmen, aber der Controller bleibt der gleiche. Das Interface zum Hostsystem bleibt identisch.
Silvio Muschter: Mit dem Zusammenschluss haben wir die Arbeiten an einem komplett neuen Firmwarekonzept begonnen, das schnelle Flash-Qualifikation ermöglicht und ein API zur Verfügung stellt, mit dem sich neue Funktionen schnell integrieren lassen, während gleichzeitig die Möglichkeit besteht, von einer auf die nächste Generation zu portieren. Die Firmware unterstützt uns dabei, Produkte in Zukunft schneller in größeren Variationen und optimiert für verschiedene Anwendungen auf den Markt zu bringen. Ende des Jahres soll das alles fertig werden. Die Resonanz auf dem Markt hierauf ist sehr positiv.
Was ist denn aus Ihrer Sicht bei Security im Software-defined Car besonders wichtig?
Silvio Muschter: Das große Thema ist Zero Trust in Kombination mit Zero Touch und einem Sicherheitsanker – und zwar Architektur-übergreifend. Sehr hilfreich ist ein One Security API, mit dem man auf vielen verschiedenen Systemen in der Architektur mit der gleich API und der gleichen Schnittstelle arbeiten kann. Ganz wichtig sind eine Device ID sowie die Secure Authentification, was wir alles über unsere sehr sichere Umgebung in der Fab aus einer Hand bieten.
Ebenfalls sehr wichtig ist das sichere Booten – Secure Boot – und in Zukunft auch Fast Boot. Außerdem sind dann noch Secure OTA-Firmware-Updates von Applikationen, Betriebssystemen, Firmware etc. äußerst wichtig. Hinzu kommt noch das Thema Self-Encrypted Storage.
Auch im Bereich Device Management sowie beim Identity Management sind wir aktiv, denn jede Komponente im Fahrzeug muss eindeutig identifizierbar sein; sie muss bildlich gesprochen ihren eigenen eindeutigen Ausweis haben. In diesem Rahmen wird auch festgelegt, wer mit wem kommunizieren und wer ein Firmware-Update bekommen darf. Wir sind in diesem Bereich zertifiziert und agieren sehr offen, denn die OEMs und Tier-1 wollen am Ende dieses Management selbst unter Kontrolle halten. Wir stehen da als Partner zur Verfügung – bei Bedarf auch inklusive Swissbit-Cloud.
Peter Berns: Hier können wir mit unserem flexiblen Firmware-Konzept für den Flash-Controller sehr aktiv zur Differenzierung beitragen. Auf Basis der kundenspezifisch angepassten Firmware können die Kunden dann ihre eigenen Anpassungen vornehmen. Wir bieten somit ein sehr zentrales Differenzierungsmerkmal. Schon heute arbeiten 60 Prozent unserer Design-Ingenieure an der Firmware und 40 Prozent an der Hardware, wobei sich dieser Prozentsatz noch stärker Richtung Firmware verschieben wird, denn über die Firmware können wir die in der Branche erforderliche intelligente Differenzierung erzielen.
Die Bootgeschwindigkeit ist ein sehr zentrales Thema, denn Systeme wie die Rückfahrkamera müssen sofort zur Verfügung stehen…
Peter Berns: Genau, und hier arbeiten wir an einem Patent, das uns mit Standard-e.MMC oder NVMe-Komponenten so nahe wie möglich an die Geschwindigkeit eines NOR-Boots heranbringt. Über Details können wir allerdings erst frühestens Ende dieses Jahres sprechen.
Wie entwickelt sich denn der Bedarf an Flash-Speichern im Fahrzeug weiter?
Peter Berns: Wie sehr der Flash-Bedarf ansteigen wird, zeigt das folgende Beispiel: Die aktuellen Navigationsdaten von ganz Europa passen in 32 GByte. Für das autonome Fahren braucht man allein in Deutschland 512 GByte. Wahrscheinlich werden wir bei den Software-definierten Applikationen für das Fahren auf hohem Autonomie-Level über Terabyte reden.
Silvio Muschter: Auch ganz ohne autonome Fahrfunktionen ist der Bedarf an performantem Flash-Speicher hoch; das fängt schon bei den Zentral- und Domänenrechnern an und geht bis zur intelligenten Peripherie. Überall ist eine hochkomplexe Firmware nötig – und die muss sicher sein; sie muss zertifiziert und nachweislich manipulationssicher sein. Hier muss man seine Supply-Chain im Griff und unter Kontrolle haben.
Ohne umfassende Security geht da nichts mehr. Weil wir unser eigenes Security-Controller-ASIC herstellen, sind wir sowohl technologisch als auch auf der Kostenseite sehr gut aufgestellt. Seit 2022 fahren wir auch unsere Komponentenfertigung in Berlin sehr stark hoch.
Bei einem derart hohen Speicherbedarf kommt auch der Verlustleistung eine ganz andere Bedeutung zu. Was tut sich in diesem Bereich?
Peter Berns: Im Automobil-Umfeld arbeiten wir mit Umgebungstemperaturen bis 105 °C, während die Halbleiter bis 125 °C spezifiziert sind. Diese 20 Grad Offset sind nicht viel, so dass auch in thermischer Hinsicht intelligente Designs gefragt sind. Gleichzeitig muss man das Problem von Anfang an angehen und schon die Generierung der Verlustleistung im Controller und Flash sehr gering halten.
Welche technischen Trends sehen Sie bei Flash-Speichern?
Peter Berns: Es gibt zunehmend Überlegungen, eine lokale Daten-Vorverarbeitung im Speichermodul vorzunehmen. Dieses In-Memory-Computing kann viele Vorteile bieten – gerade rund um KI und Machine Learning. In unserer flexiblen Firmware-Architektur haben wir ein API, auf dem wir auch andere Algorithmen laufen lassen können. So können wir die sowieso vorhandene Rechenleistung optimal nutzen. Um flexibel zu sein und genügend Rechenleistung vorzuhalten haben wir bei unseren neusten Entwicklungen bereits einen zweiten RISC-V-Kern mitintegriert…
Silvio Muschter: …den wir für die Standardfunktionalität überhaupt nicht brauchen. Wir sind in diesem Bereich in ein Forschungsprojekt involviert, bei dem es um die Architektur von Systemen mit Daten-Vorverarbeitung auf dem Speicher geht. Der Kreis schließt sich: Die Hyperstone-Integration ist also äußerst wichtig, um die Themen rund um Security und KI sauber zu adressieren.