DE102017127400A1

DE102017127400A1 - Festschreiben von technischen Entwicklungsdaten

Info

Publication number: DE102017127400A1
Application number: DE102017127400.6A
Authority: DE
Inventors: Dirk Stichling; Jobst Richert; Michael Beine; Ansgar KUHLMANN; Thomas MISCH
Original assignee: Dspace GmbH; Dspace Digital Signal Processing and Control Engineering GmbH
Current assignee: Dspace GmbH; Dspace Digital Signal Processing and Control Engineering GmbH
Priority date: 2017-11-21
Filing date: 2017-11-21
Publication date: 2019-05-23
Also published as: US20190155256A1; US11016471B2

Abstract

Die vorliegende Erfindung ist gerichtet auf ein Verfahren zur teilautomatisierten Verwaltung von technischen Entwicklungsdaten, welche sich beispielsweise auf eine Testkonfiguration eines Steuergeräts bzw. eines Endgeräts beziehen. Insbesondere bietet die vorliegende Erfindung ein Verfahren zum Festschreiben von Datenobjekten, welche technische Entwicklungsdaten modellieren, und insbesondere eine neuartige Adressierung technischer Datenbanken. Die vorliegende Erfindung ist ferner gerichtet auf eine Rechenanordnung zur Entwicklungsdatenverwaltung sowie auf ein Computerprogrammprodukt mit Steuerbefehlen, welche das vorgeschlagene Verfahren implementieren bzw. die vorgeschlagene Rechenanordnung betreiben.

Description

Die vorliegende Erfindung ist gerichtet auf ein Verfahren zur teilautomatisierten Verwaltung von technischen Entwicklungsdaten, welche sich beispielsweise auf eine Testkonfiguration eines Steuergeräts bzw. eines Endgeräts beziehen. Insbesondere bietet die vorliegende Erfindung ein Verfahren zum Festschreiben von Datenobjekten, welche technische Entwicklungsdaten modellieren und insbesondere eine neuartige Adressierung technischer Datenbanken. Die vorliegende Erfindung ist ferner gerichtet auf eine Rechenanordnung zur Entwicklungsdatenverwaltung sowie auf ein Computerprogrammprodukt mit Steuerbefehlen, welche das vorgeschlagene Verfahren implementieren bzw. die vorgeschlagene Rechenanordnung betreiben.
WO 00/67156 A1 zeigt eine semantische Modellierung von Dateneinheiten, ohne hierbei auf technische Spezifikationen einzugehen. Generell zeigt diese Druckschrift ein Verwalten von Datenobjekten mitsamt spezifizierbarer Relationen.
Bekannt ist es, bei Steuergeräten Testszenarien zu erschaffen, welche beispielsweise derart modelliert werden, dass Umgebungsparameter nicht tatsächlich realweltlich vorliegen, sondern vielmehr werden diese anhand von Modellen spezifiziert und sodann bei einem Test eines Steuergeräts eingelesen. Hierbei müssen also nicht auf eine Versuchsanordnung physische Kräfte tatsächlich einwirken, sondern vielmehr können solche Kräfte als elektronische Steuersignale modelliert und in ein Testmodell eingespeist werden. Somit ist es also möglich, einen Test lediglich zu simulieren und nicht realweltlich auszuführen. Dies spart nicht nur Kosten, sondern kann auch beliebig oft durchgeführt werden, wobei empirische Daten gesammelt werden. In diesem Anwendungsszenario ist es notwendig, Umgebungsparameter zu modellieren und gleichzeitig auch ein Anforderungsprofil zu modellieren. Typischerweise führen Steuergeräte komplexe Prozesse aus und es ist eine Vielzahl von Konfigurationsparametern notwendig, um ein Steuergerät ausreichend zu testen, bevor es im Feld zum Einsatz kommt.
Ein solches Modellieren von Testdaten ist zum einen arbeitsintensiv, da entsprechende Modelle sehr umfangreich werden können, und ferner ist ein solches Modell fehleranfällig, falls menschliche Eingaben zu berücksichtigen sind. Da es eine technische Anforderung an ein solches Verfahren ist, dass dieses beliebig oft zu wiederholen ist und zudem zugrundeliegende Daten umfangreich sind, bedarf es einer neuartigen Entwicklungsdatenverwaltung, welche speziell auf Entwicklungsdaten von Steuergeräten Rücksicht nimmt. Hierbei besteht u. a. Bedarf daran, unterschiedliche Versionen von Testkonfigurationen zu schaffen und diese separat von generischen Daten, welche weiterentwickelt werden, bereitzustellen. Somit sind herkömmliche semantische Netze an sich nicht geeignet, eine entsprechende Entwicklungsdatenverwaltung zu unterstützen, sondern vielmehr bedarf es zusätzlicher Operationen, welche dem technischen Anwendungsgebiet Rechnung tragen.
Datenmanagementsysteme sind dafür ausgelegt, eine große Menge an unterschiedlichen Daten zu verwalten und insbesondere auch in Beziehung zu setzen. Im Zuge der Verwaltung spielt der Aspekt „Version Control“ bzw. „Configuration Management“ eine große Rolle. D. h. solche Systeme verwalten nicht nur den aktuellen Stand der Daten, sondern müssen auch in der Lage sein, eine bestimmte Menge an Daten festzuschreiben, so dass diese Daten später wieder exakt reproduziert werden können.
Bei dateibasierten Systemen werden Mechanismen wie „Baselining“ oder „Checkpoints“ genutzt, um für eine definierte Menge an Dateien einen Stand festzuschreiben. In der Regel ist es so, dass der Anwender selbst vorgibt, welche Dateien in die Baseline/Checkpoint aufgenommen werden sollen. Typischerweise macht er das derart, dass er die Dateien in Ordnern strukturiert und dann das Festschreiben mit Hilfe der Ordner durchführt.
Im Gegensatz zu dateibasierten Systemen kennen Datenmanagementsysteme die Beziehungen der Daten untereinander, weil der Anwender die Daten zuvor in Beziehung gesetzt hat. Es handelt sich also nicht um eine lose Sammlung von Objekten. Aufgrund dieser Beziehungen kann es zwischen Daten sehr lange Abhängigkeitsketten geben.
Wenn der Anwender nun in einem Datenmanagementsystem den Datenbestand eines Objektes inkl. der abhängigen Objekte festschreiben möchte, dann muss er irgendwie festlegen, welche Objekte er als „abhängig“ sieht. Diese Entscheidung kann in der Regel nicht pauschal getroffen werden, sondern hängt vom konkreten Anwendungsfall ab, in dem sich der Anwender aktuell befindet. In einer Situation will er vielleicht nur wenige abhängige Objekte festschreiben. In einem anderen Fall vielleicht deutlich mehr.
Das Problem ist also, dass ein Anwender für unterschiedliche Anwendungsfälle steuern möchte, welche abhängigen Objekte festgeschrieben werden sollen und welche nicht.
Da die zugrundeliegenden zu modellierenden Daten bzw. Objekte umfangreich sind, besteht ein weiteres Problem darin, dass ein menschlicher Benutzer zur Spezifikation von Anwendungsfällen alle Datensätze bzw. Objekte verwalten müsste, was ab einem bestimmten Umfang nicht mehr möglich ist.
Ferner ist hierdurch die Wahrscheinlichkeit einer fehlerhaften Modellierung sehr groß und es kann zu verfälschten Testergebnissen eines Endgeräts bzw. eines Steuergeräts kommen. Somit besteht generell ein Bedarf an einem neuartigen Verfahren, welches sich zumindest teilweise derart automatisieren lässt, dass entsprechende Entwicklungsdaten nicht einzeln verwaltet werden müssen, sondern dass vielmehr bestimmte Einheiten gebildet werden können, welche sich in ihrer Gesamtheit einfach verwalten lassen. Insbesondere ist hierzu eine neuartige Datenstruktur zu schaffen.
Somit ist es eine Aufgabe der vorliegenden Erfindung, ein verbessertes Verfahren zur teilautomatisierten Entwicklungsdatenverwaltung zu schaffen, welches es ermöglicht, umfangreiche Datensätze mit geringem technischen Aufwand zuverlässig zu verwalten. Es ist ferner eine Aufgabe der vorliegenden Erfindung, eine entsprechend eingerichtete Rechenanordnung zu schaffen sowie ein Computerprogrammprodukt mit Steuerbefehlen, welche das Verfahren implementieren bzw. die Rechenanordnung betreiben.
Die Aufgabe wird mit den Merkmalen des Patentanspruchs 1 gelöst. Weitere vorteilhafte Ausgestaltungen sind in den Unteransprüchen angegeben.
Demgemäß wird ein Verfahren zur teilautomatisierten Entwicklungsdatenverwaltung für Steuergeräte vorgeschlagen, aufweisend ein Abspeichern eines Entwicklungsdatenmodells in einem zentralen Datenspeicher mit einer Mehrzahl von jeweils in Relation stehenden Konfigurationsdateneinheiten, wobei die Konfigurationsdateneinheiten jeweils Steuerbefehle und/oder Konfigurationsparameter abspeichern, ein Bereitstellen eines Regelwerks und Identifikation mindestens einer initialen Konfigurationsdateneinheit, wobei anhand des Regelwerks weitere Konfigurationsdateneinheiten anhand ihrer Relation zu der initialen Konfigurationsdateneinheit automatisiert identifizierbar sind, ein Anwenden des bereitgestellten Regelwerks auf das Entwicklungsdatenmodell zur Identifikation einer Teilmenge von Konfigurationsdateneinheiten innerhalb des Entwicklungsdatenmodells und ein Abspeichern der identifizierten Teilmenge.
Der Fachmann erkennt hierbei, dass die vorgenannten Verfahrensschritte weitere Unterschritte aufweisen können sowie iterativ und/oder in anderer Reihenfolge ausgeführt werden können. Beispielsweise ist es möglich, das Abspeichern des Entwicklungsdatenmodells sowie das Bereitstellen eines Regelwerks parallel auszuführen bzw. in umgekehrter Reihenfolge. Ferner kann das Entwicklungsdatenmodell iterativ aus Teilmodellen zusammengesetzt werden.
Bei dem vorgeschlagenen Verfahren handelt es sich um ein teilautomatisiertes Verfahren, da das vorgeschlagene Verfahren zumindest von einem menschlichen Benutzer initiiert werden muss. Dieser muss gemäß einem Aspekt zumindest ein initiales Objekt bzw. eine Konfigurationsdateneinheit auswählen und muss ggf. bei der Erstellung eines Regelwerks mitwirken. Sobald dies erfolgt ist, ist es mittels des vorgeschlagenen Verfahrens möglich, weitere Objekte bzw. Konfigurationsdateneinheiten anhand ihrer Relation bzw. weiterer Kriterien zu identifizieren, die sodann als eigene Version abgespeichert werden können.
Bei Entwicklungsdaten gemäß der vorliegenden Erfindung handelt es sich um jegliche Datensätze, welche bei einer Entwicklung von Steuergeräten, insbesondere bei einem Test von Steuergeräten, Einsatz finden. So kann es sich beispielsweise hierbei um Parameter oder Konfigurationsdateien für Steuergeräte handeln. Ferner ist es möglich, dass die Entwicklungsdaten als Testdaten für das Steuergerät vorliegen. Solche Testdaten stehen im Zusammenhang mit einem Umgebungsmodell, welches physikalische bzw. physische Gegebenheiten modelliert und bei einem Test eines Steuergeräts Verwendung finden kann. Somit stellt das vorgeschlagene Datenmodell bzw. die Entwicklungsdaten nicht auf eine allgemeine Semantik derart ab, dass jegliches Datenmodell erfindungsgemäß Verwendung finden kann, sondern vielmehr wird auf technische Daten abgestellt, welche sich auf ein Steuergerät beziehen. Gerade in diesem Anwendungsszenario ist es notwendig, eine Vielzahl von abhängigen Objekten zu modellieren und diese derart auszuwählen, dass eine Teilmenge bzw. eine Version oder auch ein Release entsteht. Somit ist es ein Aspekt der vorliegenden Erfindung, dass insbesondere auf eine Testspezifikation abgestellt wird, welche es ermöglicht, ein Steuergerät bezüglich seiner Funktionalität auszutesten.
Beispielsweise liegen die Entwicklungsdaten als eine Testspezifikation vor, welche im vorliegenden Beispiel einen Fensterheber testet. Hierbei kann mittels der bereitgestellten Konfigurationsdateneinheiten eine Anforderung spezifiziert werden, und ferner können tatsächliche Umweltparameter, beispielsweise im Rahmen einer Testumgebung, spezifiziert werden. Bei einem Konfigurationsdatenelement bzw. einer Konfigurationsdateneinheit handelt es sich somit um einen Sammelbegriff, der Steuerbefehle und Konfigurationsparameter umfasst. Im vorliegenden Beispiel ist es also möglich, dass der Fensterheber derart modelliert wird, dass er eine Funktion „Anheben“ implementieren muss. Ferner gibt es weitere Funktionen wie „Anhalten“ oder „Absenken“. Hierdurch wird also ein Konfigurationsdatenelement bzw. eine Konfigurationsdateneinheit bereitgestellt, welche entsprechende Steuerbefehle modelliert.
Ferner können mittels Steuerbefehlen Anforderungen modelliert werden. Beispielsweise kann ein Steuerbefehl veranlassen, dass überprüft wird, ob der Fensterheber bei einem Widerstand die Funktion „Anhalten“ ausführt. Dies trägt dem Anwendungsszenario Rechnung, welches vorsieht, dass beispielsweise ein Kind einen Arm aus einem Fahrzeug herausstreckt und hierbei der Fensterheber die Fensterscheibe an den Arm des Kindes heranführt. Dieses Beispiel verdeutlicht, dass Umgebungsmodelle zu verwenden sind, da nicht realweltlich ein solches Testszenario durchlaufen werden sollte.
Um dieses Problem zu überwinden, modelliert eine Konfigurationsdateneinheit also eine Testanforderung, nämlich dass bei einem bestimmten Widerstand das Steuergerät, im vorliegenden Beispiel der Fensterheber, eine bestimmte Funktionalität ausführt. Hierzu sind nicht nur Steuerbefehle notwendig, sondern auch vielmehr Konfigurationsparameter, welche beispielsweise angeben, wie groß der Widerstand ist, der ein Anhalten des Fensterhebers verursachen soll. Somit können also in den Konfigurationsdateneinheiten Funktionen und Parameter mitsamt deren Werten spezifiziert werden, die einen Testfall beschreiben. Ein entsprechender Steuerbefehl kann nunmehr überprüfen, ob das Steuergerät die gewünschte Funktionalität bereitstellt und beispielsweise mittels eines binären Parameters codieren, dass das Steuergerät den Testfall bestanden hat oder eben auch nicht. Da die unterschiedlichen Konfigurationsdateneinheiten in Relation stehen, formen diese in ihrer Gesamtheit das Entwicklungsdatenmodell.
Vorzugsweise wird das Entwicklungsdatenmodell zentral abgespeichert, d. h. vorzugsweise ist ein Server vorzusehen, auf den mehrere Benutzer zugreifen können. Die Konfigurationsdateneinheiten stehen untereinander derart in Relation, dass anhand eines initialen Konfigurationsdatenelements bzw. einer initialen Konfigurationsdateneinheit weitere Konfigurationsdateneinheiten identifizierbar sind. Hierzu wird ein Regelwerk vorgesehen, welches beschreibt, welche Konfigurationsdateneinheiten, im Folgenden Objekte genannt, ausgewählt werden. Hierbei handelt es sich nicht um generische Objekte, sondern wiederum um Objekte, welche Steuerbefehle oder Parametern kapseln. Diese Steuerbefehle oder Parameter sind technische Daten im Sinne der Entwicklungsdaten, wie sie bereits beschrieben wurden. Erfindungsgemäß wurde erkannt, dass es anhand der Objekte an sich sowie anhand der Relationen möglich ist, aus einem Entwicklungsdatenmodell unterschiedliche Ansichten bzw. Versionen zu generieren. Hierzu können Relationen, wie beispielsweise eine Vererbung oder weitere benutzerspezifizierte Relationen Verwendung finden. Hierbei muss ein Benutzer, beispielsweise mittels des Regelwerks, angeben, dass Objekte mit bestimmten Eigenschaften auszuwählen sind. Eine solche Eigenschaft kann bezüglich direkt eines Objektes bestehen oder aber auch in der Relation zu einem Objekt bestehen.
Um dies zu veranschaulichen, wird wiederum ein Beispiel angeführt, in dem eine erste Konfigurationsdateneinheit mit weiteren Konfigurationsdateneinheiten in einer verketteten Liste vorliegt. Somit kann eine Relation eine Nachbarschaft ausdrücken und besteht paarweise zwischen zwei Konfigurationsdateneinheiten. Somit schaffen die jeweiligen Relationen eine Kette, indem sie die Konfigurationsdateneinheiten in Serie schalten. Möchte nunmehr ein Benutzer aus dem Entwicklungsdatenmodell, also der Kette an Dateneinheiten, eine Teilmenge auswählen, so kann er im einfachsten Fall einfach ein Konfigurationsdatenelement bzw. eine Dateneinheit auswählen und konfigurieren, dass auch der Rest der verketteten Liste in eine Richtung ausgewählt werden soll. Somit spezifiziert der Benutzer also lediglich ein einzelnes Konfigurationsdatenelement bzw. eine Dateneinheit, und automatisiert werden dieser Auswahl weitere Konfigurationsdateneinheiten hinzugefügt. Hierbei sei darauf verwiesen, dass es sich um einen einfachen Anwendungsfall handelt, der aufgrund seiner geringen Komplexität einfach zu verstehen ist.
Die vorliegende Erfindung sieht ferner vor, dass anhand weiterer Relationen und Eigenschaften der Konfigurationsdateneinheiten Teilmengen gebildet werden können. Somit muss also der Benutzer lediglich ein Regelwerk erstellen bzw. auswählen und typischerweise ein initiales Konfigurationsdatenelement wählen. Anhand dieser initialen Eingabe kann somit vollautomatisiert eine Teilmenge aus dem Entwicklungsdatenmodell generiert werden.
Somit können also Testspezifikationen erzeugt werden, ohne dass es notwendig ist, dass ein Benutzer alle Anforderungen an das Steuergerät spezifiziert, sondern vielmehr muss lediglich ein Regelwerk bezüglich des Entwicklungsdatenmodells bereitgestellt werden und ein initiales Konfigurationsdatenelement ausgewählt werden. Im Kontext der vorliegenden Erfindung wird eine Dateneinheit analog zu einem Datenelement oder einem Objekt verwendet. Insgesamt wird eine technische Datenstruktur geschaffen, welches es ermöglicht, Steuerbefehle im Rahmen von Konfigurationsdateneinheiten untereinander in Bezug zu setzen und hierbei Relationen beispielsweise bezüglich einer Testspezifikation zu schaffen.
In einem darauffolgenden Verfahrensschritt erfolgt ein Anwenden des bereitgestellten Regelwerks auf das Entwicklungsdatenmodell derart, dass einzelne Konfigurationsdateneinheiten herausgegriffen werden und somit eine Teilmenge aus dem Entwicklungsdatenmodell geschaffen wird. Die Teilmenge umfasst hierbei Konfigurationsdateneinheiten und optional auch Relationen hierzu. Somit erfolgt also ein Überprüfen, ob die einzelnen Konfigurationsdateneinheiten dem Regelwerk entsprechen, und somit werden alle im Sinne dieses Regelwerks zugehörigen Konfigurationsdateneinheiten identifiziert. Das Regelwerk kann vorsehen, dass zwischen den Konfigurationsdateneinheiten nur bestimmte Relationen ausgewertet werden, und diejenigen Konfigurationsdateneinheiten ausgewählt werden, welche der vorbestimmten Relation entsprechen. Hierbei ist es erfindungsgemäß ebenfalls vorgesehen, dass unterschiedliche Typen von Relationen bestehen können, und vielmehr müssen die Relationen nicht lediglich paarweise vorliegen, wie es im Rahmen der Graphentheorie vorgesehen wird, sondern vielmehr können Relationen beliebige Anzahlen von Konfigurationsdateneinheiten verbinden. Hierbei ist es auch nicht zwingend erforderlich, dass zwischen zwei Konfigurationsdateneinheiten eine Relation vorliegt oder nicht, sondern vielmehr kann auch eine Vielzahl von Relationen zwischen zwei Konfigurationsdateneinheiten vorliegen. Somit erfolgt eine reiche Modellierung des Entwicklungsdatenmodells und es können alle technischen Gegebenheiten abgedeckt werden.
Die identifizierte Teilmenge kann beispielsweise einer Testspezifikation entsprechen, wobei dies nicht einschränkend zu verstehen ist. Hierbei werden alle zusammengehörigen Entwicklungsdaten innerhalb eines Teilmodells zusammengefasst und separat abgespeichert. Separat bezieht sich hierbei auf die Tatsache, dass es vorteilhaft ist, das Entwicklungsdatenmodell getrennt von der Teilmenge zu verwalten. So ist es Entwicklern möglich, das Entwicklungsdatenmodell weiter zu verfeinern und zu erweitern und die identifizierte Teilmenge festzuschreiben bzw. lediglich lesende Operationen hierauf zuzulassen. Somit wird mittels der identifizierten Teilmenge eine separate Version bzw. Konfiguration geschaffen, die auch als ein Release bezeichnet werden kann. Da ein solches Release bezüglich des zugrundeliegenden Steuergeräts Anwendung findet, sollen keinerlei weitere Änderungen hierauf stattfinden. Im Rahmen der Weiterentwicklung soll es lediglich möglich sein, das Entwicklungsdatenmodell fortzubilden, ohne aber das bestehende Release zu verändern.
Hierbei können auch mehrere Versionen des Release geschaffen werden, derart, dass die Verfahrensschritte iterativ ausgeführt werden und ein wiederholtes Abspeichern der identifizierten Teilmenge erfolgt. Somit kann ein Entwicklungsdatenmodell in einem ersten Zustand Verwendung finden und eine erste identifizierte Teilmenge liefern, und ein zweites, weiterentwickeltes Entwicklungsdatenmodell kann sodann zu einem späteren Zeitpunkt eine zweite Teilmenge begründen.
Somit können also Produktspezifikationen bzw. Testspezifikationen erschaffen werden, die unabhängig voneinander zu verwalten sind. Hierbei werden unterschiedliche Entwicklungsdatenmodelle oder aber auch ein einziges Entwicklungsdatenmodell verwendet. Besonders vorteilhaft ist es auch, ein generisches Entwicklungsdatenmodell für eine Vielzahl von Steuergerätetypen zu verwenden und für ein bestimmtes Steuergerät bzw. einen bestimmten Steuergerätetyp eine Teilmenge hieraus anhand des Regelwerks zu identifizieren. Somit muss ein Hersteller einer Vielzahl von Steuergerätetypen lediglich ein einziges Entwicklungsdatenmodell warten und kann hierbei in Abhängigkeit des gewünschten Steuergerätetyps eine Teilmenge aus dem generischen Entwicklungsdatenmodell generieren.
Folglich wird erfindungsgemäß das Problem überwunden, dass unterschiedliche Objekte bzw. Entwicklungsdatenmodelle gemäß dem Stand der Technik manuell verwaltet werden müssen, was zeitaufwändig und fehleranfällig ist. Gemäß herkömmlicher semantischer Graphen besteht das Problem, dass beim Festschreiben, also bei einem Release eines Objektes, immer pauschal alle abhängigen Objekte und wiederum deren abhängige Objekte, ebenfalls festgeschrieben werden. Generell kann der Anwender nichtanwendungsfallspezifisch entscheiden, welche Objekte in ein Release aufzunehmen sind.
Das Problem wird dadurch gelöst, dass der Anwender sogenannte „Release Configurations“ spezifizieren kann. Eine Release Configuration legt fest, welche Objektbeziehungen beim Festschreiben von Objekten berücksichtigt werden sollen und welche nicht. D.h. der Anwender kann sich für jeden seiner Anwendungsfälle eine Release Configuration spezifizieren. Wenn er nun konkret ein oder mehrere Objekte festschreiben möchte, dann wählt er eine der zuvor definierten Release Configurations aus. Entsprechend dieser Konfiguration werden dann auch die abhängigen Objekte festgeschrieben.
Damit das nicht jeder Anwender einzeln machen muss, können die Release Configurations zentral in dem Datenmanagementsystem abgelegt werden. Insbesondere kann eine Release Configuration auch als eine Konfigurationsdateneinheit des Entwicklungsdatenmodells ausgestaltet sein.
Durch die Einführung von Release Configurations kann der Anwender dem Vorgang des Festschreibens unterschiedliche Semantiken geben. D.h. in einem Fall wird vielleicht nur ein einzelnes Objekt festgeschrieben, in einem anderen Fall wird eine lange Kette an abhängigen Objekten festgeschrieben. Daher ist es wichtig, dass ein Anwender später für ein festgeschriebenes Objekt erkennen kann, „wie“ es festgeschrieben wurde. Dazu gibt es unterschiedliche Lösungsmöglichkeiten:

1. An jedem festgeschriebenem Objekt wird annotiert, mit welchen Release Configurations es festgeschrieben wurde. Es kann sich prinzipbedingt um mehrere Release Configurations handeln, da ein Objekt z.B. zunächst mit einer „schwachen“ Release Configuration und später mit einer „stärkeren“ Release Configuration festgeschrieben wird.
2. Der Anwender kann bei der Definition der Release Configurations Hierarchien definieren, also eine Art „Vererbung“ von Release Configurations. Er könnte z.B. eine Release Configuration „Project Release“ definieren, für die er die relevanten Beziehungstypen festlegt. Dann legt er eine Ableitung von „Project Release“ mit dem Namen „Workspace Release“ an. Diese erbt automatisch die relevanten Beziehungstypen von „Project Release“. Der Anwender kann dann noch zusätzlich weitere Beziehungstypen spezifizieren, die ebenfalls relevant sind. Durch diese Vererbung ist formal festgelegt, welche Release Configurations stärker und welche schwächer sind. Das hat den Vorteil, dass an einem Objekt nur die stärkste Release Configuration gespeichert werden muss. Zumindest sollten die Anwender idealerweise immer so arbeiten. Wenn Release Configurations nicht aus einem Vererbungsstrang kommen, dann müssen auch bei dieser Lösung weiterhin mehrere Release Configurations gespeichert werden.

Der Test-Manager arbeitet in einem Workspace. In dem Workspace befinden sich je ein Test-Management-Projekt mit Testspezifikationen und ein Requirements-Projekt mit Requirements. Der Test-Manager hat die Aufgabe, die Testspezifikationen zu verwalten und weiter zu entwickeln. Die einzelnen Testspezifikationen sind mit entsprechenden Requirements in Beziehung gesetzt.
Nun gibt es unterschiedliche Anwendungsfälle, in denen der Test-Manager seine Testspezifikationen festschreiben möchte:

1. Während der Entwicklung einer Testspezifikation möchte der Test-Manager den Stand dieser Spezifikation festhalten, damit er diesen Stand z.B. später zum Zwecke eines Vergleiches verwenden kann. Andere Objekte, wie zum Beispiel die verknüpften Requirements, will er aber nicht festschreiben. Daher legt er sich nun eine Release Configuration mit dem Namen „Archive Test Specification“ an. Dort legt er fest, dass nur die Testspezifikationen selbst, aber keine abhängigen Objekte festgeschrieben werden. Mit Hilfe dieser Release Configurationen kann er nun seine Testspezifikationen „archivieren“.
2. Zu bestimmten Meilensteinen soll nun die Gesamtheit der Testspezifikationen für ein Entwicklungsprojekt festgeschrieben werden. In diesem Beispiel seien das genau die Testspezifikationen, die sich in einem Test-Management-Projekt befinden. Daher legt der Test-Manager eine Release Configuration „Test Milestone“ an. Für diese Release Configuration legt er fest, dass alle in einem Projekt enthaltenen Testspezifikationen inkl. deren Parameter festgeschrieben werden sollen. Zum Zeitpunkt eines Milestones schreibt er dann den gesamten Inhalt des Test-Management-Projektes mit Hilfe der Release Configuration fest.
3. Zum Ende des Entwicklungsprojektes soll die Gesamtheit der Testspezifikationen und der Requirements als eine Einheit festgeschrieben werden. Dazu wird eine Release Configuration mit dem Namen „Workspace Release“ angelegt. Dort ist spezifiziert, dass alle Projekte eines Workspaces inklusive aller enthaltenen Objekte festgeschrieben werden sollen. Durch die Anwendung dieser Release Configuration auf den Workspace werden sowohl das Test-Management-Projekt als auch das Requirements-Projekt inkl. der Beziehungen zwischen den Projekten festgeschrieben.

Die hier genannten Release Configuration können auch in die o.a. Hierarchie gebracht werden: Archive Test Specification -> Test Milestone -> Workspace Release.
Im Gegensatz zu dateibasierten Systemen ist hier der Unterschied, dass es in dateibasierten Systemen keine modellierten Abhängigkeiten zwischen den Dateien gibt. Daher muss ein Anwender immer manuell die Dateien oder Ordner auswählen, die er als eine Einheit (Baseline, Checkpoint usw.) festschreiben möchte.
Gemäß einem Aspekt der vorliegenden Erfindung erfolgt das Abspeichern der identifizierten Teilmenge derart separat, dass das Entwicklungsdatenmodell nicht überschrieben wird. Dies hat den Vorteil, dass Entwickler an dem Entwicklungsdatenmodell weiterarbeiten können, also Teile verfeinern, erweitern oder gar löschen können, ohne dass hierbei eine Version bzw. eine Teilmenge berührt wird. In umgekehrter Richtung ist es möglich, dass die Teilmenge mittels eines separaten Abspeicherns gesichert werden kann und eben nicht das Entwicklungsdatenmodell überschreibt. Somit kann weiterhin an dem Entwicklungsdatenmodell gearbeitet werden, welche die identifizierte Teilmenge in ein Steuergerät integriert bzw. implementiert werden kann.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung unterliegt das abgespeicherte Entwicklungsdatenmodell in seiner Gesamtheit einer unterschiedlichen Rechtevergabe als die abgespeicherte, identifizierte Teilmenge. Dies hat den Vorteil, dass das Entwicklungsdatenmodell feingranular verwaltet werden kann, aber auch in seiner Gesamtheit editierbar verwaltet werden kann. Unabhängig davon kann die identifizierte Teilmenge gesichert werden, und es können andere Leserechte und Schreibrechte vergeben werden als bei dem Entwicklungsdatenmodell. Dies trägt wiederum dem Umstand Rechnung, dass das Entwicklungsdatenmodell von mehreren Entwicklern weitergebildet werden soll und die identifizierte Teilmenge unverändert an einen Kunden ausgeliefert werden soll bzw. eben ein Steuergerät integriert werden soll.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung wird auf die abgespeicherte, identifizierte Teilmenge ein schreibender Zugriff unterbunden. Dies hat den Vorteil, dass eine Rechteverwaltung vorgesehen werden kann, welche die identifizierte Teilmenge vor einem Zugriff schützt und lediglich ein lesender Zugriff erlaubt wird. Somit handelt es sich also bei der identifizierten Teilmenge um ein Endprodukt, welches Einsatz findet und daher nicht geändert werden soll. Somit wird also sichergestellt, dass die Teilmenge als ein statischer Datensatz vorliegt, der nicht geändert werden soll. Soll dennoch eine neue Version geschaffen werden, so ist es möglich, wiederum eine separate Teilmenge zu identifizieren und abzuspeichern. Somit werden unterschiedliche Versionen geschaffen, die jeweils abschließend definiert werden.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung wird zu der identifizierte Teilmenge ein zusätzlich Konfigurationsdateneinheit abgespeichert, wobei die zusätzliche Konfigurationsdateneinheit Informationen über die initialen Konfigurationsdateneinheiten, das bereitgestellte Regelwerk, die Konfigurationsdateneinheiten der identifizierte Teilmenge und/oder weitere Informationen über die Rahmenbedingungen des Verfahren umfasst. Diese zusätzlichen Konfigurationsdateneinheiten können im Fall eines zentralen Datenspeichers, welcher als Datenbank ausgeführt ist, selbstständige Datenbankobjekte sein. Sie umfassen dabei üblicherweise Informationen aus denen die initialen Konfigurationsdateneinheiten, das bereitgestellte Regelwerk und die Konfigurationsdateneinheiten der identifizierten Teilmenge ableitbar sind. Es können auch weitere Informationen über die Rahmenbedingungen des Verfahrens ableitbar oder direkt enthalten sein, typische Informationen sind dabei der Nutzer, welcher das Release bzw. die Versionierung mittels das Verfahrens ausgelöst hat, sowie Zeitpunkt des Releases, Ort bzw. verwendete technische Infrastruktur oder auch einen vom Nutzer zur Beschreibung verfassten Kommentar. Solche zusätzlichen Konfigurationsdateneinheiten können auch als „Checkpoints“ oder „Baselines“ bezeichnet werden. Entsprechende „Checkpoints“ bieten so einen einfachen Einstiegspunkt, um alle mittels des Verfahrens abgespeicherten Informationen und insbesondere das bereitgestellte Regelwerk und die identifizierte Teilmenge aufzeigen und bei Bedarf rekonstruieren zu können. Da zu jedem Release eine entsprechender „Checkpoint“ angelegt wird, kann man auch leicht alle zu einer Konfigurationsdateneinheit gehörigen „Checkpoints“ auffinden, da diese alle eine Relation mit der entsprechenden Konfigurationsdateneinheit aufweisen. So lässt sich sehr einfach ein Überblickt über alle abgespeicherten Zustände der Konfigurationsdateneinheit gewinnen.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung umfassen die, als Teil der identifizierten Teilmenge, abgespeicherten initialen Konfigurationsdateneinheiten eine Referenz auf das bereitgestellte Regelwerk. Mittels dieser Referenz ist es möglich die identifizierte Teilmenge auch nachträglich zu bestimmen.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung ist das bereitgestellte Regelwerk Teil einer hierarchisch aufgebauten Menge von Regelwerken. Die hierarchisch aufgebaute Menge von Regelwerken erlaubt es die „Stärke“ eins Regelwerkes gegenüber anderen Regelwerken der Menge zu klassifizieren. Dabei ist mit „Stärke“ die Größe der mit dem Regelwerk zu identifizierenden Teilmenge des Entwicklungsdatenmodells gemeint. Ein „stärkeres“ Regelwerk identifiziert, bei Anwendung auf dieselbe initiale Konfigurationsdateneinheit, eine Teilmenge mit mehr Konfigurationsdateneinheiten des Entwicklungsmodells, welche im letzten Verfahrensschritt abgespeichert wird.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung erfolgt das Abspeichern der identifizierten Teilmenge iterativ. Dies hat den Vorteil, dass mehrere Versionen der Teilmenge geschaffen werden können, ohne dass hierbei vorab identifizierte Teilmengen geändert werden müssen. Somit wird aus dem Entwicklungsdatenmodell eine Vielzahl von Teilmengen, beispielsweise zeitversetzt, generiert, und es entstehen unterschiedliche Versionen. So kann eine erste Teilmenge als ein Release Version 1 abgespeichert werden und eine zweite Teilmenge kann als ein Release Version 2 abgespeichert werden.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung modelliert das Entwicklungsdatenmodell eine Testspezifikation des Steuergeräts. Dies hat den Vorteil, dass das Entwicklungsdatenmodell Steuerbefehle und Parameter beschreibt, welche dazu dienen, das Steuergerät derart abzuprüfen, dass festgestellt werden kann, ob das Steuergerät eine gewisse Spezifikation erfüllt. Beispielsweise kann in dem Entwicklungsdatenmodell ein Test spezifiziert werden und anhand der Konfigurationsparameter können Werte für einen solchen Test bereitgestellt werden. Am Beispiel des Fensterhebers kann verdeutlicht werden, dass ein Steuerbefehl vorgesehen werden kann, welcher abprüft, ob die Funktionalität des Anhaltens des Bewegens der Fensterscheibe korrekt implementiert ist. Hierbei können die Konfigurationsparameter einen ersten oder einen zweiten Widerstand angeben. Wird hieraus eine Teilmenge generiert, so kann mittels des Regelwerks angegeben werden, dass strenge Vorgaben an den Test zu stellen sind. Beispielsweise beschreibt in dem Entwicklungsdatenmodell ein erster Konfigurationsparameter, dass die Scheibe bei einem bestimmten Widerstand innerhalb von 10 Millisekunden anhalten muss, und ein zweiter Konfigurationsparameter beschreibt, dass die Scheibe innerhalb von 20 Millisekunden anhalten muss. Nunmehr wird das Regelwerk angewandt und mittels der Relationen kann festgestellt werden, welche Objekte zu einem strengen Test gehören. Somit wird also zu dem Steuerbefehl „Überprüfen“ ein weiteres Objekt ausgewählt, nämlich eine Konfigurationsdateneinheit, welche spezifiziert, dass die Fensterscheibe innerhalb von 10 Millisekunden angehalten werden muss. Somit umfasst das Entwicklungsdatenmodell eine oder mehrere Testspezifikationen, wobei die Teilmenge hieraus die relevanten Steuerbefehle bzw. Konfigurationen aufgreift.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung beschreibt mindestens ein Steuerbefehl eine Bedingung an eine Funktionalität des Steuergeräts. Dies hat den Vorteil, dass einzelne Testfälle spezifiziert werden können, und je nach dem, welche Objekte sich in der Teilmenge befinden, können entsprechende Bedingungen abgeprüft werden. Somit kann es also möglich sein, dass eine übergeordnete Bedingung „Sicherheitsfunktion vorhanden“ mittels eines Steuerbefehls spezifiziert wird und abhängige Objekte weitere Steuerbefehle spezifizieren, wie beispielsweise „Fensterheber arbeitet korrekt“. Anhand der Steuerbefehle kann sodann die Funktionalität des Steuergeräts abgeprüft werden und die Testspezifikation bzw. die identifizierte Teilmenge kann angewendet werden.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung beschreibt mindestens ein Konfigurationsparameter einen Anforderungsparameter an das Steuergerät. Dies hat den Vorteil, dass eine Soll-Konfiguration beschrieben werden kann, und anhand der Steuerbefehle kann abgeprüft werden, ob der spezifische Anforderungsparameter erfüllt ist oder nicht. Im vorliegenden Beispiel kann der Anforderungsparameter spezifizieren, dass die Fensterscheibe bei einem bestimmten Widerstand innerhalb von 10 Millisekunden anzuhalten ist.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung besteht eine Relation indirekt zwischen mindestens zwei Konfigurationsdateneinheiten. Dies hat den Vorteil, dass Relationen nicht stets paarweise definiert werden müssen, sondern vielmehr kann eine Relation auch zwischen mehreren Objekten bzw. Konfigurationsdateneinheiten bestehen. Auch muss diese Relation nicht indirekt sein, sondern vielmehr können bildhaft gesprochen Teilgraphen gebildet werden. Somit besteht bei einer verketteten Liste auch eine Relation zwischen dem ersten Element der Liste und dem letzen Element der Liste, auch falls dazwischen weitere Elemente angeordnet sind. Somit kann bei der Identifizierung von Teilgraphen auch bildlich gesprochen über Objekte hinweggesprungen werden, und es besteht dennoch eine Relation, die spezifizierbar ist.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung weist eine Relation eine Hierarchie, eine Vererbung, eine Zusammengehörigkeit und/oder eine benutzerdefinierte Semantik auf. Dies hat den Vorteil, dass unterschiedliche Relationen von dem Regelwerk ausgewertet werden können, und es können somit unterschiedliche Konfigurationsdateneinheiten ausgehend von unterschiedlichen Aspekten identifiziert werden. Somit lassen sich unterschiedliche Anwendungsszenarien modellieren.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung erfolgt das Abspeichern des Entwicklungsdatenmodells auf einem Server und/oder das Anwenden des bereitgestellten Regelwerks wird mittels eines Client initiiert. Dies hat den Vorteil, dass das Entwicklungsdatenmodell für verschiedene Entwickler zugänglich ist, da diese das Entwicklungsdatenmodell nicht lokal verwalten bzw. darauf zugreifen, sondern dies wird von einem Server abgerufen. Lediglich das Anwenden des bereitgestellten Regelwerks erfolgt erst, nachdem ein Client bzw. ein Benutzer dies veranlasst hat.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung werden die Verfahrensschritte von verteilten Netzwerkkomponenten ausgeführt. Dies hat den Vorteil, dass die Datenhaltung dezentral erfolgen kann und somit identifizierte Teilmengen an unterschiedlichen Netzwerkknoten abgespeichert werden können. Darüber hinaus wird es unterschiedlichen Benutzern ermöglicht, das Regelwerk individuell zu spezifizieren und sodann entsprechende Entwicklungsdaten von dem Server abzurufen. Das Abspeichern der identifizierten Teilmenge kann dann lokal erfolgen, oder aber auch auf dem Server.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung beschreibt das Entwicklungsdatenmodell generische Daten für eine Mehrzahl von Steuergerätetypen, und die identifizierte Teilmenge beschränkt sich auf einen Steuergerätetyp. Dies hat den Vorteil, dass das Entwicklungsdatenmodell generisch unterschiedliche Steuergerätetypen beschreiben kann und hierbei Funktionalitäten, welche von allen Steuergerätetypen unterstützt werden, nicht mehrfach modelliert werden müssen. Ein Hersteller kann für einen einzelnen Steuergerätetyp eine Teilmenge automatisiert identifizieren, und es kann somit zentral ein Entwicklungsdatenmodell gewartet werden, während unterschiedliche Ansichten in Abhängigkeit eines Steuergerätetyps erzeugt werden können. Dies sorgt für Speichereffizienz und verringert zudem den Arbeitsaufwand. Somit stellt sich also der Vorteil ein, dass nicht für jeden Steuergerätetyp ein eigenes Entwicklungsdatenmodell erzeugt werden muss, sondern vielmehr können unterschiedliche Steuergerätetypen in einem einzigen generischen Entwicklungsdatenmodell modelliert werden, welches zudem Spezifika der einzelnen Steuergerätetypen aufweist.
Die Aufgabe wird auch gelöst durch eine Rechenanordnung zur teilautomatisierten Entwicklungsdatenverwaltung für Steuergeräte, aufweisend einen ersten zentralen Datenspeicher, eingerichtet zum Abspeichern eines Entwicklungsdatenmodells, aufweisend eine Mehrzahl von jeweils in Relation stehenden Konfigurationsdateneinheiten, wobei die Konfigurationsdateneinheiten jeweils Steuerbefehle und/oder Konfigurationsparameter abspeichern, eine Logikeinheit, eingerichtet zur Bereitstellen eines Regelwerks und Identifikation mindestens einer initialen Konfigurationsdateneinheit, wobei anhand des Regelwerks weitere Konfigurationsdateneinheiten anhand ihrer Relation zu der initialen Konfigurationsdateneinheit automatisiert identifizierbar sind, eine Ausführungseinheit, eingerichtet zum Anwenden des bereitgestellten Regelwerks auf das Entwicklungsdatenmodell zur Identifikation einer Teilmenge von Konfigurationsdateneinheiten innerhalb des Entwicklungsdatenmodells, und einen Datenspeicher, eingerichtet zum Abspeichern der identifizierten Teilmenge.
Bei dem ersten zentralen Datenspeicher und dem Datenspeicher zum Abspeichern der identifizierten Teilmenge kann es sich um den gleichen Datenspeicher oder aber auch um separate Datenspeicher handeln. Die vorgenannten Komponenten können netzwerktechnisch miteinander verbunden werden und können somit in einem Computernetzwerk betrieben werden.
Die Aufgabe wird auch gelöst durch ein Computerprogrammprodukt mit Steuerbefehlen, welche das vorgeschlagene Verfahren implementieren bzw. die Rechenanordnung betreiben.
Erfindungsgemäß ist es besonders vorteilhaft, dass das Verfahren Verfahrensschritte lehrt, welche von der Rechenanordnung strukturell nachgebildet werden können. Somit stellen strukturelle Merkmale der Rechenanordnung eine Funktionalität bereit, welche der Funktionalität der Verfahrensschritte entspricht. Somit ist die Rechenanordnung eingerichtet, das vorgeschlagene Verfahren auszuführen bzw. das vorgeschlagene Verfahren ist eingerichtet, die Rechenanordnung zu betreiben.
Weitere vorteilhafte Ausgestaltungen werden anhand der beigefügten Figuren näher erläutert. Es zeigen:

1: einen schematischen Schichtenaufbau, der das Steuergerät mit dem Entwicklungsdatenmodell in Verbindung setzt sowie das hierauf basierende Regelwerk gemäß einem Aspekt der vorliegenden Erfindung veranschaulicht;
2: eine schematische Darstellung einer identifizierten Teilmenge des Entwicklungsdatenmodells gemäß einem Aspekt der vorliegenden Erfindung; und
3: ein schematisches Ablaufdiagramm eines Verfahrens zur teilautomatisierten Entwicklungsdatenverwaltung gemäß einem weiteren Aspekt der vorliegenden Erfindung.
4: eine schematische Darstellung eines Rechensystems zur teilautomatisierten Entwicklungsdatenverwaltung gemäß eines Aspektes der vorliegenden Erfindung.

1 zeigt ein Mehrschichtenmodell, wobei in der untersten Schicht 0 ein Steuergerät gezeigt ist, welches vorliegend mittels eines Entwicklungsdatenmodells beschrieben wird. Das Steuergerät (Electronic Control Unit, ECU) umfasst einen Mikrocontroller MC, eine Sensor-Schnittstelle SEN und eine Aktor-Schnittstelle ACT. Ferner ist es möglich, mittels des Entwicklungsdatenmodells einen Testfall des Steuergeräts zu beschreiben. Hierbei wurde als Steuergerät eine ECU mit Sensor- und Aktor-Schnittstelle gewählt, wobei das vorgeschlagene Verfahren geeignet ist, eine Entwicklungsdatenverwaltung für jegliche Art von Steuergerät bzw. ECU durchzuführen. Bei dem Dargestellten handelt es sich also lediglich um ein nicht-einschränkendes Beispiel. Weiter Beispiele für Steuergeräte sind ECUs mit nur einer der Schnittstellen (für Sensor oder Aktor) oder auch virtuelle ECUs (sog. V-ECUs), welche softwaretechnische Nachbildungen realer ECUs sind. Wobei diese den Algorithmus des Steuergerätes in Form einer Anwendungsschicht und teilweise weitere Softwareschichten, wie z.B. Betriebssystem/OS oder Hard- und Softwareabstraktionsschichten, umfassen.
Auf der nächsthöher gelegenen Ebene 1 ist das Entwicklungsdatenmodell eingezeichnet. Vorliegend wird das Entwicklungsdatenmodell bildlich als ein Graph dargestellt, der aus Knoten und Kanten besteht. Hierbei beschreiben die Knoten jeweils ein Konfigurationsdatenelement bzw. eine Konfigurationsdateneinheit, und die Kanten beschreiben Relationen. Aus Gründen der Einfachheit werden alle Knoten und Kanten gleich eingezeichnet, wobei die vorliegende Erfindung auf unterschiedliche Knoteneigenschaften abstellt und auf unterschiedliche Relationen. Ferner ist lediglich beispielhaft zu verstehen, dass Objekte stets paarweise verbunden sind. Vielmehr ist es auch möglich, dass zwischen zwei Objekten bzw. Knoten unterschiedliche Relationen bestehen, bzw. dass unterschiedliche Objekte bestehen.
Auf der nächsthöheren Ebene 2 ist ein Regelwerk angedeutet, welches einzelne Regeln umfasst, die auf das Entwicklungsdatenmodell der Ebene 1 zugreifen.
Erfindungsgemäß ist es vorgesehen, dass das Entwicklungsdatenmodell der Ebene 1 abgespeichert wird und sodann das Regelwerk gemäß Ebene 2 bereitgestellt wird. Das Regelwerk beschreibt hierbei die einzelnen Konfigurationsdateneinheiten, vorliegend Knoten, mitsamt Relationen derart, dass ausgehend von einer initialen Konfigurationsdateneinheit weitere Konfigurationsdateneinheiten ausgewählt werden können. Vorliegend nicht eingezeichnet sind die Steuerbefehle und Konfigurationsparameter, welche in den Konfigurationsdateneinheiten umfasst sind. Als Steuerbefehle können wiederum Anforderungen spezifiziert werden, die an das Steuergerät gemäß Ebene 0 gestellt werden. Steuerbefehle können z.B. Befehle zur Ansteuerung eines Rechensystems, insbesondere eines Rechensystems zur Testausführung, sein. Weiterhin können Steuerbefehle auch Überprüfungen von Bedingungen sein, wie sie häufig bei der Ausführung automatisierter Tests geprüft werden.
Wie nunmehr die teilautomatisierte Entwicklungsdatenverwaltung durchgeführt wird, wird ebenfalls beispielhaft anhand der 2 erläutert. Hierbei handelt es sich um eine identifizierte Teilmenge, welche also der Ebene 1 aus 1 entnommen wird.
2 zeigt eine identifizierte Teilmenge, wobei das Regelwerk auf die Ebene 1 der 1 angewendet wird und somit ein initialer Knoten ausgewählt wird. Hierbei ist die Ebene 1 gemäß 1 lediglich schematisch zu verstehen und umfasst eine Vielzahl von Konfigurationsdateneinheiten, also Knoten, wobei vorliegend lediglich wenige eingezeichnet sind. Typischerweise umfasst das Entwicklungsdatenmodell mehrere tausend bzw. zehntausend Objekte, was im Rahmen der schematischen Figurenbeschreibung nicht praktikabel abgebildet werden kann.
Vorliegend wird also ein Teilgraph aus dem Entwicklungsdatenmodell extrahiert und als identifizierte Teilmenge abgespeichert. Hierzu zeigt 2 das Ergebnis, wobei ein initialer Knoten aus der Ebene 1 gemäß 1 ausgewählt wurde. Dieser initiale Knoten wird innerhalb der identifizierten Teilmenge verwaltet und gemäß 2 oben dargestellt. Hierbei wurde spezifiziert, dass alle Konfigurationsdateneinheiten in die Teilmenge aufgenommen werden sollen, welche in einer bestimmten Relation zu diesem initialen Konfigurationsdatenelement stehen. Dies soll derart iterativ durchgeführt werden, dass alle Konfigurationsdateneinheiten mit dieser Relation extrahiert werden. Folglich ergibt sich beispielhaft, dass zwei Konfigurationsdateneinheiten dieser Anforderung entsprechen, welche nunmehr in der vorliegenden 2 unterhalb des initialen Konfigurationsdatenelements angeordnet sind. Da diese Regel iterativ angewendet wird und auch indirekte Relationen möglich sind, ergibt sich ein Teilgraph, der lediglich beispielhaft eine Baumstruktur aufspannt.
Stark vereinfacht wird im vorliegenden Beispiel davon ausgegangen, dass alle Relationen eine Vererbungsstruktur bilden. Eine Vererbung bezieht sich hierbei auf die Attribute eines Knotens, welche an die Unterknoten weitergegeben werden. So kann in der initialen Konfigurationsdateneinheit spezifiziert werden, dass ein strenger Test generiert werden soll. Dieses Attribut „strenger Test“ wird an die weiteren Knoten vererbt, und es werden Konfigurationsparameter gewählt, die einen solchen strengen Test beschrieben.
Folglich kann es sich bei den Knoten, die unten in 2 angeordnet sind, um Konfigurationsparameter handeln, welche beispielsweise spezifizieren, dass eine maximale Anhaltedauer 10 Millisekunden dauert. Die darüberliegenden Knoten können spezifizieren, dass ein Überprüfen eines Fensterhebers durchzuführen ist. In parallelen Knoten auf derselben Ebene kann spezifiziert werden, dass eine Bremsanlage zu testen ist. Folglich kann auch in einem dazugehörigen, also in Relation stehenden, untersten Knoten spezifiziert werden, wie groß eine Reaktionszeit einer Bremsanlage bei einem strengen Test sein kann. Somit beschreibt die identifizierte Teilmenge gemäß 2 vorliegend als Graph einen komplexen Testfall, der sich auf das Steuergerät bezieht. Dies wurde nunmehr am Beispiel eines Automobils verdeutlicht, wobei explizit darauf abgestellt wird, dass es sich um jegliches Steuergerät handeln kann, welches in einem mobilen Endgerät, einem Automobil oder sonstigem Gerät verbaut ist. Somit ist weder das Beispiel des Automobils noch des Mobiltelefons einschränkend.
Erfindungsgemäß ist es besonders vorteilhaft, dass die einzelnen Objekte, welche auch als Knoten bzw. Konfigurationsdateneinheiten bezeichnet werden, automatisiert ausgewählt werden können, und es muss nicht jede Produktbeschreibung bzw. jeder Testfall einzeln generiert werden. Somit ermöglicht die vorgeschlagene Datenstruktur eine automatisierte Entwicklungsdatenverwaltung, die lediglich vom Benutzer initiiert werden muss und somit zumindest als teilautomatisiert gelten kann.
3 zeigt in einem schematischen Ablaufdiagramm ein Verfahren zur teilautomatisierten Entwicklungsdatenverwaltung für Steuergeräte, aufweisend ein Abspeichern 100 eines Entwicklungsdatenmodells in einem zentralen Datenspeicher, aufweisend eine Mehrzahl von jeweils in Relation stehenden Konfigurationsdateneinheiten, wobei die Konfigurationsdateneinheiten jeweils Steuerbefehle und/oder Konfigurationsparameter abspeichern, ein Bereitstellen 101 eines Regelwerks und Identifikation mindestens einer initialen Konfigurationsdateneinheit, wobei anhand des Regelwerks weitere Konfigurationsdateneinheiten anhand ihrer Relation zu der initialen Konfigurationsdateneinheit automatisiert identifizierbar sind, ein Anwenden 102 des bereitgestellten 101 Regelwerks auf das Entwicklungsdatenmodell zur Identifikation einer Teilmenge von Konfigurationsdateneinheiten innerhalb des Entwicklungsdatenmodells und ein Abspeichern 103 der identifizierten Teilmenge.
4 zeigt eine Ausführungsform eines Rechensystems bzw. eines Computersystems PC. Dieses weist einen Prozessor CPU, der insbesondere als Mehrkernprozessor realisiert sein kann, einen Arbeitsspeicher RAM und einen Buscontroller BC auf. Bevorzugt ist das Computersystem PC dazu ausgelegt, von einem Nutzer direkt manuell bedient zu werden, wobei über eine Grafikkarte GPU ein Monitor DIS und über eine Peripherieschnittstelle HMI eine Tastatur KEY und eine Maus MOU angeschlossen sind. Prinzipiell könnte die Mensch-Maschine-Schnittstelle des Computersystems auch als Touch-Interface ausgebildet sein. Das Computersystem umfasst weiterhin einen nichtflüchtigen Datenspeicher HDD, der insbesondere als Festplatte und/oder Solid State Disk ausgeführt sein kann, sowie eine Schnittstelle NC, insbesondere eine Netzwerkschnittstelle. Über die Schnittstelle ist ein zentraler Datenspeicher CDS mit dem Computersystem verbunden. Der zentrale Datenspeicher liegt dabei häufig in Form einer Datenbank DB vor, wie auch in der Abbildung dargestellt.
Alternativ zur der in der Figur dargestellten Form, kann das Computersystem auch ein oder mehrere Server mit ein oder mehr Prozessoren, sowie ein mit diesen verbundenen Client umfassen. Dabei umfasst der Client Ein- und Ausgabe-Einrichtungen und ist mittels einem Netzwerk mit dem Server oder den Servern verbunden. Das beanspruchte Verfahren kann dabei auch verteilt, d.h. teilweise von zumindest einem der Server und teilweise auf einem weiteren Sever oder dem verbundenen Client, ausgeführt werden. Ein Beispiel hierfür wäre die Ausführung in einer Cloud-Rechenumgebung. Der Client kann z.B. als ein Standard Computer, auch Personal Computer genannt, mit eine entsprechenden Ein- und Ausgabe-Einrichtungen und einer Netzwerkanbindung ausgeführt sein. Alternativ kann eine graphische Bedienoberfläche auch auf einem portablen Computersystem dargestellt und vom Nutzer verwendet werden. Übliche portable Computersysteme sind Tablets oder Smartphones mit berührungssensitiven Bedienbildschirmen.
Somit wird ein Verfahren zum Festschreiben von (Daten-)Objekten, insbesondere technischer Entwicklungsdaten, also Modellen, Tests, Parameter und dergleichen, vorgeschlagen. Die Objekte liegen in einer Datenbank vor und können mindestens zwei Zustände annehmen. In einem ersten Zustand sind die Objekte veränderbar und die Objekte sind in einem zweiten Zustand nicht veränderbar bzw. festgeschrieben. Zwei voneinander abhängige Objekte existieren, wobei die Abhängigkeit in der Datenbank abgespeichert ist.
Eine Festschreibungsvorschrift bzw. ein Regelwerk bzw. eine Release Configuration wird bereitgestellt und als unabhängiges Objekt, beispielsweise in einer Datenbank, abgespeichert. Die Festschreibungsvorschrift bzw. das Regelwerk legt fest, welche voneinander abhängigen Objekte gemeinsam festgeschrieben bzw. als Release veröffentlicht werden. Gemäß einem weiteren Aspekt der vorliegenden Erfindung umfasst das Verfahren die Schritte der Auswahl eines Objektes, der Auswahl einer Festschreibungsvorschrift, ein automatisches Auswerten der Festschreibungsvorschrift für das ausgewählte Objekt zur automatischen Festlegung aller festzuschreibenden Objekte, ein automatisches Festschreiben der im vorherigen Schritt bestimmten Objekte in festen Versionen sowie ein Abspeichern der verwendeten Festschreibungsvorschrift und der zuletzt festgeschriebenen Objekte in den festen Versionen, inklusive der Abhängigkeiten zwischen Objekten und Festschreibungsvorschriften.
Ferner ist ein Aufspielen des festgeschriebenen Objekts auf einem technischen Gerät vorgesehen bzw. ein Testen eines technischen Geräts mittels des festgeschriebenen Objekts. Ferner ist ein Abspeichern der verwendeten Festschreibungsvorschrift und der festgeschriebenen Objekte als Datenobjekt der Datenhaltung vorgesehen. Die verwendete Festschreibungsvorschrift zusammen mit dem festgeschriebenen Objekt wird abgespeichert, oder ein neues Datenobjekt, umfassend das festgeschriebene Objekt und die verwendete Festschreibungsvorschrift wird gespeichert, wobei sich aus dem oder den Datenobjekt(en) der Zustand beim Festschreiben wiederherstellen lässt. Die Abhängigkeit einer Referenz aus dem festen Datenmodell kann als ein vom Benutzer gesetzter Link vorliegen. Eine Festschreibungsvorschrift ist nur für einen festgelegten Kreis an Objekten anwendbar. Eine Festschreibungsvorschrift umfasst oder referenziert zusätzliche Skripte, welche vor oder nach einem der vorgenannten Schritte zusätzlich ausgeführt werden.
Ferner kann das Verfahren von einem Client-Server-System ausgeführt werden, wobei die Skripte auf dem Server und/oder dem Client ausgeführt werden. Es existiert gemäß einem Aspekt der vorliegenden Erfindung eine Default-Festschreibungsvorschrift, welche das Standardvorgehen beim Festschreiben abbildet. Die Festschreibungsvorschriften können vom Benutzer editiert werden und sind selbst als Objekte festschreibbar. Generell kann eine solche Festschreibungsvorschrift auch als ein Regelwerk spezifiziert werden, welches wiederum selbst ein Objekt des Datenmodells, also eine Konfigurationsdateneinheit des Entwicklungsdatenmodells, darstellen kann.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

WO 0067156 A1 [0002]

Claims

Verfahren zur teilautomatisierten Entwicklungsdatenverwaltung für Steuergeräte, aufweisend: - Abspeichern (100) eines Entwicklungsdatenmodells in einem zentralen Datenspeicher, aufweisend eine Mehrzahl von jeweils in Relation stehenden Konfigurationsdateneinheiten, wobei die Konfigurationsdateneinheiten jeweils Steuerbefehle und/oder Konfigurationsparameter abspeichern; - Bereitstellen (101) eines Regelwerks und Identifikation mindestens einer initialen Konfigurationsdateneinheit, wobei anhand des Regelwerks weitere Konfigurationsdateneinheiten anhand ihrer Relation zu der initialen Konfigurationsdateneinheit automatisiert identifizierbar sind; - Anwenden (102) des bereitgestellten (101) Regelwerks auf das Entwicklungsdatenmodell zur Identifikation einer Teilmenge von Konfigurationsdateneinheiten innerhalb des Entwicklungsdatenmodells; und - Abspeichern (103) der identifizierten Teilmenge.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das Abspeichern (103) der identifizierten Teilmenge derart separat erfolgt, dass das Entwicklungsdatenmodell nicht überschrieben wird.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass das abgespeicherte (100) Entwicklungsdatenmodell in seiner Gesamtheit einer unterschiedlichen Rechtevergabe als die abgespeicherte (103), identifizierte Teilmenge unterliegt.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass auf die abgespeicherte (103), identifizierte Teilmenge ein schreibender Zugriff unterbunden wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass zu der identifizierte Teilmenge eine zusätzlich Konfigurationsdateneinheit abgespeichert wird, wobei die zusätzliche Konfigurationsdateneinheit Informationen über die initialen Konfigurationsdateneinheiten, das bereitgestellte (101) Regelwerk, die Konfigurationsdateneinheiten der identifizierte Teilmenge und/oder weitere Informationen über die Rahmenbedingungen des Verfahren umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die, als Teil der identifizierte Teilmenge, abgespeicherten initialen Konfigurationsdateneinheiten eine Referenz auf das bereitgestellte (101) Regelwerk umfassen.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das bereitgestellte (101) Regelwerk Teil einer hierarchisch aufgebauten Mengen von Regelwerken ist.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Abspeichern (103) der identifizierten Teilmenge iterativ erfolgt.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Entwicklungsdatenmodell eine Testspezifikation des Steuergeräts umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass mindestens ein Steuerbefehl eine Bedingung an eine Funktionalität des Steuergeräts beschreibt.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass mindestens ein Konfigurationsparameter einen Anforderungsparameter an das Steuergerät beschreibt.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass eine Relation indirekt zwischen mindestens zwei Konfigurationsdateneinheiten besteht.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass eine Relation eine Hierarchie, eine Vererbung, eine Zusammengehörigkeit und/oder eine Benutzer definierte Semantik aufweist.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Abspeichern (100) des Entwicklungsdatenmodells auf einem Server erfolgt und/oder das Anwenden (102) des bereitgestellten (101) Regelwerks mittels eines Clients initiiert wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Verfahrensschritte von verteilten Netzwerkkomponenten ausgeführt werden.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Entwicklungsdatenmodell generische Daten für eine Mehrzahl von Steuergerätetypen beschreibt und sich die identifizierte Teilmenge auf einen Steuergerätetyp beschränkt.
Rechenanordnung zur teilautomatisierten Entwicklungsdatenverwaltung für Steuergeräte, aufweisend: - einen ersten zentralen Datenspeicher eingerichtet zum Abspeichern (100) eines Entwicklungsdatenmodells, aufweisend eine Mehrzahl von jeweils in Relation stehenden Konfigurationsdateneinheiten, wobei die Konfigurationsdateneinheiten jeweils Steuerbefehle und/oder Konfigurationsparameter abspeichern; - eine Logikeinheit eingerichtet zum Bereitstellen (101) eines Regelwerks und Identifikation mindestens einer initialen Konfigurationsdateneinheit, wobei anhand des Regelwerks weitere Konfigurationsdateneinheiten anhand ihrer Relation zu der initialen Konfigurationsdateneinheit automatisiert identifizierbar sind; - eine Ausführungseinheit eingerichtet zum Anwenden (102) des bereitgestellten (101) Regelwerks auf das Entwicklungsdatenmodell zur Identifikation einer Teilmenge von Konfigurationsdateneinheiten innerhalb des Entwicklungsdatenmodells; und - einen Datenspeicher, insbesondere der erste zentrale Datenspeicher, eingerichtet zum Abspeichern (103) der identifizierten Teilmenge.
Computerprogrammprodukt mit Steuerbefehlen, welche das Verfahren gemäß einem der Ansprüche 1 bis 16 ausführen, wenn sie auf einem Computer zur Ausführung gebracht werden.