Laden...

RedundancyMaster

Konfiguration mehrerer OPC-Server als redundante Paare

Lizenzierung ab $680,00
Download Free Demo

Produktübersicht

RedundancyMaster erhöht die Zuverlässigkeit und Verfügbarkeit Ihrer OPC-Daten durch die Möglichkeit, OPC-Server als redundante Paare zu konfigurieren. Jedes redundante Paar wird von allen OPC-Clientanwendungen als einzelner (übergangsloser) OPC-Server wahrgenommen. RedundancyMaster kann zu einer vorhandenen Client-/Serveranwendung ohne Neukonfiguration der Anwendung hinzugefügt werden, sodass die Prozesse ohne Ausfallzeiten fortgesetzt werden können.

Zuverlässigkeit für industrielle Anwendungen

Die OPC DA-Technologie (OPC Data Access) hat sich in praktisch jeder Industrieumgebung als zuverlässig erwiesen, die kontinuierlichen Datenzugriff auf Geräte und Systeme erfordert. Es gibt jedoch andere Faktoren, die die Integrität eines Systems gefährden können, z.B. Software-, Hardware- und sogar Bedienfehler. Durch den Einsatz von OPC-Redundanztechnologie können Sie die Zuverlässigkeit und Effizienz dieser Systeme erhöhen.

Höhere Rentabilität und weniger Ausfallzeiten

RedundancyMaster befindet sich auf dem OPC-Clientgerät und ermöglicht Verbindungen mit einem primären und einem sekundären OPC-Server im Systemnetzwerk durch "Einklinken" in die OPC-Aufrufe zwischen dem Client und dem Server. Wenn die Kommunikationsverbindung zwischen dem OPC-Client und dem primären OPC-Server aus irgendeinem Grund unterbrochen wird oder eine benutzerdefinierte Bedingung erfüllt ist (ein Item erhält keine Updates, ein bestimmter Item-Wert ist erfüllt, die Qualität eines Items ist auf mangelhaft festgelegt usw.), schaltet RedundancyMaster vom primären OPC-Server auf den sekundären OPC-Server im Netzwerk um  wodurch Systemausfallzeiten reduziert werden und Geld gespart wird.

Benutzerfreundlich

RedundancyMaster ist eine Plugin-Anwendung, die nicht erfordert, dass Änderungen an den OPC-Client- oder -Serveranwendungen vorgenommen werden. Die intuitive Konfiguration nimmt nur wenige Minuten in Anspruch, sodass sich ein redundantes OPC-System mühelos einrichten lässt. Durchsuchen Sie einfach die Server, und wählen Sie einen primären und einen sekundären OPC-Server aus – und schon ist Ihr System betriebsbereit. RedundancyMaster umfasst Funktionen wie E-Mail-Benachrichtigung, Objekt- und Verknüpfungsüberwachung sowie die Diagnose-Protokollierung. Für Situationen, in denen Sie mehrere redundante OPC-Serverpaare benötigen, die den gleichen Anbieter von OPC-Servern verwenden, haben wir die Möglichkeit hinzugefügt, einen Alias für die Programm-ID des OPC-Servers zu erstellen. (Aliasing erfordert möglicherweise kleine Änderungen am OPC-Client.)

Funktionen

Hier lernen Sie Funktionen kennen, die Ihre Denkweise über OPC-Redundanz verändern werden. Die Innovationen in RedundancyMaster fügen sich nahtlos in Ihre aktuelle OPC-Anwendung, und das Ergebnis ist eine zuverlässigere, kostengünstigere Lösung.

Primäre/sekundäre Gerätenamen

Suchen Sie nach dem primären Gerät, das bevorzugt für die Verbindung mit einem OPC-Server verwendet werden soll, und nach dem sekundären Gerät, das als Ausweichlösung für die Verbindung mit einem OPC-Server verwendet werden soll – wenn mit dem primären Gerät keine Kommunikation möglich ist. Jedes Mal, wenn eine neue Verbindung zwischen dem Client und dem zugrunde liegenden Server hergestellt werden soll, versucht die Anwendung zuerst, eine Verbindung mit dem Server auf dem primären Gerät herzustellen. Falls keine Verbindung mit dem Hauptserver hergestellt werden kann oder die Kommunikation mit dem Hauptserver unterbrochen wird, wird eine Verbindung mit dem sekundären Server hergestellt, wenn es möglich ist. Abhängig vom Verbindungsmodus können Sie die Anwendung so konfigurieren, dass sie automatisch die Kommunikation mit dem primären Gerät herstellt, wenn dieses verfügbar wird.

Verbindungsmodus

Der Verbindungsmodus definiert, wie und wann die Redundanzanwendung eine Verbindung mit dem zugrunde liegenden primären und sekundären Server herstellt. Der verwendete Modus wirkt sich darauf aus, wie viel Zeit bei einem Failover für den Wechsel von einem OPC-Server auf den anderen vergeht. Bei einigen Modi können Sie die Kommunikation automatisch auf den primären Server heraufstufen, wenn dieser verfügbar ist. In den folgenden Abschnitten finden Sie eine Zusammenfassung der Verbindungsmodi:

Kalt (nur aktives Gerät): In diesem Modus stellt die Anwendung immer nur eine Verbindung zu einem zugrunde liegenden Server her. Beim Start wird eine Verbindung zum primären Server hergestellt, und alle Client-bezogenen Anfragen werden an den Hauptserver weitergeleitet. Falls keine Verbindung mit dem primären Server hergestellt werden kann oder die Kommunikation mit dem primären Server unterbrochen wird, wird eine Verbindung mit dem sekundären Server hergestellt. Wenn die Redundanzanwendung mit dem sekundären Server auch keine Verbindung herstellen kann, setzt sie die Versuche – im Wechsel zwischen den beiden Servern – so lange fort, bis eine Verbindung eingerichtet ist.

Der "kalte" Verbindungsmodus minimiert die Menge an zugewiesenen Systemressourcen, da zu jedem Zeitpunkt immer nur eine Verbindung mit einem Server besteht. Außerdem wird der Netzwerkdatenverkehr reduziert, weil das inaktive Gerät nicht zusätzlich zum aktiven abgerufen werden muss, wie es bei anderen Modi der Fall ist. Der Nachteil dieser Einstellung besteht in der Zeitdauer, die bei einem Failover für den Wechsel auf den inaktiven Server vergeht. Wenn eine Unterbrechung der Kommunikation mit dem aktiven Server erkannt wird, muss die Anwendung eine Verbindung mit dem inaktiven Server einrichten, alle Items für den Client abonnieren und die entsprechenden Callback-Mechanismen initiieren.

Warm (beide Geräte abonnieren Items im aktiven Gerät): In diesem Modus versucht die Anwendung, zu jedem Zeitpunkt eine Verbindung mit dem primären und dem sekundären Server aufrechtzuerhalten. Nur die Items im Hauptserver sind aktiv und werden abgerufen. Falls die Verbindung oder die Kommunikation mit dem Hauptserver unterbrochen wird, werden im sekundären Server die gleichen Items wie im primären Server auf aktiv festgelegt. Für beide Server wird regelmäßig mittels Ping überprüft, ob die Verbindung noch besteht.

Eine "warme" Verbindung führt zu einer Erhöhung der zugewiesenen Systemressourcen, da für den Client zwei Serververbindungen hergestellt werden. Sie verursacht außerdem eine kleine Erhöhung des Netzwerkdatenverkehrs, da regelmäßig zwei Server per Ping angesprochen werden, statt nur einer wie im "kalten" Modus. Der Vorteil ist eine Reduzierung der Failover-Zeit im Vergleich zum "kalten" Modus, da die Redundanzanwendung nur Daten-Callbacks an den inaktiven Server initialisieren muss, um Daten zu erhalten. Wenn Sie Datenverlust in Ihrer Anwendung auf ein Minimum beschränken müssen und gleichzeitig den Netzwerkdatenverkehr minimieren möchten, sollten Sie diesen Verbindungsmodus verwenden.

Heiß (beide Geräte abonnieren Items in beiden Geräten): In diesem Modus versucht die Anwendung, zu jedem Zeitpunkt eine Verbindung mit dem primären und dem sekundären Server aufrechtzuerhalten. Beim Start initialisiert die Anwendung Daten-Callbacks für den primären und den sekundären Server, sodass beide Server Datenänderungsbenachrichtigungen senden. Die vom Hauptserver eingehenden Daten werden an den Client weitergeleitet. Falls die Verbindung oder die Kommunikation mit dem primären Server unterbrochen wird, werden sofort die für den sekundären Server eingehenden Daten an den Client weitergeleitet. In beiden Fällen werden Schreibvorgänge nur an den aktiven Server weitergeleitet. Für beide Server wird regelmäßig mittels Ping überprüft, ob die Verbindungen noch bestehen. Wenn die Kommunikation zwischen der Redundanzanwendung und einem der beiden Server unterbrochen wird, versucht die Anwendung regelmäßig, die Verbindung mit dem ausgefallenen Server wiederherzustellen. Diese Einstellung führt zu einer Erhöhung der zugewiesenen Systemressourcen, da für den Client zwei Serververbindungen hergestellt werden. Es gibt auch eine Erhöhung des Netzwerkdatenverkehrs, da Datenänderungsbenachrichtigungen von beiden zugrunde liegenden Servern eingehen und für beide Server regelmäßig mittels Ping überprüft wird, ob sie noch verfügbar sind. Der Vorteil dieser Einstellung besteht darin, dass ein Failover unmittelbar, nachdem der Ausfall des aktiven Servers erkannt wird, erfolgt. Wenn Datenverlust in Ihrer Anwendung von entscheidender Tragweite ist, sollten Sie diesen Verbindungsmodus verwenden.

OPC Server Aliasing (OPC-Server-Aliasing)

Mithilfe dieser Funktion können Sie mehrere Paare von OPC-Servern mit der gleichen Programm-ID konfigurieren. Diese Funktion ermöglicht Ihnen die Verwendung eines Anbieters von OPC-Servern, wenn es in Ihrem Netzwerk mehrere OPC-Serverknoten gibt. Auf diese Weise können OPC-Clients eine Verbindung zu einem bestimmten redundanten Paar herstellen, indem sie auf die Alias-Programm-ID dieses redundanten Paares verweisen.

Always Connect to Primary Machine Upon Availability (Bei Verfügbarkeit immer Verbindung mit dem primären Gerät herstellen)

Bei Auswahl dieser Einstellung kann RedundancyMaster die Kommunikation automatisch zurück auf das primäre Gerät verlegen, wenn der OPC-Server wieder verfügbar ist.

Query Server Status Interval (Intervall für Serverstatusabfrage)

Dieses Intervall (in Millisekunden) bestimmt, wie oft RedundancyMaster für die zugrunde liegenden Server mittels Ping überprüft, ob die Kommunikation unterbrochen wurde. Wenn die Abfrage in kürzeren Abständen erfolgt, können Sie die Failover-Zeit reduzieren, da die Fehlererkennung häufiger durchgeführt wird.

Query Server Status Timeout (Timeout für Serverstatusabfrage)

Dieses Intervall (in Millisekunden) bestimmt, wie lange die Redundanzanwendung auf eine Antwort auf ein Ping von den zugrunde liegenden Servern wartet, bevor sie in Betracht zieht, dass die Kommunikation unterbrochen ist.

Monitoring Settings (Überwachungseinstellungen)

Mithilfe dieser Funktion können Sie bestimmte Bedingungen konfigurieren, die ein Failover auf den inaktiven Server initiieren. Diese Bedingungen ermöglichen die Überwachung von Server-Items auf bestimmte Zustände hin, damit der Status der zugrunde liegenden Server/Geräte ermittelt werden kann. Diese Einstellungen gehen über den automatischen Failover hinaus, der bei der Unterbrechung der Kommunikation erfolgt.

Diagnostics Settings (Diagnose-Einstellungen)

Ereignisse können beim Herunterfahren der Anwendung auf der Festplatte gespeichert werden. Wenn die Anwendung das nächste Mal gestartet wird, werden die Ereignisse angezeigt, und neue Ereignisse werden am Ende der Ansicht angefügt.

Da die Diagnose Arbeitsspeicher- und Speicherressourcen belegt, empfiehlt es sich, die Menge an Diagnose-Daten zu begrenzen, die gleichzeitig gespeichert werden können. RedundancyMaster ermöglicht es Ihnen, einen Höchstwert für die Anzahl der zu erfassenden Ereignisse festzulegen. Bei Erreichen dieses Höchstwertes werden die ältesten Ereignisse verworfen, damit der Wert nicht überschritten wird.

Notifications Settings (Benachrichtigungseinstellungen)

Mithilfe dieser Funktion können Sie einen oder mehrere Empfänger konfigurieren, an den bzw. die E-Mail-Benachrichtigungen bei einem oder mehreren Diagnose-Ereignissen gesendet werden sollen. Die Ereignisse, bei denen E-Mail-Benachrichtigungen gesendet werden können, sind die gleichen Ereignisse, die in der lokalen Ereignisansicht der Diagnose-Einstellungen sichtbar sind.

Anwendungsszenarien

Objekt- und verknüpfungsbasierte Ausfälle mildern

Es gibt viele Variablen, die die Qualität und Zuverlässigkeit Ihrer Daten beeinträchtigen oder zur Unterbrechung der Verbindung zwischen einem OPC-System und einem OPC-Server führen können. In den meisten Fällen liegt es an den folgenden Gründen:

  • Der PC, auf dem der OPC-Server ausgeführt wird, wird heruntergefahren.
  • Der OPC-Server wird aufgrund von Benutzerfehlern beendet.
  • Die Netzwerkverbindung mit dem OPC-Server wird unterbrochen oder ist unzuverlässig.
  • Die Netzwerkeinstellung wird geändert, wodurch ein Verknüpfungsfehler verursacht wird.
  • Der OPC-Server selbst fällt aus irgendeinem – bekannten oder unbekannten – Grund aus.
  • Das Anmeldekonto auf dem PC mit dem OPC-Server wird geändert.

In den meisten der oben genannten Fälle kann der OPC DA-Server aufgrund eines tatsächlichen Fehlers mit dem zugrunde liegenden OPC-Server oder der Verbindung mit diesem Server keine Daten bereitstellen. Fehler dieser Art werden als "objektbasierte" Fehler bezeichnet. Objektbasierte Fehler treten auf, wenn die tatsächliche Verknüpfung zwischen Ihrer OPC-Clientanwendung und dem OPC-Zielserver unterbrochen wird. In diesen Beispielen ist die Software die Fehlerursache. Die Zuverlässigkeit kann jedoch auch durch Ausfälle der physischen Hardware einer Anwendung dramatisch beeinträchtigt werden. Zu diesen physischen Faktoren gehören u.a.:

  • Fehler bei der physischen Verbindung (das Kabel wird abgezogen)
  • Hardwarefehler (Routerfehler)
  • Elektrische Störung (Hochstromentladung)
  • Verzögerungen aufgrund der Signalausbreitung (Funkverbindungen)
  • Umweltfaktoren (Blitzeinschlag)
  • Unfälle (zufällige Ereignisse)

In diesen Fällen kann die virtuelle Verbindung zwischen dem OPC-Server und dem Client vollkommen intakt sein, selbst wenn die physische Verknüpfung zwischen dem zugrunde liegenden Gerät oder System unterbrochen ist. Fehler dieser Art werden als "verknüpfungsbasierte" Fehler bezeichnet. Verknüpfungsbasierte Fehler treten auf, wenn die Verbindung mit dem Zielgerät oder -system getrennt wurde. In den meisten Fällen ist der OPC-Server nach wie vor betriebsbereit, er kann die Daten jedoch nicht für das restliche System bereitstellen.

Zur Vermeidung unnötiger Ausfallzeiten in Ihrem System kann RedundancyMaster für die Überwachung dieser Bedingungen konfiguriert werden – dadurch sparen Sie Zeit und Geld.

Zwei OPC-Server in Verbindung mit RedundancyMaster

Wenn mehrere OPC DA-Clientanwendungen auf einen einzelnen OPC-Server zugreifen, kann ein objektbasierter oder ein verknüpfungsbasierter Fehler auftreten. Wenn der einzelne OPC-Server aus irgendeinem Grund nicht mehr betriebsbereit ist, kann dies zu einem objektbasierten Fehler führen. Und da dieser einzelne PC für die Erfassung der Daten von den zugrunde liegenden Geräten verantwortlich ist, besteht dadurch außerdem ein Single Point of Failure für die Geräteverbindungen.

Um die Zuverlässigkeit des OPC-Systems zu erhöhen, müssen Sie die Single Points of Failure beseitigen, indem Sie das OPC-System entsprechend umändern, sodass mehrere OPC-Server verwendet werden. Jeder OPC-Client wird mit RedundancyMaster gekoppelt, um den redundanten Betrieb der OPC-Server zu ermöglichen.

Mithilfe der konfigurierbaren Optionen innerhalb von RedundancyMaster können der primäre oder sekundäre OPC-Server direkt gesteuert werden. Basierend auf den ausgewählten Modi sorgt RedundancyMaster dafür, dass beide Server aktiv sind, oder startet den sekundären Server, wenn der Hauptserver ausfällt (wenn dies konfiguriert wurde).

Redundanz – lokales Gerät

In diesem Szenario befinden sich der OPC-Client, RedundancyMaster und der sekundäre OPC-Server auf einem lokalen Gerät, und der primäre OPC-Server befindet sich auf einem Remote-Gerät. In so einem Fall ist es wichtig, dass es sich bei dem sekundären OPC-Server um den zuverlässigsten Server handelt. Dieses Szenario verringert die Notwendigkeit, dass der sekundäre OPC-Server auf einem anderen Gerät ausgeführt werden muss.

Redundanz durch mehrere OPC-Serverpaare

RedundancyMaster kann mit mehreren OPC-Serverpaaren konfiguriert werden. In diesem Szenario gibt es zwei Paare von OPC-Servern, die Daten aus zwei getrennten Gerätenetzwerken sammeln. Wenn mehrere OPC-Serverpaare alle die gleiche Programm-ID aufweisen, müssen Sie die Aliasing-Funktion verwenden. Wenn sich die beiden Paare aus verschiedenen OPC-Servern mit unterschiedlichen Programm-IDs zusammensetzen, müssen Sie die Aliasing-Funktion nicht verwenden.

Ressourcen

Verfügbare Sprachen

  • Englisch

Anwendungsunterstützung

  • OPC Data Access (OPC DA) Versions 1.0 and 2.05a

Versionshinweise

2.0.99.0

21.10.2014

Configuration and Runtime

  • Improved the user experience of configuring a project in a Windows UAC-enabled environment by separating the configuration from the runtime service. This improvement applies to the following operating systems:
    • Windows 7 Professional, Enterprise, and Ultimate
    • Windows Server 2008 R2
    • Windows Server 2008
    • Windows Vista Business, Enterprise, and Ultimate
    • Windows 8.1, Windows 8.1 Professional, and Windows 8.1 Enterprise
    • Windows 8, Windows 8 Professional, and Windows 8 Enterprise
    • Windows Server 2012
    • Windows Server 2012 R2
  • The install will now notify users when another application is using the Sentinel HASP hardware key. In order for the Hardware Key to be properly installed, it requires that all Sentinel HASP hardware keys be disabled while the install is running.

2.0.48.0

29.02.2012

  • Fixed an issue where the install failed to detect the previous version which resulted in two installed versions of the product.
  • Fixed an install issue where the legacy project file was not properly migrated to the new version on an upgrade.

2.0.47.0

21.02.2012

  • Initial release of version 2 RedundancyMaster with a stand-alone License Management Utility with enhanced Hardware Key support.

2.0.128.0

02.02.2016

  • Updated the system requirements to reflect the new requirement for Windows XP SP3 or higher (SP2 is no longer supported).
  • Fixed an issue where a graceful shutdown of the primary server could delay switching over to the secondary server.
  • Added return value OPC_STATUS_SUSPENDED for IOPCServer::GetStatus to indicate the service has been stopped.
  • Fixed an issue that was causing the switch over from the secondary server back to the primary server to take longer than expected when the primary was shut down gracefully.
  • Corrected a failed startup that could cause connecting clients to wait indefinitely.
  • Fixed an issue where licenses could show up as expired on some 64-bit machines.
  • Installing on a non-system drive no longer displays a message that the log file could not be converted.
  • Added an option to “Remove User Data” during un-install with the Kepware install executable, which removes all redundant configurations and associated settings (not available through Windows program removal).
  • Corrected an issue where synchronous reads would not succeed for some specific clients.
  • Fixed issues with asynchronous and synchronous reads and writes where the values could be mismapped if invalid and valid tags were in the same tag group.
  • Resolved an issue where certain versions of Kepware OPC client products were not interoperable with RedundancyMaster. This issue was introduced in version 2.0.99.0 of RedundancyMaster.

1.10.54

23.11.2005

  • Added ProgID Aliasing to allow redundancy to be provided to multiple pairs of servers with the same ProgID.
  • Fixed anomaly that occurred when sending an e-mail notification to an SMTP address that specified a DNS name with 'dots' in the name. The application was treating this as an IP address which resulted in a runtime anomaly. (SWTB)
  • Fixed issue with properly updating DCOM configuration when uninstalling as a service.
  • RedundancyMaster will now send IOPCShutdown notifications to clients when the application is terminated by an end-user.
  • Fixed anomaly that occurred when sending an e-mail notification to an SMTP address that contained dots in the address, but was not in the form of an IP address.
  • Added the ability to alias a server's ProgID, so that we can provide redundancy to multiple pairs of servers with the same ProgID.

1.01.41.0

07.01.2005

  • We now properly apply the 'Notifications' settings prior to sending a test e-mail.

1.00.38.0

20.12.2004

Initial Release

  • Fixed issue where -unregister would not uninstall application as an NT service.
  • We no longer post the default monitor item dialog validation box for 'Specific Time Period' trigger.
  • Fixed ability to manually enter in a larger monitor item failure count in the xml file then the number of monitor items defined.
  • Removed monitor test interval, as this can be automatically calculated by the runtime. There are built in precautions so that we do not fail a monitor item test until we receive an initial update on the item.
  • We now force the 'No item changes for a given time period (ms)' trigger data to be at least 2 times the update rate associated with the monitor item. If the trigger data is less an informational prompt notify the user that the value was auto-adjusted will be displayed. Also, care was taken when loading the XML file to enforce this in case it is changed outside of the configuration utility.
  • When a monitor item can not be added, it will now be considered in error.
  • We now prevent entering trigger data that contains non-numeric characters, is empty or is set to less than 10ms for the "Specific Time Period" condition.
  • Fixed the ability to maintain the active connection appropriate machine (primary or secondary) when changin the machine names on the fly in cold mode.
  • Made modification so that there is always a new monitor test after reconnecting to a server.
  • Fixed ability to change machine name on the fly.
  • Fixed repetitive Connect/Disconnect messages when we can successfully connect to the server and call methods, but the server can not initialize a callback back into us.
  • Added ability to save diagnostics to a text file.
  • Added ability to set an update rate on a monitor item.
  • Added support to fallback to 1.0 interfaces for monitor items.
  • Fixed proper assignment of diagnostics events when switching between servers.
  • Added necessary logic to send clients bad quality updates for items when a connection to both primary and secondary servers is lost or can not be made.
  • Fixed issue which would allow a process to unload our runtime dll even if we providing services for the process.
  • Added 'Date' data type support.
  • Added the ability to import the necessary OPC server configuration from a remote machine.
  • Added registry modification log when enabling/disabling redundancy on server(s).
  • Added date as well as time to the e-mail notifications.
  • Added redundant SMTP server support for e-mail notifications.
  • Added error code to string mapper for SMTP errors.
  • Added e-mail notification support.
  • Added the ability to enable/disable the "hooking" of a redundant server.
  • Added tooltip support for the monitor item / diagnostic view list controls.
  • Added support for default canonical datatype.

Betriebssysteme

  • Windows 8
  • Windows 7 Professional/Enterprise/Ultimate
  • Windows Server 2012
  • Windows Server 2008 und 2008 R2
  • Windows Vista Business/Enterprise/Ultimate
  • Windows Server 2003 SP2
  • Windows XP Professional SP3 oder höher

Systemanforderungen

  • 2,0-GHz-Prozessor
  • 1 GB installierter Arbeitsspeicher
  • 180 MB verfügbarer Speicherplatz
  • Ethernet-Karte
  • Super VGA-Videokarte mit 800x600 oder höherer Auflösung

Ende der Lebensdauer

Seit 15. November 2016 wird RedundancyMaster V1 nicht mehr unterstützt. Sie können eine V1-Instanz weiterhin ausführen, erhalten aber keinen technischen Support und keine Software-Patches mehr. Wenn Sie sich über Ihre Upgrade-Optionen informieren möchten, kontaktieren Sie einen Mitarbeiter von Kepware oder Ihren Kepware Partner vor Ort.

Weitere Informationen

Informationen zum Kauf

RedundancyMaster

Subscription

Zahlung einer Jahresgebühr für die Verwendung der Software. Inklusive Support und Wartung.

$680,00/Jahre