WO2007068563A1 - Verfahren zur verarbeitung und erzeugung von diagnosedaten in einem softwareentwicklungsprozess - Google Patents

Verfahren zur verarbeitung und erzeugung von diagnosedaten in einem softwareentwicklungsprozess Download PDF

Info

Publication number
WO2007068563A1
WO2007068563A1 PCT/EP2006/068846 EP2006068846W WO2007068563A1 WO 2007068563 A1 WO2007068563 A1 WO 2007068563A1 EP 2006068846 W EP2006068846 W EP 2006068846W WO 2007068563 A1 WO2007068563 A1 WO 2007068563A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
files
specific
customer
software
Prior art date
Application number
PCT/EP2006/068846
Other languages
English (en)
French (fr)
Inventor
Klaus Schneider
Simone Kriso
Corina Weber
Original Assignee
Robert Bosch Gmbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch Gmbh filed Critical Robert Bosch Gmbh
Publication of WO2007068563A1 publication Critical patent/WO2007068563A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/12—Use of codes for handling textual entities
    • G06F40/14—Tree-structured documents
    • G06F40/143—Markup, e.g. Standard Generalized Markup Language [SGML] or Document Type Definition [DTD]

Definitions

  • the invention relates to a method and a device for generating and processing diagnostic data in a software development process according to claims 1 and 15.
  • a customer uses project specifications to commission a development representative with the development of his or her desired products, software programs for controlling electronic devices, for example, and also expects a good and appropriate technical documentation.
  • many given data and functional requirements have to be taken manually from a confusing specification, structured, evaluated, adapted to the hardware, documented in so-called specifications, which are returned to the client as feedback information about the implementation of the order, in addition to the created program code .
  • the technical application makes it necessary to test the created software product in its intended hardware environment.
  • diagnostic data are needed. Originally used for fault diagnosis, diagnostic data today fulfill a very wide variety of other tasks.
  • XML standard written default files that contain a descriptive text in addition to hardware-independent default data, functions and configuration data by means of suitable software tools, these data and functions are automatically obtained and transformed.
  • hardware-related data and functions are added and the default data and functions are implemented, i. h adapted to the selected hardware.
  • the default files also contain information about required or unneeded existing functions and their configuration. tion, whereby the unneeded functions are not integrated into the resulting program code, the source code, and thus the end product requires less storage volume.
  • the resulting plurality of programs are compiled according to an order also handed over in XML default file (s), resulting in executable program files without access conflicts.
  • the same system also provides automatically generated technical documentation for the automatically generated program.
  • ODX or 'Open Diagnostic Data Exchange'
  • XML description language
  • OEM developers developing in the order.
  • the data input can be carried out with the help of a GUI, an input menu, easily and without any programming knowledge.
  • the program-technical details of the ODX format are hidden from the editing user. The advantage here is that the customer-specific data can be entered easily manually, and are available quickly, since no intervention in the development environment is necessary.
  • the ODX standard In addition to naming conventions defined by ASAM Panel, the ODX standard also allows free space for the manufacturer-specific naming conventions for the data, variables and functions relevant to the diagnostic process. It is precisely these proprietary naming conventions that require an OEM contract developer to specialize in his development, which he would like to avoid, for example, with a single engine control unit to serve all his various clients, with a few adjustments. Despite the ODX standard, problems of compatibility were not completely eliminated. It's up to each OEM developer how far they automate their development processes; h wants to use the possibilities of the ODX format.
  • the diagnostic data of a motor controller may include over 600 error codes, and therefore one should not allow the input of these data to be performed manually, as this becomes very expensive and may be subject to human error.
  • the other problem is the updating of the associated documentation, and ensuring data consistency between the documentation and the actual technical condition of the hardware and software system to be developed.
  • Disadvantages of conventional manual XML and ODX methods for handling the diagnostic data are problems in ensuring data consistency, in particular with the controller behavior, since manual handling involves a source of human errors.
  • the high volume of data, for example with a motor control and its delivery frequency, make such handling even impracticable.
  • XML and ODX files contain machine readable code, small errors in this code can have a big impact, which should lead to careful handling of the input.
  • Diagnostic processes have taken on much broader tasks since their creation for the purpose of error detection and evaluation, further meaningful tasks could be added, and involve very complex processes in a development process between contracting manufacturer, its development and production, as well as technical service and commissioned developer.
  • the advantage here is that on the diagnostic data in a finished vehicle still access is possible while all other accesses to the electronic controls are installed inaccessible.
  • the complexity of the diagnostic data today can be seen from the following incomplete and constantly evolving list: measuring, starting routines, calibration, Inpul / Output Control, Flash programming, variant coding, read error memory, specification and bus node emulation.
  • the object of the present invention is to propose a method for the automatic processing of customer-specific default files in a readable, for example diverse diagnostic data containing XML format in the ODX standard, the customer independent and hardware independent design of the development process of ECU software and use, consistency assurance and updating the diagnostic data in a ECU development process, and its final Adaptation to the chosen customer-specific conventions.
  • the diagnostic data and the diagnostic process chain should be better integrated into the development of the ECU software than before.
  • the inventive solution of the problem is achieved by a reproduced in claim 1 method.
  • the format contained by a customer in a readable, text, data and program code, here specifically in the ODX format supplied specifications and a variety of diagnostic data are initially associated in part with the custom naming conventions, as it in the ODX standard in addition to fixed rules and freedom for customer-specific characteristics.
  • the default files of the client, the u. U can already be return files in an already in the rectification development circle, transformed into an in-house format.
  • the in-house format can and has in this case a wider validity, such.
  • B also data and functional specifications for the control software have a largely complete picture in it, which would not exist in the ODX format.
  • Another subsequent transformation frees the supplied default files from customer-specific characteristics, which are reflected in particular in the naming of specific variables, data records and functions, as permitted by the ODX standard.
  • the commissioned developer replaces the customer-specific naming conventions in this process step with his own in-house conventions. He does this not according to the invention preferably manually, but called with the help of automatically acting software tools, tools. This step can therefore be easily automated because all naming conventions of all clients have been previously known to the commissioned developer, have been recorded and have been made available to the tools in a structured data structure.
  • the client's files are stored in a XML-based z. B in-house format and now go to the next step in which in the diagnostic data containing default files preparatory carried out an implementation of the hardware properties for the control unit used.
  • This implementation is made manually according to the invention to allow the greatest possible flexibility and influence on the development and diagnostic process. In some cases, however, automatic software tools are also being used here.
  • the automatic action by means of software tools on the now modified and supplemented default data and diagnostic data, which could therefore be called aptly process data, will be carried out in a next step, which itself represents a complex and widely branched, so-called configuration process.
  • the diagnostic software is configured with the aid of automatically acting software tools, control unit code is generated for the customer, and the diagnostic data itself is updated.
  • the configuration process eliminates the automatically configured software tools that affect the application of the ECU software, the diagnostic software and ECU code, as well as updated diagnostics data.
  • the diagnostic data are stored in a next step in the meantime in a database for diagnostic data.
  • the diagnostic data are in a customer-specific form z. B in in-house universal format and can therefore be used for any job customer.
  • a converting process step is performed, which could be called a customer specification converter.
  • the customer-specific diagnostic data are overwritten here with the customer-specific naming conventions before they are delivered to the corresponding customer.
  • the data are first processed in general and customer-specific in XML format on the basis of so-called rules, whereby an updated control unit data record from the development is also supplied, which is thereby incorporated into the diagnostic data process. Since the rules initially affect the customer-unspecific data before it is converted, they are universally applicable and do not have to be new for every customer to be created. These rules are written in any suitable programming language, eg. B in JAVA, XSLT or a special template language, and are essentially programs that are directed to specific tasks. These objects are not the subject of the present invention.
  • the proposed method can essentially be described by its three principal process components.
  • it is proposed to combine the control unit code and the diagnostic data, i. h no longer consider them separately, which, above all, ensures data consistency.
  • the second basic process process involves targeted processing of the diagnostic data in the software development process.
  • the diagnostic data becomes the source for direct extraction of program code or program configuration.
  • the third principle is the separation of data processing and customization of diagnostic data at the conclusion of the process, leaving the processing software tools independent of customer-specific requirements.
  • Figure 1 is an overview of the entire process of data exchange between a client and development officer in the automotive sector
  • FIG. 1 is an illustration of the method according to the invention.
  • FIG. 1 provides an overview of the known process sequences in the environment of an automobile production and order development, including the service area.
  • the specifying requirements 5 are initially specified to an electronic controller in XML format, and commissioned to the developer of the electronic controller 2, where in its development 10 the specification for the controller is developed.
  • the most important parts of this specification of a control unit are intended for automotive development 6 at the automobile manufacturer, where they are tested and made ready for series production in a coupled process between the client and the authorized representative.
  • Finished electronic control with the control software then goes into production 7.
  • the car manufacturer 1 of the technical see service in the development of the service 8 incorporating the data from the specification 11 of the electronic control preparatory developed.
  • the diagnostics sequences 13 are defined in step 12 by a manufacturer 3 of the software for the service 14.
  • FIG. 2 shows the method according to the invention in an advantageous embodiment.
  • the diagnostic data in ODX format are delivered by the ordering customer 15 and are at the beginning of a process chain. These are the ODX default files 16, where BV.odx describes the basic variant, PP.odx contains the protocol description, and CP.odx describes the specification of the communication parameters of a controller or a tester. These files get into the transformation 17 in the conversion into the in-house X M L format, here z. B into a so-called MSR
  • This in-house format has a much broader scope of definition and also maps the entire development data for the ECU software, making it more suitable for in-house editing.
  • the diagnostic data are also introduced into the development process of the control software in addition to the actual diagnostic data processing and can be used in it.
  • the custom naming conventions for data, variables and functions are overwritten with the in-house naming conventions in a so-called name converter 18, whereby the files now exist in a customer-independent format and nevertheless contain all the information that the customer has delivered.
  • the implementation-specific details 19 are performed manually by developers, adding the hardware features to the electronic controller and the controller software, and the files 20 are created in the in-house customer-unspecific XM L format, which now contains both diagnostic data and other controller data.
  • diagnostic data are stored from the configuration in the database of the diagnostic data 22, from where they get into the custom data converter 24.
  • the control unit data record 25 currently obtained from the development and the diagnostic data are processed in XM L format.
  • the customer-specific converter 24, or so-called use case converter carries out a further complex process in which, according to the invention, first of all a general customer-specific processing of the data is prepared, which was prepared for this purpose in the configuration process 21, and additionally the updated one Control unit record 25 is taken into account. Subsequently, the now completed diagnostic data is converted into the ODX format and also into the customer-specific naming of data records, variables and functions. The latter represents the inverse process at the beginning of the procedure. Rules and data sets are available from which automatic software tools read the conventions of the ODX format and those of the respective customer, and with them modify the diagnostic data overridingly. In addition, the essential customer documentation 28 in XML format is also obtained automatically from the same data, and is thus consistent with the finished diagnostic data.
  • the diagnostic data are stored, for example, in the files provided by ODX standard for tasks. In Cust.odx
  • the processed diagnostic data are stored for the ordering customer, called OEM customers.
  • SCD. odx 27 is the diagnostic file created for the so-called 'Standard Customer Diagnosis', which is also delivered to the ordering customer and used in his processes.
  • the automatically generated customer documentation 28 which is referenced to the same source files, making the documentation 28 consistent; h corresponds to the facts of the development progress and the widely used updated diagnostic data.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Artificial Intelligence (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Computational Linguistics (AREA)
  • General Health & Medical Sciences (AREA)
  • Stored Programmes (AREA)

Abstract

Verfahren zur Verarbeitung und Erzeugung von Diagnosedaten in einem Softwareentwicklungsprozess, bei dem in einem ersten Verfahrensschritt Vorgaben in einer oder mehreren Vorgabedateien (16) in den Entwicklungsprozess geliefert werden, die in einer Programmiersprache, vorzugsweise in XML-Standard, insbesondere im ODX-Format, erstellt sind, in einem zweiten Verfahrensschritt der Hardware-Implementierung (19) den Vorgabedateien (16) implementierungsspezifische Eigenschaften eingeprägt werden, und die vorher implementierungsunabhängigen Daten (20) für bestimmte Steuergeräte-Hardware und -Software angepasst werden, in einem dritten Verfahrensschritt in einem Konfigurationsprozess (21) zum einen eine Diagnose-Software (23) mit Parametern und zum anderen Diagnosedaten für eine spätere Verarbeitung konfiguriert werden, und in einem vierten Verfahrensschritt die Diagnosedaten unter Berücksichtigung eines aktualisierten Steuergerätedatensatzes (25) aus der Hardwareentwicklung mittels einer Anzahl von geeigneten Software-Tools zunächst einer Verarbeitung unterzogen und abschließend in einem ODX- und kundenspezifischen Konvertierungsprozess verarbeitet werden, bei dem kundenspezifische und ODX-Benennungsregeln ausgewählt, eingelesen und mit ihnen Dateien im ODX-Format sowie eine dadurch datenkonsistente technische Dokumentation (28) automatisch erstellt werden.

Description

Beschreibung
Verfahren zur Verarbeitung und Erzeugung von Diagnosedaten in einem Softwareent- wicklungsprozess
Die Erfindung betrifft ein Verfahren und eine Vorrichtung zum Erzeugen und Verarbeiten von Diagnosedaten in einem Softwareentwicklungsprozess nach Anspruch 1 und 15.
Üblicherweise beauftragt ein Kunde mit Hilfe von Lastenheften einen Entwicklungsbeauftragten mit der Entwicklung seiner Wunschprodukte, der Softwareprogramme zur Steue- rung von elektronischen Geräten beispielsweise, und erwartet außerdem eine gute und zutreffende technische Dokumentation dazu. Es müssen dabei viele vorgegebene Daten und Funktionsanforderungen aus einem unübersichtlichen Lastenheft manuell entnommen, strukturiert, ausgewertet, angepasst an die Hardware, dokumentiert in so genannten Pflichtenheften, die als Rückinformation über die Umsetzung des Auftrags an den Auf- traggeber geliefert werden, neben dem erstellten Programmcode. Oft macht es die technische Anwendung erforderlich, das erstellte Softwareprodukt in ihrer vorgesehenen Hardwareumgebung testen zu können. Auch hierzu werden so genannte Diagnosedaten benötigt. Ursprünglich zur Fehlerdiagnose genutzt, erfüllen heute Diagnosedaten sehr vielfältige weitere Aufgaben.
Man ist dazu übergegangen den Entwicklungsprozess, speziell die Umsetzung der Vorgaben in Softwareprodukte zu automatisieren, und hierzu die Vorgaben maschinenlesbar zu gestalten.
In der DE 10 2004 005 730 Al wird ein Verfahren offenbart, mit dem aus einer Anzahl im
XML- Standard geschriebener Vorgabedateien, die einen beschreibenden Text neben hardwareunabhängigen Vorgabedaten, Funktionen und Konfigurationsdaten enthalten mit Hilfe geeigneter Softwarewerkzeuge diese Daten und Funktionen automatisch gewonnen und transformiert werden. In einem weiteren Schritt werden hardware-behaftete Daten und Funktionen hinzugefügt und die Vorgabedaten und Funktionen implementiert, d. h an die gewählte Hardware angepasst. Die Vorgabedateien enthalten zudem Informationen über benötigte oder nicht benötigte vorrätig vorhandene Funktionen und deren Konfigura- tion, wodurch die nicht benötigten Funktionen erst gar nicht in den entstehenden Programmcode, den Source-Code, eingebunden werden und dadurch das Endprodukt weniger Speichervolumen benötigt. Die entstehende Mehrzahl von Programmen wird nach einer ebenso in XML-Vorgabedatei/en überlieferten Reihenfolge kompiliert, wodurch aus- führbare Programmdateien ohne Zugriffskonflikte entstehen. Das gleiche System liefert auch eine automatisch erstellte technische Dokumentation zu dem automatisch erstellten Programm. Vorteilhaft ist hierbei, dass die hardwareunabhängigen Vorgaben in einem XML- Editor leicht und übersichtlich mit geänderten Daten gefüllt werden, beispielsweise seitens eines beauftragenden Kunden, weitere Schritte automatisch erfolgen und die technische Dokumentation immer automatisch angepasst der aktualisierten Softwareversion entspricht. Nachteilig ist, dass die Belange des Diagnoseprozesses, seiner vielfältigen Aufgaben, nicht genügend berücksichtigt werden.
ODX, oder 'Open Diagnostic Data Exchange', ist ein auf der Beschreibungssprache XML basierendes, standardisiertes Datenformat für die prozessbegleitenden Diagnosedaten einer Softwareentwicklung im automobilen Bereich zwischen beauftragenden Automobilherstellern und den im Auftrag entwickelnden sogenannten OEM-Entwicklern. Mit Hilfe komfortabler XML/ODX Editoren lässt sich die Dateneingabe mit Hilfe einer GUI, eines Eingabemenüs, leicht und ohne Programmierkenntnisse ausführen. Die programmtechni- sehen Details des ODX-Formats bleiben dem editierenden Benutzer verborgen. Vorteilhaft ist hierbei, dass die kundenspezifischen Daten einfach manuell eingegeben werden können, und schnell verfügbar sind, da kein Eingriff in die Entwicklungsumgebung nötig ist. Der ODX-Standard lässt neben durch ASAM Gremium festgelegten Namenskonventionen für die im Diagnoseprozess relevanten Daten, Variablen und Funktionen auch Frei- räum für die herstellereigenen Namenskonventionen. Genau diese herstellereigenen Namenskonventionen machen es erforderlich, dass ein OEM-Auftragsentwickler seine Entwicklung darauf spezialisiert, was er jedoch gern vermeiden würde um mit einem beispielsweise Motorsteuerungsgerät alle seine verschiedenen Auftraggeber bedienen kann, mit einigen wenigen Anpassungen. Trotz des ODX-Standards blieben also Probleme der Kompatibilität nicht ganz aus der Welt geschaffen. Jedem OEM-Entwickler bleibt es überlassen, wie weit er seine Entwicklungsprozesse automatisieren, d. h die Möglichkeiten des ODX-Formats nutzen will. Die Diagnosedaten einer Motorsteuerung können über 600 Fehlercodes umfassen, und daher sollte man die Eingabe dieser Daten nicht manuell ausführen lassen, da dies sehr aufwendig wird und mit menschlichen Fehlern behaftet sein kann. Das weitere Problem stellt die Aktualisierung der dazugehörenden Dokumentation, und die Gewährleistung der Datenkonsistenz zwischen der Dokumentation und dem tatsächlichen technischen Zustand des zu entwickelnden Hard- und Software-Systems dar. Nachteilig für konventionelle manuelle XML- und ODX-Verfahren zur Handhabung der Diagnosedaten sind Probleme bei der Gewährleistung der Datenkonsistenz, insbesondere mit dem Steuergeräteverhalten, da eine manuelle Handhabung eine Quelle menschlicher Fehler beinhaltet. Das hohe Aufkommen von Daten, beispielsweise bei einer Motorsteue- rung und ihre Lieferfrequenz machen solche Handhabung gar undurchführbar. Da XML, und ODX Dateien maschinenlesbaren Kode enthalten, können kleine Fehler in diesem Kode große Auswirkungen haben, was zu sorgfältigem Umgang mit den Eingaben veranlassen sollte.
Diagnoseprozesse haben seit ihrer Entstehung zum Zwecke der Fehlererfassung und Auswertung sehr viel weiter gehende Aufgaben übernommen, weitere sinnvollen Aufgaben könnten noch hinzu kommen, und sie umfassen sehr komplexe Vorgänge in einem Entwicklungsprozess zwischen auftraggebendem Hersteller, seiner Entwicklung und Produktion, sowie dem technischen Service und dem beauftragten Entwickler. Vorteilhaft ist hierbei, dass auf die Diagnosedaten in einem fertig gestellten Fahrzeug noch immer ein Zugriff möglich ist, während alle anderen Zugänge zu den elektronischen Steuerungen unzugänglich verbaut werden. Wie komplex die Diagnosedaten heute sind, sieht man anhand folgender nicht vollständiger und in ständiger Fortentwicklung befindender Aufzählung: Messen, Routinen starten, Kalibrierung, Inpul/Output Control, Flash- Programmierung, Varianten-Codierung, Fehlerspeicher lesen, Spezifikation und Busknoten-Emulation.
Neben der Diagnosedatenprozesskette existiert noch eine Prozesskette zur Entwicklung des Steuergerätekodes, die ähnlich in einem XML-Format abgewickelt wird, als Lasten- heft und einem rücklaufenden Pflichtenheft. Die Existenz zweier unabhängiger die Entwicklung betreffender Datenflüsse wirkt sich nachteilig aus, wenn es darum geht, dass die Entwicklungsergebnisse, die Diagnosedaten und die Dokumentation miteinander konsistent sind und es in verschiedenen Verfahrensabschnitten bleiben. Es entstehen Zeitfenster in denen wegen der aufwendigen Arbeitsgänge die Datenkonsistenz nicht schnell ge- nug wiederhergestellt werden kann.
Die Aufgabe der vorliegenden Erfindung ist es, ein Verfahren zur automatischen Verarbeitung von kundenspezifischen Vorgabedateien in einem lesbaren, beispielsweise vielfältige Diagnosedaten enthaltenden XML-Format im ODX-Standard vorzuschlagen, das eine kundenunabhängige und hardwareunabhängige Gestaltung des Entwicklungsprozesses von Steuergerätesoftware und die Nutzung, Konsistenzsicherung sowie Aktualisierung der Diagnosedaten in einem Steuergeräteentwicklungsprozess, und deren abschließende Anpassung an die gewählten kundenspezifischen Konventionen ermöglicht. Die Diagnosedaten und die Diagnoseprozesskette sollen besser als bisher in die Entwicklung der Steuergerätesoftware eingebunden werden.
Die erfindungsgemäße Lösung der gestellten Aufgabe ist durch ein im Anspruch 1 wiedergegebenes Verfahren realisiert. Die von einem Kunden in einem lesbaren, Text, Daten und Programmkode enthaltenden Format, hier speziell im ODX-Format gelieferten Vorgaben und vielfältigen Diagnosedaten sind zunächst zu einem Teil auch mit den kundenspezifischen Namenskonventionen behaftet, da es im ODX-Standard neben festen Regeln auch Freiraum für kundenspezifische Ausprägungen gibt. In einem ersten Schritt des erfindungsgemäßen Verfahrens werden die Vorgabedateien des Auftraggebers, die u. U auch bereits Rücklaufdateien in einem bereits in die Nachbesserung gehenden Entwicklungskreis sein können, in ein hausinternes Format transformiert. Das hausinterne Format kann und hat in diesem Fall eine breitere Gültigkeit, so z. B auch Daten- und Funktions- vorgaben für die Steuersoftware haben in ihm eine weitgehend vollständige Abbildung, die im ODX-Format nicht gegeben wäre.
Eine weitere darauf folgende Transformation befreit die angelieferten Vorgabedateien von kundenspezifischen Ausprägungen, die insbesondere sich in der Namensgebung für be- stimmte Variablen, Datensätze und Funktionen niederschlagen, wie der ODX-Standard es zulässt. Der beauftragte Entwickler ersetzt in diesem Verfahrensschritt die kundenspezifischen Namenskonventionen durch seine eigenen hausinternen Konventionen. Dies tut er erfindungsgemäß vorzugsweise nicht manuell, sondern mit Hilfe automatisch wirkender Softwarewerkzeuge, Tools genannt. Dieser Schritt kann deshalb gut automatisiert wer- den, weil alle Namenskonventionen aller Auftraggeber dem beauftragten Entwickler vorher bekannt gewesen sind, erfasst wurden und in einem strukturierten Datengefüge dem Zugriff der Tools bereit gestellt worden sind.
Danach liegen die Dateien des Auftraggebers in einem auf dem XML- Standard basieren- den z. B hausinternen Format vor und gelangen nun zu dem nächsten Verfahrensschritt, in dem in die Diagnosedaten enthaltenden Vorgabedateien vorbereitend eine Implementierung der Hardwareeigenschaften für das verwendete Steuergerät erfolgt. Diese Implementierung wird erfindungsgemäß manuell vorgenommen um die größtmögliche Flexibilität und Einflussnahme auf den Entwicklungs- und Diagnoseprozess zu ermöglichen. Zum Teil werden aber auch hier bereits automatische Softwarewerkzeuge angewendet. Nun liegen anschließend in den inzwischen veränderten Vorgabedateien sowohl Daten, Diagnosedaten, wie auch Steuergerätekode gleichzeitig vor, und sie entsprechen zu diesem Zeitpunkt einem gleichen Entwicklungsstand, wodurch sie zu einander in konsistentem Verhältnis stehen, und die weitere Verarbeitung im Entwicklungsprozess wird daher im höchsten Masse konsistente Datenquellen benutzen.
Das automatische Einwirken mittels Softwaretools auf die inzwischen veränderten und ergänzten Vorgabedaten und Diagnosedaten, die man deshalb nun treffender Prozessdaten nennen könnte, wird in einem nächsten Verfahrensschritt durchgeführt, der selbst einen komplexen und weit verzweigten, so genannten Konfigurationsprozess darstellt. In diesem weitergehenden Konfigurationsprozess wird unter anderem mit Hilfe automatisch wirkender Software-Werkzeuge die Diagnose-Software konfiguriert, Steuergerätekode für den Kunden erzeugt, und die Diagnosedaten selbst aktualisiert.
Dies bedeutet, dass die Entwicklungsprozesse der Steuergerätesoftware die neuesten aktuellen Erkenntnisse aus den rückläufigen oder erstmaligen Diagnosedaten des Auf- tragsgebers und ebenso aus den aktuellen Erkenntnissen der Entwicklungsabteilungen über ihre eigene Hard- und Software zum vorgesehenen Steuergerät erhalten. Das betroffene Steuergerät kann Modifikationen erfahren haben oder gar ein anderes Gerät werden, und die so erstellten Diagnosedaten und weitere Vorgaben werden durch das hauseigene Format und den manuellen Hardware-Implementierungsvorgang wirksam berücksichtigt. Aus dem Konfigurationsprozess fallen heraus die automatisch konfigurierten Softwaretools zum Einwirken auf die Applikation der Steuergerätesoftware, die Diagnosesoftware und Steuergerätekode, sowie aktualisierten Diagnosedaten.
Die Diagnosedaten werden in einem nächsten Verfahrensschritt zwischenzeitlich in einer Datenbank für Diagnosedaten abgelegt. In dieser Diagnosedatenbank liegen die Diagnosedaten in einer kundenunspezifischen Form z. B im hausinternen universellen Format vor und können daher für einen beliebigen Auftragskunden verwendet werden.
Abschließend wird ein konvertierender Verfahrensschritt ausgeführt, den man einen Kun- denspezifikationskonverter nennen könnte. Vor allem werden hier die kundenunspezifischen Diagnosedaten mit den kundenspezifischen Namenskonventionen überschrieben, bevor sie an den entsprechenden Kunden ausgeliefert werden. Doch zuvor werden die Daten zunächst generell und kundenunspezifisch in XML-Format anhand von so genannten Regeln verarbeitet, wobei ein aktualisierter Steuergerätedatensatz aus der Entwick- lung hinzu angeliefert wird, die dadurch in den Diagnosedaten- Prozess eingebunden wird. Da die Regeln zunächst noch auf die kundenunspezifischen Daten vor deren Konvertierung einwirken, sind sie universell anwendbar, und müssen nicht für jeden Kunden neu erstellt werden. Diese Regeln sind in irgendeiner geeigneten Programmiersprache erstellt, z. B in JAVA, XSLT oder einer speziellen Template-Sprache, und sind ihrem Wesen nach Programme, die auf bestimmte Aufgaben gerichtet sind. Diese Aufgaben sind nicht Gegenstand der vorliegenden Erfindung.
Somit lässt sich das vorgeschlagene Verfahren im Wesentlichen durch seine drei prinzipiellen Prozess- Bestandteile beschreiben. Zum einen wird vorgeschlagen, Steuergerätekode und die Diagnosedaten zusammenzufassen, d. h diese nicht mehr getrennt zu betrachten, wodurch vor allem die Datenkonsistenz gesichert wird. Zum zweiten prinzipiellen Prozessvorgang ge- hört eine gezielte Verarbeitung der Diagnosedaten im Softwareentwicklungsprozess. Die Diagnosedaten werden zur Quelle für eine direkte Gewinnung von Programmkode oder Programmkonfiguration. Als drittes Prinzip ist die Trennung von Datenverarbeitung und kundenspezifischer Ausprägung der Diagnosedaten am Abschluss des Verfahrens, wodurch die verarbeitenden Softwarewerkzeuge unabhängig von kundenspezifischen Anforderungen bleiben.
Weitere Ausführungsformen der Erfindung ergeben sich aus den Unteransprüchen.
Das erfindungsgemäße Verfahren wird im folgenden anhand eines Ausführungsbeispiels näher erläutert. Gleiche oder gleichwirkende Teile sind mit gleichen Bezugszeichen ver- sehen. Es zeigen:
Figur 1 eine Übersicht über den gesamten Prozess des Datenaustauschs zwischen einem Auftraggeber und Entwicklungsbeauftragten im automobilen Bereich, und
Figur 2 eine Darstellung des erfindungsgemäßen Verfahrens.
In Figur 1 ist eine Übersicht über die bekannten Prozessabläufe im Umfeld einer automobilen Fertigung und Auftragsentwicklung einschließlich des Servicebereichs gegeben. Bei einem Automobilhersteller 1 werden anfänglich die spezifizierenden Anforderungen 5 an eine elektronische Steuerung in XML-Format spezifiziert, und diese zum Entwickler der elektronischen Steuerung 2 in Auftrag gegeben, wo in seiner Entwicklung 10 die Spezifikation für die Steuerung entwickelt wird. Die wichtigsten Teile dieser Spezifikation eines Steuergerätes sind für die Automobilentwicklung 6 beim Automobilhersteller bestimmt, wo sie getestet und in einem gekoppelten Prozess zw. Auftraggeber und Beauftragten zur Serienreife gelangen. Fertige elektronische Steuerung mit der Steuersoftware gelangt dann in die Produktion 7. Für die fertigen Produkte wird beim Autohersteller 1 der techni- sehe Service in der Entwicklung des Services 8 unter Einbeziehung der Daten aus der Spezifikation 11 der elektronischen Steuerung vorbereitend entwickelt. Aus den Daten der Spezifikation 20 der elektronischen Steuerung und aus den Daten, die auf der Seite des Automobilherstellers 1 in der Service- Entwicklung 8 erstellt werden, die Daten 9 für den technischen Service erstellt, die dann in die Service-Stationen 4 geliefert werden, wo in den Fachwerkstätten an den Automobilen der Endverbraucher der technische Service geleistet wird. In einem bislang unerwähnten Prozess werden bei einem Hersteller 3 der Software für den Service 14 in Schritt 12 die Diagnosesequenzen 13 definiert.
Bei diesem Gesamtüberblick wird klar, wie komplex die Datenflüsse und erst recht deren Verarbeitung sein müssen, woraus der Bedarf nach automatisierten und standardisierten Datenaustauschvorgängen erklärbar wird. Das ist der Grund für die Verwendung von XML-Format und auf ihm basierenden ODX-Standard, das speziell die Belange der Diagnoseprozesse mit standardisierten Konventionen regelt, und dadurch den Entwicklern der elektronischen Steuerungen erlaubt Kosten sparend für verschiedenen Automobilhersteller zu produzieren. Im Prinzip muss es gar nicht mal auf die Automobilbranche beschränkt bleiben, denn ähnliche Prozesse gibt es auch in anderen Branchen.
In Figur 2 ist das erfindungsgemäße Verfahren in einer vorteilhaften Ausführung abgebil- det. Die Diagnosedaten in ODX-Format werden von dem beauftragenden Kunden 15 geliefert und stehen am Anfang einer Verfahrenskette. Es sind die ODX- Vorgabedateien 16, wobei BV.odx die Basisvariante beschreibt, PP.odx die Protokollbeschreibung beinhaltet, und CP.odx die Spezifikation der Kommunikationsparameter eines Steuergeräts bzw. eines Testers beschreibt. Diese Dateien gelangen in die Transformation 17 bei der eine Umwandlung in das hausinterne X M L- Format, hierbei z. B in ein so genanntes MSR-
Format erfolgt. Dieses hausinterne Format hat wesentlich breiteren Definitionsumfang und bildet auch die gesamten Entwicklungsdaten für die Steuergerätesoftware ab, wodurch es sich besser für die hausinterne Bearbeitung eignet. Durch diesen Verfahrensschritt werden die Diagnosedaten neben der eigentlichen Diagnosedatenverarbeitung auch in den Entwicklungsprozess der Steuersoftware eingebracht und können in ihm verwendet werden.
Im weiteren erfindungsgemäßen Verfahrensschritt werden in einem so genannten Namenskonverter 18 die kundenspezifischen Namenskonventionen für Daten, Variablen und Funktionen mit den hausinternen Namenskonventionen überschrieben, wodurch die Dateien nun in einem kundenunabhängigen Format vorliegen und trotzdem alle Informationen beinhalten, die der Kunde geliefert hat. In einem nächsten Verfahrensschritt werden die implementierungsspezifischen Details 19 manuell von Entwicklern durchgeführt, wobei die Hardwareeigenschaften der elektronischen Steuerung und der Steuergerätesoftware hinzugefügt werden, und es entstehen die Dateien 20 im haisinternen kundenunspezifi- schen X M L- Format, die nun sowohl Diagnosedaten als auch andere Steuergerätedaten enthalten. Diese Dateien gelangen nun in den nächsten Verfahrensschritt, ein Konfigura- tionsprozess 21, in dem eine automatische Konfiguration der Diagnosesoftware 23, und Verarbeitung mit anschließender Extraktion der aktualisierten Diagnosedaten erfolgt. Außerdem finden hierbei weitere automatischen Prozesse der Entwicklung der Steuergerätesoftware statt, die mittels automatischer Softwarewerkzeuge Steuergerätekode und Ko- de erzeugende Hilfsprogramme konfigurieren, erstellen oder ganz erzeugen, und dabei auf die Diagnosedaten zugreifen und sie benutzen. Die Diagnosedaten werden aus der Konfiguration in die Datenbank der Diagnosedaten 22 abgelegt, von wo sie in den kundenspezifischen Datenkonverter 24 gelangen. In diesem Datenkonverter wird der aus der Entwicklung aktuell gewonnene Steuergerätedatensatz 25 und die Diagnosedaten in X M L- Format verarbeitet.
Der kundenspezifische Konverter 24, oder so genannter Usecase-Converter, führt einen weiteren komplexen Prozess aus, bei dem erfindungsgemäß zuerst eine generelle kun- denunspezifische Verarbeitung der Daten durchgeführt wird, die hierzu in dem Konfigura- tionsprozess 21 vorbereitet wurden, und zusätzlich noch der aktualisierte Steuergerätedatensatz 25 berücksichtigt wird. Anschließend werden die nun fertig gestellten Diagnosedaten noch in das ODX-Format und außerdem in die kundenspezifische Namensgebung für Datensätze, Variablen und Funktionen konvertiert. Letzteres stellt einen zu dem am Anfang des Verfahrens stehenden inversen Vorgang dar. Es liegen Regeln und Datensätze vor, aus denen automatische Softwarewerkzeuge die Konventionen des ODX-Formats und die des betreffenden Kunden lesen, und mit ihnen die Diagnosedaten überschreibend modifizieren. Außerdem wird auch noch die unerlässliche Kundendokumentation 28 in XML-Format ebenso automatisch aus den gleichen Daten gewonnen, und ist dadurch konsistent mit den fertigen Diagnosedaten. Die Diagnosedaten sind beispielsweise in den von ODX-Standard vorgesehenen Dateien nach Aufgaben aufgeteilt abgelegt. In Cust.odx
26 sind die aufbereiteten Diagnosedaten für den auftraggebenden Kunden, OEM-Kunden genannt, abgelegt. SCD. odx 27 ist die für die sogenannte 'Standard Customer Diagnosis' erstellte Diagnosedatei, die ebenso an den auftraggebenden Kunden geliefert wird und in seinen Prozessen Verwendung findet. Schließlich bleibt noch die automatisch erstellte Kundendokumentation 28, die hierdurch auf die gleichen Quelldateien bezogen wird, wodurch die Dokumentation 28 konsistent erstellt wird, d. h den Tatsachen des Entwicklungsfortschritts und den vielfältig verwendeten aktualisierten Diagnosedaten entspricht.

Claims

Patentansprüche
1. Verfahren zur Verarbeitung und Erzeugung von Diagnosedaten in einem Softwareentwicklungsprozess, bei dem in einem ersten Verfahrensschritt Vorgaben in einer oder mehreren Vorgabedateien (16) in den Entwicklungs- prozess geliefert werden, die in einer Programmiersprache, vorzugsweise in
XML-Standard, insbesondere im ODX-Format, erstellt sind, in einem zweiten Verfahrensschritt der Hardware-Implementierung (19) den Vorgabedateien (16) implementierungsspezifische Eigenschaften eingeprägt werden, und die vorher implementierungsunabhängigen Daten (20) für bestimmte Steuergeräte- Hardware und - Software angepasst werden, in einem dritten Verfahrensschritt in einem Konfigurati- onsprozess (21) zum einen eine Diagnose-Software (23) mit Parametern und zum anderen Diagnosedaten für eine spätere Verarbeitung konfiguriert werden, und in einem vierten Verfahrensschritt die Diagnosedaten unter Berücksichtigung eines aktualisierten Steuergerätedatensatzes (25) aus der Hardwareentwicklung mittels ei- ner Anzahl von geeigneten Software-Tools zunächst einer Verarbeitung unterzogen und abschließend in einem ODX- und kundenspezifischen Konvertierungsprozess verarbeitet werden, bei dem kundenspezifische und ODX-Benennungsregeln ausgewählt, eingelesen und mit ihnen Dateien im ODX-Format sowie eine dadurch datenkonsistente technische Dokumentation (28) automatisch erstellt werden.
2. Verfahren nach Anspruch 1, bei dem im ersten Verfahrensschritt eine Transformation (17) der Vorgabedateien (16) in ein der Entwicklungsumgebung angepasstes universelleres Format erfolgt, und in einem Namenskonverter (18) kundenspezifische Namenskonventionen für Daten, Variablen und Funktionen mit universellen Namen überschrieben werden.
3. Verfahren nach Anspruch 2, bei dem das universellere Format, in das die Vorgabedateien (16) umgeformt werden, ein auf dem XML-Format basierender Standard ist, und dieser Standard einen breiteren, die Entwicklung des Steuergerätes einschlie- ßenden Definitionsumfang hat.
4. Verfahren nach einem der Ansprüche 2 oder 3, bei dem die Vorgabedateien (16) von kundenspezifischen Namenskonventionen für Daten, Variablen und Funktionen befreit werden, indem mittels automatischer Software-Werkzeuge aus einem strukturierten Datensatz universelle Namensersetzungen eingelesen und mit ihnen die ursprünglichen Namen überschrieben werden.
5. Verfahren nach einem der Ansprüche 2 bis 4, bei dem die Transformation der Vorgabedateien (16) von kundenspezifischer in eine universelle, und am Ende des Verfahrens eine hierzu inverse Transformation aus der universellen in eine gewählte kundenspezifische Namenskonventionen für Daten, Variablen und Funktionen durch gleiche automatisch wirkende Softwarewerkzeuge erfolgt, wobei diese eine Vorgabe enthalten, aus welchem Datensatz diese die ersetzenden Namen auslesen sollen.
6. Verfahren nach Anspruch 1, bei dem die Dateien mit Diagnosedaten zunächst von kundenspezifischen Eigenschaften unabhängig konvertiert und im XML-Format in der Entwicklung der Steuergeräte-Software und der Auswertung der aktualisierten Diagnose-Steuergerätedaten verarbeitet werden, und danach in einem separaten Regelwerk anhand von kundenspezifisch konvertierenden Regeln die kundenspezifischen Dateien, der Programmkode, die Diagnosedaten und die Dokumentation (28) erstellt werden.
7. Verfahren nach einem der vorstehenden Ansprüche, bei dem spezifische Regeln für ein separates Regelwerk in einer geeigneten Programmiersprache universell und kundenunspezifisch abgefasst sind, durch eine Variable auf einen gewählten kun- denspezifischen Datensatz einstellbar sind, danach auf den hierdurch gewählten kundenspezifischen Datensatz zugreifen und kundenspezifische Namenskonventionen aus diesem gelesen werden, und mit diesen Konventionen universelle Namensplatzhalter in den vorher kundenunabhängig verarbeiteten Dateien überschrieben werden.
8. Verfahren nach einem der vorstehenden Ansprüche, bei dem im zweiten Verfahrensschritt die Dateien (20) mit hardwarespezifischen Eigenschaften eines Steuergerätes und seiner Steuersoftware manuell implementiert werden, und hierzu Daten, Variablen und Programmkode bearbeitet und hinzugefügt werden.
9. Verfahren nach einem der vorstehenden Ansprüche, bei dem im zweiten Verfahrensschritt die Dateien (20) mit hardwarespezifischen Eigenschaften eines Steuer- gerätes mittels halb- oder vollautomatischer Software-Werkzeuge implementiert werden, und hierzu Daten, Variablen und Programmkode bearbeitet und hinzugefügt werden.
10. Verfahren nach einem der vorstehenden Ansprüche, bei dem im dritten Verfahrensschritt aus den an die Hardware angepassten Vorgabedateien (16) automatisch mittels geeigneter Softwarewerkzeuge Daten-, Variablen- und Funktionskonfigurations- anweisungen ausgelesen, und eine automatische Konfiguration der Diagnose- Software (23) für den Entwicklungsprozess ausgeführt wird.
11. Verfahren nach einem der vorstehenden Ansprüche, bei dem im vierten Verfahrensschritt aus den an die Hardware angepassten Vorgabedateien (16) automatisch mittels geeigneter Softwarewerkzeuge Daten, Variablen und Funktionskonfigurations- anweisungen herausgelesen, und automatisch mittels weiterer geeigneten Soft- warewerkzeuge Steuergerätekode erzeugt wird, indem die eingelesenen Konfigurationsvorgaben für Programme und Module berücksichtigt wird, indem Quellkode mit aktualisierten Daten berichtigt und anschließend in einem Kompilierungsprozess ausführbarer Steuergerätekode erzeugt wird.
12. Verfahren nach einem der vorstehenden Ansprüche, bei dem im vierten Verfahrensschritt mindestens ein Steuergerätedatensatz (25) aus dem Entwicklungsprozess zusätzlich ausgewertet wird, und mittels einer Anzahl geeigneter Softwarewerkzeuge, nach festgelegten Regeln unter Berücksichtigung von kundenspezifischen Konventionen für die Namen der Variablen, der Datensätze und Funktionen eine auto- matisch aktualisierte Dokumentation (28) in einem Text, Daten und Programmkode enthaltenden Format, vorzugsweise im XML-Standand in ODX-Ausprägung, erzeugt wird.
13. Verfahren nach einem der vorstehenden Ansprüche, bei dem die Steuergeräte- Software und die dazugehörenden Diagnosedaten gleichzeitig betrachtet und verarbeitet werden, und hierzu in gleichen Dateien unsepariert vorliegen.
14. Verfahren nach einem der vorstehenden Ansprüche, bei dem die Diagnosedaten in einer Datenbank (22) abgelegt und wieder aus dieser ausgelesen werden.
15. Vorrichtung zum Betreiben des Verfahrens nach einem der vorstehenden Ansprüche, bei dem strukturierte Datensätze für je einen auftraggebenden Kunden mit sei- nen spezifischen Namenskonventionen, sowie mindestens ein Datensatz mit universellen Namenskonventionen, und ein Datensatz mit ODX-Namenskonventionen für Daten, Variablen und Funktionen erstellt und geeignet für einen automatischen Zugriff durch Software-Werkzeuge zur Verfügung gestellt sind.
PCT/EP2006/068846 2005-12-14 2006-11-23 Verfahren zur verarbeitung und erzeugung von diagnosedaten in einem softwareentwicklungsprozess WO2007068563A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102005060161.8 2005-12-14
DE102005060161A DE102005060161A1 (de) 2005-12-14 2005-12-14 Verfahren zur Verarbeitung und Erzeugung von Diagnosedaten in einem Softwareentwicklungsprozess

Publications (1)

Publication Number Publication Date
WO2007068563A1 true WO2007068563A1 (de) 2007-06-21

Family

ID=37965109

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2006/068846 WO2007068563A1 (de) 2005-12-14 2006-11-23 Verfahren zur verarbeitung und erzeugung von diagnosedaten in einem softwareentwicklungsprozess

Country Status (2)

Country Link
DE (1) DE102005060161A1 (de)
WO (1) WO2007068563A1 (de)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104965507A (zh) * 2015-06-29 2015-10-07 广州汽车集团股份有限公司 生成开放式诊断数据交换数据库的方法及装置
CN111090476A (zh) * 2019-12-06 2020-05-01 深圳市元征科技股份有限公司 一种数据配置方法、设备诊断方法及相关产品
CN111103861A (zh) * 2018-10-25 2020-05-05 上汽通用汽车有限公司 开发基于车辆售后诊断需求的集成系统的方法和装置
US11797430B2 (en) 2021-12-03 2023-10-24 T-Mobile Usa, Inc. Configuration-driven data conversion and hosting for software development systems and methods

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102010056232B4 (de) 2010-12-24 2022-10-20 Volkswagen Ag Verfahren zum Speichern von Diagnosedaten für ein Steuergerät eines Fahrzeugs sowie entsprechende Vorrichtung

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102004005730A1 (de) * 2004-02-05 2005-08-25 Robert Bosch Gmbh Verfahren zur Konfiguration eines Computerprogramms

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102004005730A1 (de) * 2004-02-05 2005-08-25 Robert Bosch Gmbh Verfahren zur Konfiguration eines Computerprogramms

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
K.SCHNEIDER ET AL.: "ODX in der Motorsteuerung - Status bei Bosch Diesel Systems", 17 November 2005 (2005-11-17), XP002432240, Retrieved from the Internet <URL:http://www.asam.net/additional/2005-11-17_Bosch_Diagnostics_Academy_RB_DS.pdf> [retrieved on 20070504] *
ROBERT BOSCH GMBH: "Herzlich willkommen zur Bosch Diagnostics Academy", XP002432241, Retrieved from the Internet <URL:http://www.asam.net/additional/2005-11-17_Einladung_Bosch_Diagnostics_Academy.pdf> [retrieved on 20070504] *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104965507A (zh) * 2015-06-29 2015-10-07 广州汽车集团股份有限公司 生成开放式诊断数据交换数据库的方法及装置
CN111103861A (zh) * 2018-10-25 2020-05-05 上汽通用汽车有限公司 开发基于车辆售后诊断需求的集成系统的方法和装置
CN111103861B (zh) * 2018-10-25 2023-04-07 上汽通用汽车有限公司 开发基于车辆售后诊断需求的集成系统的方法和装置
CN111090476A (zh) * 2019-12-06 2020-05-01 深圳市元征科技股份有限公司 一种数据配置方法、设备诊断方法及相关产品
US11797430B2 (en) 2021-12-03 2023-10-24 T-Mobile Usa, Inc. Configuration-driven data conversion and hosting for software development systems and methods

Also Published As

Publication number Publication date
DE102005060161A1 (de) 2007-06-21

Similar Documents

Publication Publication Date Title
DE102005026040B4 (de) Parametrierung eines Simulations-Arbeitsmodells
EP1723513B1 (de) Verfahren zur konfiguration eines computerprogramms
DE10351351A1 (de) Verfahren und System zur dynamischen Generierung von User Interfaces
WO2015185328A1 (de) Computerimplementiertes verfahren und signalfolge für ein programm zur wiederverwendung von ausführbaren softwarekonfigurationen für softwaresysteme sowie rechneranlage und ein computerprogramm mit programmcode zur durchführung des verfahrens
DE102007029285A1 (de) Testvorrichtung zum Testen wenigstens eines elektronischen Steuerungssystems sowie Verfahren zum Betreiben einer Testvorrichtung
EP3451202B1 (de) Verfahren zum erzeugen eines auf einem testgerät ausführbaren modells eines technischen systems und testgerät
WO2007068563A1 (de) Verfahren zur verarbeitung und erzeugung von diagnosedaten in einem softwareentwicklungsprozess
EP3217236A1 (de) Verfahren und system zur generierung eines bedienprogramms in form einer auf einem mobilen gerät lauffähigen mobilen applikation
DE102005042129A1 (de) Verfahren und Vorrichtung zum automatisierten Bewerten der Qualität eines Software-Quellcodes
DE10015114A1 (de) Verfahren und Vorrichtung zur Modellierung eines mechatronischen Systems in einem Kraftfahrzeug
EP2407842A2 (de) Verfahren zur Inbetriebnahme von Maschinen oder Maschinen einer Maschinenserie und Projektierungssystem
DE10041072A1 (de) Verfahren zur automatischen Erzeugung von Programmcode
WO2005045538A1 (de) Verfahren und vorrichtung zur stimulation von funktionen zur steuerung von betriebsabläufen
DE4104568A1 (de) Verfahren und vorrichtung zur programmverarbeitung
DE3318410A1 (de) Verfahren zur veraenderung und optimierung von daten und programmablaeufen fuer programmierte steuergeraete in kraftfahrzeugen
EP1944664B1 (de) Verfahren zur Fehlersuche in einem Automatisierungsgerät
EP1383061A2 (de) Verfahren und Konfigurator zur Erstellung eines Anlagenkonzepts aus einer Anzahl von Anlagenkomponenten
DE102009032333A1 (de) Verfahren zur Prüfung von Modellen
DE10228610A1 (de) Verfahren zum Überprüfen eines auf einer elektronischen Recheneinheit ablaufenden Steuerprogramms
EP1387260A1 (de) Verfahren und Vorrichtung zur Erzeugung von Software
DE10233971A1 (de) Verfahren und Vorrichtung zur Erzeugung von Software
DE102010044039A1 (de) Verfahren und Vorrichtung zur Qualitätsanalyse von Systemmodellen
EP1960854A1 (de) Diagnoseverfahren und diagnosevorrichtung zur funktionsorientierten diagnose eines systems mit vernetzten komponenten
DE102007038190B4 (de) Verfahren zur Parametrierung eines Diagnosegerätes, korrespondierendes Computerprogramm und Computerprogrammprodukt sowie Diagnosesystem
DE102017212612A1 (de) Verfahren zum automatischen Erzeugen von Tests für die Software eines Fahrzeugs

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase

Ref document number: 06807836

Country of ref document: EP

Kind code of ref document: A1