DE10131438B4 - Verfahren zur Entwicklung einer technischen Komponente - Google Patents

Abstract

Verfahren zur Entwicklung einer technischen Fahrzeug-Komponente, insbesondere Software-Komponente,
– bei dem mittels eines Software-Entwicklungswerkzeuges (1) mit graphischer Benutzeroberfläche ein Modell zur Entwicklung und Simulation der Eigenschaften der technischen Fahrzeug-Komponente erstellt wird,
– bei dem an einer Schnittstelle des Software-Entwicklungswerkzeugs (1) Modellinformationen bezüglich des Modells und der Simulation der Eigenschaften der modellierten technischen Komponente bereitgestellt werden,
– bei dem einzelnen Modellinformationen mindestens eine Attributsinformation zugewiesen wird,
– die Attributsinformation strukturiert, also in Datenfeldern nach spezifischer Information, abgelegt wird, wobei die Daten technische Spezifikationen und beschreibende Informationen für mindestens einen Bestandteil der technischen Komponente enthalten und
– die Attributsinformation zu Dokumentations- und Prüfzwecken in einem Speichermittel (3) abgelegt wird,
dadurch gekennzeichnet,
dass
– das Modell aus Modellelementen aufgebaut wird, die hierarchisch in einer Baumstruktur aus mehreren Typen von Modellelementen zusammengesetzt wird, nämlich die oberste Hierarchieebene Modell, als Baumwurzelknoten, und mindestens eine der Hierarchieebenen Module,...

Description

• Die Erfindung betrifft ein Verfahren zur Entwicklung einer technischen Fahrzeug-Komponente, insbesondere Software-Komponente.
• Die Bedeutung von Software nimmt bei der Erstellung von technischen Komponenten immer mehr zu. Besonders bei hybriden Systemen, die Hardware- und Software-Komponenten beinhalten, zeigt sich dies deutlich. Beispielsweise besitzen X-by-Wire-Systeme in Fahrzeugen neben der eigentlichen Hardware-Komponente eine komplizierte Steuerungssoftware.
• Durch die zunehmende Komplexität der aktuellen Systeme steigt der Entwicklungsaufwand. Das Fehlerrisiko im Produkteinsatz nimmt zu. Aus diesem Grunde spielen die Entwicklungs-Methoden und -Werkzeuge eine zentrale Rolle. Die effektive und zuverlässige Entwicklung innovativer Systeme, wie beispielsweise Weiterentwicklungen auf dem Gebiet der elektronischen Stabilisierung von Fahrzeugen, werden mit Hilfe mächtiger graphischer Werkzeuge durchgeführt, durch die eine Erhöhung des Abstraktionsniveaus und die Möglichkeit zur automatischen Implementierung gegeben ist.
• Die Dokumentation für derartige Systementwicklungen ist problematisch, da diese eine Beschreibung des Systems, der Schnittstellen, der Module, usw. für verschiedene Benutzergruppen wie Entwickler, Anwender, Projektleiter, Manager und verschiedene Zielrichtungen wie Nachweis der Erfüllung eines Standards, Pflichten-/Lastenhefterstellung, Tests, Schulung von Anwendern, Tätigkeitsbericht zur Verfügung stellen muss. Zudem soll die Dokumentation auch strukturierte Informationen enthalten, die es erlauben Spezifikationen, wie beispielsweise Typ, Wertebereich, Einheit von Variablen, zu dokumentieren.
• Aus der EP 0 451 371 B1 ist ein Verfahren zur Aufbereitung und Verarbeitung von produktbeschreibenden Daten innerhalb eines mehrstufigen Entwicklungsprozesses bekannt. Hierbei werden die produktbeschreibenden Daten strukturiert und der Datenzugriff auf die produktbeschreibenden Daten für die verschiedensten Prozesse vereinfacht. Das Verfahren eignet sich insbesondere zum computerunterstützten Design von integrierten Halbleiterschaltungen.
• In der US 5 995 969 A ist ein Metamodellsystem für Daten bzw. Datenbehälter einer computerunterstützten Softwareentwicklung (CASE – computer aided software engineering) offenbart. Das Metamodellsystem basiert auf der Methodik von Prozessen mittels strukturierter Techniken, insbesondere unter Einsatz von Informationsquelleverzeichnissen (IRDS – Iformation resource dictionary system), welche vom CASE-Werkzeug generierte Daten speichert und zur Verfügung stellt.
• Aus der DE 199 55 481 A1 ist ein Verfahren zur maschinellen Abbildung, Integration und Steuerung von Unternehmensprozessen, Produkten und IT-Strukturen sowie -Architekturen für ein Gesamtsystem bekannt. Die offenbarte integrierte Methodologie ist ein mehrdimensionales und mehrstufiges Modell, wobei diese das Gesamtarchitekturmodell für Informationssysteme und Produkte, Dienste sowie Netze umfasst, das aus vier hierarchischen Konzetionsebenen besteht, die jeweils die Methodik des Vorgehens und die Modellierung integrativ beschreiben.
• In der EP 694 835 A1 ist ein Verfahren zur automatischen Erstellung von Software-Dokumentation offenbart. Hierbei wird die Dokumentationsinformation direkt im Quellcode abgelegt. Mit Hilfe von Dokumentations-Schlüsselwörtern und -Regeln, kann die Dokumentationsinformation beim Kompiliervorgang extrahiert und verarbeitet werden. Hierzu muss der Kompilierer um die grammatikalische Analysefähigkeit erweitert werden. Die erstellte Dokumentation hat nur beschreibenden Charakter, kann also keine Überprüfung der Implementierung vornehmen. Um eine aktuelle Dokumentation zu erhalten, muss erst der Kompiliervorgang durchgeführt werden.
• In der EP 877 318 A1 ist ein Verfahren und eine Vorrichtung zur. Dokumentationserstellung von Prozessmodellen, die über Software realisiert sind, offenbart. Bei diesem Verfahren werden Dateien mit den Modelldefinitionen zur Verfügung gestellt. Ausgehend von diesen Definitionsdateien wird automatisch eine Berichtsdatei erstellt, die den Inhalt für den menschlichen Benutzer verständlich aufbereitet. Zudem ist es möglich Konsistenzprüfungen zwischen den verschiedenen Modelldefinitionsdateien durchzuführen. Kontrollinformationen wie beispielsweise Tabellen, die Auskunft darüber geben, wie oft ein definiertes Feld in den verschiedenen definierten Prozeduren verwendet wird, können ebenfalls generiert werden. Fehlermeldungen, die bei der Berichtserstellung generiert werden, können in einer separaten Datei abgelegt werden.
• Durch die Trennung von Implementierung und Dokumentation/Spezifikation kommt es immer wieder zu Inkonsistenzen und Widersprüchen zwischen den beiden Darstellungen. Oftmals sind die Dokumente unvollständig, da diese in verschiedenen Sichten und/oder Formaten vorliegen, wie Online-Hilfe, Schnittstelle-Dokumentation, vollständige Systemdokumentation, Lasten- oder Pflichtenheft. Da die Dokumentation meist auf eine beschreibende Funktion beschränkt ist, also nicht strukturiert hinterlegt ist, sind derartige Probleme nicht durch eine automatische Prüfung aufzudecken. Durch die Vielzahl der Dokumente, die zur Dokumentation eines Systems gehören, wird die Problematik noch verschärft. Wenn noch in Betracht gezogen wird, dass diese Systeme meist in langfristig angelegten Projekten mit großen Teams realisiert werden, ist die Gefahr inkonsistenter und unvollständiger Dokumentation traditionell sehr hoch. Zudem können Informationen zur Spezifikation der technischen Komponente, die im Allgemeinen in verschiedenen Dokumenten abgelegt sind, nicht als Grundlage einer automatischen Prüfung zur Verfügung gestellt werden.
• Es ist nun die Aufgabe der vorliegenden Erfindung das eingangs beschriebene Verfahren derart weiterzubilden, dass Dokumentations- und/oder Spezifikationsinformationen bei der Entwicklung einer technischen Komponente in Verbindung mit den Modellinformationen des Software-Entwicklungswerkzeugs abgelegt werden. Ziel ist es die Trennung von Modell-Implementierung und Dokumentation/Spezifikation sowie der damit verbundenen Nachteile aufzuheben. Zudem soll das Verfahren auf Basis dieser Informationen eine Prüfung der Spezifikations- und Dokumentationsinformationen ausführen. Ferner wird eine Vorrichtung zur Durchführung des Verfahrens aufgezeigt.
• Diese Aufgabe wird erfindungsgemäß durch die Merkmale des Anspruchs 1 gelöst. Danach wird einzelnen Modellinformationen mindestens eine Attributsinformation zugewiesen. Die Attributsinformation wird in strukturierter Form, also in Datenfeldern nach spezifischer Information, abgelegt. Die in den Attributsinformationen strukturiert abgelegten Daten enthalten technische Spezifikationen und/oder beschreibende Information für mindestens einen Bestandteil der technischen Komponente. Die Attributsinformation wird in einem Speichermittel zu Dokumentations- und/oder Prüfzwecken abgelegt.
• Die Modellinformationen bilden die Informationen über die Modellelemente des Modells der technischen Komponente innerhalb des Software-Entwicklungswerkzeugs ab. Das Software-Entwicklungswerkzeug wird im Allgemeinen als geschlossenes System gekauft, so dass nur die vom Hersteller des Entwicklungswerkzeugs vorgesehenen Informationen bei der Entwicklung der Komponente in den Modellinformationen abgelegt werden können. Wie obige Ausführung gezeigt hat, ist dies bei weitem nicht ausreichend.
• Da die technische Komponente aus den einzelnen Modellelementen des Software-Entwicklungswerkzeugs modelliert wird und die Modellinformationen an der Schnittstelle zur Verfügung stehen, wird der Entwickler oder andere Anwender mit Hilfe dieses Verfahrens in die Lage versetzt zusätzliche Informationen ablegen zu können. Dies hat den Vorteil, dass Implementierung im Modell und Dokumentation/Spezifikation kombiniert werden können.
• Hierzu wird diesen Modellinformationen eine Attributsinformation zugewiesen, die einerseits technische Spezifikationen wie Wertebereich, Datentyp, Einheit, Gradient und beschreibende Information wie Erstelldatum, Name des Entwicklers, Funktionsbeschreibung enthält. Hervorzuheben ist, dass die Daten strukturiert, also in Datenfeldern nach spezifischer Information, abgelegt und gespeichert werden. Die Datenfelder richten sich nach dem spezifischen Dateninhalt. So ist beispielsweise die beschreibende Information „Erstelldatum" in einem separaten Feld mit Datentyp „Datum" und nicht in einem Feld mit Datentyp „Text" abgelegt. Dies hat den Vorteil, dass die Daten strukturiert weiterverarbeitet werden können. Beispielhafte Anwendungen wären Prüfung auf Vollständigkeit der Attributsinformationen oder automatische Dokumentationserstellung.
• Das Speichern der Attributsinformationen hat auch den Vorteil, dass der Entwickler oder andere Anwender jederzeit Zugriff auf den aktuellen Stand hat.
• Bei einer Weiterbildung des erfindungsgemäßen Verfahrens werden für die Attributsinformationen Prüfregeln festgelegt. Da die Daten der Attributsinformation strukturiert abgelegt sind, können entsprechende Prüfregeln festgelegt werden. In erster Linie werden hiermit die Regeln zur Prüfung des Datentyps, des Datenformats, der Einheiten, des Gradienten, des Namens bzw. der Namenskonvention festgelegt. Weiterführende Regeln beinhalten beispielsweise, welche Datentypen und -variablen zur beschreibenden Dokumentation zu zählen sind. Oder die Prüfregel legt fest, dass die technische Spezifikation in einer Attributsinformation bezüglich eines bestimmten Modellelements bestimmte Datenfelder enthalten muss. Beispielsweise kann für ein Modellelement „Parameter" als Attributsinformation Einheit, Datentyp und Wertebereich gefordert sein.
• Das Festlegen der Prüfregeln hat den Vorteil, dass die Prüfung an die anwendungsspezifische Situation angepasst werden kann. Je nach Entwicklungsstand des Modells können unterschiedliche Prüfungsroutinen notwendig sein. So kann am Beginn der Entwicklung als Ziel die Lastenhefterstellung sein, so dass vor allem die beschreibende Dokumentation in den Attributsinformationen abgeprüft wird. Hingegen wird bei Ende der Entwicklungsarbeiten die technische Umsetzung im Vordergrund stehen, so dass die Prüfregeln sich stärker auf die technische Spezifikation der Attributsinformation konzentrieren.
• Bei einer Weiterbildung des erfindungsgemäßen Verfahrens, wird anhand der Prüfregeln eine Prüfung auf Vollständigkeit der vorhandenen Attributsinformationen ausgeführt. Beispielsweise kann vor der Erstellung einer Dokumentation für die technische Komponente geprüft werden, ob in den Attributsinformationen die beschreibende Dokumentation vollständig ausgefüllt ist. Die Vollständigkeitsprüfung ist ebenfalls notwendig, wenn bestimmte Eigenschaften einer technischen Komponente anhand des Modells überprüft werden sollen, da in diesem Fall sichergestellt sein muss, dass die technischen Spezifikationen in den entsprechenden Attributsinformationen vorhanden ist.
• Das erfindungsgemäße Verfahren lässt sich in vorteilhafter Weise weiterbilden, indem anhand der Prüfregeln die Attributsinformation mit den aktuell erfassten und mit diesen korrespondierenden Modellinformationen auf Konsistenz, also Übereinstimmung, geprüft wird.
• Der Fokus liegt hier in der Simulation der Eigenschaften des Modells mittels des Software-Entwicklungswerkzeugs und der Prüfung auf Übereinstimmung mit der in den korrespondierenden Attributsinformation abgelegten technischen Spezifikation. Auf diese Weise kann sichergestellt werden, dass die technische Komponente die spezifizierten Anforderungen erfüllt. Bei der Überprüfung sind vor allem Schnittstellen innerhalb des Modells der technischen Komponente betroffen, da an diesen Stellen im Allgemeinen Daten übergeben werden. Die Schnittstellen-Spezifikationen wie Datentyp, Wertebereich, Einheit, usw. müssen von den Daten erfüllt werden, damit diese von einer Schnittstelle zu nächsten Schnittstelle übergeben werden können. Ein großer Vorteil des Verfahrens ist es, dass diese Fehler durch die Konsistenzprüfung aufgedeckt werden können.
• Bevorzugt werden in diesem Verfahren verschiedene Datensichten mit Attributs- und/oder Modellinformationen zur automatischen Dokumentation statisch und/oder dynamisch generiert. Dabei werden aus den Attributsinformationen Darstellungen mit Funktionen und/oder Grafiken erzeugt.
• An der Schnittstelle kann leicht auf die Attributs- wie auch auf die Modellinformationen zugegriffen werden. Über verschiedene Sichten der Daten, können diese Informationen für die spezifische Benutzergruppe und/oder Anwendung selektiert werden. Beispielsweise muss für ein technisches Handbuch einen komplexerer Teil der Daten zur Verfügung gestellt werden, als für einen Tätigkeitsbericht. Der Vorteil dieses Verfahrens ist, dass die Modellinformation und die Attributsinformation zusammen vorhanden ist. Damit ist sichergestellt, dass die spezifi sche Information für spezifische Benutzer und spezifische Anwendungen zur Verfügung gestellt werden kann. Die Nachteile der getrennten Datenführung in verschiedenen Systemen, wie sie eingangs erwähnt wurden, entfällt dadurch.
• Es gibt nun verschiedene Möglichkeiten, die Lehre der vorliegenden Erfindung in vorteilhafter Weise auszugestalten und weiterzubilden. Dazu ist einerseits auf die untergeordneten Ansprüche und andererseits auf die nachfolgende Erläuterung einer Ausführungsform zu verweisen. Es sollen auch die vorteilhaften Ausgestaltungen einbezogen sein, die sich aus einer beliebigen Kombination der Unteransprüche ergeben. In der Zeichnung ist eine Ausführungsform des erfindungsgemäßen Verfahrens und eine entsprechende Vorrichtung dargestellt. Es zeigen jeweils in schematischer Darstellung,
• 1 eine Vorrichtung zur Durchführung des erfindungsgemäßen Verfahrens und
• 2 hierarchisches Baummodell eines Software-Entwicklungswerkzeuges zur Durchführung des erfindungsgemäßen Verfahrens.
• Eine Vorrichtung zur Durchführung des erfindungsgemäßen Verfahrens ist in 1 als Modulsystem abgebildet. Das Grundmodul 1 steht für ein graphisches Entwicklungswerkzeug zur Erstellung und Simulation hybrider Komponenten.
• Das Dokumentationsmodul 2 ist eigenständig über die Benutzeroberfläche 4 nutzbar. Anhand der Benutzeroberfläche 4 erfolgt die interaktive Pflege sowie das Nachschlagen der Attributsinformationen. Zudem sorgt das Dokumentationsmodul 2 für die Zuordnung der Attributsinformation zu den Modellelementen und speichert diese Information zusammen mit den Attributsinformationen in der Datenbank 3. Die gestrichelte Verbindungslinie 7 soll andeuten, dass die Benutzeroberfläche mittels Zugangspunk ten an den jeweiligen Modellelementen aus dem Software-Entwicklungswerkzeug heraus aufrufbar ist.
• Das Prüfmodul 5 hat Zugriff auf das Dokumentations- und Grundmodul, um die Prüfungen durchzuführen und das Ergebnis direkt interaktiv oder mittels des Berichtmoduls zu dokumentieren. Vor dem Ausführen einer Prüfung, müssen erst die korrespondierenden Prüfregeln festgelegt werden. Standard-Prüfungen sind die Prüfungen auf Vollständigkeit und Konsistenz.
• Das Berichtsmodul 6 hat Zugriff auf die Informationen der Datenbank 3 des Dokumentationsmoduls 2 und auf die Informationen des Software-Entwicklungswerkzeugs 1. Anhand dieser Informationen generiert das Berichtsmodul 6 Darstellungen, d.h. Sichten in verschiedenen Formaten.
• Die einzelnen Module 1,2,5 und 6 können auch auf verschiedenen Rechnersystemen laufen. Es muss nur sichergestellt werden, dass die einzelnen Module Zugriff auf die Attributs- und/oder Implementierungsinformationen besitzen.
• Beispielhaft ist als Software-Entwicklungswerkzeug MAT-LAB/SIMULINK eingesetzt worden, wobei auch jedes andere Entwicklungswerkzeug genommen werden kann, das über entsprechende Schnittstellen zum Zugriff auf die Modellinformationen besitzt. MATLAB/SIMULINK hat den Vorteil, dass es über eine eigene Skriptsprache verfügt an Hand derer der Zugriff auf die Modellinformationen gegeben ist und die Module 2, 5 und 6 umgesetzt wurden.
• Das Software-Entwicklungswerkzeug MATLAB/SIMULINK gibt ein hierarchisches Modell vor. In diesem Modell werden Modellelemente sowie Modellelemente-Eigenschaften definiert. In 2 ist eine graphische Abbildung der Hierarchie für die Modellelemente dargestellt. Auf der untersten Ebene befinden sich die elementaren Modellelemente 10, 11, 12. Diese sind Blöcke 10, also Schaltelemente, Signale 11 und Parameter 12. Die hierarchische Anordnung entspricht einer Baumstruktur, wobei die oberste Ebene vom Element Modell 8 gebildet wird. Die folgenden Ebenen werden durch Module 9 gebildet. In der 2 ist dies ebenfalls durch folgende UML-Notation veranschaulicht: Die Raute 13 steht für „besteht aus", der schwarzgefüllte Kreis 15 steht für eine „1...n-Beziehung" und der weißgefüllte Kreis 14 steht für eine „0...n-Beziehung".
• Die Modellelemente beinhalten Modellinformationen. So müssen einem Block Eigenschaften wie Position in der Hierarchie, Name, Verstärkungsfaktor, usw. zugewiesen werden. Bei Signalen beinhalten die Eigenschaften die Angabe von Quelle und Ziel, Verlauf oder Namen. Signale könne visuell zu Vektoren oder Bussen gruppiert werden. Der Verbund hat dann zusätzliche Eigenschaften wie Anzahl und Namen der Signalelemente. Das elementare Modellelement Parameter hat als Eigenschaft Variablennamen und Wert.
• Über das Dokumentationsmodul 2 werden die den Modellelementen korrespondierenden Attributsinformationen zugeordnet. Hierzu müssen innerhalb des Dokumentationsmoduls 2 zu den Modellelementen gehörende Attributselemente hinterlegt werden. Diese sind MDLSPEC für das oberste Modul, SYSSPEC für Module und Knoten innerhalb der Hierarchieebenen, PARASPEC für die Parameter und SIGSPEC mit IN-/OUTSPEC für die Signale. Für jedes dieses Attributselemente steht ein entsprechendes GUI (Graphical User Interface), also ein Zugangspunkt zur Benutzeroberfläche 4 des Dokumentationsmoduls 2 auf der graphischen Benutzeroberfläche des Software-Entwicklungswerkzeugs MATLAB/SIMULINK, zur Eingabe zur Verfügung.
• Das bedeutet beispielsweise, dass für das Modellelement Parameter die zusätzliche Angabe von Spezifikationen wie Einheit, Datentyp, Wertebereich, oder Gradient, sowie die Angabe der beschreibenden Informationen wie Funktion, Autor, Entstehungszeitpunkt, usw. über das GUI PARASPEC innerhalb des graphischen Entwicklungswerkzeugs erfolgt.
• Für die Steuerung der Benutzerberechtigung wurde das dem Entwicklungswerkzeug MATLAB/SIMULINK zugrunde liegende Tool benutzt.
• Bei der Eingabe wird über das Dokumentationsmodul 2 bereits eine Syntaxprüfung durchgeführt. So wird geprüft ob ein bestimmter Datentyp existiert, ob der Wert für diesen Datentyp korrekt ist oder ob der Wertebereich mit dem Wert und dem Datentyp vereinbar ist.
• Die eigentliche Prüfung erfolgt über das Prüfmodul 5. Hier werden die Eigenschaften, die im Entwicklungswerkzeug hinterlegt sind, mit dem im Dokumentationsmodul 2 hinterlegten Attributsinformation auf Vollständigkeit und Konsistenz geprüft. Die Prüfung kann statisch oder dynamisch erfolgen. Bei der statischen Prüfung liegt der Schwerpunkt in dem Vergleich von sich entsprechenden Feldinhalten zwischen Modell- und Attributsinformation. Bei der dynamischen Prüfung kann beispielsweise in Verbindung mit einer Simulation zusätzlich dafür gesorgt werden, dass Feldinhalte auf der Modellseite ganze Wertebereiche durchlaufen. Die Prüfung kann innerhalb des Entwicklungswerkzeugs 1 oder über die Benutzeroberfläche 4 des Dokumentationsmoduls 2 gestartet werden.
• In Bezug auf die Vollständigkeit wird geprüft, ob Felder ausgefüllt sind. Die Prüfregeln legen fest, welche Felder dies betrifft. Die Prüfregel kann sich je nach Entwicklungsstand ändern. Beispielsweise wird bei der Lastenhefterstellung in der Hauptsache nur das Ausfüllen der beschreibenden Informationen gefordert, während hingegen kurz vor Fertigstellung alle Werte hinterlegt sein müssen. Zudem wird an dieser Stelle geprüft, ob die Eindeutigkeit der Informationen im Entwicklungswerkzeug 1 und/oder im Dokumentationsmodul 2 gegeben ist.
• Bei der Prüfung auf Konsistenz zwischen den im Dokumentationsmodul 2 abgelegten Attributsinformationen und den im Software- Entwicklungswerkzeug aktuell erfassten und korrespondierenden Modellinformationen, liegt der Schwerpunkt auf dem Test des modellierten Systems. Beispielsweise wird auf diese Weise geprüft ob der Wertebereich, der Datentyp oder der Gradient von Parametern der erstellten Komponente eingehalten wird. Von großer Bedeutung ist diese Prüfung bei Schnittstellen, also Signalverbindung zwischen zwei Modulen. Die Prüfung muss dann feststellen, ob derselbe Datentyp übergeben wird, ob der übergebene Wert im Wertebereich der Schnittstelle liegt oder ob die Einheiten übereinstimmen. Hier kann die Prüfung um einen Automatismus erweitert werden. An Schnittstellen existiert oft das Problem, dass zwischen zwei Schnittstellen verschieden Einheiten, beispielsweise m/s und km/h festgelegt sind. Die Prüfroutine kann auch selbstständig diese Fehler korrigieren indem diese die Einheiten selbstständig anpasst und die Umrechnung vornimmt.
• Die Konsistenzprüfung erfolgt auch direkt mittels Prüfsonden im Entwicklungswerkzeug, indem diese beispielsweise an Zugangspunkte für Signale gesetzt werden. An diese Zugangspunkten wird die entsprechende Attributsinformation mit dem aktuellen Ergebnis für die Signalwerte verglichen.
• Das Berichtsmodul 6 ist über die Benutzeroberfläche 4 des Dokumentationsmoduls 2 aktivierbar. Da die GUI zur Pflege der Attributsinformationen über die graphische Benutzeroberfläche des Entwicklungswerkzeugs 1 erfolgt, ist es nicht notwendig über das Berichtsmodul 6 eine ONLINE-Hilfe zur Verfügung zu stellen. Über das Berichtsmodul 6 werden Systembeschreibungen für einzelne Module oder das Gesamtsystem in HTML-Layout erstellt. Zuvor werden die Elemente und die Felder der Modell- und/oder Attributsinformationen, die für den Bericht ausgegeben werden sollen, festgelegt. Da es sich bei MATLAB/SIMULINK um ein graphisches Software-Entwicklungswerkzeug handelt stehen auch graphische Informationen zur Verfügung, die über das Berichtsmodul 6 ebenfalls verarbeitet werden.

Claims (12)

1. Verfahren zur Entwicklung einer technischen Fahrzeug-Komponente, insbesondere Software-Komponente, – bei dem mittels eines Software-Entwicklungswerkzeuges (1) mit graphischer Benutzeroberfläche ein Modell zur Entwicklung und Simulation der Eigenschaften der technischen Fahrzeug-Komponente erstellt wird, – bei dem an einer Schnittstelle des Software-Entwicklungswerkzeugs (1) Modellinformationen bezüglich des Modells und der Simulation der Eigenschaften der modellierten technischen Komponente bereitgestellt werden, – bei dem einzelnen Modellinformationen mindestens eine Attributsinformation zugewiesen wird, – die Attributsinformation strukturiert, also in Datenfeldern nach spezifischer Information, abgelegt wird, wobei die Daten technische Spezifikationen und beschreibende Informationen für mindestens einen Bestandteil der technischen Komponente enthalten und – die Attributsinformation zu Dokumentations- und Prüfzwecken in einem Speichermittel (3) abgelegt wird, dadurch gekennzeichnet, dass – das Modell aus Modellelementen aufgebaut wird, die hierarchisch in einer Baumstruktur aus mehreren Typen von Modellelementen zusammengesetzt wird, nämlich die oberste Hierarchieebene Modell, als Baumwurzelknoten, und mindestens eine der Hierarchieebenen Module, Blöcke, Signale oder Parameter, – die Modellelemente durch die Modellinformationen beschrieben werden, – den Modellelementen ihrem Typ entsprechende Attributselemente zugeordnet werden, womit genau ein Attributselement für die oberste Hierarchieebene, ein Attributselement für jedes Modul innerhalb der Hierarchieebenen, zugeordnet wird, – die Zuordnung der Attributselemente zu den Modellelementen in dem Speichermittel (3) gespeichert werden, – dass für jedes dieser Attributselemente ein Zugangspunkt zu einer Benutzeroberfläche (4) zu Dokumentations- und Prüfzwecken auf der graphischen Benutzeroberfläche des Software-Entwicklungswerkzeugs zur Verfügung gestellt wird, – dass die Zugangspunkte für die Benutzeroberfläche (4) unmittelbar an den jeweiligen Modellelementen des Software-Entwicklungswerkzeugs (1) platziert werden und – dass die Bearbeitung der Attributselemente anhand eines Funktionsmoduls innerhalb des Software-Entwicklungswerkzeugs (1) erfolgt.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass mittels der Benutzeroberfläche (4) die Attributsinformationen aus dem Speichermittel (3) als ONLINE-Hilfe in dem Software-Entwicklungswerkzeug (1) zur Verfügung gestellt werden.
3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass Berechtigungsstrukturen zur Bearbeitung von Attributsinformationen anhand von Benutzergruppen und/oder einzelner Benutzer vergeben werden.
4. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass bei Eingabe der Attributsinformation eine Syntax-Prüfung ausgeführt wird.
5. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass für die Attributsinformation Prüfregeln festgelegt werden.
6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass die Prüfung dynamisch in Verbindung mit einer Simulation erfolgt.
7. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass anhand der Prüfregeln eine Prüfung auf Vollständigkeit der vorhandenen Attributsinformationen ausgeführt wird.
8. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass anhand der Prüfregeln die Attributsinformationen mit den aktuell erfassten und mit diesen korrespondierenden Modellinformationsdaten auf Konsistenz geprüft werden.
9. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass verschiedene Datensichten mit Attributs- und/oder Modellinformationen zur automatischen Dokumentation statisch und/oder dynamisch generiert werden.
10. Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass in den Datensichten graphische Modellinformationen aus dem Software-Entwicklungswerkzeug (1) mit den Attributsinformationen verbunden werden.
11. Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass die Datensichten benutzer- und anwendungsspezifisch generiert werden.
12. Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass die Datensichten in HTML erstellt werden.