Funktionale Entwicklung und Optimierung komplexer Systeme in 2020

Transkript

1 Funktionale Entwicklung und Optimierung komplexer Systeme in 2020 Andrea Denger 1, Markus Zoier 1, Christian Zingel 2 1 Virtual Vehicle Competence Center (ViF), Graz, Österreich 2 Inst. f. Produktentwicklung, Karlsruher Institut für Technologie (KIT), Karlsruhe, Deutschland K2 Competence Center - Initiated by the Federal Ministry of Transport, Innovation & Technology (BMVIT) and the Federal Ministry of Economics & Labour (BMWA). Funded by FFG, Land Steiermark and Steirische Wirtschaftsförderung (SFG) 1

2 Der Arbeitsplatz der Zukunft? 2

3 Services Funded and Contractual Research VIRTUAL VEHICLE im Überblick: Zielsetzung: effiziente virtuelle Methoden für Gesamtfahrzeugentwicklung MA ca. 180 K2 Research Projects 10 Years Funded Programme TU-Graz and Institutes Research Facilities Industrial Partners 3

4 Agenda Motivation & Zielsetzung Zukünftige Anforderungen an ein Product Lifecycle Management Portfoliomanagement als Beispiel der Adressierung dieser Anforderungen Technischer Lösungsvorschlag für Informationsvernetzung Zusammenfassung & Ausblick 4

5 Motivation & Zielsetzung Wie könnte das Unternehmensumfeld in der Zukunft aussehen? (Betrachtungszeitraum 2020) Werden die heutigen Herausforderungen (z.b. Komplexität, Transdisziplinarität etc.) auch die zukünftigen sein? Was kann ein Beteiligter in der Produktentstehung erwarten, worauf muss er sich vorbereiten, wie kann sich ein Unternehmen bestmöglich rüsten? (speziell Kalibrierung) Mit welchen Product Lifecycle Management- Einführungsstrategien wird man zukünftig Erfolg haben und welche Rolle spielt dabei der Faktor Mensch? Wie können die Herausforderungen bewältigen werden? (ausgewählt: Datenmanagement/-vernetzung) Das Ganze ist mehr als die Summe seiner Teile. (Aristotels ca. 320 v. Chr.) 5

6 Was muss heute (Gesamt-)Fahrzeugentwicklung leisten? ein hochkomplexes Produkt kundenorientiert kostengünstig unter Nutzung vorhandener Erfahrung und Wissen Entwerfen in sehr kurzer Zeit mit einer heterogenen Mannschaft pro Entwicklungsphase mit wechselnden Mannschaften über die Entwicklungsphasen über mehrere Standorte Entwickeln Absichern mit einem hohen Ausmaß an virtueller Entwicklung unter Vermeidung interdisziplinärer Zielkonflikte mit nachvollziehbaren Entscheidungen mit hybriden Absicherungsmethoden 6

7 Product Lifecycle Management (PLM) PLM ist ein strategisches Konzept (Geschäftsansatz) zum Management des IP eines Produktes* über den gesamten Produktlebenszyklus. Kunden Beginning of life (BOL) Idee Design Prod. Planung Konzept Verifikation Produktion Middle of life (MOL) Vertrieb Service End of life (EOL) Wiederaufbereitung Entsorg. PDM Zulieferer PLM *) Das Produkt beinhaltet auch Dienstleistung (z.b: Service und Wartung) 7

8 PLM-Einführung ist nicht immer eine Erfolgsstory Quelle: Studie Benefits of PLM; Prof. Dr.-Ing. Michael Abramovici 8

9 Product Lifecycle Management (PLM) PLM ist ein strategisches Konzept (Geschäftsansatz) zum Management des IP eines Produktes* über den gesamten Produktlebenszyklus. Das Konzept umfasst Elemente eines Unternehmens wie Prozesse insbesondere Änderungs- und Konfigurationsprozesse, Organisationsstrukturen, Methoden und unterstützende IT-Systeme. In dem Projekt FuturePLM wird insbesondere der Faktor Mensch betrachtet. Kunden Beginning of life (BOL) Idee Design Prod. Planung Konzept Verifikation PDM Produktion Zulieferer Middle of life (MOL) Vertrieb Service PLM End of life (EOL) Wiederaufbereitung Entsorg. *) Das Produkt beinhaltet auch Dienstleistung (z.b: Service und Wartung) 9

10 Systems Engineering Systems Engineering ist ein interdisziplinärer Ansatz, um komplexe technische Systeme in großen Projekten zu entwickeln und zu realisieren. 10

11 Informations- und Kommunikationswege / Einflußfaktoren 11

12 Das Produkt Stakeholder der Entstehung eines Produktes Team Prozess Organisation Methoden IT-Systeme 12

13 Das Produkt Stakeholder der Entstehung eines Produktes Team Prozess Organisation Methoden IT-Systeme 13

14 Das Produkt und seine Stakeholder in der Entstehung 14

15 Das Produkt und seine Stakeholder in der Entstehung 15

16 Zukünftige Anforderungen an ein Product Lifecycle Management 16

17 E i n f l u s s a u f P L M Wirkgefüge FuturePLM Analyse (Interviews) Faktor Mensch Kommunikation zu/von Management Interdisziplinärer Erfahrungsaustausch Interdisziplinärer Erfahrungsaustausch (1 Vortrag): (1 Vortrag): Essenz Essenz aus aus Ethik Ethik und und Gesellschaftslehre (5 Vorträge): (5 Vorträge): Essenz Essenz aus aus Lernen, Lernen, Wissen Wissen & & Kommunikation (2 Vorträge): (2 Vorträge): Essenz Essenz aus aus Komplexität & & Verantwortung PLM FuturePLM Cross-Lifecycle Cross-Lifecycle Knowledge Wissensmanagement Management Cross-domain Cross-domain Zusammenarbeit Kollaboration Globale Globale Kommunikation Kommunikation Szenarioentwicklung Szenarien Szenario 1 1 Globalisierung extrem Szenario 2 2 Die Die Entnetzung Szenario 3 3 Auf Auf der der Informationswelle (4 Vorträge): (4 Vorträge): Essenz Essenz aus aus Mensch Mensch & Kultur & Kultur Szenario 4 4 Der Der Mensch im im Mittelpunkt Anforderungskatalog Anforderungskatalog PLM Roadmap Roadmap PLM

18 Anforderungskatalog

19 Bisherige Ergebnisse FuturePLM Transparenz, Rolle im Entwicklungsablauf/Gesamtprozess erkennen, sichtbar machen, bewusst sein, gemeinsame Ziele sehen, Bedarf an Kommunikation Die Komplexität des Entwicklungsprozesses nimmt schneller zu als Verbesserung desselben, deshalb sind weitere Innovationen erforderlich. Menschliche Komponente Technische Komponente Zusammenhänge abbilden und verwalten Abhängigkeiten sichtbar machen Primäres Ziel, Entwickler optimal zu unterstützen 19

20 Portfolio-Management als Beispiel der Adressierung dieser Anforderungen 20

21 Bsp. Portfolio-Management Herausforderungen Anforderungen, Funktionen, Produkt über Planungslebenszyklus (Idee, Entwicklung, Stilllegung) verwalten von Marktanforderungen zu Produktfunktionen angesiedelt am Beginn der Entwicklungskette produktübergreifend klare Ziele definieren konkurrierende Entscheidungen in Produktstrategie vermeiden Methodischer Lösungsansatz Anforderungen auf Produktportfolio abbilden, Roadmap Features/Produkt über Zeit Beeinflussende Objekte und Abhängigkeiten identifizieren, u.a. Anforderungen, Produktfunktionen und Produktarchitektur 21

22 Schritt 1 Aufbau funktionaler Lösungsraum Die funktionale Lenkung mechatronischer Produkte ist ein komplexer Vorgang, unter Einbeziehung aller produktrelevanten Informationsquellen entlang des gesamten Produktlebenszyklus. Eine wesentliche Fragestellung ist die Modellierungsmöglichkeit von Zusammenhängen und Beziehungen einzelner Elemente (Prozesse, Methoden, Organisation, Teams und IT-Systeme) und deren Kommunikationspfade, die zzz bisher nicht zufriedenstellend integriert werden konnten. 22

23 Schritt 2 Einschränkung des Lösungsraums durch Rahmenbedingungen und Qualitätsanforderungen 23

24 Technischer Lösungsansatz Funktionale Modellierung Herausforderung: Beschreiben der Produktentwicklungs- Welt Domains selbst (welche Objekte gibt es) Zusammenhänge und Abhängigkeiten (zwischen den Objekten und Domains) Methode Ablauf der Lösungsfindung Zu Modellierende Objekte: Bedürfnisse Anforderungen Funktionen Komponenten (HW, SW) Module Produkte Zusammenhänge, Abhängigkeiten Funktionale Beschreibung - Warum? Formal -> präzise, eindeutig Mensch- und maschinenlesbare Repräsentation Gangbarer Mittelweg von für Mensch und Maschine abbildbarer Semantik Trend: Methoden aus prof. Softwareentwicklung zur Verbesserung automotiver Produktentwicklungsprozess 24

25 Umsetzung in SysML Systems Modeling Language (SysML) Auf der UML basierende standardisierte Sprache Für die Modellierung von komplexen Systemen SysML als Baukasten für die Sprachelemente zur Beschreibung des Lösungsansatzes Möglichkeit für Beschreibung virtueller Produkte Bedürfnisse Anforderungen Funktionen Komponenten (HW, SW) Zusammenhänge, Abhängigkeiten Module Produkte 25

26 Aspekte zum Lösungsansatz Was mache ich dann mit den in SysML modellierten Zusammenhängen? Naheliegend: eindeutige Beschreibung der Lösung z.b. als Anforderungsdokument einer Portofolio-Management- Software Möglichkeit: Informations-Management-System aufbauen, das Beschreibungen direkt versteht Müssen nun alle Entwickler und Produktverantwortlichen SysML lernen? Nein, in Mehrzahl der Fälle funktionale Modell hinter angepassten klassischen GUIs versteckt Oder die Beschreibungen werden sowieso im Backend eines Systems angewandt 26

27 Technischer Lösungsvorschlag für Informationsvernetzung 27

28 Idee Der gezeigten Lösungsansatz kann auch dazu dienen, eine Datenmanagement-Plattform zu bauen, um Zusammenhänge zwischen Entwicklungstools oder existierenden Informationssystemen entlang des gesamten Produktentwicklungsprozesses abzubilden. Ziel 1: bei steigender Produktkomplexität Qualität des Entwicklungsprozesses sicherstellen Ziel 2: Designentscheidungen nachvollziehbar gestalten Was nicht funktioniert: Einführung eines monolithischen Datenmanagements (alles in einem großen System) illusorisch, unflexibel, starr, sehr lange Einführungszeiträume Ablösung etablierter Lösungen in Domänen/Bereichen 28

29 Wie manage ich den Informationsfluss technisch? Einfachster Fall direkte Peer-to-Peer-Kopplung Tool 1 Tool 2 Tool 3 Role 1 Role 2 Role 3 Tool 4 Role 4 Nachteile Logik der Umsetzung in vielen verstreuten Interfaces Keine übergreifende Steuerung, Berücksichtigung von Abhängigkeiten Integrationsplattform Tool 1 Tool 2 Tool 3 Tool 4 Logik der Umsetzung in Plattform zusammengezogen Virtuelle Beschreibung des Produkts Role 1 Role 2 Role 3 Role 4 Übergreifendes Modell für Ordnung der Umsetzungsregeln etablierbar Standardisierte Interfaces Integration Infrastructure Ordnung der Umsetzungsregeln Cockpit Workflow Engine Automatisierte Abläufe und Verfolgung der Abhängigkeiten möglich 29

30 Idee Nutzung der funktionalen Beschreibung der Strukturen und Zusammenhänge als virtuelle Produktbeschreibung System- Modell Anforderungsmodell Produktfunktionen Architekturmodell Modell der Testfälle Baue funktionales Modell nicht händisch auf, sondern lasse das eine Businesslogik innerhalb einer Datenmanagementplattform machen Aus dem relevanten Teil der Daten eines Tools (Nutzdaten, z.b. Input-Deck oder Testergebnisse) wird ein Teil des Systemmodells generiert Dieses Systemmodell wird bei Änderungen der Nutzdaten (z.b. neue Version) automatisch synchron gehalten Systemmodell basiert aus Elementen verschiedener funktionaler Sprachen, z. B. SysML, EAST-ADL, AUTOSAR, IP++, OSLC 30

31 Wie sieht ein Entwicklungsschritt aus? Tool 3 Role 3 Tool 4 Role 4 Tool 5 Role 5 Tool- Daten Tool- Adapter System- Modell Tool Data Management Tool Data Management Integration Infrastructure Teil des Systemmodells + Referenz auf Tool-Daten Tool Data Management Cockpit Meta Data Repository Referenzmodelle = Umsetzungsregeln 31

32 Conclusio Für die Entwicklung übergreifender Methoden ist die (grobe) Kenntnis der Teilbereiche/Domains erforderlich Steigende Komplexität des Entwicklungsprozesses erfordert Sicht des einzelnen (spezialisierten) Entwicklers als Teil des Ganzen. Es kommt nicht darauf an, die Zukunft vorherzusagen, sondern auf die Zukunft vorbereitet zu sein (Perikles ca. 450 v. Chr.) 32

33 Systeme, Prozesse und Organisation müssen den Menschen in der Produktentwicklung signifikant unterstützen und ihm ermöglichen, eine holistische Aufgabenstellung kreativ zu bearbeiten. Kontakt: Andrea Denger, Markus Zoier Virtual Vehicle 33