Search for:

Type your search term and press [Enter]

Das Configit Technology Center

Herr Rasmussen, was ist Ihre aktuelle Funktion bei Configit?

Ich bin Mitglied des Technology Centers (TC), eines Teams, das sich mit unserer Kerntechnologie beschäftigt. Im Bereich der Software zählen dazu die Compiler, die Configit Runtime und viele erweiterte Funktionen der Configit Runtime wie Stücklistenanalyse oder Prüfung von Stücklisten auf Regeln.

Wie lange arbeiten Sie schon in dieser Funktion?

Ich arbeite seit der Gründung von Configit vor 15 Jahren an unserer Kerntechnologie, das TC als Konzept oder Team gibt es aber erst seit ca. einem Jahr.

Mit dem TC konzentrieren wir uns wieder auf die Kerntechnologie. Generell geht es uns nicht nur um die Anwendungsmöglichkeiten unserer Technologie, sondern auch um eine Erweiterung unserer technologischen Präsenz.

Können Sie uns einige aktuelle Initiativen des TC nennen?

Wir entwickeln zurzeit eine Neuimplementierung bestehender Lösungen, um leichter zugängliche APIs (nicht Komponenten) zu schaffen, die unsere Möglichkeiten erweitern. Dazu gehört zum Beispiel die Möglichkeit von Analysen wie etwa Stücklistenprüfungen, die über die reine Kompilierung und Konfiguration hinausgehen.

Es gibt auch neue Anwendungsmöglichkeiten für Produktmodelle. Man kann nun nicht mehr nur nach gültigen Kombinationen suchen, sondern auch anspruchsvollere Fragen stellen.

Sie haben von einer Neuimplementierung bestehender Funktionalitäten gesprochen. Können Sie das weiter ausführen?

Bisher hatten wir einen stapelorientierten Konfigurationsansatz. Er beinhaltet einerseits Werkzeuge zur Definition von Produktmodellen und einen Compiler, der die Produktmodelle in VT-Dateien konvertiert, und andererseits eine Anwendung, die die VT-Dateien in die Runtime lädt. Das sind zwei verschiedene Schritte.

Im Rahmen der Neuimplementierung fassen wir diese beiden Schritte zusammen. Eine strenge Unterscheidung zwischen Kompilierung und Runtime ist nun nicht mehr erforderlich. Einige Operationen müssen noch kompiliert werden, bevor die Daten verwendet werden können, doch wird dabei ein umfassenderer Ansatz verwirklicht. Bei der Modellierung möchte man oft wissen, was die einzelnen Regeln beinhalten – etwa, ob man andere Regeln verletzt oder eine andere Ansicht des Lösungsraums erhalten kann. Wir stellen uns das als geschlossenen Kreislauf aus Zusammenstellung, Kompilierung und Verwendung von Daten vor. Bei der Zusammenstellung von Daten möchte man sie in der Regel schnell kompilieren und verwenden, um die Auswirkungen zu sehen. Die Neuimplementierung bietet eine einheitliche Lösung mit einem geschlossenen Kreislauf anstatt einer Lücke zwischen Zusammenstellung und Verwendung.

Könnte man sagen, dass pmc (Product Model Compiler), Runtime und Configit Model in einer einzigen Einheit zusammengefasst werden?

Technologisch gesehen ja. Im Grunde bündeln wir alle verfügbaren Funktionen in einem Paket, in dem Kompilierungs- und Laufzeitschritte integriert sind. Typischerweise findet man kaum Analysen und Erklärungen für Fehler in neuen Regeln oder Zuweisungen, die sich anders als erwartet verhalten. Unser Ziel ist es, eine Lösung für alle unsere Produkte zu entwickeln: Model, Ace und Build sowie eingebunden in andere zukünftige Produkte von Configit.

Wird diese Implementierung einen offiziellen Namen haben?

Ja. Der Arbeitstitel lautet „Configit Core“, intern „Noddy“. Das hat historische Gründe. Vor der Gründung von Configit entwickelte ein brillanter Programmierer ein BDD-Paket namens „Buddy“. Daraus wurde bei uns „Cuddy“, wobei das C für Configit stand, und schließlich „Noddy“. Noddy dient immer noch als Modul auf der untersten Ebene von Configit Core. Vereinfacht ausgedrückt, führt Noddy BDD-Operationen aus und bildet die Grundlage für alles, was wir bei Configit machen. Darüber liegen zahlreiche weitere Schichten für das Authoring und Composing (wobei die Eingabe im Text-, BDD- oder in einem anderen Format erfolgen kann), für die Konfiguration und für die Runtime.

Welche Kunden sollen mit Configit Core vor allem angesprochen werden?

Core soll die Integration der Technologien in Ace weiter verbessern. Technisch gesprochen wird Core zunächst von Ace verwendet. Bei einigen Projekten wurden aber auch schon Kundendaten so aufbereitet, dass sie sich konfigurieren und an die Endkunden weitergeben ließen. Mit Core muss man die Kundendaten vor der Konfiguration nicht mehr in Configit Model importieren, erneut exportieren und durch den pmc laufen lassen, um eine VT-Datei zu erhalten, sondern kann die Daten nahtlos konfigurieren.

Nutzer von Configit Core

Wird Core bereits von Ace genutzt?

Ja.

Welche Beispiele können Sie uns nennen?

Aus Vertraulichkeitsgründen wollen wir von „Kunde A“ und „Kunde B“ sprechen. Kunde A strebt eine Kompletteinführung von Ace an, möchte jedoch Inhalte aus einem anderen Authoring-Werkzeug für die Konfiguration verwenden. Die Verbindung zwischen dem Produktwerkzeug des Kunden und der Konfiguration wird durch Core hergestellt. Die Eleganz dieses Ansatzes besteht darin, dass der Kunde heute sein eigenes Authoring-Werkzeug und morgen Ace einsetzen kann und dabei mit derselben Dienstfunktion Konfigurationen verwenden und Lösungen ausführen kann. Mit Core kann er die künftige Lösungsfunktion in Ace nutzen.

Kunde B ist ebenfalls interessant, da er völlig andere Anforderungen hat. Der Kunde hat keinen Konfigurationsbedarf. Stattdessen verfügt er über ein PLM-System, das unter anderem Regelkonzepte für das Schreiben und Editieren und die Überwachung des Änderungsmanagements beinhaltet. Das PLM-System kümmert sich aber nicht sonderlich um Regeln. Der Kunde möchte wissen, ob seine Regeln konsistent und plausibel sind, wie sie sich einsetzen lassen, ob sie korrekt aussehen und ob die Stücklisten abgestimmt sind. Unsere Aufgabe besteht im Wesentlichen darin, die Systemregeln des Kunden auf Inkonsistenzen zu überprüfen und entsprechende Berichte zu erstellen. Dazu extrahieren wir die Regeln mit Core und kompilieren sie ins neue VT-Format von Core. Anstatt eine Konfiguration durchzuführen, prüfen wir dann, ob die Regeln korrekt sind, ob die Werte und Intervalle möglich sind, ob Inkonsistenzen vorliegen usw.

Was sich konfigurieren lässt, lässt sich auch bauen

Sie haben Lösungs-, Konfigurations- und Analysefunktionen erwähnt. Können Sie uns auch etwas über Stücklistenfunktionen sagen?

Die Stücklistenprüfung zählt zu den fortschrittlichsten Analysefunktionen, die Configit verwendet. Die Herausforderung bei der Arbeit mit Konfigurationsdaten besteht oft darin, dass Vertriebs-, Konstruktions- und Fertigungsfaktoren getrennt voneinander definiert sind.

Ace ermöglicht es, die Absichten des Marketing mit denen der Konstruktionsabteilung zu verbinden. Die Marketingobjekte, Zielmärkte und Marketingzeiten und die technischen Anforderungen werden gleichzeitig erfasst. Bei der Auswahl von Merkmalen erhält der Nutzer somit automatisch alle zugehörigen Anforderungen. Dabei müssen Angebot und Fertigungsmöglichkeiten miteinander in Einklang gebracht werden.

Hierzu können wir anhand der Definitionen aller Teile, aus denen ein Produkt bestehen kann, eine „Maximalstückliste“ erstellen und diese mit allen Vertriebs- und Konstruktionsregeln für das Produkt abgleichen. So stellen wir sicher, dass sich alles, was sich konfigurieren lässt, auch bauen lässt.

Die Teile eines Produkts werden in Komponenten (Stücke) aufgeteilt. Wir können gewährleisten, dass es für jede gültige Konfiguration genau ein Teil in jeder Komponente gibt und wir keine unvollständigen oder fehlerhaften Endprodukte erstellen.

Underengineering und Overengineering

Wie nennen Sie es, wenn eine Stückliste diesen Anforderungen nicht entspricht?

Dann sprechen wir meist von Underengineering. Dazu kommt es, wenn Ingenieure „vergessen“ zu beschreiben, wie eine bestimmte Konfiguration umzusetzen ist.

Um die Sache noch komplizierter zu machen, muss der Faktor Effektivität ebenfalls berücksichtigt werden, da verschiedene Teile in verschiedenen Komponenten einander zu verschiedenen Zeitpunkten ersetzen und sich die Gültigkeit der Konfigurationen im Laufe der Zeit ändert. So gibt es zum Zeitpunkt eines Auftrags keine Garantie, dass er zu einem bestimmten Zeitpunkt gefertigt werden kann. Dennoch muss die Teilstückliste im Hinblick auf einen bestimmten Zeitpunkt geprüft werden, nämlich den voraussichtlichen Fertigungstermin. (Die Teilstückliste erhält man, wenn man die Konfiguration auf die Maximalstückliste anwendet. Sie enthält die Teile, die für die Fertigung der Konfiguration benötigt werden.) Zu Komplikationen kann es kommen, wenn ein Auftrag umterminiert wird. Wenn sich die Ausführung eines Auftrags ganz oder teilweise verzögert, müssen die entsprechenden Teile neu berechnet oder neu bestätigt werden. Es kann sogar notwendig sein, die Konfiguration der Teile zu ändern. Stücklisten lassen sich aber nicht für jeden einzelnen Zeitpunkt neu konfigurieren oder auflösen, was die Fertigung erschwert.

In solchen Fällen gewährleisten wir, dass die Kriterien für die Stückliste für jedes Produkt gelten, das sich zu irgendeinem Zeitpunkt konfigurieren lässt.

Underengineering ist deshalb interessant, weil die Unternehmen garantieren wollen, dass bestellte Produkte auch gefertigt werden können. Es gab bereits Fälle, in denen Produkte bestellt und konfiguriert wurden, aber wegen fehlender Teile nicht gefertigt werden konnten.

Ein weiteres Problem ist Overengineering. Overengineering liegt vor, wenn einem Teil unter bestimmten Bedingungen eine bestimmte Stelle in der Stückliste zugewiesen wird. Ein Beispiel aus der Automobilindustrie: Ein Unternehmen führt einen neuen beheizbaren Sitz, eine automatische Temperaturregelung und vielleicht noch andere moderne Komponenten ein. Die entsprechende Kombination wird jedoch nicht zugelassen. Ein Teil – zum Beispiel der neue beheizbare Sitz – kommt dann nicht zum Einsatz und ist damit nutzlos. Die Bedingungen erscheinen zwar korrekt, verursachen jedoch erhebliche Kosten. Wird ein Teil nicht verwendet, verschwenden Ingenieure Zeit mit dem Aufstellen unlösbarer Rätsel und anschließend mit dem Versuch diese zu lösen. Die Prüfung auf Overengineering ist im Grunde nur eine Plausibilitätsprüfung auf Gültigkeit der Stückliste.

Stücklistenprüfung

Was sind die Hauptschwierigkeiten bei der Stücklistenprüfung?

Vielen Kunden fällt es schwer, die Bedeutung dieser Art von Technologie zu verstehen. In der Automobilindustrie kennt man die damit verbundenen Probleme und findet sich damit ab, d.h. unternimmt nichts dagegen, oder entwickelt individuelle Lösungen auf Basis von Brute-Force-Prüfverfahren bzw. lässt die Stücklistendefinitionen von den Ingenieuren überprüfen. Dass dieser Prozess vollständig automatisch ablaufen kann, klingt oft noch wie Zukunftsmusik.

Eignet sich die Automobilindustrie Ihrer Meinung nach am besten für die Einführung einer Stücklistenprüfung und -analyse?

Die Automobilindustrie eignet sich dafür gut, denn Lösungsraum-Management oder Stücklistenprüfungen sind nur unter bestimmten Voraussetzungen sinnvoll: Es muss ein hochgradig konfigurierbares Produkt mit einer modernen Stückliste vorliegen. Das ist bei PKW, LKW und vielen Nutzfahrzeugen der Fall. Oft werden aber auch Auftragskonstruktionen (Engineer-to-Order, ETO) ausgeführt. Zahlreiche LKW-Hersteller akzeptieren sie in großem Umfang, obwohl sie vielleicht eine (konfigurierbare) Maximalstückliste haben. In diesem Fall erfordert ein Großteil der Aufträge spezielles Engineering und dient die Stückliste lediglich als Richtlinie.

Haben andere Industriezweige ähnliche Anforderungen?

Der Ansatz bleibt derselbe, aber die Konfigurierbarkeit von Maximalstücklisten unterscheidet sich von Unternehmen zu Unternehmen. Im Falle von Pumpen etwa sind sie weniger konfigurierbar. Pumpenanbieter verfügen über ein breites Produktspektrum, stehen jedoch bei der Konfiguration oft vor der Herausforderung, das richtige Produkt zu finden und die Optionen dann an das Produkt anzupassen. Die Automobilindustrie bietet weniger, aber konfigurierbarere Produkte an. Die Herausforderungen bleiben jedoch dieselben.

Configuration Lifecycle Management (CLM)

Ist CLM in der Automobilindustrie sinnvoll?

CLM beginnt in den frühen Phasen eines Produktlebenszyklus. Wir wollen uns hier speziell mit der Konstruktionsphase befassen. Ich habe vorhin über die Verbindung von Vertrieb und Fertigung gesprochen, aber in der Konstruktionsphase geht es nicht darum, welche Produkte vertrieben werden können. Das ist Aufgabe des Vertriebskonfigurators. In dieser Phase verwenden wir die Engineering-Stückliste (E-BOM), die meist die Grundlage für die anderen Stücklisten bildet (Vertriebsstückliste, Fertigungsstückliste, Ersatzteilstückliste usw.). Mit der E-BOM fängt alles an. Die E-BOM drückt aus, wie die Ingenieure ihre Produkte sehen, und es ist in der Regel diese Liste, die von uns geprüft wird. Wenn wir über Stücklistenprüfung sprechen, wissen unsere Kunde, dass wir damit die frühen Phasen meinen, in denen die Produkte definiert werden, und nicht die späteren Vertriebsphasen, die in der Regel gemeint sind, wenn von Konfiguration die Rede ist.

Lösungsräume

Inwiefern kann Configit als Vorreiter gelten?

Unsere Technologie ist einmalig in der Branche. Im Unterschied zu anderen Konfigurationsanbietern sind wir in der Lage, mit Lösungsräumen zu arbeiten. Dieser Ansatz mag sich auf den ersten Blick nur in Nuancen von anderen Ansätzen (z. B. Constraint Solvern) unterscheiden. Der große Unterschied besteht jedoch darin, dass wir den Lösungsraum für den Vertrieb mit dem Lösungsraum für die Konstruktion vereinen und mit Lösungsräumen für Kunden abgleichen können. Andere Konfigurationstechnologien können teilweise das Gleiche, aber unsere Technologie hat den Vorteil, dass sie dieser Herausforderung bestens gerecht wird. Letztendlich geht es darum, Überschneidungen und Lücken in Lösungsräumen zu finden, und dafür ist unsere VT-Technologie sehr gut geeignet.

Könnte man sagen, dass herkömmliche Technologien mit Punkten in Lösungsräumen arbeiten und unsere mit vollständigen Lösungsräumen?

Die Sache ist komplizierter. Constraint Solver wollen im Grunde nur herausfinden, ob es eine Lösung gibt. Dies geschieht in einem aufwendigen Suchprozess. Einige Technologien eignen sich teilweise für die Stücklistenprüfung. Bei uns gibt es aber keine bloße Ja/Nein-Prüfung. Wir finden auch Gegenbeispiele und individuelle Regeln zur Analyse und zum Debugging des Lösungsraums.

Unsere Kunden versuchen manchmal selbst, eine Stücklistenprüfung durchzuführen. Manche listen nach der Brute-Force-Methode alle gültigen Kombinationen in einem Variablensatz auf, um herauszufinden, ob sie eine korrekte Stückliste ergeben. Einem LKW-Hersteller zufolge, der nach dieser Methode vorgeht, ist das nur begrenzt möglich, da bereits die Prüfung einer einzigen Komponente kompliziert sein könne. Für eine bestimmte Komponente gebe es 128 Millionen gültige Kombinationen von Fahrvariablen, die in Verbindung mit Tausenden von Teilen zu unzähligen Kombinationen führten, die alle geprüft werden müssten. Deshalb mache man dies nicht allzu oft.

Wir streben jedoch eine kontinuierliche Prüfung an, und zwar mithilfe eines integrierten Ansatzes aus Kompilierung und Verwendung. Im Rahmen der Stücklistenprüfung wollen wir die Materialien des Nutzers in PLM-Systemen definieren und ihm beim Authoring der Materialien auf der PLM-Plattform unmittelbares Feedback geben. Er sieht dann sofort, ob seine Regeln stets erfüllt werden. Damit machen wir Konfigurationsdaten systemübergreifend zugänglich. Es geht uns nicht primär um das Authoring von Stücklisten, aber wir unterstützen es über das PLM.

Gibt es Feedback zum CLM-Authoring und zur Stücklistenprüfung?

Ein großer Automobilhersteller hat uns mitgeteilt, dass er manchmal scheinbar harmlose Konstruktionsentscheidungen trifft, ohne alle Auswirkungen auf die Teile abschätzen zu können. Er würde gerne wissen, ob eine Konstruktionsentscheidung – etwa die Zulassung einer bestimmten Merkmalskombination – durch die Teile in der Stückliste abgedeckt wäre. Außerdem ist er an den erweiterten Kosten einer Einführung neuer Teile interessiert. Er arbeitet mit Margen von wenigen Euro pro Teil, die sich aber bei jährlich Tausenden von Teilen in Hunderttausenden von Fahrzeugen zu einer beträchtlichen Summe addieren. Da selbst kleine Änderungen große Auswirkungen haben können, kommt der Wirkungsanalyse eine hohe Bedeutung zu.

Zusagen erfüllen

Es geht uns nicht nur um Kostenersparnis und Umsatzsteigerung, sondern auch darum, dass unsere Kunden die Zusagen gegenüber ihren Kunden erfüllen und die bestellten Produkte auch wirklich fertigen können. Dies bedeutet Effizienz, Qualität und nicht zuletzt Goodwill.

Dasselbe gilt für die Konfiguratoren. Anstatt blindlings Aufträge entgegenzunehmen, verwenden wir einen Vertriebskonfigurator. Das hat zwei Gründe. Der erste ist Support: Wir wollen die Prozesse verbessern, indem wir sicherstellen, dass unsere Kunden unnötigen Konstruktionsaufwand vermeiden und ihre Kunden zufriedenstellen können. Der zweite Grund liegt im Auffinden der richtigen Teile, Entfernen nicht funktionierender Teile und Identifizieren von Einsparpotenzialen bei den Teilen.

Download GEA Tuchenhagen case study






Download Linde Hydraulics case study






Download Stroz case study






Download the CIMdata product review






Download CLM White paper






Download the Sales-oriented product models for SAP






Download VT White paper