MSR-Standards in der Praxis
MSR Standards in Practical Use
Version: 1
MSR ist ein firmenübergreifendes Komitee zur Unterstützung gemeinsamer Entwicklungen zwischen Automobilherstellern und deren Elektronik System Zulieferern.
Durch Untersuchung und Erprobung einer ganzen Reihe von Technologien zur Standardisierung und zum Austausch von Spezifikationen und Simulationsmodellen wurden die derzeit verfügbaren technischen Möglichkeiten ausgelotet. Als besonders tragfähig erwies sich SGML als Basis für die modulare, interaktive Zusammenarbeit bei Spezifikation und Dokumentation elektronischer Systeme. Die strukturellen Grundlagen für die komplette Beschreibung elektronischer Systeme wurden abgestimmt und in Pilotprojekten erfolgreich erprobt. Sie liegen als SMGL-Dokument-Typ-Definitionen allgemein verfügbar vor.
Zukünftige Themen in MSR sind, neben der Verbreitung der erarbeiteten Schnittstellen-Standards, die Intensivierung der Zusammenarbeit mit ASAM und die firmenübergreifende Synchronisation der Prozesse bei der Entwicklung elektronischer Kfz-Systeme.
MSR is a commitee of several german companies with the goal to support cooperative developments between carmanufacturers and their electronic system suppliers.
A number of technologies for standardisation and exchange of spezifications and simulation models were evaluated and tested to clarify the actual technical potentials. SGML was found to be a highly useful standard for modular and interactive cooperation in spezification and documentation of electronic systems. The structural fundamentals for the complete description of electronic systems were defined an succesfully used in pilot projects. The structures are freely available as SGML-document-type-definitions.
Besides spreading the now defined interface standards, future activities in MSR are the intensivation of the cooperation with ASAM and the clarification of the means for synchronisation of processes when developping elctronic systems.


I. Dokumentenverwaltung

MSR-Standards in der Praxis
I. Dokumentenverwaltung

Beteiligte Personen
Name | Firma |
Bernhard Weichel | MSR MEDOC | Telefon: 0711 8118322 Abteilung: Robert Bosch GmbH, Schwieberdingen Bernhard.Weichel@de.bosch.com
E. Perenthaler | MSR MEDOC | Abteilung: Robert Bosch GmbH
T. Hirth | MSR MEDOC | Abteilung: DaimlerChrysler AG, Stuttgart
P. Rauleder | MSR MEDOC | Abteilung: DaimlerChrysler AG, Stuttgart
Roman Reimer, XI-Works | MSR MEDOC | Abteilung: XI-Works
Versionsübersicht
Version | Datum | Herausgeber | Status
1 | 2002-11-03 | Bernhard Weichel | RD
Änderungen
Version
Änderung
Bezug
Enthaltene Änderungen
Datum
Kapitel
Änderung
Bezug


1. Ausgangssituation und bisheriger Verlauf von MSR

MSR-Standards in der Praxis
1. Ausgangssituation und bisheriger Verlauf von MSR

Das Projekt MSR (Manufacturer Supplier Relationship) ist ein Entwicklungsvorhaben mehrerer deutscher Automobilhersteller und Elektrik/Elektronik-Zulieferer mit der Zielsetzung, die Zusammenarbeit zwischen Hersteller und Zulieferer zu verbessern und in der Effizienz zu steigern. Die entsprechende Zieldefinition für das Projekt lautete:
MSR: Ein Projekt zur Definition von methodischen Arbeitsweisen und Beschreibungsmitteln für die Realisierung steuer- und regelungstechnischer Konzepte im Bereich Automobil - Elektrik/Elektronik unter dem Gesichtspunkt der engen Zusammenarbeit zwischen Her-steller und Zulieferer
Dieses Ziel wurde durch die Entwicklung und Anwendung neuer Methoden und Entwurfsumgebungen sowie neuer Konzepte in der Dokumentation verfolgt (vgl. /MSR92-1/, /MSR92-2/). Die dabei betrachteten Entwicklungsphasen waren die folgenden:
Abbildung 1:
'Abb. 1: Phasenstruktur
Die Teilprojektstruktur von MSR sowie deren Zusammenhang zu den Entwicklungsphasen ist in Abb. 2 dargestellt.
Abbildung 2:
'Abb. 2: Teilprojekte
Das 1990 von den Firmen BMW, Bosch, Daimler-Benz, Hella, Porsche, Siemens, VDO und VW initiierte Projekt wurde 1995, nach der Entwicklung und Implementierung mehrerer Werkzeug-Prototypen und deren Verifikation und Validierung in Pilotprojekten, neu strukturiert (vgl. /MSR98/).
Das Teilprojekt MESA/MERLAN wurde 1995 abgeschlossen. Die ersten positiven Erfahrungen mit dem Einsatz von System Design Werkzeugen im Teilprojekt MESA/MERLAN sind in /MSR94/ beschrieben. Zwischenzeitlich gibt es zahlreiche am Markt operierende Anbieter solcher Werkzeuge für den Steuerungs- und Regelungsentwurf. Vor diesem Hintergrund finden die MESA-MERLAN-Arbeiten ihre Fortsetzung in automobilspezifischen Arbeitskreisen etablierter Werkzeuganbieter.
Die Standardisierung von Schnittstellen zum Dokument- und Datenaustausch wurde im Teilprojekt MEDOC vorangetrieben.
Das Teilprojekt MEDOC hat bis zum Jahr 1995 die folgenden Phasen durchlaufen:
  • Sammlung von Anforderungen
  • Datenmodellierung anhand von Prototypen
  • Auswahl einer Austauschtechnologie (SGML)
  • Festlegung der Basiskonzepte zur Anwendung dieser SGML-Technologie
  • Erstellung erster spezifischer Standards auf Basis von SGML.
Seit 1996 werden die Arbeiten auf dieser Basis weiterverfolgt. Dabei werden zum einen die Standards thematisch erweitert (z.B. zur Abdeckung von FMEA-Daten) und zum anderen die Basiskonzepte zur Anwendung der SGML-Technologie weiterentwickelt (z.B. um Konzepte für dokumentübergreifende Hypertextreferenzen). Im Bereich der Dokumentformatierung wurde ein gemeinsames Werkzeug entwickelt. Weitere Werkzeugimplementierungen werden in den beteiligten Firmen und von Drittanbietern auf Basis marktgängiger SGML-Werkzeuge (Editoren, Datenbanken, Konverter, ...) durchgeführt. Erste Kopplungen zu CAD-Werkzeugen sind ebenfalls am Markt verfügbar.
Das World Wide Web Consortium (W3C) hat im Februar 1998 die Entscheidung getroffen, eine Untermenge von SGML als zukünftige Sprache des World Wide Web einzuführen (unter dem Titel XML – eXtensible Markup Language). Dies wird weitreichende Folgen für die Verbreitung dieser Technologie als Basis für den zukünftigen Daten- und Dokumentaustausch in Computer- und Telekommunikationsanwendungen haben. Initiativen wie MSR MEDOC finden deshalb derzeit viele Nachahmer und bestehende Datenaustausch-Initiativen, die bisher auf anderen Technologien beruhen, stellen den Datenaustausch auf diese Technologie um.
Das folgende Kapitel beschreibt nun die Hintergründe für die Definition sowie den aktuellen Stand der MSR-Standards im Teilprojekt MEDOC.


2. MSR-Standards

MSR-Standards in der Praxis
2. MSR-Standards

Die zunehmende Interaktion im Entwicklungsprozeß zwischen Fahrzeugherstellern und Elektronikzulieferern bringt auch eine Zunahme des Daten- und Dokumentaustauschs mit sich. Dabei werden in den unterschiedlichen Unternehmen auch unterschiedliche IT-Werkzeuge eingesetzt, weshalb ein standardisiertes Datenaustauschformat benötigt wird.
Die gesuchten Formate haben dabei die Aufgabe, sowohl den Austausch von (formalen) Datenbank- und CAD-Daten, als auch den Austausch von (informellen) Textdokumenten zu organisieren. Außerdem ist die Aufgabe zu lösen, eine Gesamtdokumentation, bestehend aus den formalen und informellen Anteilen, erstellen zu können. Folglich benötigt man auch eine Technologie zur Dokumentorganisation.
Abbildung 3:
'
Abb. 3a: Prozeßinteraktion Hersteller/Zulieferer
In einer Workshop-Reihe wurden zunächst verschiedene Dokumentaustausch-Formate untersucht und gegenübergestellt. Ein Kandidat war der Dokumentaustausch-Standard SGML (Standard Generalized Markup Language ISO 8879). Eine genauere Betrachtung dieser Technologie sowie existierender SGML-Anwendungen in der Automobil-, Elektronik- und Luftfahrtindustrie ergab, daß mit Hilfe dieses Formats neben der Lösung von Dokumentations- und Publikationsaufgaben auch der Austausch von Daten organisiert werden kann. Diese Chance, alle anstehenden Aufgaben auf Basis eines einzigen Formats lösen zu können, sowie die Verfügbarkeit von SGML-Werkzeugen am Markt waren ausschlaggebend für die Wahl von SGML als Basistechnologie für den Daten- und Dokumentaustausch in MSR.
Abbildung 4:
'
Abb. 3b: 3-Ebenen-Modell
Die Darstellungsebene umfaßt die traditionelle Präsentationsweise von Information, etwa in Form eines gedruckten Dokumentes, bei dem die inhaltliche Strukturierung der Information mit Hilfe klassischer Layoutmittel und klassischer Navigationsmittel erschließbar wird.
Die Ebene der Entwicklungsdaten repräsentiert die Entwicklungsdaten in den Originalformaten der im Prozeß verwendeten Entwicklungswerkzeuge. Diese Dateien werden meist in EDMS (Engineering Data Management Systems) gehalten, welche keinen direkten Zugriff auf die verwalteten Inhalte besitzen.
Die Lücke zwischen Darstellungsebene und Entwicklungsdatenebene kann durch Einführung einer Zwischenschicht, der Ebene der Dokumentorganisation geschlossen werden. Diese Ebene muß auf einem standardisierten Format basieren, welches alle Informationen aufnehmen kann, die zum Erzeugen der gewünschten Präsentationen erforderlich sind.
Die Ebene der Dokumentorganisation ist die Domäne der SGML-Technologie. Die Trennung von Struktur, Inhalt und Layout ermöglicht eine vergleichsweise einfache Erzeugung bzw. Auswertung und gleichzeitig die Abbildung sehr komplexer Datenstrukturen (Abb. 4).
Abbildung 5:
'
Abb. 4: SGML-Technologie
Der erste Schritt zur Anwendung der SGML-Technologie war die Definition von einheitlichen Grundsätzen und Regeln zum Umgang mit dieser Technologie (MSR MEDOC Applikationsprofil). Ziel dabei ist die Interoperabilität der einzelnen entstehenden MSR-Standards sowie die Unterstützung der Wiederverwendung von Software, die die MSR-Standards implementiert.


2.1. Das SGML Applikationsprofil von MSR MEDOC

Die MEDOC-Datenmodelle werden in SGML implementiert. Dies geschieht bei SGML durch die Definition sogenannter DTDs (Document Type Definitions). Alle MSR DTDs haben die folgenden, im Applikationsprofil festgelegten, einheitlichen Prinzipien:
Hyperlink-Modell
Das MSR Hyperlink-Modell unterstützt diverse Möglichkeiten, Hyperlinks innerhalb eines Dokuments oder auch zwischen unterschiedlichen Dokumenten zu definieren. Damit wird es ermöglicht, die Gesamtheit der verschiedenen Dokumente zu einem Steuergerät (System- und HW-Lastenheft, Softwaredokumentation, Vernetzungsbeschreibung, etc.) als eine große, vernetzte "Steuergeräte-Datenbank" aufzufassen.
Basiselemente
In allen DTDs werden dieselben Basiselemente verwendet. Diese Basiselemente umfassen u.a. alle Elemente zur reinen Textdarstellung (z.B. zahlreiche Listenformen) aber darüber hinaus auch einheitliche Modelle wie z.B. die Darstellung von Parametern oder die Behandlung von physikalischen Einheiten.
Konfigurierbarkeit
Die zahlreichen Konfigurierungsmöglichkeiten in den DTDs dienen u.a dazu, sich an unterschiedliche Prozeßschritte oder Werkzeugumgebungen anpassen zu können.
Klassifikationsmechanismen
Die DTDs beinhalten ein einheitliches Klassifikationskonzept, das über Namenserweiterungen der Datenelemente abgebildet ist.
Administrative Daten
Die administrativen Daten umfassen Versions-, Änderungs-, u.ä –Informationen und erlauben so die Kopplung der MSR-Daten an Verwaltungssysteme (Dokumentenmanagement-Systeme, Produktdatenmanagement-Systeme o.ä.).
Konstruktionsmechanismen für die DTDs
Alle DTDs werden nach festgelegten Konstruktionsmechanismen gebildet (z.B. Namenskonventionen).


2.2. Die einzelnen MSR-Standards

Im folgenden sind die derzeit festegelegten MSR-Standards aufgelistet und erläutert.
System (MSRSYS DTD)
Die MSRSYS DTD (früher MSRDOC) dient zur Spezifikation und Dokumentation kompletter Elektrik/Elektronik-Systeme. Sie erlaubt u.a. die folgenden Beschreibungen:
  • Projektdaten
  • Bauteile und ihr hierarchischer Aufbau
  • Verhalten
  • Architektur (Signale, Schnittstellen, Verbindungen)
  • Elektrische Eigenschaften
  • Mechanische Eigenschaften
  • Optische und akustische Eigenschaften
  • Umweltverträglichkeit
Die DTD wurde in verschiedenen Autorenumgebungen implementiert und befindet sich in zahlreichen Projekten im Einsatz.
Abbildung 6:
'
Abb.5: Aktuelle MSR-Standards
Software (MSRSW DTD)
Die MSRSW DTD dient zur Spezifikation und Dokumentation von Steuergerätesoftware und umfasst die folgenden Bereiche:
  • Datenlexikon
  • Funktionale Spezifikation
  • Kenngrößen
Der Einsatz dieser DTD in einem Entwicklungsprojekt wird in Kapitel 3 detailliert erläutert. Erste Tool-Kopplungen für diese DTD sind am Markt verfügbar.
Network (MSRNET DTD)
Die MSRNET DTD dient zur Spezifikation und Dokumentation der Fahrzeugvernetzung (mit dem aktuellen Fokus auf CAN-Netzwerke). Sie erlaubt u.a. die Beschreibung der Netzwerktopologie sowie der auf dem Netz ausgetauschten Signale und Botschaften. Erste Implementierungen der MSRNET DTD sind am Markt verfügbar und Pilotanwendungen wurden gestartet.
FMEA (MSRFMEA DTD)
Im Bereich Failure Mode and Effect Analysis (FMEA) wurde eine DTD erstellt. Die DTD wird derzeit in ersten Projekten erprobt, ist aber noch nicht publiziert.
Diagnose
Im Februar 98 wurde eine Arbeitsgruppe gegründet, die eine DTD für Diagnose-Lastenhefte erstellt. Diese DTD hat viele Anknüpfungspunkte zu anderen DTDs und damit die Aufgabe, eine integrierte Darstellung der Diagnosegesichtspunkte zu ermöglichen. Ein weiterer Anknüpfungspunkt bildet die im ASAM/ASAP-Projekt definierte SGML DTD zur Beschreibung der Kommunikation von Steuergeräten mit Off-Board-Diagnose- und Testsystemen. Sowohl zur Interoperabilität dieser DTDs als auch zur inhaltlichen Aufteilung der Arbeiten finden entsprechende Abstimmungen zwischen MSR MEDOC und ASAM/ASAP statt.
Report (MSRREP DTD)
Dies ist eine allgemein einsetzbare DTD, die nur zu Publikationszwecken und zum Dokumentaustausch, nicht aber zum Datenaustausch eingesetzt wird. Sie findet derzeit Anwendung für sämtliche Dokumentationen, die in den MSR MEDOC Arbeitsgruppen erstellt werden, sowie auch für Anwendungsgebiete, die noch nicht mit einer MSR DTD abgedeckt sind. Neben einem allgemeinen Dokumentmodell mit Kapiteln, Paragraphen etc. unterstützt die MSRREP DTD auch eine strukturierte Alternativenbehandlung (z.B. für den Änderungs- und Versionsplanungsprozeß).


3. Ergebnisse und Erfahrungen beim Einsatz der Standards in Entwicklungsprojekten

MSR-Standards in der Praxis
3. Ergebnisse und Erfahrungen beim Einsatz der Standards in Entwicklungsprojekten

Nach diesem Überblick über die bisher in MSR erarbeiteten Standarddokumente berichten wir in diesem Kapitel über die Nutzung eines der Standards in einem aktuellen Projekt. Es geht um die Dokumentation eines Steuergeräteprogrammes , das von Daimler-Benz und Bosch gemeinsam entwickelt wird. Sowohl die einzelnen Funktionen als auch das Gesamtprogramm werden unter Verwendung der MSRSW-DTD spezifiziert und dokumentiert.


3.1. Projektsituation

In die Entwicklung eines neuen Steuergerätes sollen neue Ideen der Funktionsarchitektur als auch neue Funktionen aus diversen Daimler-Benz Forschungsprojekten eingebracht werden. Es wird ein Entwicklungsteam aus Bosch- und Daimler-Benz Mitarbeiter zusammengestellt, das in einem Projekthaus räumlich zusammengefaßt wird (Abb. 6).
Beide beteiligten Firmen bringen bereits vorhandene Funktionsbeschreibungen, Datenspezifikationen und zum Teil auch fertige Programm-Module ein, aus denen das Entwicklungsteam ein funktionierendes Programm, eine konsistente Gesamt-Datenspezifikation und eine geschlossene Beschreibung des ganzen Programmes erstellen soll. Die geschlossene Beschreibung wird sowohl für die Applikationsarbeit, bei der Kennlinien und Kennfelder für einen bestimmten Motortyp ermittelt werden, als auch für den Test und die Weiterentwicklung der Funktionen benötigt.
Während für das Programm ANSI-C mit im Projekthaus vereinbarten Programmierkonventionen verwendet wird, kommt für die Datenspezifikation und die Verhaltensbeschreibung der Funktionen die MSRSW-DTD zum Einsatz.
Abbildung 7:
'
Abb. 6


3.2. Datenfluß im Projekt

Die Entwicklung von Funktionen des Motormanagements erfolgt in beiden am Projekthaus beteiligten Firmen schon seit längerem unter Verwendung von Simulationswerkzeugen (Abb. 7).
Simulationsmodelle, grafische Darstellungen des Modellverhaltens und Datenspezifikationen aus den Simulationstools werden in Datenbanken abgelegt. Das Projekthaus verfügt über eine eigene Datenbank, die aus Sicherheitsgründen mit den Datenbanken der Firmen nur über den Austausch von Files in Verbindung steht. Dieser Austausch muß regelmäßig erfolgen, um die Informationen in den drei Datenbanken konsistent zu halten. Damit die von einer Datenbank geschriebenen Files beim Einlesen in die andere Datenbank richtig interpretiert werden, muß der Inhalt der Files geeignet standardisiert werden. Als Standard für dieses Projekt konnte die MSRSW-DTD verwendet werden, da als Ziel die Entwicklung von Software vorgegeben war.
Abbildung 8:
'
Abb. 7
Die Beschreibung eines ganzen Programmes wird je nach Anwendungsfall gedruckt auf Papier, oder am Bildschirm benötigt. Die in der Datenbank abgelegten MSRSW-Files enthalten alle Informationen in einer neutralen Form. Daher ist es möglich, daraus Dokumente in verschiedenen Darstellungsformen auf verschiedenen Medien zu erzeugen. Im vorliegenden Projekt wurde gedruckte Dokumentation über PostScript und elektronische Dokumentation über PDF sowie als Hypertext (IDS-View) bereitgestellt.
Die bereits in die Simulationsmodelle eingegebenen Datenspezifikationen werden vom jeweiligen Werkzeug ebenfalls in MSRSW-Files geschrieben und in den Datenbanken abgelegt. Durch einen Konverter werden die Datenspezifikationen aus den MSRSW-Files in C-Definitionen und Header-Files umgesetzt. Neben einer wirksamen Fehlervermeidung durch den Entfall der manuellen Übertragung, wird mit dieser Konvertierung auch die Effizienz der Softwareentwicklung gesteigert.


3.3. Prozeßschritte und MSRSW-Files

Die Struktur der MSRSW-DTD ist so definiert, daß sie alle Spezifikations- und Beschreibungsinformationen sowohl zu einzelnen Funktionen als auch zu ganzen Programmen aufnehmen kann. Im Entwicklungsprozeß entstehen diese Informationen jedoch nicht alle gleichzeitig. Abbildung 8 verdeutlicht das. Die im Hintergrund von links nach rechts dargestellte Baumstruktur ist die MSRSW-DTD. In den Prozeßschritten Funktionssimulation, Funktionsspezifikation, Softwareimplementierung und Systemapplikation werden jeweils unterschiedliche Teile des Baumes mit konkreten Informationen befüllt.
Es hat sich als nützlich erwiesen, eine Reihe von Standardfiles zu definieren, die mit einem bestimmten Teilumfang befüllt sind und dafür Namen festzulegen, an dem der Teilumfang direkt erkennbar ist.
Wir werden diese Erfahrung im Detail in einem "MSRSW Implementation Guide" allgemein zugänglich machen.
Abbildung 9:
'
Abb. 8


3.4. Ergebnisse des MSRSW Piloteinsatzes

  • Für den ersten Programmstand der vom Projekthaus an die Applikation weitergegeben wurde, lieferte Daimler-Benz 40 und Bosch ca. 200 Funktionen (Abb. 9). Für alle Funktionen wurden Beschreibungen in Form von SGML-Files in die Datenbanken eingestellt.
  • Für die neu erstellten C-Module wurden die Datenspezifikationen und Header-Files aus den MSRSW-Files erzeugt, bei älteren Funktionen waren die dafür erforderlichen Informationen in den SGML-Files noch nicht verfügbar.
  • Es wurde eine Beschreibung des Gesamtprogrammes in gedruckter Form, als PDF-File und in Hypertext Form erzeugt. Alle Darstellungen haben ein durchgängiges Inhaltsverzeichnis und für die Eingänge und Ausgänge der 240 Funktionen ein Cross Reference Listing über das im Hypertext-System auch navigiert werden kann. Die gedruckte Version der Programmbeschreibung umfaßt 1400 Seiten.
  • Der Abgleich der Entwicklungsdatenbanken läuft produktiv.
Abbildung 10:
'
Abb.9
Die Verwendung des Standards MSRSW-DTD im Projekthaus zwischen Daimler-Benz und Bosch hat gezeigt, daß SGML und die MSRSW-DTD eine solide Grundlage sind für den Datenaustausch in firmenübergreifenden Kooperationen zur Entwicklung von Kfz-Steuergeräte-programmen.
Auch das Ziel der Werkzeugunabhängigkeit wurde erreicht.
Die verfügbaren SGML-Werkzeuge sind in der Lage, auch sehr große Dokumente mit mehreren hundert Grafiken mediengerecht für verschiedene Darstellungsformen aufzubereiten.
Damit wurden die in die Entwicklung der MSRSW-DTD gesetzten Ziele vollständig erreicht.


4. MSR-Aktivitäten: Ausblick

MSR-Standards in der Praxis
4. MSR-Aktivitäten: Ausblick

Nach diesem Erfahrungsbericht über die bisherigen MSR Ergebnisse und deren Praxiseinsatz zum Schluß ein Ausblick auf zukünftige Aktivitäten.


4.1. Neue MSR-Arbeitsgruppe: Prozeßsynchronisation

MSR hat bisher das Thema der Entwicklungszusammenarbeit zwischen Automobilhersteller und Zulieferer vor allem aus Sicht der für den Datenaustausch erforderlichen Schnittstellen betrachtet (Abb. 10). Es wurden Dokumentstrukturen vereinbart, die den Anforderungen an diese Schnittstellen gerecht werden. Im Verlauf eines Entwicklungsprozesses werden diese Dokumentstrukturen gefüllt, die Inhalte auch mehrfach geändert, bis am Ende die Befüllung vollständig ist und die Inhalte serientauglich sind.
Abbildung 11:
'
Abb. 10
Bei der Durchführung von Entwicklungskooperationen zeigte sich, daß mit der Schnittstellensicht alleine noch keine reibungslose und effiziente Zusammenarbeit erreichbar ist. Es bleiben Fragen offen wie: Wann muß eine bestimmte Information vorliegen? Ab wann kann ich mich auf eine vorliegende Information verlassen? Wann darf eine Information nicht mehr verändert werden, weil die Änderung gravierende Auswirkungen hätte? usw.
In allen diesen Fragen steckt der zeitliche Aspekt der Zusammenarbeit und die Frage, welche Qualität die Informationen zu einem gegebenen Zeitpunkt haben müssen. Es ist die Frage nach der Synchronisation der Entwicklungsprozesse zwischen den an der Kooperation beteiligten Partnern.
Aufgrund dieser Erkenntnis haben die an MSR beteiligten Firmen sich entschlossen, eine neue MSR Arbeitsgruppe zu gründen, deren Aufgabe es ist, diese Synchronisationsprobleme zu untersuchen und ein Instrumentarium zu schaffen, mit dem zu Beginn von Entwicklungskooperationen sehr schnell und für alle Partner verständlich und eindeutig Synchronisationspunkte vereinbart werden können. Die AG hat Ihre Arbeit im Oktober dieses Jahres aufgenommen und soll Ende nächsten Jahres Ergebnisse vorlegen.


4.2. Nächste Schritte

Neben der Erarbeitung einer unternehmensübergreifenden Prozeßsynchronisation werden wir die Pflege und Weiterentwicklung der in Kapitel 2 vorgestellten Dokument-Typ-Definitionen fortführen. Diese Weiterentwicklung wird in enger Zusammenarbeit mit den ASAM Arbeitskreisen erfolgen (Abb.11). Als Vorbereitung dieser Zusammenarbeit hat bereits ein Workshop stattgefunden, in dem eine Roadmap für das kommende Jahr vereinbart wurde.
Abbildung 12:
'
Abb. 11
Um die Vorteile der MSR-Standards zu nutzen, die sich in den Pilotprojekten gezeigt haben, ist natürlich der flächendeckende Einsatz dieser Standards eines der wichtigsten Themen. Dieser Einsatz sollte nicht auf die an MSR beteiligten Firmen beschränkt bleiben, sondern möglichst flächendeckend in der ganzen Automobilindustrie erfolgen. Fragen, Anregungen und Diskussionen sind jederzeit willkommen. Ansprechpartner finden Sie unter der MSR Hompage, die Adresse ist in Bild 11 angegeben.


5. Literaturverzeichnis

MSR-Standards in der Praxis
5. Literaturverzeichnis

/MSR92-1/ J. Leohold (1992): Das MSR-Projekt: Werkzeugunterstützung für neue Wege der Zusammenarbeit zwischen Automobilhersteller und Zulieferer. VDI-Berichte 1009, S. 491
/MSR92-2/ K. G. Besel, T. Hirth (1992): Werkzeuge im MSR-Projekt VDI-Berichte 1009, S. 503
/MSR94/ M. Reinfrank, Regensburg Modellbasierte Funktionsentwicklung für Motorsteuerungen – Ein Pilotprojekt in der MSR-Entwicklungsumgebung MESA; VDI-Berichte 1152, S. 253
/MSR98/ Das MSR-Projekt im Internet http://www.msr-wg.de
Früher: Meß-, Steuer- und Regelungstechnische Systeme