EP4377663A1 - Verfahren zur durchführung einer funktionsdiagnose zumindest einer fahrzeugkomponente und diagnosesystem - Google Patents

Verfahren zur durchführung einer funktionsdiagnose zumindest einer fahrzeugkomponente und diagnosesystem

Info

Publication number
EP4377663A1
EP4377663A1 EP23714670.9A EP23714670A EP4377663A1 EP 4377663 A1 EP4377663 A1 EP 4377663A1 EP 23714670 A EP23714670 A EP 23714670A EP 4377663 A1 EP4377663 A1 EP 4377663A1
Authority
EP
European Patent Office
Prior art keywords
vehicle
computing unit
external
diagnostic
internal
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
EP23714670.9A
Other languages
English (en)
French (fr)
Inventor
Simone König
Oliver Kopp
Michael Hahn
Rose Sturm
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mercedes Benz Group AG
Original Assignee
Mercedes Benz Group AG
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 Mercedes Benz Group AG filed Critical Mercedes Benz Group AG
Publication of EP4377663A1 publication Critical patent/EP4377663A1/de
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01M—TESTING STATIC OR DYNAMIC BALANCE OF MACHINES OR STRUCTURES; TESTING OF STRUCTURES OR APPARATUS, NOT OTHERWISE PROVIDED FOR
    • G01M17/00—Testing of vehicles
    • G01M17/007—Wheeled or endless-tracked vehicles
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60L—PROPULSION OF ELECTRICALLY-PROPELLED VEHICLES; SUPPLYING ELECTRIC POWER FOR AUXILIARY EQUIPMENT OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRODYNAMIC BRAKE SYSTEMS FOR VEHICLES IN GENERAL; MAGNETIC SUSPENSION OR LEVITATION FOR VEHICLES; MONITORING OPERATING VARIABLES OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRIC SAFETY DEVICES FOR ELECTRICALLY-PROPELLED VEHICLES
    • B60L3/00—Electric devices on electrically-propelled vehicles for safety purposes; Monitoring operating variables, e.g. speed, deceleration or energy consumption
    • B60L3/12—Recording operating variables ; Monitoring of operating variables
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B15/00—Systems controlled by a computer
    • G05B15/02—Systems controlled by a computer electric
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0808—Diagnosing performance data
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60L—PROPULSION OF ELECTRICALLY-PROPELLED VEHICLES; SUPPLYING ELECTRIC POWER FOR AUXILIARY EQUIPMENT OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRODYNAMIC BRAKE SYSTEMS FOR VEHICLES IN GENERAL; MAGNETIC SUSPENSION OR LEVITATION FOR VEHICLES; MONITORING OPERATING VARIABLES OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRIC SAFETY DEVICES FOR ELECTRICALLY-PROPELLED VEHICLES
    • B60L2270/00—Problem solutions or means not otherwise provided for
    • B60L2270/40—Problem solutions or means not otherwise provided for related to technical updates when adding new parts or software
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C2205/00—Indexing scheme relating to group G07C5/00
    • G07C2205/02—Indexing scheme relating to group G07C5/00 using a vehicle scan tool

Definitions

  • the invention relates to a method for carrying out a functional diagnosis of at least one vehicle component of a vehicle in production and a diagnostic system for carrying out the method according to the type defined in more detail in the preamble of claim 7.
  • a vehicle Before a vehicle is delivered, it is checked whether the correct software, in particular the current version, is installed on the respective computing units or control devices installed in the vehicle.
  • the sensors installed in the vehicle are calibrated.
  • the inspection of the vehicle can stipulate that individual functional check steps are carried out manually, partially assisted or fully automatically by a computer system.
  • a corresponding computer system is typically connected by cable to a computing unit in the vehicle using a so-called onboard diagnostic connector.
  • the vehicle-external computer system then controls the corresponding vehicle components to be checked or calibrated.
  • DE 102009 033 806 A1 discloses a method for manufacturing and testing functionality in production.
  • the method describes central management of the performance of the functional test of a vehicle or vehicle components in production by a central computing unit. It is therefore necessary to carry out different functional tests at different production and/or testing stations for different model variants.
  • the relevant process steps and corresponding program code are stored on the central computing unit for the different model variants and production and/or testing stations.
  • the test data generated during the test is also collected and evaluated centrally, which enables potential errors to be quickly and directly assigned to a corresponding source of error. This also makes it easier to initiate countermeasures to correct a corresponding error.
  • the maintenance of motor vehicle control units via mobile radio is known from DE 102013 014 878 B3.
  • the method provides for the establishment of a mobile radio-based communication connection between a vehicle-external computing device and a vehicle-internal control device, with device data being exchanged between the computing device and the control device via the communication connection.
  • the device data is configuration data for the control device, error messages from the control device and/or status messages from the control device.
  • the vehicle-external computing device acts as a central administrative body for carrying out vehicle diagnostics. In this way, the computing device can transmit a command to a respective control device, which causes a self-test to be carried out according to a predefined routine implemented in the respective control unit.
  • DE 102012 110 623 A1 discloses a measuring device for carrying out measuring and testing tasks in predeterminable processes.
  • the measuring device is set up to read a file that contains a process description.
  • the measuring device converts the process description into a program flow routine and executes it.
  • the file may have been created with a Business Process Model and Notation editor.
  • a method and a manufacturing system for manufacturing a motor vehicle is known from DE 102018 203 067 A1.
  • the method provides for the detection of a voice input by a vehicle-internal control device and the assignment of a corresponding meaning.
  • a data record corresponding to the meaning is then transmitted to the test device for evaluation via an interface between the control device and the vehicle-external test device.
  • the present invention is based on the object of specifying an improved method for carrying out a functional diagnosis of at least one vehicle component of a vehicle in production, which ensures efficient and reliable implementation of the functional diagnosis.
  • this object is achieved by a method for carrying out a functional diagnosis with the features of claim 1 and a corresponding diagnostic system used for this purpose with the features of claim 7.
  • Advantageous refinements and further developments result from the requirements that depend on this.
  • a method according to the invention for carrying out a functional diagnosis of at least one vehicle component of a vehicle in production differs from a generic method in that it has the following method steps:
  • - Generating a diagnostic execution protocol by means of a first vehicle-external computing unit, the diagnostic execution protocol comprising machine-readable instructions for carrying out an at least partially automated functional diagnosis of vehicle components by a vehicle-internal computing unit; - Transferring the diagnostic execution protocol to the vehicle-internal computing unit of the vehicle being manufactured;
  • the method according to the invention provides for the computing unit executing the functional diagnosis to be relocated to the vehicle itself.
  • the vehicle carries out the functional diagnosis independently, which enables the functional diagnosis to be carried out particularly efficiently.
  • fewer computing-intensive resources are required to carry out the functional diagnosis, since a single central computing system no longer has to control a large number of control devices at the same time to carry out the functional diagnosis of a large number of vehicles.
  • the first computing unit external to the vehicle can be understood as a developer system.
  • the machine-readable instructions are program code that can be executed by the vehicle's internal computing unit. This enables the vehicle-internal computing unit to control the vehicle components to be checked in accordance with the diagnostic steps to be carried out. Corresponding diagnostic steps can be carried out and logged completely automatically by the vehicle's internal computing unit or manually assisted by the person supervising the production of the vehicle. For example, it may be necessary that the person has to manipulate the vehicle manually so that the functional test can be carried out completely and/or the person has to record and record the reaction caused by controlling the vehicle component. The person can then see a corresponding test result Enter the vehicle itself or via the first or second computing unit external to the vehicle.
  • the second vehicle-external computing unit can be a computing system used in production. For example, it can be a central production computer or an isolated system, for example a computer system provided at a production and/or testing station.
  • the diagnostic execution protocol can include corresponding instructions for responding to errors, such as re-performing individual calibration or testing steps and/or post-processing steps, which are then implemented accordingly by the vehicle-internal computing unit.
  • the corresponding instructions can be part of a common diagnostic procedure or, in addition, can be designed as a “standard answer” to respond to typical errors.
  • Individual diagnostic execution protocols can also be generated for these standard answers and transferred to the vehicle's internal computing unit for storage, which are then executed as required.
  • the instructions included in the diagnostic execution protocol can be executed sequentially and/or in parallel by the vehicle-internal computing unit.
  • the diagnosis to be carried out is divided into a “preparation”, a “main part” and a “post-processing”.
  • preparation can be: setting up a communication connection between computing units inside and/or outside the vehicle, carrying out authentication and/or authorization, setting up a so-called “session” and the like.
  • the main part can be: controlling actuators, reading sensor data, reading out an error memory of a control unit, adjusting calibration parameters and the like.
  • post-processing can be: ending a communication connection, writing result data, publishing the result data to a system external to the vehicle, resetting control unit states and the like.
  • the diagnostic execution protocol is generated on the first computing unit external to the vehicle using a graphic specification language
  • the diagnostic execution protocol being a flowchart from the vehicle-internal Computing unit includes diagnostic steps to be carried out, wherein the vehicle-external computing unit reads machine-readable instructions corresponding to the diagnostic steps from a vehicle-external database and integrates them into the diagnostic execution protocol.
  • the process for generating applicable program code on the vehicle-internal computing unit is designed efficiently, from the pure idea, through the exact procedure of how a process step is to be carried out, to the generation of program code, up to the final implementation and application by the vehicle-internal computing unit. In particular, this allows media disruptions to be avoided, which significantly reduces the risk of errors.
  • the process steps to be carried out in the functional diagnosis are graphically formulated in a user-friendly and easy-to-understand manner using the graphical specification language and are converted directly into machine-readable instructions by automatically reading the instructions suitable for the respective diagnostic steps from the vehicle-external database by the first vehicle-external computing unit.
  • the vehicle-external database can be understood as a so-called code repository. Machine-readable instructions required for all possible machine-executable steps are implemented in the code repository. This means that manual programming effort is no longer required to integrate the machine-readable instructions required to carry out a specific functional diagnosis into the vehicle's internal computing unit.
  • a programmer can write new machine-readable instructions into the vehicle-external database, i.e. the code repository, which also allows functional diagnostics to be carried out reliably using the new components. If bugs occur, existing machine-readable instructions in the vehicle-external database can be updated and revised.
  • the diagnostic execution protocol thus describes a generic term for both the purely mental sequence of the test steps to be carried out in a functional diagnosis and the program code used for this purpose to control vehicle components by the vehicle-internal computing unit.
  • the use of a graphical specification language leads in particular to a reduction in manual errors by the person supervising production.
  • the person can view the test steps to be carried out graphically displayed on any display device, for example on a tablet used in production and/or augmented reality glasses, and thereby understand the work steps involved in an easy-to-understand manner.
  • the diagnostic execution protocol can therefore be interpreted in an easily understandable manner by both the person and a machine.
  • BPMN Business Process Model and Notation
  • a further advantageous embodiment of the method further provides that the vehicle-internal computing unit is connected by wire and/or wirelessly to a common communication network with a vehicle-external computing unit and the vehicle-internal computing unit exchanges information with the vehicle-external computing unit indirectly via a communication server.
  • the vehicle-external computing unit can be the first or the second vehicle-external computing unit.
  • the vehicle-internal computing unit can be connected to the corresponding vehicle-external computing unit by cable via an Ethernet cable or an onboard diagnostic cable.
  • WLAN and/or mobile communications are preferably used for wireless communication, in particular using 5G or future mobile communications standards. In particular, the use of WLAN and/or mobile communications with at least the 5G mobile communications standard allows data transmission at comparatively high data transmission rates.
  • the vehicle-external computing unit can be a tablet or desktop computer used by the person supervising production, which is connected by wire or wirelessly to the vehicle-internal computing unit in a communicative manner.
  • the person's tablet can set up an ad hoc WLAN into which the vehicle's internal computing unit connects.
  • the person can, for example, generate a new diagnostic execution protocol on the tablet using the graphical specification language and transmit this directly to the vehicle's internal computing unit for use.
  • This enables a particularly quick reaction and adjustment of the process steps to be carried out to carry out the functional diagnosis.
  • Such a procedure can also be used in the development of the machine-readable instructions to be stored in the vehicle-external database from the corresponding process steps integrated in the flowchart.
  • a vehicle-external database can be integrated into the tablet integrated at the production and/or testing station. After the person has generated a corresponding flowchart, the tablet can integrate corresponding machine-readable instructions into the diagnostic execution protocol. There is a risk that outdated machine-readable instructions will be read from the tablet-internal, vehicle-external database.
  • corresponding distributed vehicle-external databases can be updated with updated program code.
  • a further advantageous embodiment of the method according to the invention further provides that the vehicle-internal computing unit controls a vehicle-external manipulation machine in order to carry out at least one diagnostic step and/or initiate measures if the at least one vehicle component is malfunctioning in its correct functioning.
  • Corresponding machine-readable instructions for controlling the vehicle-external manipulation machine are then also integrated into the diagnostic execution protocol or into further diagnostic execution protocols.
  • the integration is preferably carried out automatically depending on the process steps of the flowchart defined in the graphical specification language.
  • the vehicle-external manipulation machine can be a robot provided at the production and/or testing station.
  • Manipulation of the vehicle or a vehicle component can be done in a variety of ways, for example the vehicle-external manipulation machine can move the vehicle or a vehicle component, check it with the help of sensors external to the vehicle, add new components or replace, detach, or the like already integrated components. This makes it possible to rework the vehicle or vehicle components after carrying out the actual functional diagnosis.
  • the method according to the invention therefore enables the vehicle-internal computing unit to be able to control vehicle-external machines used in production or testing. A central computing unit is then no longer required to control the vehicle-external manipulation machines. This also ensures increased efficiency when carrying out functional diagnostics.
  • the vehicle-internal computing unit can directly control the vehicle-external manipulation machine, for example via direct communication via WLAN or indirectly via a vehicle-external computing unit such as a central factory server.
  • a diagnostic system with a first vehicle-external computing unit and with a vehicle in production comprising a vehicle-internal computing unit
  • the first vehicle-external computing unit and the vehicle are set up to carry out a method described above.
  • the vehicle-internal computing unit is able to control and monitor all relevant vehicle components electrically or electronically. This allows time-critical diagnostic process steps to be carried out with particularly low resources and comparatively low latencies. This ensures an efficient functional diagnostic process.
  • An advantageous development of the diagnostic system provides at least a second vehicle-external computing unit, the second vehicle-external computing unit being set up to receive information from the vehicle-internal computing unit to be received and/or controlled.
  • the vehicle-internal computing unit can, for example, transmit results of the functional diagnostic test to the second vehicle-external computing unit, which are stored there for evaluation. Depending on the evaluated results, measures to correct errors can also be initiated by the second vehicle-external computing unit.
  • the vehicle-internal computing unit can also control the second vehicle-external computing unit.
  • the second vehicle-external computing unit is the control device of a vehicle-external manipulation machine.
  • the diagnostic system preferably comprises a communication server, wherein the communication server is set up to exchange information between the vehicle-internal computing unit and the first vehicle-external computing unit.
  • This enables central management of the vehicle-external database. This means that the engineers involved in functional diagnostic planning do not have to be physically present in the factory to develop or implement new functional diagnostic processes.
  • the corresponding newly generated diagnostic execution protocols can be transmitted via the communication server to the respective production and/or testing stations in production and imported there to the respective in-vehicle computing units. In general, it is also possible that said diagnostic execution protocols are already pre-installed on the vehicle-internal computing unit before the corresponding vehicle-internal computing units are installed in the vehicle.
  • Corresponding diagnostic results can be temporarily stored on the vehicle-internal computing unit and transmitted to the first and/or second vehicle-external computing unit as soon as there is a communication connection to the first and/or second vehicle-external computing unit.
  • FIG. 2 shows a schematic representation of the infrastructure of a vehicle manufacturer used for the production and development of vehicles according to a first embodiment
  • FIG. 3 shows a schematic representation of the infrastructure of a vehicle manufacturer used for the production and development of vehicles according to a second embodiment
  • Fig. 4 is a schematic representation of a production line
  • Fig. 5 is a schematic representation of distributed production.
  • the core idea of the method according to the invention for carrying out a vehicle diagnosis of at least one vehicle component of a vehicle 1 that is in production is the independent implementation of the functional diagnosis by a vehicle-internal computing unit RI.
  • the complete sequence of development of the process steps to be carried out in the functional diagnosis up to the generation of program code, implementation of the program code in the vehicle-internal computing unit RI and execution of this is designed by using a graphic specification language, preferably Business Process Model and Notation (BPMN).
  • BPMN Business Process Model and Notation
  • An engineer 5 creates a flowchart of the diagnostic steps to be carried out by the vehicle-internal computing unit RI on a first vehicle-external computing unit RE_1 using the graphic specification language.
  • a diagnostic execution log 2 is created from this.
  • the diagnostic execution protocol 2 can be formulated in the graphical specification language and then converted into a metalanguage such as XML.
  • the first vehicle-external computing unit RE_1 reads machine-readable instructions corresponding to the diagnostic steps from a vehicle-external database 3, also referred to as a code repository, and integrates these into the diagnostic execution protocol 2. This is done in method step 101.
  • the vehicle-external database 3 can be stored on the first vehicle-external computing unit RE_1 are held and/or on a data storage in a network, for example on a central server.
  • the diagnostic protocol 2 is transmitted via a communication server RKOM, for example a proxy server, to a factory 6 of the vehicle manufacturer in which production is located. In the factory 6, the diagnostic execution protocol 2 is distributed to the corresponding in-vehicle computing unit RI of the vehicle 1 to be checked.
  • the diagnostic execution protocol 2 or the machine-readable instructions contained therein are executed by the vehicle-internal computing unit RI, whereby the vehicle-internal computing unit RI at least controls a vehicle component to be checked and the corresponding response behavior is recorded automatically or manually assisted by a person supervising the production of the vehicle 1. If the functional diagnosis is successful, as indicated by a checkmark in FIG. 1, the vehicle 1 can be released for the next production step or for handover to the dealer. However, if the functional diagnosis is faulty, as indicated by a flash in Figure 1, further measures must be taken. The further measures can also be described by instructions integrated into the diagnostic execution protocol 2 and can be executed or initiated by the vehicle-internal computing unit RI.
  • Figures 2 and 3 serve once again to illustrate the vehicle manufacturer's infrastructure used for the production and development of vehicles.
  • FIG 2 several first vehicle-external computing units RE_1 are shown.
  • Each of the first vehicle-external computing units RE_1 includes its own vehicle-external database 3.
  • the first vehicle-external computing units RE_1 can be, for example, the development PC of an engineer 5.
  • a diagnostic execution protocol 2 can be generated via such a PC and transmitted to a respective factory 6 via the communication server RKOM.
  • a communication relay 7, for example a WLAN router or a 5G modem can be provided, via which the communication server RKOM is connected to a common communication network with the vehicle-internal computing unit RI.
  • a corresponding transmission of the diagnostic execution protocol 2 to the vehicle-internal computing unit RI is shown in Figure 2 by a dotted line.
  • the vehicle-internal computing unit RI can also control a vehicle-external manipulation machine 4, for example a manipulation robot. So can the manipulation robot moves parts of the vehicle or manipulates them in some other way.
  • vehicle-external manipulation machine 4 can also include one or more sensors for checking the condition of the vehicle 1 or vehicle components. Such a sensor can be, for example, a camera, a conductivity sensor, a temperature sensor, a force sensor, an ultrasonic sensor or the like.
  • a control device of the vehicle-external manipulation machine 4 can be referred to as a second vehicle-external computing unit RE_2.
  • vehicle-external computing units RE_2 can also be provided, such as a central factory server RE_2_Zentral.
  • Results of a respective functional diagnosis generated by the vehicle-internal computing units RI of vehicles 1 to be manufactured and/or checked can be stored and evaluated on the central factory server RE_2_Zentral.
  • the vehicle-internal computing unit RI or the central factory server RE_2_Zentral can control corresponding vehicle-external manipulation machines 4 in order to automatically initiate countermeasures to correct the error in the event of an error. People can also be notified who can initiate manual troubleshooting.
  • a first vehicle-external computing unit RE_1 can also communicate directly with the vehicle-internal computing unit RI.
  • a tablet computer RE_2_Tab is shown as an example, which can be used by a person supervising the production of the vehicle 1 to interact with the vehicle-internal computing unit RI. This allows particularly short communication paths between the first vehicle-external computing unit RE_1 and the vehicle-internal computing unit RI.
  • Figure 3 shows a representation similar to Figure 2.
  • a central vehicle-external database 3.1 and, if necessary, a central server RE_1_Zentral, indicated by a dashed line, are integrated into the computer network of the first vehicle-external computing units RE_1.
  • Developers can maintain machine-readable instructions, i.e. code modules, stored in the central vehicle-external database 3.1.
  • the corresponding first vehicle-external computing units RE_1 for example developer PCs, can then update their respective vehicle-external database 3 by reading out the central vehicle-external database 3.1.
  • Some of the developer PCs do not have an integrated one vehicle-external database 3 and are dependent on a direct connection to the central vehicle-external database 3.1.
  • the entire process can also be managed by the central server RE_1_Zentral.
  • the results of the functional diagnoses transmitted by the vehicle-internal computing units RI of the individual vehicles 1 can be stored and evaluated. This enables central analysis of data from production. In this way, the advantages of decentralized control of the performance of the functional diagnosis and the central evaluation of the corresponding results can be combined.
  • FIG. 4 shows the manufacturing and/or testing stations 9 arranged in series on a production line 8. Individual manufacturing steps of a vehicle 1 or a vehicle component can be carried out at a manufacturing and/or testing station 9 and/or a vehicle 1 or vehicle components be subjected to a functional diagnosis.
  • Each manufacturing and/or testing station 9 can have its own second, vehicle-external computing unit RE_2, for example a central computer, which controls the machines used at the respective manufacturing and/or testing station 9.
  • Each such machine for example a vehicle-external manipulation machine 4
  • Corresponding control commands can also be issued by the central factory server RE_2_Zentral and, in particular, transmitted via WLAN, 5G or a future mobile radio standard in the factory 6 to the individual second, vehicle-external computing units RE_2.
  • Data generated by the vehicle-internal computing unit RI depending on the functional diagnosis carried out can then be transmitted back to the central factory server RE_2_Zentral for evaluation.
  • Figure 5 shows an alternative or supplementary version of the factory 6.
  • Individual or all production and/or testing stations 9 can be arranged in a distributed manner. This enables particularly flexible and efficient production and/or testing of vehicles 1 in accordance with the ideas of Industry 4.0.
  • a vehicle 1 to be manufactured is not dependent on passing through the individual manufacturing and/or testing stations 9 sequentially, but can remain assigned to a single manufacturing and/or testing station 9 for several production or testing steps and/or flexibly between change this, whereby free capacities are optimally used in terms of efficiency.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Sustainable Development (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Sustainable Energy (AREA)
  • Power Engineering (AREA)
  • Transportation (AREA)
  • Mechanical Engineering (AREA)
  • Automation & Control Theory (AREA)
  • General Engineering & Computer Science (AREA)
  • Testing And Monitoring For Control Systems (AREA)
  • Automobile Manufacture Line, Endless Track Vehicle, Trailer (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zur Durchführung einer Funktionsdiagnose zumindest einer Fahrzeugkomponente eines sich in der Fertigung befindenden Fahrzeugs (1). Das erfindungsgemäße Verfahren ist gekennzeichnet durch die folgenden Verfahrensschritte: - Erzeugen eines Diagnoseausführungsprotokolls (2) mittels einer ersten fahrzeugexternen Recheneinheit (RE_1), wobei das Diagnoseausführungsprotokoll (2) maschinenlesbare Anweisungen zur Durchführung einer zumindest teilautomatisierten Funktionsdiagnose von Fahrzeugkomponenten durch eine fahrzeuginterne Recheneinheit (RI) umfasst; - Übertragen des Diagnoseausführungsprotokolls (2) auf die fahrzeuginterne Recheneinheit (RI) des sich in der Fertigung befindenden Fahrzeugs (1); - Ausführung des Diagnoseausführungsprotokolls (2) durch die fahrzeuginterne Recheneinheit (RI), wobei die fahrzeuginterne Recheneinheit (RI) wenigstens eine Fahrzeugkomponente zur Überprüfung einer korrekten Funktionsweise der wenigstens einen Fahrzeugkomponente ansteuert, und wobei das Antwortverhalten der wenigstens einen Fahrzeugkomponente automatisiert durch die fahrzeuginterne Recheneinheit (RI) oder manuell assistiert durch eine die Fertigung des Fahrzeugs (1) betreuende Person erfasst wird; und - Ausgabe des erfassten Antwortverhaltens an die erste fahrzeugexterne Recheneinheit (RE_1) und/oder eine zweite fahrzeugexterne Recheneinheit (RE_2).

Description

Verfahren zur Durchführung einer Funktionsdiagnose zumindest einer Fahrzeugkomponente und Diagnosesystem
Die Erfindung betrifft ein Verfahren zur Durchführung einer Funktionsdiagnose zumindest einer Fahrzeugkomponente eines sich in der Fertigung befindenden Fahrzeugs sowie ein Diagnosesystem zur Durchführung des Verfahrens nach der im Oberbegriff von Anspruch 7 näher definierten Art.
Komplexe Maschinen wie Fahrzeuge bedürfen einer Vielzahl einzelner Arbeitsschritte zur Fertigstellung in der Montage. Dabei können einzelne Montageschritte fehlerhaft durchgeführt worden sein und/oder fehlerhafte Komponenten verbaut worden sein. Dies erfordert es relevante Fahrzeugfunktionen vor einer Auslieferung des Fahrzeugs auf eine korrekte Funktionsweise zu kontrollieren. Treten Fehler auf, so können Maßnahmen eingeleitet werden, um die Fehler zu beheben, bevor das Fahrzeug ausgeliefert wird
Beispielsweise wird bei einem Fahrzeug vor dessen Auslieferung geprüft, ob auf den jeweiligen im Fahrzeug verbauten Recheneinheiten bzw. Steuergeräten die richtige Software, insbesondere in der aktuellen Version, installiert ist. Zudem werden die im Fahrzeug verbauten Sensoren kalibriert. Die Kontrolle des Fahrzeugs kann vorsehen, dass einzelne Funktionsüberprüfungsschritte manuell, teilassistiert oder vollautomatisch durch ein Rechnersystem durchgeführt werden. Hierzu wird typischerweise ein entsprechendes Rechnersystem kabelgebunden mittels eines sogenannten Onboard- Diagnose-Steckers an eine Recheneinheit des Fahrzeugs angeschlossen. Das fahrzeugexterne Rechnersystem steuert dann die entsprechenden zu überprüfenden bzw. zu kalibrierenden Fahrzeugkomponenten an.
Die Planung, Vorbereitung und Durchführung einer solchen Funktionsüberprüfung ist mit erheblichem Aufwand verbunden. Zuerst gilt es die in der Fahrzeugdiagnose durchzuführenden Prozessschritte zu spezifizieren und zu dokumentieren. Anschließend müssen die entsprechenden Prozessschritte in Programmcode überführt werden, welcher dann auf das Rechnersystem eingespielt werden muss. Anschließend muss der Programmcode ausgeführt werden. Während dieses Vorgangs der Übertragung der Planungsschritte in einen zur Steuerung der Fahrzeugkomponenten verwendeten Programmcode treten sogenannte Medienbrüche auf, wodurch Fehler entstehen können. Beispielsweise kann ein Prozessschritt von einem Programmierer falsch verstanden werden, woraufhin eine falsche Anweisung in den Programmcode integriert wird. Zudem unterscheiden sich die Rechensysteme des Fahrzeugs mit den Entwicklungssystemen, was verstärkt zu Bugs führen kann. So kann ein Diagnoseprogramm in einer Testumgebung einwandfrei funktionieren, jedoch bei einer Ausführung im Fahrzeug fehlerhaft laufen.
Die DE 102009 033 806 A1 offenbart ein Verfahren zur Fertigung und Prüfung der Funktionalität in der Fertigung. Das Verfahren beschreibt eine zentrale Verwaltung der Durchführung der Funktionsprüfung eines sich in der Fertigung befindenden Fahrzeugs bzw. von Fahrzeugkomponenten durch eine zentrale Recheneinheit. So ist es erforderlich, auf verschiedenen Fertigungs- und/oder Prüfstationen für unterschiedliche Modellvarianten verschiedene Funktionstests durchzuführen. Dabei werden auf der zentralen Recheneinheit für die verschiedenen Modellvarianten und Fertigungs- und/oder Prüfstationen die jeweils relevanten Vorgehensschritte und entsprechender Programmcode vorgehalten. Die während der Prüfung anfallenden Prüfdaten werden ebenfalls zentral gesammelt und ausgewertet, was eine schnelle und direkte Zuordnung von potenziell auftretenden Fehlern zu einer entsprechenden Fehlerquelle ermöglicht. Zudem wird hierdurch das Einleiten von Gegenmaßnahmen zur Behebung eines entsprechenden Fehlers vereinfacht.
Aus der DE 102013 014 878 B3 ist die Wartung von Kraftfahrzeug-Steuergeräten per Mobilfunk bekannt. Das Verfahren sieht das Aufbauen einer auf Mobilfunk basierenden Kommunikationsverbindung zwischen einer fahrzeugexternen Recheneinrichtung und einem fahrzeuginternen Steuergerät vor, wobei über die Kommunikationsverbindung Gerätedaten zwischen der Recheneinrichtung und dem Steuergerät ausgetauscht werden. Bei den Gerätedaten handelt es sich um Konfigurationsdaten für das Steuergerät, Fehlermeldungen des Steuergeräts und/oder Statusmeldungen des Steuergeräts. Die fahrzeugexterne Recheneinrichtung fungiert als zentrales Verwaltungsorgan zur Durchführung der Fahrzeugdiagnose. So kann die Recheneinrichtung einen Befehl an ein jeweiliges Steuergerät übermitteln, welcher dieses veranlasst einen nach einer fest vorgegebenen und im respektiven Steuergerät implementierten Routine definierten Selbsttest durchzuführen.
Ferner offenbart die DE 102012 110 623 A1 ein Messgerät zum Durchführen von Mess- und Prüfaufgaben in vorgebbaren Prozessen. Das Messgerät ist dazu eingerichtet eine Datei einzulesen, welche eine Prozessbeschreibung enthält. Das Messgerät wandelt die Prozessbeschreibung in eine Programmablaufroutine um und führt diese aus. Die Datei kann mit einem Editor für Business Process Model and Notation erstellt worden sein.
Zudem ist aus der DE 102018 203 067 A1 ein Verfahren und eine Fertigungsanlage zum Fertigen eines Kraftfahrzeugs bekannt. Das Verfahren sieht das Erfassen einer Spracheingabe durch eine fahrzeuginterne Steuerungseinrichtung und Zuweisen einer korrespondierenden Bedeutung vor. Anschließend wird über eine Schnittstelle zwischen Steuerungseinrichtung und fahrzeugexterner Prüfeinrichtung der Prüfeinrichtung zur Auswertung ein mit der Bedeutung korrespondierender Datensatz übermittelt.
Der vorliegenden Erfindung liegt die Aufgabe zugrunde ein verbessertes Verfahren zur Durchführung einer Funktionsdiagnose zumindest einer Fahrzeugkomponente eines sich in der Fertigung befindenden Fahrzeugs anzugeben, welches eine effiziente und zuverlässige Durchführung der Funktionsdiagnose gewährleistet.
Erfindungsgemäß wird diese Aufgabe durch ein Verfahren zur Durchführung einer Funktionsdiagnose mit den Merkmalen des Anspruchs 1 sowie ein entsprechendes hierzu verwendetes Diagnosesystem mit den Merkmalen des Anspruchs 7 gelöst. Vorteilhafte Ausgestaltungen und Weiterbildungen ergeben sich aus den hiervon abhängigen Ansprüchen.
Ein erfindungsgemäßes Verfahren zur Durchführung einer Funktionsdiagnose zumindest einer Fahrzeugkomponente eines sich in der Fertigung befindenden Fahrzeugs unterscheidet sich zu einem gattungsgemäßen Verfahren durch die folgenden Verfahrensschritte:
- Erzeugen eines Diagnoseausführungsprotokolls mittels einer ersten fahrzeugexternen Recheneinheit, wobei das Diagnoseausführungsprotokoll maschinenlesbare Anweisungen zur Durchführung einer zumindest teilautomatisierten Funktionsdiagnose von Fahrzeugkomponenten durch eine fahrzeuginterne Recheneinheit umfasst; - Übertragen des Diagnoseausführungsprotokolls auf die fahrzeuginterne Recheneinheit des sich in der Fertigung befindenden Fahrzeugs;
- Ausführung des Diagnoseausführungsprotokolls durch die fahrzeuginterne Recheneinheit, wobei die fahrzeuginterne Recheneinheit wenigstens eine Fahrzeugkomponente zur Überprüfung einer korrekten Funktionsweise der wenigstens einen Fahrzeugkomponente ansteuert, und wobei das Antwortverhalten der wenigstens einen Fahrzeugkomponente automatisiert durch die fahrzeuginterne Recheneinheit oder manuell assistiert durch eine die Fertigung des Fahrzeugs betreuende Person erfasst wird; und
- Ausgabe des erfassten Antwortverhaltens an die erste fahrzeugexterne Recheneinheit und/oder eine zweite fahrzeugexterne Recheneinheit.
Das erfindungsgemäße Verfahren sieht vor, die die Funktionsdiagnose ausführende Recheneinheit in das Fahrzeug selbst zu verlegen. Das Fahrzeug führt mit anderen Worten die Funktionsdiagnose selbstständig aus, was eine besonders effiziente Durchführung der Funktionsdiagnose ermöglicht. So wird der Kommunikationspfad der steuernden Recheneinheit zu den angesteuerten Komponenten verkürzt, was eine besonders schnelle Reaktionszeit und damit Absenkung von Latenzen erlaubt. Dies ermöglicht eine effiziente Ausführung zeitkritischer Aufrufe. Zudem werden weniger rechenintensive Ressourcen zur Durchführung der Funktionsdiagnose erfordert, da nicht mehr zeitgleich ein einziges zentrales Rechensystem eine Vielzahl an Steuergeräten zur Durchführung der Funktionsdiagnosen einer Vielzahl an Fahrzeugen ansteuern muss.
Die erste fahrzeugexterne Recheneinheit kann dabei als Entwicklersystem verstanden werden. Bei den maschinenlesbaren Anweisungen handelt es sich um Programmcode, welcher von der fahrzeuginternen Recheneinheit ausgeführt werden kann. Hierdurch wird die fahrzeuginterne Recheneinheit dazu in die Lage versetzt, die zu überprüfenden Fahrzeugkomponenten selbst entsprechend der durchzuführenden Diagnoseschritte anzusteuern. Entsprechende Diagnoseschritte können vollständig automatisiert von der fahrzeuginternen Recheneinheit durchgeführt und protokolliert werden oder auch manuell assistiert durch die die Fertigung des Fahrzeugs betreuende Person. Beispielsweise kann es erforderlich sein, dass die Person das Fahrzeug manuell manipulieren muss, damit die Funktionsprüfung vollständig durchgeführt werden kann und/oder die Person die durch Ansteuerung der Fahrzeugkomponente hervorgerufene Reaktion erfassen und protokollieren muss. Ein entsprechendes Prüfergebnis kann die Person dann im Fahrzeug selbst oder auch über die erste oder zweite fahrzeugexterne Recheneinheit eingeben. Bei der zweiten fahrzeugexternen Recheneinheit kann es sich um ein in der Fertigung verwendetes Rechensystem handeln. Beispielsweise kann es sich um einen zentralen Produktionsrechner oder auch ein Inselsystem handeln, beispielsweise ein an einer Fertigungs- und/oder Prüfstation vorgesehenes Rechnersystem.
Werden während der Funktionsprüfung Fehler entdeckt, so kann das Diagnoseausführungsprotokoll entsprechende Anweisungen zur Reaktion auf Fehler umfassen, wie das erneute Durchführen einzelner Kalibrier- oder Prüfschritte und/oder Nachbearbeitungsschritte, welche dann entsprechend von der fahrzeuginternen Recheneinheit umgesetzt werden. Die entsprechenden Anweisungen können dabei Teil eines gemeinsamen Diagnoseverfahrens sein oder ergänzend hierzu als „Standardantwort“ zur Reaktion auf typische Fehler ausgeführt sein. So können für diese Standardantworten auch individuelle Diagnoseausführungsprotokolle erzeugt und an die fahrzeuginterne Recheneinheit zum Vorhalten übertragen werden, welche dann nach Bedarf ausgeführt werden.
Die vom Diagnoseausführungsprotokoll umfassten Anweisungen können von der fahrzeuginternen Recheneinheit sequentiell und/oder parallel ausgeführt werden. Beispielsweise wird die durchzuführende Diagnose in eine „Vorbereitung“, einen „Hauptteil“ und eine „Nachbearbeitung“ unterteilt. Beispiele für eine Vorbereitung können sein: Aufbau einer Kommunikationsverbindung zwischen fahrzeuginternen und/oder fahrzeugexternen Recheneinheiten, Durchführen einer Authentifizierung und/oder Autorisierung, Aufbau einer sogenannten „Session“ und dergleichen. Beispiele für den Hauptteil können sein: Ansteuerung von Aktuatoren, Lesen von Sensordaten, Auslesen eines Fehlerspeichers eines Steuergeräts, Anpassen von Kalibrierparametern und dergleichen. Beispiele für eine Nachbearbeitung können sein: Beenden einer Kommunikationsverbindung, Schreiben von Ergebnisdaten, Publikation der Ergebnisdaten an ein fahrzeugexternes System, zurücksetzen von Steuergerätzuständen und dergleichen.
Eine vorteilhafte Weiterbildung des Verfahrens sieht vor, dass das Diagnoseausführungsprotokoll auf der ersten fahrzeugexternen Recheneinheit unter Anwendung einer grafischen Spezifikationssprache erzeugt wird, wobei das Diagnoseausführungsprotokoll einen Ablaufplan der von der fahrzeuginternen Recheneinheit durchzuführenden Diagnoseschritte umfasst, wobei die fahrzeugexterne Recheneinheit aus einer fahrzeugexternen Datenbank den Diagnoseschritten entsprechende maschinenlesbare Anweisungen ausliest und in das Diagnoseausführungsprotokoll integriert. Hierdurch wird der Ablauf zur Erzeugung anwendbaren Programmcodes auf der fahrzeuginternen Recheneinheit von der reinen Idee, über das genaue Vorgehen wie ein Prozessschritt durchzuführen ist, über das Erzeugen von Programmcode, bis hin zur finalen Implementierung und Anwendung durch die fahrzeuginterne Recheneinheit effizient ausgestaltet. Insbesondere lassen sich hierdurch Medienbrüche vermeiden, was das Risiko von Fehlern signifikant senkt. So werden die in der Funktionsdiagnose durchzuführenden Prozessschritte mittels der grafischen Spezifikationssprache anwenderfreundlich und leicht verständlich grafisch formuliert und direkt in maschinenlesbare Anweisungen überführt, indem die für die jeweiligen Diagnoseschritte passenden Anweisungen automatisiert durch die erste fahrzeugexterne Recheneinheit aus der fahrzeugexternen Datenbank ausgelesen werden. Die fahrzeugexterne Datenbank kann dabei als sogenanntes Code Repository verstanden werden. In dem Code Repository werden für alle möglichen von einer Maschine ausführbaren Schritte erforderliche maschinenlesbare Anweisungen implementiert. So ist kein manueller Programmieraufwand zur Integration der zur Durchführung einer bestimmten Funktionsdiagnose benötigten maschinenlesbaren Anweisungen in die fahrzeuginterne Recheneinheit mehr erforderlich.
Werden von einem Fahrzeughersteller neue Fahrzeuge, Fahrzeugkomponenten und/oder Fahrzeugfunktionen entwickelt, so können von einem Programmierer neue maschinenlesbare Anweisungen in die fahrzeugexterne Datenbank, sprich das Code Repository, geschrieben werden, welche auch eine zuverlässige Durchführung der Funktionsdiagnose unter Verwendung der neuen Komponenten erlaubt. Treten Bugs auf, so können entsprechende bestehende maschinenlesbare Anweisungen der fahrzeugexternen Datenbank aktualisiert und überarbeitet werden.
Das Diagnoseausführungsprotokoll beschreibt somit einen Oberbegriff sowohl für den rein gedanklichen Ablauf der in einer Funktionsdiagnose durchzuführenden Prüfschritte, als auch des hierzu zur Ansteuerung von Fahrzeugkomponenten durch die fahrzeuginterne Recheneinheit verwendeten Programmcodes. Die Verwendung einer grafischen Spezifikationssprache führt insbesondere zu einer Reduktion manueller Fehler durch die die Fertigung betreuende Person. So kann die Person die durchzuführenden Prüfschritte grafisch dargestellt auf einer beliebigen Anzeigevorrichtung, beispielsweise auf einem in der Fertigung verwendeten Tablet und/oder einer Augmented-Reality-Brille, betrachten und dadurch die anfallenden Arbeitsschritte leicht verständlich auffassen. Das Diagnoseausführungsprotokoll ist somit sowohl von der Person, als auch von einer Maschine in leicht verständlicher Art und Weise interpretierbar.
Entsprechend einer weiteren vorteilhaften Ausgestaltung des erfindungsgemäßen Verfahrens wird als grafische Spezifikationssprache Business Process Model and Notation (BPMN) verwendet. Hierbei handelt es sich um eine in der Wirtschaftsinformatik und im Prozessmanagement bewährte grafische Spezifikationssprache. Durch den klaren Bezug zwischen den durchzuführenden Prozessschritten und entsprechenden Programmcode lässt sich die für das Testen verschiedener Softwarevarianten erforderliche Zeit reduzieren, was das Durchführen der Funktionsdiagnose in seiner Effizienz weiter verbessert.
Eine weitere vorteilhafte Ausgestaltung des Verfahrens sieht ferner vor, dass die fahrzeuginterne Recheneinheit drahtgebunden und/oder drahtlos an ein gemeinsames Kommunikationsnetzwerk mit einer fahrzeugexternen Recheneinheit angeschlossen ist und die fahrzeuginterne Recheneinheit mit der fahrzeugexternen Recheneinheit mittelbar über einen Kommunikationsserver Informationen austauscht. Bei der fahrzeugexternen Recheneinheit kann es sich um die erste oder auch die zweite fahrzeugexterne Recheneinheit handeln. Beispielsweise kann die fahrzeuginterne Recheneinheit kabelgebunden über ein Ethernet-Kabel oder ein Onboard-Diagnosekabel mit der entsprechenden fahrzeugexternen Recheneinheit verbunden sein. Zur drahtlosen Kommunikation wird bevorzugt WLAN und/oder Mobilfunk, insbesondere unter Nutzung von 5G oder auch künftiger Mobilfunkstandards, eingesetzt. Insbesondere die Verwendung von WLAN und/oder Mobilfunk mit zumindest dem Mobilfunkstandard 5G erlaubt eine Datenübertragung mit vergleichsweise hohen Datenübertragungsraten. Insbesondere wenn die fahrzeuginterne Recheneinheit gleichzeitig sowohl drahtgebunden als auch drahtlos an das gemeinsame Kommunikationsnetzwerk mit der fahrzeugexternen Recheneinheit angeschlossen ist, lassen sich für verschiedene Anwendungen hohe Datenübertragungsraten erzielen. Generell ist es auch möglich, dass die fahrzeugexterne Recheneinheit unmittelbar mit der fahrzeuginternen Recheneinheit kommuniziert. Beispielsweise kann es sich bei der fahrzeugexternen Recheneinheit um ein von der die Fertigung betreuenden Person eingesetztes Tablet oder Desktopcomputer handeln, welcher drahtgebunden oder drahtlos an die fahrzeuginterne Recheneinheit in kommunikativer Art und Weise angeschlossen ist. Beispielsweise kann das Tablet der Person ein ad hoc WLAN aufbauen, in welches sich die fahrzeuginterne Recheneinheit einklinkt. Treten beispielsweise unvorhergesehene Ereignisse ein, welche das manuelle Eingreifen der Person erfordern, so kann die Person beispielsweise auf dem Tablet ein neues Diagnoseausführungsprotokoll unter Anwendung der grafischen Spezifikationssprache erzeugen und dieses unmittelbar zur Anwendung an die fahrzeuginterne Recheneinheit übertragen. Dies ermöglicht ein besonders schnelles Reagieren und Anpassen der zur Durchführung der Funktionsdiagnose durchzuführenden Prozessschritte. Ein solches Vorgehen kann auch in der Entwicklung der in der fahrzeugexternen Datenbank abzulegenden maschinenlesbaren Anweisungen aus den entsprechenden im Ablaufplan integrierten Prozessschritten angewendet werden.
Mit Hilfe des Kommunikationsservers wird ein zentraler Zugang der Vielzahl an fahrzeuginternen Recheneinheiten, auch über verschiedene Fertigungsstandorte hinweg, zu einer zentralen fahrzeugexternen Datenbank ermöglicht. So kann beispielsweise in das an der Fertigungs- und/oder Prüfstation integrierte Tablet eine fahrzeugexterne Datenbank integriert sein. So kann das Tablet nach Erzeugen eines entsprechenden Ablaufplans durch die Person selbst entsprechende maschinenlesbare Anweisungen in das Diagnoseausführungsprotokoll integrieren. Dabei besteht das Risiko, dass veraltete maschinenlesbare Anweisungen aus der tabletinternen fahrzeugexternen Datenbank ausgelesen werden. Durch den Zugriff auf die zentrale fahrzeugexterne Datenbank über den Kommunikationsserver können entsprechende verteilte fahrzeugexterne Datenbanken mit aktualisiertem Programmcode geupdated werden.
Eine weitere vorteilhafte Ausgestaltung des erfindungsgemäßen Verfahrens sieht ferner vor, dass die fahrzeuginterne Recheneinheit eine fahrzeugexterne Manipulationsmaschine ansteuert, um zumindest einen Diagnoseschritt durchzuführen und/oder Maßnahmen einzuleiten, wenn die zumindest eine Fahrzeugkomponente in ihrer korrekten Funktionsweise gestört ist. Entsprechende maschinenlesbare Anweisungen zum Ansteuern der fahrzeugexternen Manipulationsmaschine sind dann ebenfalls in das Diagnoseausführungsprotokoll bzw. in weitere Diagnoseausführungsprotokolle integriert. Die Integration erfolgt dabei bevorzugt automatisiert in Abhängigkeit der in der grafischen Spezifikationssprache definierten Prozessschritte des Ablaufplans. Beispielsweise kann es sich bei der fahrzeugexternen Manipulationsmaschine um einen an der Fertigungs- und/oder Prüfstation vorgesehenen Roboter handeln. Eine Manipulation des Fahrzeugs bzw. einer Fahrzeugkomponente kann auf vielfältige Art und Weise erfolgen, beispielsweise kann die fahrzeugexterne Manipulationsmaschine das Fahrzeug oder eine Fahrzeugkomponente bewegen, mit Hilfe fahrzeugexterner Sensoren überprüfen, neue Komponenten hinzufügen oder bereits integrierte Komponenten austauschen, loslösen oder dergleichen. So ist eine Nachbearbeitung des Fahrzeugs bzw. von Fahrzeugkomponenten nach dem Durchführen der eigentlichen Funktionsdiagnose möglich. Das erfindungsgemäße Verfahren ermöglicht es also der fahrzeuginternen Recheneinheit in der Produktion bzw. in der Prüfung verwendete fahrzeugexterne Maschinen selbst ansteuern zu können. Es ist dann keine zentrale Recheneinheit zum Ansteuern der fahrzeugexternen Manipulationsmaschinen mehr erforderlich. Auch dies sorgt für eine gesteigerte Effizienz bei der Durchführung der Funktionsdiagnose. Die fahrzeuginterne Recheneinheit kann die fahrzeugexterne Manipulationsmaschine unmittelbar ansteuern, beispielsweise über eine direkte Kommunikation mittels WLAN oder auch mittelbar über eine fahrzeugexterne Recheneinheit wie einen zentralen Fabrikserver.
Bei einem Diagnosesystem mit einer ersten fahrzeugexternen Recheneinheit und mit einem sich in der Fertigung befindenden Fahrzeug, umfassend eine fahrzeuginterne Recheneinheit, sind erfindungsgemäß die erste fahrzeugexterne Recheneinheit und das Fahrzeug zur Durchführung eines im vorigen beschriebenen Verfahrens eingerichtet. Die fahrzeuginterne Recheneinheit ist dazu in der Lage alle relevanten Fahrzeugkomponenten elektrisch bzw. elektronisch anzusteuern und zu überwachen. Dies erlaubt das besonders ressourcenarme Durchführen zeitlich kritischer Diagnoseprozessschritte mit vergleichsweise geringen Latenzen. Hierdurch wird ein effizienter Funktionsdiagnoseablauf gewährleistet.
Eine vorteilhafte Weiterbildung des Diagnosesystems sieht wenigstens eine zweite fahrzeugexterne Recheneinheit vor, wobei die zweite fahrzeugexterne Recheneinheit dazu eingerichtet ist, von der fahrzeuginternen Recheneinheit Informationen zu empfangen und/oder angesteuert zu werden. Die fahrzeuginterne Recheneinheit kann beispielsweise Ergebnisse der Funktionsdiagnoseprüfung an die zweite fahrzeugexterne Recheneinheit übermitteln, welche dort zur Auswertung gespeichert werden. Auch können in Abhängigkeit der ausgewerteten Ergebnisse durch die zweite fahrzeugexterne Recheneinheit Maßnahmen zur Behebung von Fehlern eingeleitet werden. Die fahrzeuginterne Recheneinheit kann die zweite fahrzeugexterne Recheneinheit auch ansteuern. Beispielsweise handelt es sich bei der zweiten fahrzeugexternen Recheneinheit um das Steuergerät einer fahrzeugexternen Manipulationsmaschine.
Bevorzugt umfasst das Diagnosesystem einen Kommunikationsserver, wobei der Kommunikationsserver dazu eingerichtet ist, Informationen zwischen der fahrzeuginternen Recheneinheit und der ersten fahrzeugexternen Recheneinheit auszutauschen. Dies ermöglicht eine zentrale Verwaltung der fahrzeugexternen Datenbank. So müssen die in die Planung der Funktionsdiagnose eingebundenen Ingenieure nicht örtlich in der Fabrik anwesend sein, um neue Funktionsdiagnoseprozesse zu entwickeln oder zu implementieren. Die entsprechenden neu generierten Diagnoseausführungsprotokolle lassen sich über den Kommunikationsserver an die jeweiligen Fertigungs- und/oder Prüfstationen in der Fertigung übertragen und dort auf die jeweiligen fahrzeuginternen Recheneinheiten einspielen. Generell ist es auch möglich, dass besagte Diagnoseausführungsprotokolle bereits auf der fahrzeuginternen Recheneinheit vorinstalliert sind, bevor die entsprechenden fahrzeuginternen Recheneinheiten im Fahrzeug verbaut werden. Dies ermöglicht das Durchführen bestimmter Funktionsdiagnoseüberprüfungen auch ohne eine bestehende Kommunikation zwischen fahrzeugexterner Recheneinheit und fahrzeuginterner Recheneinheit. Entsprechende Diagnoseergebnisse können auf der fahrzeuginternen Recheneinheit zwischengespeichert werden und sobald eine Kommunikationsverbindung zur ersten und/oder zweiten fahrzeugexternen Recheneinheit besteht an diese übertragen werden.
Weitere vorteilhafte Ausgestaltungen des erfindungsgemäßen Verfahrens zur Durchführung der Funktionsdiagnose zumindest einer Fahrzeugkomponente eines sich in der Fertigung befindenden Fahrzeugs und des Diagnosesystems ergeben sich auch aus den Ausführungsbeispielen, welche nachfolgend unter Bezugnahme auf die Figuren näher beschrieben werden. Dabei zeigen:
Fig. 1 eine schematisierte Darstellung des Ablaufs eines erfindungsgemäßen Verfahrens;
Fig. 2 eine schematisierte Darstellung der zur Fertigung und Entwicklung von Fahrzeugen verwendeten Infrastruktur eines Fahrzeugherstellers gemäß einer ersten Ausführung;
Fig. 3 eine schematisierte Darstellung der zur Fertigung und Entwicklung von Fahrzeugen verwendeten Infrastruktur eines Fahrzeugherstellers gemäß einer zweiten Ausführung;
Fig. 4 eine schematisierte Darstellung einer Fertigungsstraße; und
Fig. 5 eine schematisierte Darstellung einer verteilten Fertigung.
Kerngedanke des erfindungsgemäßen Verfahrens zur Durchführung einer Fahrzeugdiagnose zumindest einer Fahrzeugkomponente eines sich in der Fertigung befindenden Fahrzeugs 1 ist die selbstständige Durchführung der Funktionsdiagnose durch eine fahrzeuginterne Recheneinheit RI. Bevorzugt wird der vollständige Ablauf der Entwicklung der in der Funktionsdiagnose durchzuführenden Prozessschritte bis hin zur Erzeugung von Programmcode, Implementierung des Programmcodes in der fahrzeuginternen Recheneinheit RI und Ausführung von dieser durch Anwendung einer grafischen Spezifikationssprache, bevorzugt Business Process Model and Notation (BPMN) ausgestaltet.
Ein Ingenieur 5 erstellt an einer ersten fahrzeugexternen Recheneinheit RE_1 einen Ablaufplan der von der fahrzeuginternen Recheneinheit RI durchzuführenden Diagnoseschritte mittels der grafischen Spezifikationssprache. Hieraus wird ein Diagnoseausführungsprotokoll 2 erstellt. Das Diagnoseausführungsprotokoll 2 kann in der grafischen Spezifikationssprache ausformuliert sein und dann in eine Metasprache wie beispielsweise XML gewandelt werden. Dabei liest die erste fahrzeugexterne Recheneinheit RE_1 aus einer fahrzeugexternen Datenbank 3, auch als Code Repository bezeichnet, den Diagnosenschritten entsprechende maschinenlesbare Anweisungen aus und integriert diese in das Diagnoseausführungsprotokoll 2. Dies erfolgt im Verfahrensschritt 101. Dabei kann die fahrzeugexterne Datenbank 3 auf der ersten fahrzeugexternen Recheneinheit RE_1 vorgehalten werden und/oder auf einem Datenspeicher in einem Netzwerk, beispielsweise auf einem zentralen Server. Das Diagnoseprotokoll 2 wird über einen Kommunikationsserver RKOM, beispielsweise einen Proxyserver, an eine Fabrik 6 des Fahrzeugherstellers, in der sich die Fertigung befindet, übertragen. In der Fabrik 6 erfolgt eine Verteilung des Diagnoseausführungsprotokolls 2 an die entsprechende fahrzeuginterne Recheneinheit RI des zu überprüfenden Fahrzeugs 1. Im Verfahrensschritt 102 wird das Diagnoseausführungsprotokoll 2 bzw. die darin enthaltenden maschinenlesbaren Anweisungen von der fahrzeuginternen Recheneinheit RI ausgeführt, wodurch die fahrzeuginterne Recheneinheit RI die zumindest eine zu überprüfende Fahrzeugkomponente ansteuert und das entsprechende Antwortverhalten automatisiert oder manuell assistiert durch eine die Fertigung des Fahrzeugs 1 betreuende Person erfasst. Ist die Funktionsdiagnose erfolgreich, wie in Figur 1 durch ein Häkchen angedeutet, so kann das Fahrzeug 1 für den nächsten Fertigungsschritt bzw. zur Übergabe an den Händler freigegeben werden. Ist die Funktionsdiagnose hingegen wie in Figur 1 durch einen Blitz angedeutet fehlerhaft, so sind weitere Maßnahmen einzuleiten. Dabei können die weiteren Maßnahmen ebenfalls beschrieben durch in das Diagnoseausführungsprotokoll 2 integrierte Anweisungen durch die fahrzeuginterne Recheneinheit RI ausgeführt bzw. angestoßen werden.
Die Figuren 2 und 3 dienen noch einmal zur Veranschaulichung der zur Fertigung und Entwicklung von Fahrzeugen verwendeten Infrastruktur des Fahrzeugherstellers. In Figur 2 sind mehrere erste fahrzeugexterne Recheneinheiten RE_1 dargestellt. Dabei umfasst jede der ersten fahrzeugexternen Recheneinheiten RE_1 eine eigene fahrzeugexterne Datenbank 3. In diesem Falle kann es sich bei den ersten fahrzeugexternen Recheneinheiten RE_1 beispielsweise um den Entwicklungs-PC eines Ingenieurs 5 handeln. Über einen solchen PC kann ein Diagnoseausführungsprotokoll 2 erzeugt werden und über den Kommunikationsserver RKOM an eine jeweilige Fabrik 6 übertragen werden. In einer jeweiligen Fabrik 6 kann ein Kommunikationsrelais 7, beispielsweise ein WLAN-Router oder ein 5G Modem, vorgesehen sein, über dass der Kommunikationsserver RKOM an ein gemeinsames Kommunikationsnetzwerk mit der fahrzeuginternen Recheneinheit RI angeschlossen ist. Eine entsprechende Übertragung des Diagnoseausführungsprotokolls 2 an die fahrzeuginterne Recheneinheit RI ist in Figur 2 durch eine gepunktete Linie dargestellt.
Die fahrzeuginterne Recheneinheit RI kann auch eine fahrzeugexterne Manipulationsmaschine 4, beispielsweise einen Manipulationsroboter, ansteuern. So kann der Manipulationsroboter Teile des Fahrzeugs bewegen oder auf eine sonstige Art und Weise manipulieren. Auch kann die fahrzeugexterne Manipulationsmaschine 4 einen oder mehrere Sensoren zur Überprüfung des Zustands des Fahrzeugs 1 bzw. von Fahrzeugkomponenten umfassen. Bei einem solchen Sensor kann es sich beispielsweise um eine Kamera, einen Leitfähigkeitssensor, einen Temperatursensor, einen Kraftsensor, einen Ultraschallsensor oder dergleichen handeln.
Ein Steuergerät der fahrzeugexternen Manipulationsmaschine 4 kann dabei als zweite fahrzeugexterne Recheneinheit RE_2 bezeichnet werden. In der Fabrik 6 können auch weitere zweite fahrzeugexterne Recheneinheiten RE_2 vorgesehen sein wie beispielsweise ein zentraler Fabrikserver RE_2_Zentral. Auf dem zentralen Fabrikserver RE_2_Zentral können von den fahrzeuginternen Recheneinheiten RI zu fertigender und/oder zu überprüfender Fahrzeuge 1 erzeugte Ergebnisse einer jeweiligen Funktionsdiagnose gespeichert und ausgewertet werden. So kann zum einen die fahrzeuginterne Recheneinheit RI oder auch der zentrale Fabrikserver RE_2_Zentral entsprechende fahrzeugexterne Manipulationsmaschinen 4 ansteuern, um im Falle eines Fehlers automatisiert Gegenmaßnahmen zur Behebung des Fehlers einzuleiten. Es können auch Personen benachrichtigt werden, welche eine manuelle Fehlerbehebung einleiten können.
Ferner kann eine erste fahrzeugexterne Recheneinheit RE_1 auch unmittelbar mit der fahrzeuginternen Recheneinheit RI kommunizieren. So ist beispielhaft ein Tabletcomputer RE_2_Tab dargestellt, welcher von einer die Fertigung des Fahrzeugs 1 betreuenden Person zur Interaktion mit der fahrzeuginternen Recheneinheit RI genutzt werden kann. Dies erlaubt besonders kurze Kommunikationswege zwischen erster fahrzeugexterner Recheneinheit RE_1 und fahrzeuginterner Recheneinheit RI.
Figur 3 zeigt eine der Figur 2 ähnliche Darstellung. Dabei sind in das Rechnernetz der ersten fahrzeugexternen Recheneinheiten RE_1 eine zentrale fahrzeugexterne Datenbank 3.1 sowie gegebenenfalls, angedeutet durch eine gestrichelte Linie, ein Zentralserver RE_1_Zentral integriert. Entwickler können in der zentralen fahrzeugexternen Datenbank 3.1 gespeicherte maschinenlesbare Anweisungen, sprich Codebausteine, pflegen. Die entsprechenden ersten fahrzeugexternen Recheneinheiten RE_1 , also beispielsweise Entwickler- PCs, können dann ihre jeweilige fahrzeugexterne Datenbank 3 durch Auslesen der zentralen fahrzeugexternen Datenbank 3.1 aktualisieren. Dabei können auch einige der Entwickler- PCs über keine integrierte fahrzeugexterne Datenbank 3 verfügen und sind auf eine direkte Anbindung an die zentrale fahrzeugexterne Datenbank 3.1 angewiesen.
Das gesamte Verfahren ist auch durch den Zentralserver RE_1_Zentral verwaltbar. Beispielsweise können die von den fahrzeuginternen Recheneinheiten RI der einzelnen Fahrzeuge 1 übermittelten Ergebnisse der Funktionsdiagnosen gespeichert und ausgewertet werden. Dies ermöglicht eine zentrale Analyse der Daten aus der Fertigung. So können die Vorteile der dezentralen Steuerung der Durchführung der Funktionsdiagnose und das zentrale Auswerten der entsprechenden Ergebnisse kombiniert werden.
So lassen sich besonders einfach systematische Fehlerursachen ermitteln, welche beispielsweise auf eine fehlerhafte Charge einzelner Bauelemente schließen lassen. Auch können hierdurch Prozessschritte ermittelt werden, welche eine erhöhte Fehleranfälligkeit aufweisen, beispielsweise weil eine Sensorkalibrierung zu viel Zeit beansprucht.
Figur 4 zeigt die zu einer Fertigungsstraße 8 in Reihe angeordneten Fertigungs- und/oder Prüfstationen 9. Dabei können an einer Fertigungs- und/oder Prüfstation 9 einzelne Fertigungsschritte eines Fahrzeugs 1 bzw. einer Fahrzeugkomponente durchgeführt werden und/oder ein Fahrzeug 1 bzw. Fahrzeugkomponenten einer Funktionsdiagnose unterzogen werden. Dabei kann jede Fertigungs- und/oder Prüfstation 9 eine eigene zweite fahrzeugexterne Recheneinheit RE_2 aufweisen, beispielsweise einen zentralen Computer, welcher die an der jeweiligen Fertigungs- und/oder Prüfstation 9 verwendeten Maschinen steuert. Auch kann eine jede solcher Maschine, beispielsweise eine fahrzeugexterne Manipulationsmaschine 4, ein eigenes Steuergerät in Form einer zweiten fahrzeugexternen Recheneinheit RE_2 umfassen.
Entsprechende Steuerbefehle können auch von dem zentralen Fabrikserver RE_2_Zentral ausgegeben werden und insbesondere über WLAN, 5G oder einen künftigen Mobilfunkstandard in der Fabrik 6 an die einzelnen zweiten fahrzeugexternen Recheneinheiten RE_2 übermittelt werden. Von den fahrzeuginternen Recheneinheit RI in Abhängigkeit der durchgeführten Funktionsdiagnose erzeugte Daten lassen sich dann entsprechend auf den zentralen Fabrikserver RE_2_Zentral zur Auswertung rückübermitteln. Figur 5 zeigt eine alternative oder ergänzende Ausführung der Fabrik 6. So können einzelne oder auch alle Fertigungs- und/oder Prüfstationen 9 verteilt angeordnet sein. Dies ermöglicht eine besonders flexible und effiziente Fertigung und/oder Prüfung von Fahrzeugen 1 entsprechend des Gedankenguts von Industrie 4.0. So ist ein zu fertigendes Fahrzeug 1 nicht darauf angewiesen, die einzelnen Fertigungs- und/oder Prüfstationen 9 sequentiell hintereinander zu durchlaufen, sondern kann für mehrere Produktions- bzw. Prüfschritte einer einzelnen Fertigungs- und/oder Prüfstation 9 zugeordnet bleiben und/oder flexibel zwischen diesen wechseln, wodurch freie Kapazitäten bezüglich ihrer Effizienz optimal genutzt werden.

Claims

Patentansprüche Verfahren zur Durchführung einer Funktionsdiagnose zumindest einer Fahrzeugkomponente eines sich in der Fertigung befindenden Fahrzeugs (1), gekennzeichnet durch die folgenden Verfahrensschritte:
- Erzeugen eines Diagnoseausführungsprotokolls (2) mittels einer ersten fahrzeugexternen Recheneinheit (RE_1), wobei das Diagnoseausführungsprotokoll (2) maschinenlesbare Anweisungen zur Durchführung einer zumindest teilautomatisierten Funktionsdiagnose von Fahrzeugkomponenten durch eine fahrzeuginterne Recheneinheit (RI) umfasst;
- Übertragen des Diagnoseausführungsprotokolls (2) auf die fahrzeuginterne Recheneinheit (RI) des sich in der Fertigung befindenden Fahrzeugs (1);
- Ausführung des Diagnoseausführungsprotokolls (2) durch die fahrzeuginterne Recheneinheit (RI), wobei die fahrzeuginterne Recheneinheit (RI) wenigstens eine Fahrzeugkomponente zur Überprüfung einer korrekten Funktionsweise der wenigstens einen Fahrzeugkomponente ansteuert, und wobei das Antwortverhalten der wenigstens einen Fahrzeugkomponente automatisiert durch die fahrzeuginterne Recheneinheit (RI) oder manuell assistiert durch eine die Fertigung des Fahrzeugs (1) betreuende Person erfasst wird; und
- Ausgabe des erfassten Antwortverhaltens an die erste fahrzeugexterne Recheneinheit (RE_1) und/oder eine zweite fahrzeugexterne Recheneinheit (RE_2). Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass das Diagnoseausführungsprotokoll (2) auf der ersten fahrzeugextern Recheneinheit (RE_1) unter Anwendung einer grafischen Spezifikationssprache erzeugt wird, wobei das Diagnoseausführungsprotokoll (2) einen Ablaufplan der von der fahrzeuginternen Recheneinheit (RI) durchzuführenden Diagnoseschritte umfasst, wobei die erste fahrzeugexterne Recheneinheit (RE_1) aus einer fahrzeugexternen Datenbank (3) den Diagnoseschritten entsprechende maschinenlesbare Anweisungen ausliest und in das Diagnoseausführungsprotokoll (2) integriert. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass als grafische Spezifikationssprache Business Process Model and Notation verwendet wird. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass die fahrzeuginterne Recheneinheit (RI) drahtgebunden und/oder drahtlos an ein gemeinsames Kommunikationsnetzwerk mit einer fahrzeugexternen Recheneinheit (RE_1, RE_2) angeschlossen ist und die fahrzeuginterne Recheneinheit (RI) mit der fahrzeugexternen Recheneinheit (RE_1 , RE_2) mittelbar über einen Kommunikationsserver (RKOM) Informationen austauscht. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass eine drahtlose Kommunikation mittels WLAN und/oder Mobilfunk, insbesondere unter Nutzung von 5G, erfolgt. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass die fahrzeuginterne Recheneinheit (RI) eine fahrzeugexterne Manipulationsmaschine (4) ansteuert, um zumindest einen Diagnoseschritt durchzuführen und/oder Maßnahmen Einzuleiten, wenn die zumindest eine Fahrzeugkomponente in ihrer korrekten Funktionsweise gestört ist. Diagnosesystem mit einer ersten fahrzeugexternen Recheneinheit (RE_1) und mit einem sich in der Fertigung befindenden Fahrzeug (1), umfassend eine fahrzeuginterne Recheneinheit (RI), dadurch gekennzeichnet, dass die erste fahrzeugexterne Recheneinheit (RE_1) und das Fahrzeug (1) zur Durchführung eines Verfahrens nach einem der Ansprüche 1 bis 6 eingerichtet sind. Diagnosesystem nach Anspruch 7, gekennzeichnet durch wenigstens eine zweite fahrzeugexterne Recheneinheit (RE_2), wobei die zweite fahrzeugexterne Recheneinheit (RE_2) dazu eingerichtet ist von der fahrzeuginternen Recheneinheit (RI) Informationen zu empfangen und/oder angesteuert zu werden. Diagnosesystem nach Anspruch 7 oder 8, gekennzeichnet durch einen Kommunikationsserver (RKOM), wobei der Kommunikationsserver (RKOM) dazu eingerichtet ist Informationen zwischen der fahrzeuginternen Recheneinheit (RI) und der ersten fahrzeugexternen Recheneinheit (RE_1) auszutauschen.
EP23714670.9A 2022-04-12 2023-03-23 Verfahren zur durchführung einer funktionsdiagnose zumindest einer fahrzeugkomponente und diagnosesystem Pending EP4377663A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102022001254.5A DE102022001254B8 (de) 2022-04-12 2022-04-12 Verfahren zur Durchführung einer Funktionsdiagnose zumindest einer Fahrzeugkomponente und Diagnosesystem
PCT/EP2023/057400 WO2023198421A1 (de) 2022-04-12 2023-03-23 Verfahren zur durchführung einer funktionsdiagnose zumindest einer fahrzeugkomponente und diagnosesystem

Publications (1)

Publication Number Publication Date
EP4377663A1 true EP4377663A1 (de) 2024-06-05

Family

ID=85800528

Family Applications (1)

Application Number Title Priority Date Filing Date
EP23714670.9A Pending EP4377663A1 (de) 2022-04-12 2023-03-23 Verfahren zur durchführung einer funktionsdiagnose zumindest einer fahrzeugkomponente und diagnosesystem

Country Status (7)

Country Link
US (1) US20250252787A1 (de)
EP (1) EP4377663A1 (de)
JP (1) JP2025512018A (de)
KR (1) KR20240140125A (de)
CN (1) CN118829865A (de)
DE (1) DE102022001254B8 (de)
WO (1) WO2023198421A1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102024103076A1 (de) * 2024-02-05 2025-08-07 Bayerische Motoren Werke Aktiengesellschaft Verfahren zur Individualisierung einer Mensch-Maschine-Interaktion in der Fertigung und Fertigungsanlage und Kraftfahrzeugprodukt zur Anwendung des Verfahrens

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19607950A1 (de) * 1996-03-01 1997-09-04 Schenck Rotec Gmbh Verfahren zum Prüfen von Kraftfahrzeugen und Prüfsystem
DE19635839A1 (de) * 1996-09-04 1998-03-05 Teves Gmbh Alfred Verfahren zum Prüfen des Bauteils eines Systems in einem Kraftfahrzeug
US6611740B2 (en) * 2001-03-14 2003-08-26 Networkcar Internet-based vehicle-diagnostic system
US7155321B2 (en) * 2001-08-06 2006-12-26 Idsc Holdings Llc System, method and computer program product for remote vehicle diagnostics, monitoring, configuring and reprogramming
JP4059064B2 (ja) * 2002-11-12 2008-03-12 日産自動車株式会社 無線通信方法およびシステム
US9117319B2 (en) * 2005-06-30 2015-08-25 Innova Electronics, Inc. Handheld automotive diagnostic tool with VIN decoder and communication system
DE102009033806A1 (de) 2009-07-18 2011-01-20 Dr. Ing. H.C. F. Porsche Aktiengesellschaft Verfahren zur Fertigung und Prüfung der Funktionalität in der Fertigung
DE102012110623B4 (de) 2012-11-06 2017-08-17 Testo Ag Messgerät zum Durchführen von Mess- und Prüfaufgaben in vorgebbaren Prozessen
DE102013014878B3 (de) 2013-09-06 2014-10-30 Audi Ag Wartung von Kraftfahrzeug-Steuergeräten per Mobilfunk
DE102015012524A1 (de) * 2015-09-26 2016-05-12 Daimler Ag Verfahren und System zur Diagnose eines Fahrzeuges
DE102018203067B4 (de) 2018-03-01 2022-03-03 Audi Ag Verfahren und Fertigungsanlage zum Fertigen eines Kraftfahrzeugs

Also Published As

Publication number Publication date
DE102022001254A1 (de) 2023-10-12
CN118829865A (zh) 2024-10-22
JP2025512018A (ja) 2025-04-16
WO2023198421A1 (de) 2023-10-19
US20250252787A1 (en) 2025-08-07
DE102022001254B8 (de) 2024-02-22
KR20240140125A (ko) 2024-09-24
DE102022001254B4 (de) 2023-12-07

Similar Documents

Publication Publication Date Title
EP2705430A1 (de) System zur diagnose einer komponente in einem fahrzeug
DE102004062434A1 (de) System und Verfahren zum automatischen Aktualisieren von Funktionalitäten in einem verteilten Netzwerk
DE10343963A1 (de) Bereitstellung von Diagnoseinformationen
EP3001310B1 (de) Verfahren und Einrichtung zur Aktualisierung von Firmware für Komponenten einer industriellen Automatisierungsanordnung
EP2718774A1 (de) Simulationssystem, verfahren zur durchführung einer simulation, leitsystem und computerprogrammprodukt
EP4160390B1 (de) Verfahren und anordnung zur inbetriebnahme einer aktualisierten anwendung für eine industrielle automatisierungsanordnung
DE102022001254B4 (de) Verfahren zur Durchführung einer Funktionsdiagnose zumindest einer Fahrzeugkomponente und Diagnosesystem
EP4096198A1 (de) Verfahren zur diagnose eines bordnetzes eines fahrzeugs
WO2008095518A1 (de) Anwendung einer verteilten diagnosearchitektur in autosar
EP3353650B1 (de) System und verfahren zur verteilung und/oder aktualisierung von software in vernetzten steuereinrichtungen eines fahrzeugs
EP3132322B1 (de) Verfahren zur diagnose eines kraftfahrzeugsystems, diagnosegerät für ein kraftfahrzeugsystem, steuergerät für ein kraftfahrzeugsystem und kraftfahrzeug
EP2557464A1 (de) Verfahren zum Betrieb eines Automatisierungssystems
DE102012003000A1 (de) Ferndiagnostizierung von Fahrzeugen
EP4148514B1 (de) Integriertes diagnosesystem für sps-basierte fernwirk-aussenstationen
WO2005022382A2 (de) Verfahren zur installation einer programmkomponente
WO2012028366A1 (de) Verfahren zur sicherstellung der korrekten funktionsweise einer automatisierungsanlage
EP4117977B1 (de) Eisenbahnanlage mit diagnosesystem und verfahren zu deren betrieb
DE102020200453A1 (de) Multi-Cloud-Industriecontroller
EP1814763B1 (de) Verfahren und System zur Bereitstellung von internen diagnoserelevanten Informationen in einem Fahrzeug
EP4335127B1 (de) Computer-implementiertes verfahren zum betrieb eines end-geräts mit hoher verfügbarkeit in einem netzwerk
DE102020213809A1 (de) Verfahren zum Betreiben eines Steuergeräts beim Testen einer Software des Steuergeräts und Verfahren zum Betreiben eines Testcomputers beim Testen einer Software eines Steuergeräts
EP1079289A2 (de) Projektierungseinheit für korrespondierende Diagnosedatensätze eines Systems mit Steuerungseinheit und Bedien- und/oder Beobachtungseinheit, und System mit Mitteln zum Versionsvergleich von zugeordneten Diagnosedatensätzen
DE10140763A1 (de) Verfahren und Anordnung zur Konfiguration von Baugruppen in einer Datenverarbeitungsanlage
DE10161321A1 (de) Verfahren zur Aktualisierung von elektronisch modifizierbaren Komponenten eines Automatisierungsgerätes
DE102022203325A1 (de) Verfahren zur Überprüfung der Ausführbarkeit einer Softwareanwendung

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20240227

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20250708