"Make or buy" bei der Entscheidung für eine neue Steuer- und Regelungsplattform

Transkript

1 "Make or buy" bei der Entscheidung für eine neue Steuer- und Regelungsplattform "Die auf sbrio basierende Entwicklung hat grosse Vorteile, steht doch das System unmittelbar für erste Versuche zur Verfügung (Risikominimierung) und ermöglicht es, (...) die drei Teile des Software-Systems realisieren zu können:pc-seitige Software, Real-Time-System auf dem sbrio, FPGA-System auf dem sbrio." - Amadeo Vergés, Zühlke Engineering AG ( Die Aufgabe: Gesamtkosten-Betrachtung über den ganzen Produktlebenszyklus für eine Steuer- und Regelungsplattform als Grundlage "Make or Buy"-Entscheides Die Lösung: Systematische Anlyse und Bewertung der über den gesamten Lebenszklus des Produkte anfallenden Kosten und Risiken, welche oft vernachlässigt werden. Autor(en): Amadeo Vergés - Zühlke Engineering AG ( "Das magische Dreieck gilt auch bei Steuerungen" Was hat das magische Dreieck mit der Produktlebenszyklus moderner Steuerungsplattformen zu tun? Auf den ersten Blick wenig. Doch wer für ein Gerät, ein System oder eine Anlage eine Steuerung evaluiert oder eine Entwicklung plant, ist wie bei anderen Aufgabenstellungen mit dem magischen Dreieck konfrontiert: - Kosten - Termine - Funktionalität Eine Änderung an einer Seite des Dreiecks hat zwangsläufig Einfluss auf die anderen beiden Seiten. Darin liegt die "Magie" des Dreieckes. Oft wurde versucht, sich dieser Gesetzmässigkeit zu widersetzen. Wem dieses Kunststück gelingt, ist entweder ein grossartiger Magier oder, und dies ist eher wahrscheinlich, hat vergessen etwas zu berücksichtigen. Betrachten wir die drei Seiten des Dreieckes und deren Einfluss im Hinblick auf die Wahl einer Steuerung für Anwendungen bei kleinen und mittleren Stückzahlen (1 bis 1000 Stück). Die Kosten Zu den eigentlichen Einkaufspreisen sind auch die durch die Anzahl der Geräte geteilten Entwicklungs- oder Beschaffungskosten zu berücksichtigen. Weitere Kosten sind oft nicht direkt erkennbar wie beispielsweise: Zertifizierungen: Produkte müssen zunehmend Normen und Zertifizierungen erfüllen Produktpflege: Diese Kosten fallen beispielsweise an, wenn Bauteile abgekündigt und ersetzt werden müssen oder ein Software-Update bereitzustellen ist. Know-how-Pflege:Bei einer Eigenentwicklung muss das Know-how dokumentiert, auf mehrere Mitarbeiter verteilt und gepflegt werden. Einem Know-how-Verlust bei Mitarbeiterwechseln kann nur so entgegnet werden.beim Einsatz mehrerer Entwicklungssysteme für die eingesetzten Subsysteme und Komponenten, müssen diese gepflegt und aktualisiert werden. Lagerhaltungskosten: Muss eine Anzahl von Steuerungen am eigenen Lager gehalten werden, sind damit Lagerhaltungskosten verbunden. Die Vereinheitlichung von verschiedenen Steuerungen auf einen Typ für verschiedene Geräte/Systeme lohnt sich oft finanziell, auch wenn sich dadurch die Stückkosten der Steue-rung für kleinere Systeme erhöhen. Die Termine Oft wird nicht spezifiziert, welche monetären Verluste zu erwarten sind, sollte das Produkt später als geplant Marktreife erlangen, resp. welche Einnahmen zu erzielen sind, sollte das Produkt früher auf den Markt kommen als geplant. Diese sind jedoch mit zu berücksichtigen zu quantifizieren. Neben den offensichtlichen Terminen für die Entwicklung und Realisierung des ersten Systems ist an folgende Punkte zu denken: Bei Eigenentwicklungen von Hardware wird oft unterschätzt, dass normalerweise mehrere Designzyklen erforderlich sind, sowie die Zertifizierungen und Prüfungen zusätzlichen Zeitaufwand bedingen. Wie lange soll die Steuerung im Einsatz sein? Wie lange wird das Produkt mit dieser Steuerung verkauft und wie lange muss die Steuerung als Ersatzteil verfügbar sein? Die Funktionalität "Der Appetit kommt mit dem Essen". Im Verlauf des Projektes oder während der Produktlebensdauer sind nicht selten Zusatzfunktionen zu integrieren. Wird eine Steuerung gewählt oder entwickelt, welche nur die zu Beginn bekannten Vorgaben erfüllt, kann sich dies später rächen. Mit den heutigen Kosten für Rechenleistung und Speicher lohnt es sich darum, genügend Leistungsreserven vorzusehen ohne dass sich dies, bei kleineren bis mittleren Stückzahlen, signifikant in den Kosten niederschlägt. Es lohnt sich auch zu überlegen, ob andere Baugruppen und Schnittstellen in die neue Steuerung integriert werden könnten. Beispielsweise können mit FPGA-Funktionalitäten in industriellen Steuerungen gewisse Sicherheitsfunktionen direkt integriert und dadurch bisher benötigte zusätzliche Systeme eingespart werden. Bei einer Eigenentwicklung wird zudem viel Zeit benötigt, um diese zu prüfen und Fehler zu beseitigen. Bei einer käuflichen Lösung kann sich der Entwickler viel schneller mit der eigentlichen Implementierung der Funktionalität und dem Erkunden der Möglichkeiten beschäftigen. Das magische Dreieck verhindert es, im Bereich der Kosten Änderungen vorzunehmen, ohne dass sich dadurch die Termine oder der Funktionsumfang ändern. Diese Gesamtbetrachtung muss immer gemacht werden. Käufliche Lösung vs. Eigenentwicklung: der konkrete Fall Die Erfahrung zeigt, dass beim Entscheid käufliche Lösungen oder Eigenentwicklung oft nur die direkten Beschaffungskosten beachtet werden. Sowohl eine käufliche Lösung wie auch die Eigenentwicklung haben ihre Berechtigung. Eine pauschale Entscheidungshilfe gibt es nicht. Für einen fundierten Entscheid ist es daher umso wichtiger, die entsprechenden Punkte zu berücksichtigen. Im Rahmen eines konkreten Falls wurde ein Vergleich zwischen einer kundenspezifischen Entwicklung und dem Produkt "Single Board RIO" (sbrio), einer käuflichen OEM-Lösung zur Realisierung anspruchsvoller Steuer- und Regelungsaufgaben von National Instruments, durchgeführt. Das Ergebnis war, dass eine Eigenentwicklung erst ab deutlich mehr als ca. 300 Stück relevante Kostenvorteile bringen würde. Die auf sbrio basierende Entwicklung hat jedoch grosse Vorteile, steht doch das System unmittelbar für erste Versuche zur Verfügung (Risikominimierung) und ermöglicht es, mit einer einzigen Entwicklungsumgebung die drei Teile des Software-Systems realisieren zu können: 1/5

2 Entwicklungsumgebung die drei Teile des Software-Systems realisieren zu können: - PC-seitige Software - Real-Time-System auf dem sbrio - FPGA-System auf dem sbrio Produktivitätsgewinn vs. Ressourcenoptimierung Es genügt nicht, eine Plattform nur vom Hardware-Gedanken her auszuwählen. Die dazugehörige Entwicklungssoftware ist auch entscheidend. Die oben aufgelisteten Anteile eines Softwaresystems (PC, Real-Time-System, FPGA), werden heute oft gemeinsam verwendet. Dies bedingt meist verschiedene Entwicklungssysteme. Gelingt es neben einer käuflichen Hardware-Plattform auch ein dazu passendes, übergreifendes Entwicklungssystem zu finden, mit welchem alle Komponenten des Softwaresystems realisiert werden können, ergibt sich ein erheblicher Nutzen. So entfällt die Thematik der Kommunikationsschnittstellen zwischen den einzelnen Systemen. Im erwähnten Beispiel des sbrio-modules steht mit LabVIEW die zugehörige Entwicklungsumgebung für alle Softwareanteile zur Verfügung. Bei den erwähnten Stückzahlen ist Flexibilität und Produktivität fast immer mehr wert als eine Optimierung des Speicherplatzes auf das letzte Byte. Schlussfolgerung Wie so oft gibt es auch hier keine klare Antwort auf die Frage "Make or Buy". Es ist aber empfehlenswert vor dem Start eines Projektes genügend Zeit für die Abklärung einzusetzen, ob ein käufliches (Teil-) Produkt über alles gesehen weniger Risiken, geringere Kosten und vor allem einen Produktivitätsvorteil bringt. Auch wenn die Technologiezyklen immer kürzer werden und laufend Innovationen auf den Markt kommen, ist die Produkt-Kontinuität eine der Stärken der hiesigen Industrie. In der Möglichkeit, sich auf das eigentliche Kern-Know-how zu konzentrieren liegt eine der Chancen im heutigen industriellen Umfeld. Elektronische Steuerungen als Komponenten selber zu entwickeln gehört meist nicht dazu. Autor: Amadeo Vergés Zühlke Engineering AG ( Wiesenstr. 10a Schlieren 8952 Schweiz Tel: av@zuehlke.com (mailto:av@zuehlke.com) Zühlke-Logo 2/5

3 Faktoren bei der "Make- or Buy-Entscheidung" 3/5

4 sbrio-modul 4/5

5 Die Zuehlke Embedded Plattform Rechtliche Hinweise Diese Kundenlösung ( Kundenlösung ) wurde von einem Kunden von National Instruments ( NI ) entwickelt. DIESE KUNDENLÖSUNG WIRD IM IST-ZUSTAND ZUR VERFÜGUNG GESTELLT UND NI ÜBERNIMMT KEINERLEI GARANTIEN. AUSFÜHRLICHERE ERLÄUTERUNGEN ZU ANDEREN EINSCHRÄNKUNGEN ENTNEHMEN SIE BITTE DEN NUTZUNGSBEDINGUNGEN FÜR NI.COM. 5/5