Diskussion über Software-Bausteine
PICMG möchte Standardisierung vereinfachen
Im Dezember trafen sich einige Mitglieder der PICMG auf Einladung von WEKA Fachmedien zu einem Roundtable. Thema waren die verschiedenen offenen Standards der PICMG und wie sich diese weiterentwickeln müssen. Schließlich will man mit der Technologie Schritt halten.
Die technologischen Fortschritte, zum Beispiel in den Bereichen Automotive oder Medizintechnik, erfordern es immer öfter, Applikationen einfach und schnell anpassen zu können. Welchen Beitrag Computer-on-Modules (CoMs) hier leisten können, erklärt Christian Engels, Product Marketing Manager bei Avnet Embedded: »Viele unserer Kunden möchten die neueste Generation an Prozessoren und Funktionen in ihre Produkte integrieren – und das muss reibungslos funktionieren. Hier hilft ein offener Industriestandard. Nutzt ein Entwickler hingegen proprietäre Formfaktoren, muss er praktisch bei Null anfangen. Standards beschleunigen den Entwicklungsprozess mit einem gemeinsamen Ansatz«, erklärt Engels. Außerdem komme zunehmend die Software-Ebene ins Spiel. Entwickler benötigen wiederverwendbare Bausteine auf Betriebssystem-, Firmware- oder API-Ebene. Auch hier seien offene Standards gefragt, meint Engels.
Jobangebote+ passend zum Thema
Brandon Lewis, Marketing Officer der PCI Industrial Computer Manufacturers Group (PICMG), greift den Punkt der Software-Ebene auf. »Die meisten CoM-Anbieter innerhalb der PICMG wollen sich auf einer höheren Ebene des Software-Stacks differenzieren. Demnach wäre es vorteilhaft, mit der Definition von Board-Support-Packages (BSPs) zu beginnen.«
Christian Eder, Director Product Marketing bei congatec und Chairman der COM-HPC Working Group innerhalb der PICMG, greift die Aussage von Engels auf: »Im Zuge des Entwickelns von COM-HPC haben wir mit dem Spezifizieren von Software-Stacks begonnen, zum Beispiel mit dem Plattformmanagement-Interface. Für mich ist Innovation, verschiedene Software-Bausteine miteinander zu kombinieren. Das Ziel ist es, bestimmte Bausteine für bestimmte Applikationen anzubieten, zum Beispiel für die Medizintechnik oder für die Automation.« Hierfür seien verschiedene Schritte erforderlich, so Eder weiter.
Zum anderen müsse man alles dafür tun, um die Standardisierung zu vereinfachen, erklärt Eder. »Ein großer Schritt ist der Carrier-Board-Design-Guide, den wir für COM-HPC vorangetrieben haben. Bei COM Express wurde dieser erst vier Jahre nach der Spezifikation veröffentlicht. Bei COM-HPC haben wir bereits jetzt eine erste Revision überarbeitet, nur ein paar Wochen nach der ersten Veröffentlichung. Zudem haben wir in der Zwischenzeit die zweite große Spezifikation, COM-HPC Mini, veröffentlicht. Der Software-Stack jedoch ist und bleibt kompliziert umzusetzen«, führt Eder seinen Gedanken zu Ende.
Jess Isquith, President der PICMG, denkt indes darüber nach, wie viel Arbeit in einem technischen Unterausschuss geleistet wird und welche Dinge all die Prozesse durchlaufen müssen – ganz im Gegensatz zu einem offenen Ansatz, zu dem die Leute beitragen können oder nicht. Die PICMG schaffe Werte, die ohne formale Gremien nicht denkbar wären.
Bausteine für Sicherheit einführen
Gerade in Hinblick auf künstliche Intelligenz (KI) nimmt die Software auch beim Thema der Hardware-Standardisierung einen immer höheren Stellenwert ein. Peter Müller, Vice President Product Line Modules bei Kontron, denkt, dass man kein standardisiertes Software-Framework benötige, stimmt jedoch dem Baustein-Gedanken von Eder zu: »Ich denke, dass wir Referenzbausteine für Sicherheit und Konnektivität benötigen. Diesen Ansatz verfolgen wir bei Kontron, es gibt zum Beispiel Bausteine für die Konnektivität oder die TSN-Implementierung«. Müller denkt, für die PICMG wäre es ein Ansatz, diese Bausteine in eine Art Design-Leitfaden zu integrieren, zum Beispiel für die 5G-Konnektivität. Jens Hagemeyer, Research Associate an der Universität Bielefeld, möchte das Thema auf die Firmware-Ebene herunterbrechen. »Für USB-Anschlüsse haben wir zum Beispiel einen eingebetteten Controller entwickelt, bei dem es sich um ein spezifisches Tool des Chip-Anbieters Intel handelt«, erklärt Hagemeyer.
Auch Richard Pinnow, Business Development Manager Modules bei Adlink Technology, legt seinen Standpunkt dar: »Besonders gut gefällt mir die Tatsache, dass wir versuchen, einen gemeinsamen Nenner in Bezug auf Safety & Security zu finden. Sicherheit ist gerade für die Medizin- und Automobilindustrie sehr wichtig – hier möchten wir verstärkt Applikationen anbieten. Hierbei muss es sich nicht unbedingt nur um Hardware handeln. Gerade bei COM-HPC Mini haben wir die funktionale Sicherheit als Teil implementiert und zudem eine Schnittstelle entwickelt«, erklärt Pinnow.
Computer-on-Module-Standards im Vergleich
Die Software ist also ein Thema, das mittlerweile auch Hardware-Entwickler stark umtreibt. Jedoch ist der Markt an CoM-Standards inzwischen so groß geworden, dass es hilfreich ist, diese differenziert zu betrachten. So stellt sich die Frage, worin die Vorteile und Nachteile der einzelnen Standards, im Speziellen von COM-HPC und COM Express im Vergleich mit SMARC oder Qseven – beides Standards der Standardization Group for embeddded Technologies (SGeT) – liegen.
Christian Eder meint hierzu: »Mit COM-HPC erreichen wir ein anderes Leistungsniveau als bei stromsparenden Standards wie SMARC oder Qseven. SMARC hat eine Leistungsaufnahme von etwa 15 Watt, COM-HPC ist für etwa 350 Watt skaliert«, so Eder. Peter Müller ergänzt: »Es geht darum, so viele PCIe-Lanes oder Ethernet-Kanäle wie möglich zur Verfügung zu haben.« Christian Engels unterstreicht das: »In Bezug auf die physikalische Bandbreite ist COM-HPC derzeit die einzige wahre Adaption, die es für CoMs gibt. Möchten Entwickler die maximale Bandbreite erreichen, müssen sie zum neuen Standard wechseln«, so Engels.
Aus Sicht des Connector-Herstellers Samtec habe man die Pins für verschiedene Kommunikations-, Signalisierungs- oder Stromversorgungsfunktionen definiert, erklärt Neil Potter, Field Application Engineer bei Samtec. »Wir charakterisieren die Pin-Belegungen nach bestimmten Standards und können sie hierfür optimieren. So haben wir zum Beispiel für PCIe Gen5 100-Gigahertz-Ethernet adaptiert; für Gen6 können wir die Leistung nochmals beschleunigen. Somit möchten wir künftige Migrationspfade für die nächsten Generationen an Konnektoren ermöglichen«, berichtet Potter.
»Im Moment gibt es nicht so viele Halbleiterbausteine für COM-HPC- und COM-Express-Module. Jedoch, denke ich, wird die Anzahl an Bausteinen in den nächsten Jahren weiter ansteigen; zudem haben wir viel aus den Entwicklungen mit Qseven und SMARC gelernt. Hierauf können wir in Zukunft aufbauen«, meint Pinnow. »Meiner Meinung nach ergänzen sich die Arbeit der PICMG und der SGeT«, fügt Jess Isquith an. »Es gibt kein Interesse daran, dass die PICMG an etwas arbeitet, was die SGeT adressiert. Ich denke, dass sich beide auf komplementäre Weise entwickeln«, denkt Isquith.
Arm- oder x86-Architektur?
Christian Eder, neben der PICMG ebenfalls im SGeT-Gremium aktiv, denkt zurück, als SMARC mit der Version 1.0 gestartet wurde. »Ursprünglich war SMARC für Arm-Plattformen gedacht, mit großer Unterstützung für die sehr spezifischen I/Os. Wir haben herausgefunden, dass ein Standard austauschbar sein muss, jedoch nicht alle Funktionen abdecken kann – das war die Lehre aus der Spezifizierung von SMARC. So haben wir uns auf ein paar bestimmte I/Os reduziert, zum Beispiel USB, PCIe oder I2S. Offene Standards schränken Entwickler immer ein, man kann nicht alle Funktionen nutzen, die der Chip bietet. Das ist der Unterschied zu den proprietären Modulen, die spezielle Eigenschaften eines Chips abdecken können. Gerade im Arm-Bereich gibt es jede Menge proprietärer Module. Mit einem Standard ist man jedoch austauschbar und kann beliebig skalieren.«
Peter Müller denkt, dass der COM-HPC-Standard ebenso für Arm-Produkte gut geeignet sei. »Ich denke, was fehlt, ist, dass COM-HPC auf Arm-Plattformen mehr Anklang findet, sei es von den Halbleiterherstellern selbst oder von uns, um dem Markt zu zeigen, dass es hierfür Produkte gibt«, führt Müller aus.
Künstliche Intelligenz auf Edge-Ebene umsetzen
Künstliche Intelligenz sowie der Markt für KI-Applikationen sind ein großer Treiber von Innovationen in den nächsten Jahren. Offene Standards können zum Erfolg von KI-Applikationen beitragen; fraglich ist jedoch, ob hierfür alle Voraussetzungen gegeben sind. Thomas Kaminski, Director Product Sales and Marketing Management bei Advantech, beschreibt seine Sicht der Dinge: »Ich denke, es wird mehr und mehr Anwendungen geben, bei denen es um Automation, Verkehrskontrolle oder Sicherheit geht, und man wird viele Edge-Geräte nutzen, die letztendlich eine hohe Verarbeitungsleistung benötigen. Das erfordert schnelles PCIe oder eine leistungsfähigere CPU.« Hinsichtlich Arm-CPUs ist Kaminski der Meinung, der Durchbruch für High-End-Chipsätze von Qualcomm oder anderen Anbietern werde in den nächsten ein bis zwei Jahren erfolgen. »Sobald die Akzeptanz auf dem Verbrauchermarkt für die Chipsätze steigt, werden sie auch wieder stärker in der Industrie nachgefragt.«
Richard Pinnow meint, es hänge ein wenig davon ab, über welche Art von Halbleiter man spreche. »Zum Beispiel gibt es hybride Halbleiter, also eine CPU neben einer leistungsstarken GPU, wie sie die Jetson-Produktlinie von Nvidia aufweist. Diese Halbleiter werden wir in naher Zukunft sehr häufig in unseren Standards verwenden«, meint Pinnow. Jens Hagemeyer kann das aus Sicht der Forschung unterstreichen. Er möchte die heterogene Architektur im Rechenzentrum auf CoMs übertragen. Denn sie seien sich vom Gesamtkonzept her sehr ähnlich. »So bekommt man ein skalierbares System, ist im Sinne der Architektur flexibel, egal ob man auf x86- oder RISC-V-Systeme setzt. Man kann das für mittlere bis High-End-Leistungsbereiche umsetzen und bei den I/Os oder beim Speicher skalieren – über verschiedene Computerarchitekturen hinweg«, denkt Hagemeyer.
Christian Engels widerspricht: »In Bezug auf KI müssen wir davon ausgehen, dass die Anforderungen die Fähigkeiten der KI immer übertreffen werden. Möchte ein Entwickler ein System erweitern, kann er das nicht durch mehr Speicher oder mehr Rechenleistung bewerkstelligen, sondern muss es in die Cloud auslagern. Aus diesem Grund muss man bei Edge-Applikationen immer ein Backup in der Cloud sowie eine Hochgeschwindigkeits-Netzwerkverbindung verfügbar haben. Wir werden in Zukunft heterogene Systeme haben – da bin ich mir ziemlich sicher«, ergänzt er.
Server ist nicht gleich Server
Mit dem COM-HPC-Server-Formfaktor versucht die PICMG den Server-Markt zu erschließen. Christian Eder berichtet von den Anfängen: »Mit dem COM-HPC-Server-Formfaktor wollten wir etwas Besseres und Leistungsfähigeres als COM Express Type 7 präsentieren. Jedoch war es nie unsere Absicht, Rechenzentren auszustatten. Wir möchten hiermit lediglich den Edge-Server-Markt bedienen«, erklärt Eder. Man müsse davon ausgehen, dass nicht alle Daten immer im Rechenzentrum übertragen werden können, sondern oftmals direkt am Edge. Das bedeute, in einer rauen Umgebung, im Freien oder in einer Fabrik. Mit COM-HPC Server möchte man Plattformen bieten, die robust seien und sich den Bedürfnissen am Edge anpassen, so Eder.
Peter Müller denkt, »dass der Markt, auf den wir hier abzielen, noch nicht verstanden hat, dass wir sehr leistungsfähige Produkte anbieten können. Was wir häufig sehen, sind Anforderungen am unteren Level für COM-HPC-Server, die mehr oder weniger dem Leistungsniveau entsprechen, das wir bereits mit COM Express erreicht haben. Was wir meiner Meinung nach noch nicht ganz schaffen, ist, mit einem Standard-High-End-Motherboard zu konkurrieren. Das ist die Herausforderung oder der Markt, der in den nächsten zwei Jahren das Ziel sein muss«, gibt Müller die Richtung vor.
Richard Pinnow kann hier nur zustimmen. »Herkömmliche Netzwerkgeräte sind für den 24/7-Betrieb ausgelegt. Man schaltet sie ein und niemand kümmert sich um die Boot-Zeit. Aber genau das ist unser tägliches Brot – wir bieten unseren Kunden in der Verteidigungs- und Datenerfassungsbranche an, dass sie sich darauf verlassen können, dass das Gerät innerhalb von acht Sekunden hochfährt. Genau hier können wir den Unterschied zu herkömmlichen Netzwerkgeräten machen«, so Pinnow.
Update für COM Express 3.1
Ein Update gab es zudem unlängst für den Standard COM Express mit der Revision 3.1. Christian Eder erklärt die Hintergründe zum Update: »Besonders bei Type 7, vor allem beim Ethernet, gab es einen Kompatibilitätsbruch, weil von Revision 3.0 auf 3.1 die Ethernet-Schnittstelle geändert werden musste, sonst wäre es nicht möglich gewesen, sie zu unterstützen.
Leider ist sie zur alten Revision nicht rückwärtskompatibel. Das stört etwas meine grundsätzliche Meinung zu modularen Systemen.« Eder denkt, die Revision 3.1 sei in Summe nicht nötig gewesen und erzeuge lediglich Verwirrung bei Entwicklern. Christian Engels meint: »Die Dinge entwickeln sich weiter, COM Express ist immer noch aktuell, und das wird noch eine Weile so bleiben. Die Vorteile sind jedoch sehr überschaubar, was COM Express 3.1 betrifft.«
Peter Müller meint: »COM Express 3.1 ist wahrscheinlich in Ordnung. Aber irgendwann, glaube ich, muss man aufhören, immer neue Revisionen zu erschaffen. Wenn wir in der Geschichte zurückgehen, war es genauso bei ETX. Es gab immer den Versuch, ETX durch die Implementierung von PCI oder Ähnlichem künstlich am Leben zu halten. Ich denke, das sind gute Ideen, aber ergibt keinen Sinn. Es gibt den COM-Express-Standard und ich denke, dass er noch viele Jahre weiterlebt«, so Müller.
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Interview mit Andreas Willig, TQ
»Proprietär oder Standard? Beides nutzen!«
Advantech entwickelt OSM-Lötmodule
Kompakt und energieeffizient
Embedded-KI
Gefahr oder Heilsbringer?
Messe mit Konferenzen
Embedded-Branche trotzt Konjunkturschwäche
Mehr als ein Automatisierer
Hardware, Software und Services aus einer Hand
KI als Wachstumschance
»Das Wettrennen ist noch nicht entschieden«
Roundtable der PICMG
Lange Lebensdauer und Modularität im Visier
