Siemens NX-Lizenzierung

Das Lizenzmanagement von Siemens NX-Lizenzen ist vielen Wechseln unterworfen und stellt Lizenzmanager auch aktuell vor einige Herausforderungen. Ob SALT oder Siemens NX Token Licensing, neue Versionen bedeuten für Firmen häufig fehlerhafte Auswertungen zur Lizenznutzung und Mehrausgaben, da sich beispielsweise Token Pakete ändern und Features nicht mehr genau zuweisbar sind.

Deshalb haben wir für unsere Kunden im Juli einen interaktiven Workshop zum Thema „Siemens NX-Lizenzierung“ durchgeführt. Schwerpunkt war der Austausch mit unseren Kunden über deren Einsatz von Siemens NX-Lizenzen. Wir sprachen über aktuelle technische Herausforderungen und Lösungsansätze. Im folgenden Blogbeitrag wollen wir dies näher beleuchten.

Siemens NX-Lizenzierung im Wandel der Zeit

Ursprünglich war NX ein Produkt der Firma Unigraphics und entsprechend spiegelte sich das auch bei der Bezeichnung der Tools wider. Der Lizenzierungsverwaltungs-Daemon trug anfangs beispielsweise den Namen UniGraphics Licensing Management Daemon, kurz „uglmd“. Bei der Übernahme durch SIEMENS wurde er umbenannt in „ugslmd“, wobei „uglmd“ vereinzelt weiter im Einsatz ist.

Im Jahr 2021 führte Siemens ein Token-Lizenzierungsmodell ein. Das sogenannte „Value Based Licensing“ ist eine flexible Methode, um Module über „Pay per Use“ nutzen zu können, die im Standardumfang nicht enthalten sind oder welche nicht genügend lizensiert wurden. In der Praxis ergaben sich fürs Lizenzmanagement daraus allerdings einige Schwierigkeiten.

Anfang 2024 hat Siemens Digital Industries zudem begonnen, seine Produkte auf ein neues Lizenzierungsmodell umzustellen. Dazu gehören eine neue Lizenzierungssoftware, neue Lizenzdateien und neue Methoden zur Einrichtung der Lizenzierung. Die Einführung war nicht ganz einfach und hat viele Probleme bereitet, sowohl bei der Softwarenutzung als auch beim Monitoring.

Die neue Siemens Lizenzmanagement Technologie SALT

Die neue Lizenzmanagementtechnologie SALT umfasst ein komplettes Lizenzierungsmodell auf der Basis von Revenera’s FlexNet sowie eine neue Lizenzierungs-API für Siemens EDA- und PLM-Anwendungen. Dazu gehört ebenso die Unterstützung für Anwendungen zur Nutzung der SALT-API mit mgcld-, ugslmd- und saltd-Anbieter-Daemons und -Lizenzen. Hierfür gibt es einen Lizenzserver, den Siemens License Server (SLS) und einen Installer, der sowohl ältere Mentor- und Siemens-Anbieter-Daemons (mgcld und ugslmd) als auch einen neuen Anbieter-Daemon (saltd) unterstützt.

Saltd: Lizenzwächter und Standard-Daemon

Der Vendor-Daemon saltd hat eine doppelte Funktion. Zum einen ist er der Vendor-Daemon für das Siemens Advanced Licensing Toolkit (saltd). Zum anderen ist er auch eine Art Lizenzwächter, da er durch die Common Vendor Daemon-Funktionalität die anderen Vendor-Daemon-Lizenzdateien bedienen kann. Hierzu gehören:

• Common Licensing Toolkit (CLT) – (ugslmd) *
• Mentor-Standard-Lizenzierung (MSL) – (mgcld)
• Simcenter STAR-CCM+/SPEED/STAR-CD/BDS- (cdlmd)
• Simcenter HEEDS – (RCTECH)

* unter anderem bei NX, Simcenter 3D, Teamcenter, Fibersim, Tecnomatix und Plant Simulation im Einsatz

Beim Auslesen der Lizenzfiles in OpenLM führt dies allerdings dazu, dass unter Vendor bereits „saltd“, bei den Packages und Features aber weiterhin „ugslmd“ steht. OpenLM liest sowohl das Lizenzfile als auch die Log Files und den lmutil / lmstat Output und kombiniert dann alle Infos. Dies hatte zur Folge, dass bei OpenLM keine Denials mehr reported werden konnten. Im April hat OpenLM nun zunächst für ugslmd eine Lösung umgesetzt.

Herausforderungen durch die NX-Token-Lizenzierung

Bereits seit August 2021 ist die Auswertung von Siemens NX Token in OpenLM möglich. Seither konnten wir mit unseren Kunden viel Erfahrung mit dem Monitoring und der Auswertung der NX Token Lizenzen sammeln und einige Lösungen für Token-spezifische Probleme erarbeiten.

Wechselnde Token Pakete/ Versionen

Aktuell gibt es drei Siemens NX Token Pakete: Simcenter Tokens, Design Tokens sowie Manufacturing Tokens. Der Umfang bzw. der Inhalt in diesen Token Paketen ändert sich allerdings von Version zu Version. Das wiederum stellt eine Herausforderung bei der späteren Auswertung dar, da die Features/ Packages aus den Lizenzfiles nicht mehr übereinstimmen. 

Workaround: In NX kann man sich die aktuellen Features über Help -> About anzeigen lassen und die OpenLM json Files im config Verzeichnis der OpenLM Installation entsprechend anpassen.

Steuerung der Token-Features Nutzung

Ein weiteres Problem ist, dass sich die Token-Features nicht über das Options File steuern lassen, da die Token-Features nicht im Lizenzfile enthalten sind. Deshalb limitieren einige unserer Kunden die maximale Anzahl an Tokens für jeden User, um so wieder eine gewisse Steuerung der Lizenznutzung zu ermöglichen. So können Features, die diese Limitierung an Tokens überschreiten würden, nicht genutzt werden.

Sichtbarkeit von Lizenzen für Features

In OpenLM lassen sich die Features der gezogenen Tokens ablesen. Dabei ist zu beachten, dass die Tokens und die Features in zwei verschiedenen Zeilen erscheinen. So würde zum Beispiel das Feature „adv_assemblies“ in der ersten Zeile erscheinen und unterhalb dazu die Tokens „nx_design_tokens“. Sollte es hierbei Probleme geben, kann man auch hier die json Files aktualisieren und die jeweiligen Features einfügen/ergänzen.

Token Freigabe für Features

Das Token Konzept von Siemens sieht vor, dass beim Starten eines Features in NX die Tokens gezogen werden, und wenn der Nutzer das Feature wieder schließt, diese Tokens wieder freigegeben und in den Pool zurückgegeben werden. In der Praxis hat sich gezeigt, dass das bei vielen unseren Kunden so nicht funktioniert. Häufig muss hierfür die komplette NX Software geschlossen werden. Von den Nutzern kann man aber natürlich nicht verlangen, dass sie nach jedem Feature-Wechsel die ganze Applikation beenden sollen. Außerdem werden bei manchen unserer Kunden Tokens gezogen, bei denen nicht nachvollziehbar ist, aus welcher Funktion heraus genau diese Tokens verwendet werden.

Workaround: Es empfiehlt sich, den Nutzern nahezulegen, dass sie zumindest am Abend NX schließen sollten. Dies könnte man auch per Active Agent Push-Up Notification umsetzen.