Software unbekannter Herkunft (SOUP) in Medizinprodukten

In den Projekten, die wir bei Somco für Hersteller medizinischer Geräte durchführen, taucht das Thema SOUP fast immer auf. Ob wir nun eine Benutzeroberfläche in Qt erstellen oder die Gerätesteuerung in C/C++ implementieren – früher oder später stellt jemand die Frage: „Können wir diese Bibliothek verwenden?“ oder „Gilt Qt als SOUP?“

Für Hersteller medizinischer Geräte ist dies ein ständiger Balanceakt – bewährte Softwarelösungen von Drittanbietern zu nutzen, um die Entwicklung zu beschleunigen und Kosten zu senken, während gleichzeitig die volle Kontrolle über die Patientensicherheit und die Einhaltung gesetzlicher Vorschriften gewahrt bleibt.

Zu verstehen, wie man dieses Gleichgewicht bewahrt, ist entscheidend. Werfen wir einen genaueren Blick darauf, was beim Umgang mit SOUP wirklich zählt.

Das werden Sie lernen:

• was SOUP ist und warum dieser Begriff in der Entwicklung medizinischer Gerätesoftware verwendet wird,
• wichtige Risiken und regulatorische Herausforderungen, die damit einhergehen,
• wie zentrale Normen und Vorschriften (IEC 62304, ISO 14971, FDA, MDR/IVDR) den Umgang mit SOUP regeln,
• und Best Practices zur Gewährleistung von Compliance und Sicherheit – etwa durch Verwendung von SBOMs oder die Zusammenarbeit mit erfahrenen Entwicklern.

Entwickeln Sie medizinische Gerätesoftware, die höchste Anforderungen an Sicherheit und Leistung erfüllt.
Starten Sie Ihr Projekt mit Zuversicht – arbeiten Sie mit Somco Software zusammen.

 

Was gilt als SOUP in medizinischen Geräten?

Im Kontext der Entwicklung medizinischer Geräte wird SOUP (manchmal als Software unbekannter Herkunft oder unbekannter/unsicherer Provenienz bezeichnet) in der IEC 62304 definiert als „Softwareelement, das bereits entwickelt und allgemein verfügbar ist und nicht für die Integration in das Medizinprodukt entwickelt wurde, oder ein zuvor entwickeltes Softwareelement, für das keine ausreichenden Aufzeichnungen über den Entwicklungsprozess vorliegen.“

Einfacher gesagt: SOUP umfasst jede Softwarekomponente, die in einem Medizinprodukt verwendet wird, ohne dass der Hersteller die vollständige Kontrolle über deren Lebenszyklus hat. Dazu gehören:

 

• Kommerzielle Standardsoftware (OTS – Off-The-Shelf) – z. B. Betriebssysteme, Treiber, Kommunikations-Stacks – ursprünglich für allgemeine oder andere Zwecke entwickelt (die FDA verwendet den Begriff Off-The-Shelf Software (OTS) für solche Komponenten).

 

• Open-Source-Bibliotheken und -Frameworks – Code, der aus offenen Communities stammt (bei denen jeder beitragen oder den Quellcode einsehen kann) und vom Hersteller genutzt wird.

 

• Drittanbieter-Bibliotheken und zuvor entwickelte proprietäre Software – Softwaremodule, die vom Hersteller (oder einem Partner) für andere Zwecke oder Produkte entwickelt wurden, für die jedoch keine detaillierte Entwicklungsdokumentation oder Nachweise zur Verifizierung vorliegen.

 

Wichtig ist: Die eigene Software des Geräts kann nicht einfach als SOUP deklariert werden, um Entwicklungsauflagen zu umgehen – die IEC 62304 stellt ausdrücklich klar, dass das medizinische Gerätesoftware-System selbst nicht als SOUP gelten kann. Stattdessen bezieht sich SOUP auf Unterkomponenten, die in die Gerätesoftware integriert sind. In der Praxis enthalten die meisten modernen Medizinprodukte irgendeine Form von SOUP – von zugrunde liegenden Betriebssystemplattformen bis hin zu Mathematikbibliotheken oder Netzwerkkommunikationsmodulen.

Hersteller entscheiden sich für SOUP, um Entwicklungszeit zu sparen, bewährte Lösungen zu nutzen oder innovative Funktionen zu integrieren. Der Kompromiss besteht jedoch darin, dass der Hersteller diese Komponenten nicht selbst entwickelt oder validiert hat – daher ist eine besonders sorgfältige Bewertung erforderlich. Wie kontrollierte Softwareentwicklung und Prototyping den regulatorischen Anforderungen entsprechen, erfahren Sie hier: Entwicklung von medizinischen Geräteprototypen.

 

Risiken beim Einsatz von SOUP in medizinischen Geräten

Die Verwendung von SOUP-Software bringt Risiken mit sich, die in den Bereichen Technik/Patientensicherheit, Cybersicherheit, regulatorische Konformität und rechtliche Verantwortung aktiv gemanagt werden müssen.

Wie unser CTO Adam Sowa es ausdrückt:

„SOUP ist nicht das Problem – mangelnde Kontrolle und fehlendes Bewusstsein sind es. Entscheidend ist, wie man mit dem umgeht, was man nicht selbst gebaut hat.“

 

Technische Risiken und Risiken für die Patientensicherheit

Unkontrollierte Komponenten können die Zuverlässigkeit und Sicherheit des Geräts gefährden, da ihr Verhalten außerhalb des Qualitätsprozesses des Herstellers nicht eindeutig vorhersehbar ist. SOUP kann latente Fehler oder nicht dokumentierte Fehlermodi enthalten und darf nicht für sicherheitsrelevante Funktionen verwendet werden, ohne dass unabhängige Maßnahmen zur Risikokontrolle getroffen wurden.

Die begrenzte Transparenz erschwert die Sicherheitsbewertung – insbesondere dann, wenn die Software die klinische Leistung beeinflussen kann. Hersteller sollten potenzielle Fehlerauswirkungen analysieren, sicherheitskritische Funktionen vom Einfluss der SOUP isolieren und Mechanismen zur Fehlererkennung und sicheren Fehlerbehandlung implementieren, sodass das Gerät bei Absturz oder falscher Ausgabe in einen sicheren Zustand übergeht.

Kompatibilität und Leistung sind zusätzliche Herausforderungen: SOUP hat oft Voraussetzungen (z. B. Betriebssystem, Speicher, andere Ressourcen). Werden diese nicht erfüllt oder schlecht integriert, kann das Gerät unvorhersehbar reagieren. Behandeln Sie SOUP als eine Blackbox, für die explizite Anforderungen, Prüfung von Voraussetzungen, umfassende Integrationstests und ein defensives Design erforderlich sind.

 

Risiken in der Cybersicherheit

Durch die Einbindung von SOUP übernehmen Hersteller auch deren Schwachstellen. Die fehlende Transparenz über Unterkomponenten erhöht die Angriffsfläche und erschwert das Patch-Management. Veraltete oder ungepatchte Komponenten stellen ein zusätzliches Sicherheitsrisiko dar. Die unklare Herkunft erhöht außerdem die Risiken in der Lieferkette. Gegenmaßnahmen umfassen die Pflege einer vollständigen Software-Stückliste (SBOM), kontinuierliches Monitoring von Schwachstellen, zeitnahe Updates und sicherheitsorientierte Tests. Einen umfassenden Überblick über Anforderungen und Best Practices zur Cybersicherheit finden Sie unter Medizinische Gerätesicherheit – Standards und Compliance.

 

Regulatorische Compliance-Risiken

Zulassungsbehörden erlauben den Einsatz von SOUP, erwarten jedoch risikobasierte Kontrollen, dokumentierte Anforderungen, Verifizierung/Validierung sowie eine Wartung über den gesamten Lebenszyklus – vergleichbar mit intern entwickelter Software. Mangelhafte Dokumentation, unzureichende Tests oder fehlende Update-Strategien können Zulassungsverfahren oder Audits gefährden. Zu den Anforderungen nach der Markteinführung gehören die Überwachung von Drittanbieterproblemen, deren Bewertung sowie gegebenenfalls die Umsetzung von Korrekturmaßnahmen oder Patches.

 

Rechtliche Risiken und Haftungsrisiken

Hersteller tragen die Verantwortung für Schäden, die durch Gerätesoftware verursacht werden – unabhängig von deren Ursprung. SOUP kann Lizenzpflichten, Risiken in Bezug auf geistiges Eigentum, Support- und Gewährleistungsprobleme mit sich bringen – etwa, wenn Zulieferer den Support einstellen – sowie potenzielle Datenschutzverantwortung beim Umgang mit Patientendaten. Erforderlich sind ein stabiles Governance-Modell, klare Verträge (wo anwendbar), Lizenz-Compliance und eine Verringerung der Unsicherheiten in der Softwarelieferkette.

 

Regulatorische Anforderungen und Erwartungen an SOUP

Sowohl die US-amerikanische FDA als auch die EU-Richtlinien MDR/IVDR akzeptieren den Einsatz von Drittanbieter-Software in medizinischen Geräten, verlangen jedoch von den Herstellern, die damit verbundenen Risiken zu kontrollieren. Die Konformität wird in der Regel durch IEC 62304 (Software-Lebenszyklus) und ISO 14971 (Risikomanagement) nachgewiesen, unterstützt durch relevante Leitlinien, die Anforderungen an den Lebenszyklus bei der Integration externer Komponenten festlegen.

 

 

USA: FDA-Richtlinien zu OTS-Software und SOUP

Konzept: Die FDA bezeichnet Drittanbieter-Komponenten als Off-The-Shelf (OTS); dies überschneidet sich in der Praxis mit dem Begriff SOUP. Hersteller müssen einen risikobasierten Ansatz verfolgen und umfassende Dokumentation bereitstellen.

Dokumentation vor der Markteinführung: OTS-Komponenten unterliegen dem gleichen Dokumentationsniveau wie das Gesamtgerät (Basic oder Enhanced).

 

• Basic: Beschreibung der OTS-Komponente, Risikobewertung und Nachweis der Integrationstests.
• Enhanced: zusätzlich Informationen zu Entwicklungsmethoden und kontinuierlicher Wartung (z. B. Updates und Patches). Wenn Informationen vom Lieferanten fehlen, muss eine zusätzliche Verifizierung oder eine risikobasierte Begründung erbracht werden.

Risikobewertung: SOUP-Fehlerszenarien müssen in der ISO-14971-Datei berücksichtigt und geeignete Maßnahmen zur Risikominderung definiert werden. Eine strukturierte Risikobewertung sollte während der gesamten Entwicklung gepflegt und bei neuen Informationen aktualisiert werden.

Qualitätssystem & Lieferanten: Gemäß 21 CFR 820 ist zu überprüfen und zu validieren, dass die Drittanbieter-Software den festgelegten Anforderungen entspricht. Einkaufs- und Lieferantenkontrollen sind gemäß der Kritikalität anzupassen.

Cybersicherheit & SBOM: Bei Einreichungen von „Cyber Devices“ ist eine Software Bill of Materials (SBOM) erforderlich – sowie Pläne zur Schwachstellenüberwachung und zum Update-Management im Rahmen eines sicheren Entwicklungsprozesses.

 

Europa: MDR/IVDR, IEC 62304 und verwandte Normen

Kontrolle des Lebenszyklus: MDR Anhang I fordert Entwicklung nach dem Stand der Technik, Risikomanagement, Verifizierung und Validierung für alle Gerätesoftware. Nach IEC 62304 wird SOUP unter Konfigurationsmanagement gestellt, erhält explizite Anforderungen im jeweiligen Kontext und wird entsprechend verifiziert – der Verifizierungsaufwand richtet sich nach der Sicherheitsklassifikation des Systems.

Risikomanagement: ISO 14971 verlangt die Identifikation von Gefährdungen durch Softwareanomalien und den Nachweis, dass der Nutzen die verbleibenden Risiken überwiegt – inklusive technischer oder kennzeichnungsbezogener Maßnahmen.

Cybersicherheit & PMS: Hersteller müssen unbefugten Zugriff verhindern, Update-Mechanismen bereitstellen, Drittanbieter-Probleme nach der Markteinführung überwachen und bei Bedarf Korrekturmaßnahmen umsetzen. Leitlinien (z. B. MDCG) empfehlen den Einsatz einer SBOM und regelmäßige Schwachstellenanalysen.

 

Best Practices zur Risikominimierung bei SOUP

Ein effektiver Umgang mit Software unbekannter Herkunft (SOUP) in medizinischen Geräten erfordert einen strukturierten Lebenszyklusansatz – von Auswahl und Qualifizierung bis zur Verifikation, Freigabe und Wartung nach der Markteinführung.

 

 

1. Auswahl und Lieferantenqualifizierung

 

• Bevorzugen Sie Komponenten von vertrauenswürdigen und aktiv gepflegten Quellen; bewerten Sie die Reife und das Qualitätsmanagementsystem (QMS) des Anbieters.
• Stellen Sie Transparenz sicher – fordern Sie Dokumentation zu Entwicklung, Test und Wartung an.
• Setzen Sie auf Minimalismus: Integrieren Sie nur, was für die beabsichtigte Funktionalität erforderlich ist.
• Überprüfen Sie die Lizenzkompatibilität und Langzeit-Supportoptionen (z. B. Wartungsverträge oder Escrow-Vereinbarungen).
• Implementieren Sie einen formalen Genehmigungsprozess (technische, qualitätsbezogene und rechtliche Prüfung) für alle Drittanbieter-Komponenten.

Das Qt Framework ist beispielsweise eine hervorragende Technologieoption für medizinische Geräte. Es bietet eine breite und zusammenhängende Modulauswahl – für Kommunikationsprotokolle, Datenbanken, Einstellungsverwaltung, Sensorik, Multimedia und GUI – alles innerhalb eines einheitlichen Ökosystems gepflegt. Im Gegensatz zu vielen Frameworks, die zahlreiche kleine externe Bibliotheken einbinden, vereinfacht die integrierte Architektur von Qt die Risiko- und Sicherheitsbewertung. Sie führen die SOUP-Bewertung und -Wartung einmal für ein einheitliches Framework durch – und nicht mehrfach für viele unterschiedliche Abhängigkeiten.

 

2. Anforderungen, Risikoanalyse und Gefahrenabwehr

 

• Definieren Sie die vorgesehene Rolle und Einschränkungen der SOUP im System.
• Führen Sie eine gezielte Risikoanalyse durch: Identifizieren Sie Gefährdungen durch Fehlfunktionen, Ausfälle oder Cybersicherheitsrisiken.
• Implementieren Sie Risikokontrollmaßnahmen – z. B. Isolation sicherheitskritischer Funktionen, Redundanz, Watchdogs, Eingabevalidierung und sicheres Design.
• Stellen Sie vollständige Rückverfolgbarkeit sicher: Risiko → Kontrolle → Anforderung → Testnachweis. Einen schrittweisen Überblick darüber, wie Verifikation und Validierung zur regulatorischen Compliance beitragen, finden Sie unter: Verifikation und Validierung bei medizinischer Gerätesoftware.

 

3. Verifikation, Tests und Dokumentation

 

• Führen Sie Modul- und Integrationstests im Geräte-Kontext durch; inklusive Stresstests, Robustheitstests und Fuzz-Tests, sofern anwendbar. Einen ausführlichen Überblick über Teststrategien und -tools gemäß IEC 62304 und FDA finden Sie unter: Software-Tests für medizinische Geräte.
• Führen Sie Sicherheitstests und Schwachstellenscans durch.
• Verwalten Sie Versionen und Konfigurationen; dokumentieren Sie die Testergebnisse und etwaige Anomalien.
• Pflegen Sie eine prägnante SOUP-Zusammenfassung und stellen Sie eine klare Rückverfolgbarkeit zwischen Anforderungen, Risiken und Tests sicher, um Prüfern vollständige Transparenz zu gewährleisten.

 

4. Open-Source- und Lizenz-Governance

 

• Setzen Sie einen Genehmigungsprozess für Open-Source-Software (OSS) um, einschließlich technischer und rechtlicher Prüfung.
• Pflegen Sie eine vollständige und regelmäßig aktualisierte Software-Stückliste (SBOM), die alle Komponenten und Lizenzen auflistet.
• Stellen Sie die Lizenzkonformität sicher (z. B. Namensnennung, Offenlegung, Weitergabepflichten) und schulen Sie Entwicklerteams in der korrekten Nutzung.

 

5. Überwachung nach Markteinführung und Wartung

 

• Überwachen Sie kontinuierlich die Leistung im Feld, Schwachstellendatenbanken und Lieferanten-Updates.
• Wenden Sie Patches oder Abhilfemaßnahmen umgehend an; protokollieren Sie diese Schritte und aktualisieren Sie die Risikodokumentation.
• Definieren und kommunizieren Sie eine Support- und Update-Strategie für alle aktiven und Altgeräte.

SOUP kann sicher verwendet werden, wenn Herkunft, Funktion und Risiken vollständig verstanden und kontrolliert werden – durch sorgfältige Qualifikation, Prüfung, Dokumentation und kontinuierliches Lebenszyklusmanagement.

 

Partnerschaften und Herkunftsnachweise: Aufwand reduzieren

Wenn Sie als Entscheidungsträger Softwareentwicklung auslagern oder Drittanbieterkomponenten integrieren möchten, lohnt es sich zu beachten, wie strategische Partnerschaften und moderne Tools zur Herkunftsverfolgung die SOUP-Verwaltung deutlich erleichtern können. Die Zusammenarbeit mit erfahrenen Entwicklern eingebetteter Software für regulierte Systeme kann Integrationsprobleme erheblich reduzieren und die regulatorische Zulassung reibungsloser gestalten.

Ein guter Entwicklungspartner wendet viele der hier genannten Best Practices bereits standardmäßig an. Er verfügt mit hoher Wahrscheinlichkeit über ein etabliertes QMS und eine entwickelte Methodik (z. B. ISO 13485 und IEC 62304 konforme Prozesse), sodass auch bei Einsatz von SOUP eine strukturierte Kontrolle sichergestellt ist. Er kann bei der Auswahl zuverlässiger Drittanbieterkomponenten unterstützen (vielleicht sind bestimmte Bibliotheken sogar bereits qualifiziert). Solche Partner pflegen oft eine interne Wissensdatenbank mit bewährten Softwarekomponenten sowie bekannten Schwachstellen – ein unschätzbarer Vorteil.

Darüber hinaus kann der Entwicklungspartner die Dokumentationslast übernehmen. Er kann die notwendige Softwaredokumentation für regulatorische Einreichungen vorbereiten – inklusive SOUP-Listen, Gefährdungsanalysen, Rückverfolgbarkeitsmatrizen usw. – da er dies vermutlich bereits mehrfach getan hat. Dies kann Ihre Markteinführungszeit erheblich verkürzen, indem Rückfragen von Behörden zur Software vermieden werden. Partner können auch bei der Einführung von Provenance-Tracking-Tools helfen – etwa durch automatisierte SBOM-Generierung im Build-Prozess und Integration von Schwachstellenscans in die Entwicklungs-Pipeline. Auf diese Weise entsteht von Anfang an ein kontinuierliches Protokoll aller Softwarebestandteile und ihres Zustands.

Ein weiterer Vorteil der richtigen Partnerschaft ist der laufende Support. Ein verantwortungsvoller Softwarepartner bietet Wartungsverträge an oder zumindest eine Anleitung, wie die Software nach der Produkteinführung gepflegt werden kann. Er stellt eventuell Patches für integrierte Drittanbieterkomponenten bereit oder benachrichtigt Sie zeitnah, wenn ein Update erforderlich ist. Im Grunde wird der Partner zu einer Erweiterung Ihres Teams, indem er die Überwachung der Softwarelandschaft übernimmt. So kann sich Ihr internes Team stärker auf das Kerndesign des Geräts und klinische Aspekte konzentrieren, während die technische Pflege im Hintergrund abgesichert ist.

Transparenz ist bei solchen Partnerschaften entscheidend. Stellen Sie sicher, dass der Partner Ihnen nach Projektabschluss eine vollständige SBOM und zugehörige Dokumentation übergibt. Es dürfen keine „unbekannten Binärdateien“ enthalten sein – jede integrierte Komponente muss identifiziert und gemeinsam abgestimmt worden sein. Wenn diese Transparenz gewährleistet ist, fühlt sich die Software in Ihrem Produkt nicht mehr als „unbekannter Herkunft“ an – Sie wissen genau, woher jedes Teil stammt, wer es entwickelt hat und wie es integriert wurde. Das verschafft Ihnen einen klaren Vorteil – sowohl gegenüber Regulierungsbehörden als auch auf dem Markt – da Sie die volle Kontrolle über Ihre Software-Lieferkette nachweisen können.

Im größeren Zusammenhang fördern auch die Regulierungsbehörden selbst den Einsatz solcher Expertise und Tools zur Herkunftsverwaltung. Der Ruf nach SBOMs und Cybersicherheits-Best-Practices ist letztlich ein Appell an Hersteller, ihre Software-Herkunft lückenlos zu kennen. Der praktische Weg, diese Erwartungen zu erfüllen – ohne das Rad neu zu erfinden – führt über moderne Tools (zur automatisierten Compliance-Prüfung, SBOM-Management etc.) und erfahrene Partnerschaften.

 

Provenienz-Kontrolle über die Software hinaus

Auch wenn sich SOUP und SBOM primär auf den Softwarebereich der Entwicklung medizinischer Geräte beziehen, erweitern moderne regulatorische Anforderungen zunehmend diese Prinzipien auf die Hardwareebene. Mit anderen Worten: Es geht nicht nur darum, die Herkunft Ihrer Software zu kennen – sondern jede einzelne Komponente, aus der Ihr Produkt besteht.

 

 

Dieses Vorgehen spiegelt sich im Konzept des Hardware Bill of Materials (HBOM) wider – einer strukturierten Liste aller physischen Komponenten eines Geräts, einschließlich Prozessoren, Sensoren, Platinen und Module sowie deren Hersteller- und Bezugsdaten. Genauso wie eine SBOM Softwareabhängigkeiten erfasst und überwacht, sorgt eine HBOM für Rückverfolgbarkeit und Kontrolle in der Hardwarelieferkette.

Das Hardware-Pendant zu SOUP wird gelegentlich als Hardware of Unknown Provenance (HOUP) bezeichnet. Es beschreibt Komponenten oder Module, deren Herkunft, Dokumentation oder Sicherheitsstatus unklar ist – und die somit potenzielle Risiken für Sicherheit, Zuverlässigkeit oder Cybersicherheit darstellen. Besonders relevant ist dies im Rahmen neuer Vorgaben wie dem EU Cyber Resilience Act (CRA), der Transparenz und Lieferkettensicherheit in Hard- und Software gleichermaßen betont.

Bei Somco Software begegnen wir dieser Herausforderung durch enge Zusammenarbeit mit bewährten Hardwarepartnern wie Toradex und SoMLabs. Diese Unternehmen liefern zuverlässige, gut dokumentierte und – sofern erforderlich – CRA-fähige System-on-Module (SoM)-Plattformen, die als Grundlage für viele medizinische und industrielle Geräte unserer Kunden dienen. Durch die Kombination einer kontrollierten Hardwarebasis (HBOM) mit unserer rigorosen Softwareentwicklung und SOUP-Verwaltung (SBOM) ermöglichen wir Herstellern eine durchgängige Herkunftskontrolle – vom Silizium bis zum Quellcode.

 

Fazit

Software unbekannter Herkunft (SOUP) stellt unbestreitbare Herausforderungen bei der Entwicklung sicherer und leistungsfähiger medizinischer Geräte dar. Doch „unbekannt“ muss nicht gleichbedeutend mit „unkontrollierbar“ sein. Mit einem klaren Verständnis der Risiken – von technischen und sicherheitsrelevanten Aspekten bis hin zu regulatorischen Fallstricken – sowie durch den Einsatz konsequenter Kontrollmechanismen können Hersteller und Softwareentwickler Drittanbieter- und Open-Source-Komponenten sicher nutzen und gleichzeitig Patientensicherheit und Compliance gewährleisten.

SOUP darf niemals als Nebensache behandelt werden. Es erfordert frühzeitige Planung, disziplinierte Ingenieursarbeit und kontinuierliche Überwachung über den gesamten Produktlebenszyklus hinweg. Wenn es richtig gehandhabt wird, ist SOUP lediglich ein weiterer kontrollierter Bestandteil des Systems – einer, der Innovation unterstützt, statt sie zu gefährden.

Bei Somco Software haben wir gesehen, wie strukturierte Prozesse und technisches Know-how diese Herausforderung in einen Vorteil verwandeln können. Mit klarer Herkunftsverfolgung, robuster Validierung und proaktiver Wartung kann Drittanbietersoftware sicher als Motor für die nächste Generation medizinischer Geräte dienen.

Bauen Sie mit Kontrolle, innovieren Sie mit Vertrauen – und stellen Sie sicher, dass keine Software in Ihrem Produkt jemals wirklich „unbekannt“ bleibt.

Starten Sie Ihr Projekt mit Zuversicht – arbeiten Sie mit Somco Software zusammen.