Skip to content

TopSolid PDM: Architektur, Konfiguration, Best Practices für Administratoren

 Ein Serverraum

Der PDM-Server von TopSolid ist das funktionale Herzstück jeder kollaborativen Konstruktions- und Fertigungsumgebung auf Basis der Topsolid-Plattform. Trotz seiner zentralen Rolle im täglichen Workflow gilt er vielen Administratoren und Anwendern als diffuse „Blackbox“. Läuft der Dienst reibungslos im Hintergrund, gerät er schnell in Vergessenheit – treten jedoch Performance-Einbrüche, fehlerhafte Backups oder Startprobleme nach Wartungsfenstern auf, steht der gesamte Betrieb still. Ein solides Verständnis der internen Funktionsweise beseitigt Unsicherheiten und ermöglicht es, das System performant abzusichern, Ausfallszenarien vorzubeugen und fundierte Entscheidungen für Infrastrukturfragen wie Homeoffice-Anbindungen zu treffen.

Die Kernarchitektur: Das Zusammenspiel von Vault und SQL-Datenbank

Um administrative Aufgaben wie Backups, Migrationen oder Fehleranalysen sicher durchzuführen, muss man die strikte Trennung zwischen Nutzdaten und Metadaten verstehen. Der TopSolid PDM-Server speichert Informationen niemals an einem einzigen Ort, sondern teilt sie auf zwei klar abgegrenzte Systeme auf.

                   

Der Vault (Tresor)

Im Vault liegen sämtliche Konstruktions- und Fertigungsdaten physisch auf der Festplatte. Wer jedoch nach vertrauten Projekt- und Ordnerstrukturen oder sprechenden Dateinamen wie Baugruppe_01.TopAsm sucht, wird im Dateisystem nicht fündig:

  • Eindeutige Bezeichner (GUIDs): Beim ersten Erstellen eines Bauteils weist TopSolid diesem Dokument eine weltweit eindeutige Kennung (Global Unique Identifier) zu. Diese Kennung bleibt über den gesamten Lebenszyklus des Dokuments unveränderlich – unabhängig davon, wie oft das Bauteil in der Konstruktionsoberfläche umbenannt, in andere Unterordner verschoben oder in andere Projekte transferiert wird. Referenzen zwischen Bauteilen brechen dadurch niemals ab.
  • Revisionsdateien: Jede freigegebene oder zwischengespeicherte Version wird als eigenständige Datei abgebildet. Die Dateinamen enden mit Kennziffern für die Haupt- und Nebenrevision (beispielsweise Major Revision A, Revisionsstand 0 bis 7).
  • Append-Only-Prinzip: Im Vault-Verzeichnis werden bestehende Dateien im regulären Betrieb niemals überschrieben oder inhaltlich modifiziert. Es kommen durch Check-ins neuer Revisionsstände oder neuer Teile ausschließlich neue Dateien hinzu – oder Dateien werden durch explizites Bereinigen des Papierkorbs physisch entfernt. Jede Revisionsdatei repräsentiert einen exakt definierten, zeitlich unveränderlichen Zustand.

Die SQL-Server-Datenbank

Die relationale SQL-Server-Datenbank fungiert als administratives Gehirn des PDM-Systems. Sie enthält:

  • Die Zuordnung der kryptischen GUIDs im Vault zu den in der TopSolid-Oberfläche sichtbaren Namen und Projektpfaden.

  • Vollständige Verwendungsnachweise (welches Bauteil in welcher Revision ist in welcher Baugruppe verbaut?).

  • Benutzerkonten, Gruppenrichtlinien und granulare Zugriffsrechte.

  • Sämtliche Dokumenteigenschaften, Attribute, Bibliotheksdefinitionen und Freigabestatus.

Für Administratoren gilt die Metapher: Der Vault ist das Auto, die SQL-Datenbank ist der Zündschlüssel. Besitzt man nur das Dateisystem ohne Datenbank, hält man gigantische Datenmengen aus unverständlichen Dateifragmenten in der Hand, die sich nicht mehr zusammensetzen lassen. Besitzt man nur die Datenbank ohne Vault, verfügt man über präzise Inhaltsverzeichnisse für Daten, die physisch nicht existieren.

Der Arbeitsdatenfluss: Check-out, Workspace und Check-in

Der Datenaustausch zwischen den CAD-Workstations und dem Serverdienst folgt einem kontrollierten Kreislauf:

  1. Auschecken (Check-out): Öffnet ein Anwender ein Bauteil zur Bearbeitung, meldet der TopSolid-Client den Bedarf an den PDM-Server. Der Server ermittelt in der SQL-Datenbank den aktuellen Revisionsstand, zieht die entsprechende Datei aus dem Vault und überträgt sie an die Workstation.

  2. Lokaler Arbeitsbereich (Workspace): Die Datei wird auf der lokalen Festplatte des Benutzers zwischengespeichert. Jedes reguläre Speichern während der Konstruktionsarbeit schreibt Änderungen zunächst ausschließlich in diesen lokalen Arbeitsbereich.

  3. Einchecken (Check-in): Erst beim Einchecken wird der finalisierte Stand zurück an den Server geschickt. Der Server legt im Vault eine neue Datei mit der nächsthöheren Revisionsnummer ab und vermerkt den neuen Stand samt Zeitstempel und Benutzerkennung in der SQL-Datenbank.

Strategien für eine konsistente Datensicherung

Aus der Doppel-Struktur von Vault und SQL-Datenbank ergibt sich die wichtigste Grundregel für die Datensicherung: Backups müssen atomar und konsistent erfolgen.

Ein weit verbreiteter Fehler besteht darin, den Vault beispielsweise wöchentlich per Dateibackup zu sichern, während die SQL-Datenbank täglich gesichert wird. Fällt das System aus und muss wiederhergestellt werden, passen die Metadaten der Datenbank nicht mehr zum Datenbestand des Vaults. Verweise zeigen ins Leere oder neuere Vault-Dateien werden von der Datenbank als nicht existent ignoriert.

Anforderung Technische Umsetzung Typische Fehlerquelle
Gleichzeitigkeit Einsatz von VSS (Volume Shadow Copy Service), um im exakt selben Moment einen Snapshot von Vault-Volume und SQL-Volume zu erzeugen. Zeitlich versetzte Skripte für Dateisystem und SQL-Dump.
Laufzeit-Sicherung Nutzung professioneller Backup-Lösungen, die den laufenden Betrieb über VSS einfrieren, während im Hintergrund weitergearbeitet wird. Manuelles Kopieren des Vault-Ordners im laufenden Konstruktionsbetrieb.
Sicherungszeitpunkt Durchführung in Randzeiten (Nachtbetrieb), um Schreiblast und Transaktionsvolumen während des Snapshots zu minimieren. Vollsicherungen während der Kernarbeitszeit mit parallelen Groß-Check-ins.
Verifikation Regelmäßige Test-Restaurierung auf einem separaten Test-Server (Disaster-Recovery-Probe). Unbemerkte Medienfehler, korrupte Archive oder fehlende Lesezugriffsrechte.

Ein Backup gilt erst dann als existent, wenn die erfolgreiche Wiederherstellung auf einem parallelen Testsystem mindestens einmal vollständig durchgespielt und verifiziert wurde.

 

Konfiguration und Performance-Tuning im PDM-Server-Manager

Die Verwaltung des Dienstes erfolgt über den PDM-Server Manager. Einige Kernparameter haben wichtige Auswirkungen auf Sicherheit und Durchsatz.

Dienstkonten und SQL-Berechtigungen

Standardmäßig wird der Windows-Dienst häufig unter dem Local System Account eingerichtet. Aus Sicht der IT-Sicherheit ist das ein Risiko, da dieser Account über uneingeschränkte administrative Rechte auf Betriebssystemebene verfügt.

  • Best Practice: Richten Sie für den TopSolid PDM-Dienst ein dediziertes, nicht-privilegiertes Dienstkonto ein.

  • SQL-Rollenanforderung: Dieses Dienstkonto benötigt auf SQL-Ebene die Serverrolle sysadmin, um bei Bedarf neue Datenbanken initial anlegen und konfigurieren zu können.

  • Datenbankebene: Auf der konkreten PDM-Datenbank muss das Dienstkonto zwingend als db_owner eingetragen sein, um Tabellenstrukturen zu modifizieren, Indizes zu pflegen und Lese-/Schreiboperationen uneingeschränkt auszuführen.

Speicherort des Vaults: Lokale Datenträger vs. Netzlaufwerke

In den Einstellungen der Vaults (Vaults / Add Vault) verlangt das System zwingend Pfade auf lokalen physischen oder virtuellen Festplatten des Server-Hosts.

Netzlaufwerke (SMB/UNC-Pfade) sind ausnahmslos unzulässig. Netzwerkfreigaben unterliegen unberechenbaren Latenzen und bieten keine zuverlässige Garantie für die atomare Schreibbestätigung von Dateizugriffen. Im Worst-Case droht bei Netzwerk-Timeouts Datenverlust oder eine Korrumpierung des Vault-Bestands.

Für Unternehmen mit mehreren Standorten bietet TopSolid ein Multi-Vault-Konzept: Während am Hauptstandort PDM-Dienst und SQL-Datenbank laufen, kann an einer Außenstelle eine Instanz im Modus File Server only betrieben werden. Dieser lokale Fileserver hält häufig genutzte Vault-Daten der Außenstelle vor Ort, synchronisiert die Metadaten jedoch zentral mit dem Hauptserver.

Kommunikationsprotokolle und Firewall

Moderne TopSolid-Versionen (ab Version 7.18) nutzen für die Kommunikation zwischen Client und Server ein zustandsloses Protokoll auf Basis von HTTP bzw. HTTPS.

  • Vorteil: Früher führte jeder kurze Neustart des PDM-Servers dazu, dass sämtliche Client-Verbindungen abbrachen und alle Konstrukteure abgemeldet wurden. Mit dem modernen Protokoll können Konfigurationsänderungen oder Server-Neustarts in wenigen Sekunden erfolgen; solange ein Anwender in diesem Intervall keine Check-in- oder Check-out-Operation anstößt, bemerkt er den Neustart in der Praxis nicht.

  • Ports und Verschlüsselung: Standardmäßig lauscht der Dienst auf TCP-Port 8086. Für moderne Umgebungen empfiehlt sich die Umstellung auf HTTPS mit einem vertrauenswürdigen SSL/TLS-Zertifikat, um Identitätsdiebstahl im Netzwerk zu verhindern und den Datenstrom abzusichern.

 

„Zentralisierter Arbeitsbereich“: Fluch oder Segen?

In der erweiterten Konfiguration (Advanced Management) findet sich die Option „Use centralized workspace“. Sie entscheidet grundlegend darüber, wie die Datensicherung auf Konstruktionsebene funktioniert.

Deaktivierter zentraler Workspace (moderner Standard)

Änderungen werden bei jedem Zwischenspeichern ausschließlich auf der lokalen Festplatte der Workstation gesichert. Erst beim Check-in fließen die Daten über das Netzwerk in den Vault.

  • Vorteil: Maximale Arbeitsgeschwindigkeit. Lokale NVMe-SSDs verarbeiten auch komplexe Baugruppen im Werkzeug- und Formenbau ohne Verzögerung.

  • Nachteil: Wird die lokale Festplatte des Konstrukteurs vor dem Einchecken beschädigt, sind die Zwischenstände seit dem letzten Check-in verloren.

Aktivierter zentraler Workspace (historischer Standard)

TopSolid speichert lokal und sendet bei jedem einzelnen Speichervorgang (Strg + S) parallel eine Kopie der Arbeitsdaten über das Netzwerk an einen Workspace-Spiegel auf dem PDM-Server.

  • Vorteil: Bricht die Hardware der Workstation zusammen, liegt ein Abbild des letzten Speicherstands auf dem Server. Zudem kann ein Konstrukteur den Arbeitsplatz wechseln und findet seinen Workspace synchronisiert vor.

  • Nachteil: Netzwerklast. Große Spritzguss- oder Folgeverbundwerkzeuge umfassen schnell mehrere hundert Megabyte. Diese Datenmenge muss bei jedem Zwischenspeichern vollständig durch das Netzwerk geschleust werden, was den Konstruktionsfluss spürbar ausbremst.

Wichtiger Praxishinweis: In Szenarien mit Homeoffice, mobilen Workstations oder VPN-Verbindungen muss der zentrale Workspace dringend deaktiviert werden. Die geringe Bandbreite von VPN-Tunnels führt bei aktiviertem zentralen Workspace zu massiven Ladezeiten und Programmblockaden beim Speichern.

 

Erweiterte Wartungswerkzeuge: Integritätsprüfungen und Dateisuche

Der PDM-Server bringt Diagnosewerkzeuge mit, die Administratoren bei Inkonsistenzen einsetzen können:

  • Check Database Integrity: Überprüft die logische Konsistenz der SQL-Tabellen. Es wird kontrolliert, ob alle Bauteilreferenzen gültig sind und verwaiste Datensätze vorliegen. Dieser Vorgang ist schlank und dauert in der Regel wenige Sekunden bis Minuten.

  • Check Files Integrity: Liest jede einzelne Datei im Vault ein, prüft deren Lesbarkeit und gleicht Dateigröße sowie Prüfsumme mit den Metadaten der SQL-Datenbank ab. Bei gewachsenen Vaults mit mehreren hundert Gigabyte Datenvolumen beansprucht dieser Vorgang erhebliche I/O-Ressourcen und sollte ausschließlich außerhalb der Betriebszeiten gestartet werden.

  • Search Missing Files: Untersucht gezielt, ob für jeden registrierten Datenbankeintrag das entsprechende Revisions-Dokument im Vault existiert. Sollte durch Dateisystemfehler, versehentliches Löschen oder Speicherüberläufe eine Lücke entstanden sein, generiert das System einen strukturierten Textbericht, mit dem fehlende Dokumente gezielt aus Backup-Archiven rekonstruiert werden können.

 

Der Neustart-Klassiker: Windows-Dienstabhängigkeiten automatisieren

Ein bekanntes Problem nach Windows-Updates oder Server-Neustarts: Das Betriebssystem fährt hoch, der TopSolid PDM-Dienst meldet einen Fehler und startet nicht. Die Ursache liegt meist nicht an fehlerhaften Microsoft-Patches, sondern an einer Race Condition beim Systemstart. Windows startet automatisch konfigurierte Dienste parallel und ohne feste Reihenfolge. Versucht der PDM-Dienst zu starten, bevor die zugrundeliegende SQL-Server-Instanz einsatzbereit ist und Anfragen beantwortet, schlägt die Initialisierung fehl. Da die grafische Verwaltungskonsole von Windows (services.msc) keine interaktive Konfiguration von Abhängigkeiten erlaubt, muss dies administrativ per Skript gelöst werden.

Lösung per Batch-Skript

Ermitteln Sie die exakten Dienstnamen in den Diensteigenschaften (beispielsweise MSSQL$SQLTOPSOLID für die benannte SQL-Instanz und TopSolid PDM Server 7.20 für den PDM-Server).

Legen Sie eine Batchdatei mit folgendem Befehl an und führen Sie diese mit Administratorrechten aus:

sc config "TopSolid PDM Server 7.20" depend= "MSSQL$SQLTOPSOLID"

(Hinweis zur Syntax: Das Leerzeichen direkt nach depend= ist für den Windows-Befehl sc zwingend erforderlich).

Nach der Ausführung wartet Windows beim Bootvorgang ab, bis die SQL-Datenbank erfolgreich gestartet ist, bevor der PDM-Serverdienst gestartet wird.

Achtung bei Service-Pack-Installationen: Bei der Aktualisierung des PDM-Servers über TopSolid-Service-Packs wird der Dienst unter Windows typischerweise deinstalliert und neu registriert. Dabei gehen manuell definierte Dienstabhängigkeiten verloren. Deponieren Sie das Skript auf dem Server-Desktop und führen Sie es nach jedem Service-Pack-Update erneut aus.

 

PDM-Server in der Cloud: Potenziale und Hürden

Viele Unternehmen erwägen, ihre On-Premises-Infrastruktur aufzugeben und den PDM-Server bei Anbietern wie Microsoft Azure, AWS oder Google Cloud zu hosten, um Wartungskosten zu reduzieren und verteilten Teams standortunabhängigen Zugriff zu ermöglichen.

Technisch lässt sich der PDM-Server auf virtuellen Cloud-Maschinen betreiben – der kritische Engpass liegt jedoch in der Lizenzierung:

  • Hardware-Dongles: Cloud-Hyperscaler betreiben hochgradig standardisierte Rechenzentren, in denen das Einstecken physischer USB-Lizenz-Dongles kategorisch ausgeschlossen ist.

  • Virtuelle Hardware-IDs (MAC-/Machine-IDs): Lizenzierungen über Rechner- und Netzwerkkarten-Identifikatoren geraten in Cloud-Umgebungen schnell an Grenzen. Virtuelle Maschinen werden von Cloud-Anbietern bei Host-Ausfällen oder Ressourcenoptimierungen dynamisch im laufenden Betrieb auf andere physische Knoten verschoben. Verändert sich dabei die zugrundeliegende virtuelle Hardware-Signatur, wird die TopSolid-Lizenz ungültig.

  • Ausblick auf Cloud Licensing: Reseller nutzen bereits TopSolid-eigene Cloud-Lizenzsysteme, die Lizenzen dynamisch über HTTPS aus einem Pool zuweisen. Solange dieses softwarebasierte Lizenzmodell für industrielle Endkunden noch nicht flächendeckend freigegeben ist, erfordert ein stabiler Cloud-Betrieb oft dedizierte physische Server (Bare-Metal-Instanzen) – was den Kostenvorteil gegenüber klassischer Vor-Ort-Hardware deutlich schmälert.

Administrator-Leitfaden für den PDM-Betrieb

Der TopSolid PDM-Server ist ein robustes, wartungsarmes Werkzeug, wenn seine architektonischen Eigenheiten respektiert werden. Ein stabiler Betrieb stützt sich im Kern auf vier Säulen:

  • Konsistenz vor Geschwindigkeit beim Backup: Vault und SQL-Server immer als zeitgleichen VSS-Snapshot sichern und Wiederherstellungen turnusmäßig üben.

  • Keine Experimente beim Speicherort: Lokale NVMe-/SSD-Datenträger für den Vault nutzen und Netzwerkfreigaben vermeiden.

  • Workspace-Konfiguration prüfen: Den zentralisierten Workspace deaktivieren, um den Netzwerktraffic zu entlasten – insbesondere bei der Arbeit über VPN.

  • Dienst-Start absichern: Nach jedem Software-Update die Windows-Dienstabhängigkeiten zwischen SQL- und PDM-Server kontrollieren.

Mit diesem Setup ist das PDM-System optimal gerüstet für hohe Datenmengen, maximale Ausfallsicherheit und einen reibungslosen Workflow in der Konstruktion

 

Mehr zu diesem Thema, finden Sie in unserer TopSolid Sprechstunde