Kepware Alternative im Kontext des Unified Namespace (UNS)

Aufgrund der lokalen Beschränktheit von Kepware sowie der aktuellen Unsicherheiten durch die Kepware-Übernahme von PTC durch TPG suchen immer mehr Unternehmen nach einer Kepware Alternative. Parallel dazu verschiebt sich der Fokus in der industriellen IT/OT-Integration von isolierten Gateway-Setups hin zu skalierbaren, modularen Unified-Namespace-Architekturen (UNS). Während klassische Systeme wie Kepware auf lokale Datensammlungen und punktuelle Verbindungen setzen, zielen moderne Architekturen auf eine unternehmensweite, semantisch strukturierte Datenebene. Der UNS fungiert dabei als Single Source of Truth und stellt kontextreiche Daten in Echtzeit von der SPS bis zur Cloud konsistent bereit.

Der folgende Artikel zeigt vor diesem Hintergrund die zentralen Gemeinsamkeiten und Unterschiede zwischen Kepware und i-flow Edge als Kepware Alternative.

Was ist Kepware?

Kepware ist eine industrielle Konnektivitätssoftware zur Anbindung von SPSen, Maschinen und Automatisierungssystemen an übergeordnete IT-Systeme. Kepware fungiert primär als lokales Gateway, das unterschiedliche Industrieprotokolle (z. B. Modbus, Siemens S7, EtherNet/IP) integriert und OT-Daten zentral über einen OPC-UA-Server als standardisierte Schnittstelle bereitstellt. Die Daten können so von SCADA-, MES- oder IoT-Systemen abgerufen werden. Kepware wird typischerweise in klassischen, lokalen und standortgebundenen Automatisierungsarchitekturen eingesetzt.

Was ist i-flow Edge?

i-flow Edge ist eine Edge-Runtime für performante OT/IT-Datenverarbeitung und fungiert als Datengateway innerhalb einer Unified-Namespace-Architektur. i-flow Edge wird nahe an den Datenquellen im Produktionsnetzwerk betrieben und verbindet Maschinen, Steuerungen, Sensoren sowie Historian- und MES-Systeme über industrielle Protokolle wie OPC UA, Modbus, Siemens S7 oder HTTP. Die Daten werden anhand offener Standards (z. B. ISO 22400 oder OPC UA Companion Specifications) harmonisiert, in Echtzeit verarbeitet und eventbasiert über moderne Protokolle wie MQTT im Unified Namespace bereitgestellt. Das zentrale Management, die Konfiguration und der Rollout verteilter Edge-Instanzen erfolgen über den i-flow Hub, der Governance, Monitoring, Security und Versionierung abdeckt.

Da i-flow mit Edge, Hub und Broker eine vollständige UNS-Architektur abbildet, wird i-flow Edge in diesem Artikel inklusive Hub betrachtet und als Kepware Alternative direkt mit Kepware verglichen.

Kepware & i-flow Edge: Gemeinsamkeiten

Trotz unterschiedlicher architektonischer Ausrichtung adressieren Kepware und i-flow Edge ähnliche Grundanforderungen in der industriellen Datenintegration. Die folgenden Punkte zeigen, in welchen Bereichen sich beide Lösungen funktional überschneiden.

1. Gemeinsame Rolle als Datengateway

Sowohl Kepware als auch i-flow Edge können als Datengateway in industriellen Architekturen eingesetzt werden. Beide Lösungen binden Maschinen, Steuerungen und OT-Systeme über industrielle Protokolle an und stellen deren Daten für übergeordnete Systeme bereit. Während Kepware traditionell als klassisches OPC-UA-Gateway genutzt wird, kann i-flow Edge diese Gateway-Rolle ebenfalls übernehmen – jedoch als Bestandteil einer erweiterten, UNS-fähigen Edge-Architektur.

2. Redundanz und Hochverfügbarkeit

Sowohl Kepware als auch i-flow unterstützen hochverfügbare Betriebsmodelle, um den Ausfall einzelner Komponenten abzufangen. In beiden Fällen lassen sich Redundanzkonzepte umsetzen, die einen kontinuierlichen Betrieb ermöglichen. Die konkrete Ausgestaltung unterscheidet sich zwar architektonisch, doch beide Lösungen adressieren das grundlegende Ziel, produktive Datenflüsse auch bei Störungen aufrechtzuerhalten, was für industrielle Umgebungen essenziell ist.

3. Write-back und Closed-Loop-Szenarien

Beide Systeme ermöglichen bidirektionale Datenflüsse zwischen IT- und OT-Ebene. Sowohl Kepware als auch i-flow Edge können nicht nur Daten aus der Produktion erfassen, sondern auch Schreiboperationen in Richtung Steuerung oder Maschine ausführen. Damit lassen sich Closed-Loop-Szenarien realisieren, bei denen Analyse-, Optimierungs- oder Planungsergebnisse aus IT-Systemen wieder in operative Prozesse zurückgeführt werden – eine grundlegende Voraussetzung für fortgeschrittene Industrie-4.0-Anwendungen.

Zusammenfassung Gemeinsamkeiten

Kepware vs. i-flow Edge: Unterschiede

Obwohl beide Lösungen ähnliche Grundaufgaben erfüllen, unterscheiden sie sich grundlegend in Architektur, Kommunikationsmodell und Skalierungsansatz. Für IT/OT-Architekten, die eine Kepware Alternative im Kontext UNS bewerten, sind insbesondere die folgenden Punkte relevant.

1. Kepware vs. i-flow Edge: Lokales Gateway vs verteilte Edge-Architektur

Kepware ist ein klassischer OPC-UA-Gateway: Es aggregiert Daten aus Feldgeräten und stellt sie über OPC UA oder andere Schnittstellen bereit. Die Architektur folgt dabei einem zentralen Gateway-Prozess pro Standort oder Linie, der lokal konfiguriert wird. Dieses Prinzip hat sich in vielen Fabriken bewährt, führt aber zu isolierten Dateninseln, sobald mehrere Gateways im Einsatz sind. Daten bleiben häufig auf Standortebene begrenzt, während der organisationsweite Kontext fehlt.

i-flow Edge erweitert dieses Konzept: Jede Edge-Instanz fungiert als verteiltes, aber zentral verwaltetes Gateway, das Daten lokal verarbeitet und über MQTT in den globalen UNS publiziert. Der Hub orchestriert dabei sämtliche Edges, stellt eine einheitliche Konfiguration sicher und ermöglicht eine föderierte, aber zentral gesteuerte Architektur. So entsteht ein skalierbares Netz aus Edge-Knoten, die ihre Daten semantisch harmonisiert in den globalen Namespace einspeisen – ein zentraler Unterschied einer modernen Kepware Alternative.

2. Kommunikationsmodelle: Polling- vs. Eventbasierte Protokolle

Kepware nutzt überwiegend das OPC UA Client/Server-Modell. Hierbei fragt ein Client (z. B. ein MES oder SCADA-System) zyklisch Daten vom Server ab – ein etabliertes Verfahren, das sich für lokale Automatisierungsaufgaben eignet, aber nur punktuelle Verbindungen erlaubt. Je mehr Systeme Daten benötigen, desto stärker steigt die Komplexität und Netzlast auf der Quellseite.

i-flow Edge setzt dagegen auf eventbasierte Protokolle (z.B. MQTT) und das Publish/Subscribe-Modell. Daten werden nicht abgefragt, sondern ereignisgesteuert veröffentlicht. Der Message Broker (Teil des UNS) verteilt die Informationen an beliebig viele Abonnenten, ohne die Quelle oder i-flow Edge zusätzlich zu belasten. Dieses Modell ermöglicht echtzeitfähige, asynchrone Kommunikation über Standort- und Systemgrenzen hinweg. Ein Kernargument für eine Kepware Alternative in skalierenden IIoT-Architekturen.

3. Governance und Betrieb

Ein zentraler Unterschied zwischen Kepware und i-flow Edge zeigt sich im operativen Betrieb verteilter Gateways.

Kepware-Instanzen werden typischerweise lokal und individuell konfiguriert. In Umgebungen mit mehreren Linien oder Standorten führt dies häufig zu inkonsistenten Datenmodellen, abweichenden Tag-Strukturen und manuellem Pflegeaufwand. Änderungen an Namenskonventionen, Sicherheitsrichtlinien oder Konfigurationen müssen meist pro Instanz umgesetzt werden, was globale Skalierung und Standardisierung erschwert.

Der i-flow Hub adressiert genau diese Betriebsebene: Als zentrale Governance- und Managementschicht steuert er alle i-flow-Edge-Instanzen einheitlich. Datenmodelle, Namensräume und Policies werden zentral definiert und automatisch auf alle Edges ausgerollt. Zusätzlich ermöglicht der Hub rollenbasierte Zugriffskontrolle, Zertifikatsmanagement, Monitoring sowie versionierte Deployments.

Damit verschiebt sich der Fokus von der lokalen Gateway-Verwaltung hin zu einem standardisierten, reproduzierbaren Betrieb – eine entscheidende Voraussetzung für skalierbare UNS- und IIoT-Architekturen.

4. Kepware vs. i-flow Edge: Sicherheit

Klassische OPC-UA-Server wie Kepware erfordern für die bidirektionale Kommunikation in der Regel eingehende Verbindungen aus der IT- oder MES-Ebene. Benutzer, Rollen und Zertifikate werden dabei häufig lokal pro Gateway verwaltet. In verteilten Umgebungen führt dies zu hohem Administrationsaufwand, inkonsistenter User- und Rechtevergabe (z.B. admin / admin User) und erhöhten Angriffsflächen.

i-flow Edge verfolgt ein anderes Sicherheitsprinzip: Die Edge-Instanzen bauen ausschließlich ausgehende, gesicherte Verbindungen zum Broker im Unified Namespace auf. Auch für die bidirektionale Kommunikation zwischen IT und OT. Dadurch können Firewalls geschlossen bleiben, Netzwerksegmente sauber getrennt werden und das OT-Netz bleibt von direkten IT-Zugriffen isoliert. Zudem erfolgt Identitäts-, Zertifikats- und Rechteverwaltung zentral über den i-flow Hub. Lokale Benutzerkonten entfallen zugunsten einer zentralen Governance, inklusive Integration in bestehende Identity-Provider wie Microsoft Entra ID. Das ermöglicht rollenbasierte Zugriffe, konsistente Security-Policies und revisionssichere Verwaltung über alle Standorte hinweg – ein klarer Vorteil für sicherheitskritische, skalierende OT/IT-Architekturen. Weitere Infos finden Sie hier.

5. i-flow als Kepware Alternative für Datenverarbeitung und Semantik

Kepware ist primär für zuverlässige Erfassung und Weiterleitung ausgelegt, nicht für semantische Harmonisierung. Es liefert Rohdaten (Tags, Werte, Typen), deren Kontextualisierung nachgelagert erfolgt.

i-flow Edge verfolgt einen deutlich erweiterten Ansatz: Datenverarbeitungspipelines direkt an der Quelle ermöglichen es, Daten bereits am Edge zu konvertieren, zu bereinigen, zu normalisieren und mit Kontext- oder Stammdaten anzureichern. Vor der Veröffentlichung in den Unified Namespace werden die Informationen in standardisierte, semantisch definierte Formate überführt. Auf diese Weise entstehen konsistente Informationsobjekte, die logisch entlang der UNS-Struktur (z. B. Werk → Linie → Maschine → Parameter) organisiert sind. Diese semantische Einheitlichkeit reduziert den Integrationsaufwand in MES-, Historian-, BI- und Cloud-Analytics-Systemen erheblich und ist ein zentrales Kriterium für IT/OT-Architekten, die skalierbare und zukunftssichere Dateninfrastrukturen entwerfen.

6. Skalierbarkeit und Lifecycle-Management

Kepware skaliert in der Praxis überwiegend vertikal, indem bestehende Instanzen durch leistungsfähigere Hardware oder größere virtuelle Maschinen erweitert werden. Zwar können auch mehrere Kepware-Instanzen parallel betrieben werden, diese sind jedoch jeweils eigenständig zu konfigurieren und zu betreiben. Eine zentrale Orchestrierung, Template-basierte Konfiguration oder versionsübergreifende Governance über mehrere Instanzen hinweg ist nicht Bestandteil der Architektur.

i-flow Edge setzt dagegen auf horizontale Skalierung. Neue Edge-Instanzen lassen sich flexibel bereitstellen und zentral über den i-flow Hub orchestrieren. Versionierung, Templating und wiederverwendbare Datenfluss-Definitionen ermöglichen standardisierte Rollouts und konsistente Updates. Dieser Ansatz überträgt DevOps-Prinzipien auf die industrielle Datenintegration und ermöglicht ein strukturiertes Lifecycle-Management, das im klassischen OT-Umfeld bislang kaum realisiert wurde.

7. i-flow Edge: Kepware Alternative für Virtualisierung

Moderne Unternehmen und Fabrikumgebungen setzen zunehmend auf virtualisierte und containerisierte Infrastrukturen, um Skalierbarkeit, Ausfallsicherheit, standardisierte Deployments und eine enge Integration in IT-Betriebsmodelle (z. B. Cloud, Edge, DevOps) zu erreichen. Virtualisierung ist damit ein zentraler Baustein moderner IT/OT-Architekturen.

i-flow Edge ist vollständig containerbasiert und lässt sich flexibel in virtualisierten Umgebungen, Kubernetes-Clustern oder Cloud-Edge-Setups betreiben. Dies ermöglicht automatisiertes Deployment, einfache Skalierung und eine saubere Integration in bestehende IT-Lifecycle- und Betriebsprozesse.

Kepware hingegen ist nicht für containerisierte oder cloud-native Umgebungen ausgelegt. Der Betrieb erfolgt typischerweise klassisch auf dedizierten Windows-Systemen, wodurch Virtualisierung, automatisiertes Skalieren und moderne Betriebsmodelle nur eingeschränkt oder gar nicht unterstützt werden.

8. Weiterentwicklungszyklen

Regelmäßige Weiterentwicklungszyklen sind für industrielle Integrationssoftware essenziell, um Sicherheit, Stabilität und die Unterstützung neuer Protokolle und Use Cases sicherzustellen. Sowohl Kepware als auch i-flow Edge werden aktiv weiterentwickelt und kontinuierlich gepflegt.

Der Unterschied liegt jedoch in der Taktung: Kepware folgt einem eher klassischen Release-Modell mit typischerweise einige Releases pro Jahr. i-flow hingegen setzt auf deutlich kürzere Entwicklungs- und Release-Zyklen mit Updates im Wochen- bis Monatsrhythmus. Dieser Ansatz ermöglicht eine schnellere Umsetzung neuer Anforderungen und eine engere Verzahnung mit modernen DevOps- und UNS-Architekturen. Ein praktischer Vorteil einer modernen Kepware Alternative.

9. Kepware vs. i-flow Edge: Verfügbare Konnektoren

Kepware bietet eine sehr breite Palette an OT-Konnektoren und Gerätetreibern für klassische Automatisierungsprotokolle und Steuerungen. Der Fokus liegt klar auf der zuverlässigen Anbindung von Feldgeräten und SPSen. Erweiterungen erfolgen überwiegend über herstellerspezifische Treiber; eine offene, allgemein verfügbare SDK-Strategie zur schnellen Eigenentwicklung von Konnektoren ist nur eingeschränkt vorhanden.

i-flow Edge deckt ebenfalls zentrale OT-Protokolle ab, legt den Schwerpunkt jedoch zusätzlich auf IT- und Enterprise-Konnektoren. Neben Echtzeit-Schnittstellen unterstützt i-flow auch Batch- und filebasierte Integration (z. B. CSV, Dateien, REST-APIs), was die Anbindung von MES, ERP, Data Lakes oder Cloud-Services erleichtert. Über das i-flow SDK lassen sich zudem eigene Konnektoren und Datenpipelines entwickeln und nahtlos in die Plattform integrieren – ein klarer Vorteil für heterogene IT/OT-Landschaften und individuelle Integrationsanforderungen.

Eine Übersicht aller verfügbaren Konnektoren finden Sie hier.

10. Kommerzielle Rahmenbedingungen und Planungssicherheit

Für IT/OT-Architekturen sind planbare Kosten, stabile Lizenzmodelle und transparente Preisstrukturen entscheidend, da Integrationsplattformen typischerweise langfristig und unternehmenskritisch eingesetzt werden.

i-flow Edge folgt einem klaren Subscription-Modell mit stabilen, planbaren Preisentwicklungen. Das Modell ist auf Skalierung ausgelegt und unterstützt eine langfristige Budget- und Lifecycle-Planung ohne disruptive Lizenzwechsel.

Bei Kepware befinden sich Kunden aktuell in einem Lizenzumstieg hin zu Subscriptions. In diesem Zuge wurden bereits Preisanpassungen und -erhöhungen kommuniziert, was bei Bestandskunden zu Unsicherheiten hinsichtlich zukünftiger Kosten und Investitionssicherheit führt. Für Unternehmen mit wachsender oder verteilter Gateway-Landschaft kann dies ein relevanter Entscheidungsfaktor sein.

11. Datenpufferung und Offline-Fähigkeit

Kepware verfügt über eine begrenzte, protokollnahe Pufferung im Rahmen des OPC-UA-Standards. Kurzzeitige Verbindungsunterbrechungen können über interne Caches oder OPC-UA-Session-Mechanismen teilweise abgefedert werden. Ein persistentes, systematisches Store-and-Forward-Konzept zur verlustfreien Datenerfassung über längere Offline-Zeiten ist jedoch nicht Bestandteil.

i-flow Edge ist hingegen explizit für instabile Netzwerke und verteilte Architekturen ausgelegt. Die Edge-Runtime speichert Daten lokal und persistent, sobald die Verbindung zum Zielsystem unterbrochen ist. Nach Wiederherstellung der Verbindung werden die Ereignisse vollständig und automatisch nachgeliefert. Dieses integrierte Buffering- und Store-and-Forward-Verhalten stellt sicher, dass keine Daten verloren gehen. Dies ist ein entscheidender Vorteil für Cloud-, Hybrid- und standortübergreifende UNS-Architekturen.

12. Nachvollziehbarkeit, Audit-Trail und Betriebs-Transparenz

Kepware stellt grundlegende Diagnose- und Event-Logs zur Verfügung, mit denen sich Verbindungszustände oder Serverereignisse nachvollziehen lassen. Eine vollständige, durchgängige Rückverfolgbarkeit aller Datenoperationen – also wann, wie und warum ein Datenpunkt gelesen, verändert, verworfen oder weitergeleitet wurde – ist jedoch nicht Bestandteil der Standardarchitektur. Logs sind überwiegend instanzlokal, nicht semantisch korreliert und nur eingeschränkt für revisionssichere Audits oder Root-Cause-Analysen geeignet.

i-flow Edge ist dagegen von Grund auf auf vollständige Transparenz und Nachvollziehbarkeit ausgelegt. Jede Datenoperation – von der Erfassung über Verarbeitung, Buffering, Transformation bis zur Veröffentlichung in den Unified Namespace – wird deterministisch und lückenlos nachvollziehbar gemacht. In Kombination mit dem i-flow Hub entstehen zentrale Audit-Trails, die Konfigurationsänderungen, Versionen, Fehlerzustände und Datenflüsse über alle Edge-Instanzen hinweg korrelieren.

Diese durchgängige Rückverfolgbarkeit ist eine zentrale Voraussetzung für Compliance, regulatorische Anforderungen, Root-Cause-Analysen und den stabilen Betrieb skalierbarer UNS-Architekturen – und geht deutlich über klassische Gateway-Logging-Ansätze hinaus.

Zusammenfassung Unterschiede

i-flow in Kombination mit Kepware

In bestehenden Brownfield-Umgebungen können Kepware und i-flow Edge auch komplementär eingesetzt werden. Kepware übernimmt dabei die Rolle des OT-Protokollübersetzers, der heterogene Feldgeräte und Steuerungen anbindet und deren Daten zentral über OPC UA bereitstellt. i-flow Edge fungiert in diesem Szenario als OPC-UA-Consumer und Datenverarbeitungsplattform direkt am Edge. Die von Kepware bereitgestellten Rohdaten werden von i-flow Edge konsumiert, verarbeitet, semantisch harmonisiert und angereichert, bevor sie eventbasiert über moderne Protokolle in den Unified Namespace publiziert werden. Auf diese Weise lassen sich bestehende Kepware-Installationen schrittweise in skalierbare UNS-Architekturen integrieren, ohne etablierte OT-Anbindungen sofort ersetzen zu müssen.

Fazit

Der Vergleich zeigt: Kepware und i-flow Edge erfüllen ähnliche Grundfunktionen in der industriellen Datenintegration, folgen jedoch unterschiedlichen architektonischen Ansätzen. Kepware ist ein bewährtes, lokales OPC-UA-Gateway für klassische, standortgebundene Integrationsszenarien.

Mit dem Übergang zu skalierbaren Unified-Namespace-Architekturen werden jedoch verteilte Edge-Konzepte, eventbasierte Kommunikation, zentrale Governance und semantische Datenmodelle entscheidend. Genau hier setzt i-flow Edge an und positioniert sich als moderne Kepware Alternative für UNS- und IIoT-Architekturen.

In Brownfield-Umgebungen können beide Lösungen zudem komplementär eingesetzt werden: Kepware als OT-Protokollübersetzer, i-flow Edge als OPC-Consumer, Datenprozessor und UNS-Integrator. Die Entscheidung ist damit weniger ein Ersatz als eine strategische Weichenstellung für die zukünftige IT/OT-Architektur.