WO2014183949A1 - Vorrichtung und verfahren für ein fahrerassistenzsystem eines fahrzeuges - Google Patents

Vorrichtung und verfahren für ein fahrerassistenzsystem eines fahrzeuges Download PDF

Info

Publication number
WO2014183949A1
WO2014183949A1 PCT/EP2014/057619 EP2014057619W WO2014183949A1 WO 2014183949 A1 WO2014183949 A1 WO 2014183949A1 EP 2014057619 W EP2014057619 W EP 2014057619W WO 2014183949 A1 WO2014183949 A1 WO 2014183949A1
Authority
WO
WIPO (PCT)
Prior art keywords
sensor
vehicle
sensor signal
sensors
driver assistance
Prior art date
Application number
PCT/EP2014/057619
Other languages
English (en)
French (fr)
Inventor
Michael Fiegert
Wendelin Feiten
Original Assignee
Siemens Aktiengesellschaft
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 Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Publication of WO2014183949A1 publication Critical patent/WO2014183949A1/de

Links

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/02—Ensuring safety in case of control system failures, e.g. by diagnosing, circumventing or fixing failures
    • B60W50/0205—Diagnosing or detecting failures; Failure detection models
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/10—Geometric CAD
    • G06F30/15—Vehicle, aircraft or watercraft design
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/02—Ensuring safety in case of control system failures, e.g. by diagnosing, circumventing or fixing failures
    • B60W50/0205—Diagnosing or detecting failures; Failure detection models
    • B60W2050/0215—Sensor drifts or sensor failures

Definitions

  • the present invention relates to an apparatus and a method for a driver assistance system of a vehicle with a number of driver assistance applications.
  • driver assistance applications or applications are often integrated. Since the applications can come from independent manufacturers and can be developed independently of each other, the sensor signals originating from a specific application can not be used by another application. The main reason for this is the vertical integration of the applications, ie the applications including the necessary hardware and software are developed independently of each other and installed in the vehicle.
  • the respective application has specially provided sensors, its own system model and its own output, namely the application of the respective driver assistance application. This creates an unnecessary redundancy of sensors, hardware and software, especially in vehicles with a high degree of equipment.
  • the unnecessary redundancy is particularly unnecessary because it can provide no added value, such as reliability, due to the purely vertical integration.
  • the close coupling of sensors and applications means that the individual processing steps from the detection of the environment by the sensor to the reaction, ie the application of the driver assistance application, are often not separated but implemented as one block.
  • This block conventionally comprises three levels, namely the detection of the environment by the sensor, the interpretation of the sensor values on the basis of a system model and the reaction by the driver assistance application. In most systems today, these three levels are not explicitly present, but are closely related, making reuse of a single level nearly impossible. Cooperation between the various sensors, system models and applications is therefore very difficult or impossible.
  • the respective system model is also usually in the respective sensor and the application
  • the conversion rule according to which the sensor data are converted into the system model is conventionally integrated in a fusion algorithm. If a new type of sensor is to be integrated into the system, the entire fusion algorithm must be reopened. Then the fusion algorithm has to be re-formulated taking into account the new sensor type. Again, the developer must know exactly the peculiarities of this new sensor type.
  • the document DE 10 2004 052 242 A1 shows a sensor fusion system and vehicle control system with a sensor fusion system.
  • Each of a plurality of probability distribution output units calculates a probability distribution of a data value detected by a corresponding sensor or algorithm in image recognition processing.
  • the respective probability distributions of the plurality of probability distribution output units are output to a synthesis determination processing unit. Data formats of the outputs of the synthesis determination processing unit can thereby be standardized.
  • the synthesis determination processing unit is excluded from considering on which type of sensor or algorithm each of the outputs is based. Even if a sensor or algorithm is added or changed, the same data-fusing algorithm can be used in the synthesis-determining processing unit. However, here, probability distribution output units and a synthesis designating processing unit are necessary.
  • the document WO 2007/017308 A1 shows a method for creating environmental hypotheses for driver assistance functions.
  • a device for a driver assistance system of a vehicle comprising a number of driver assistance applications.
  • the device has a plurality of sensors, a first arithmetic unit, a second arithmetic unit and a control unit.
  • the respective sensor is set up for outputting a sensor signal, wherein an associated formalized description of the sensor signal is associated with the respective sensor signal.
  • the first arithmetic unit is set up to fuse the sensor signals output by the sensors based on the associated formalized descriptions and output a fused sensor signal as a function thereof.
  • the second arithmetic unit is configured to calculate a system model at least as a function of the output fused sensor signal.
  • the control unit is set up to provide at least one of the driver control application based on the calculated system model.
  • the developer of the first computing unit does not have to know or research the specific properties of the respective sensor, since he either uses the formalized description directly from the sensor or in another way, for example via a sensor
  • USB stick or as a downloadable file over the Internet, receives.
  • the present device is more modular in design than conventional driver assistance system devices.
  • Another aspect besides the possibility of using redundancy is that the hardware required for the driver assistance system can be reduced since individual sensors are used multiple times. Also, the complexity of the overall system
  • the formalized descriptions allow separately working groups of developers, for example for the sensors, the first computing unit, the second computing unit and the control unit, to work together by means of defined interfaces, namely the formalized descriptions.
  • Another advantage is the ability to progressively develop driver assistance systems through the increased modularity created. Instead of equipping each application with its own sensors as usual, the existing sensors can be reused. The additional cost of a new driver assistance application is then oriented only to the optionally additionally installed sensors and the costs for new software.
  • the fusion model ie how the sensor signals of a certain type of sensor affect the entries in a specific type of system model, from the actual fusion algorithm for generating the system model.
  • the formalized descriptions of the sensor signals as metadata are predetermined
  • the metadata advantageously describe properties and features of the associated sensor signal.
  • Probabilistic descriptions are particularly suitable for fusing sensor signals from different sensors with different modalities, for example radar sensor and laser sensor, to a model or a fused sensor signal.
  • the respective probabilistic description includes the variance of the sensor signal and / or the probability density function of the sensor signal.
  • the variances or probability density function are particularly suitable parameters for comparing and thus also for combining sensor signals of different sensors.
  • the formalized descriptions each include the variance of the sensor signal, the probability density function of the sensor signal, an indication of the physical unit of the sensor signal, a sensor model of the physical properties of the sensor Time information for indicating the time of detection of the sensor signal and / or an indication of the clock used in the detection of the time.
  • the respective indication of the physical unit of the respective sensor signal it is possible to convert sensor signals of different sensors into each other.
  • the sensor model advantageously describes which measured value a particular sensor produces in a specific environment. This can also include statistical properties of the measured values.
  • the time information is important. Also, this is the respective reference, that is, the clock used in each case important to perform the synchronization correctly.
  • the respective sensor is configured to detect a state of the vehicle, at least part of the surroundings of the vehicle and / or a state of the driver of the vehicle.
  • the condition of the vehicle, the environment of the vehicle and the condition of the driver can contribute to the optimization of the system model.
  • the system model comprises a vehicle model for modeling at least a part of the vehicle, an environment model for modeling at least part of the surroundings of the vehicle, in particular based on a grid map and / or an object map, a driver model for modeling at least one predetermined property of the driver of the vehicle and / or a number of sensor models for modeling a number of sensors.
  • the vehicle model describes where the sensors are relative to the vehicle.
  • these are relevant for geometrical conditions.
  • electrical conditions can also be used if, for example, according to the sensor model, fluctuations in the supply voltage can lead to increased noise in the measured values.
  • the supply voltage possibly as a random variable, can be used as part of the vehicle model.
  • the environment model or physical environment model contains the physical properties of the environment needed to simulate or derive the ground truth of a perceived environment model
  • the physical physical environment model becomes the corresponding physical properties
  • the geometry and textures of the objects may be sufficient
  • the formats that set up the physical sensor model and the physical environmental model A standardized example of such a standardization is a probabilistic formulation, that is, the en corresponding parameters are considered as random variables.
  • the plurality of sensors comprises at least one ultrasonic sensor, a radar, a lidar, a wheel rotation sensor, an inertial sensor, an acceleration sensor, a rotation rate sensor, a temperature sensor, an air humidity sensor, a position sensor for determining at least one parameter of the driving dynamics of the vehicle Seat occupancy sensor, a distance sensor and / or at least one camera.
  • control unit is adapted to at least two of the number of vehicle ap- plications, preferably all vehicle applications, based on the calculated system model.
  • control unit is configured to control all vehicle applications based on the calculated system model.
  • the control unit may advantageously control a plurality of vehicle applications. Furthermore, a plurality of control units can also be provided.
  • the device has a number of further sensors for outputting sensor signals.
  • each of the number of further sensors is associated with exactly one third arithmetic unit.
  • the respective third arithmetic unit is configured to calculate a further system model based on the sensor signal output by the associated further sensor.
  • the other sensors are adapted to output conventional sensor signals without associated formalized description. Consequently, it is possible to use both conventional sensor signals and sensor signals with associated formalized description in the present device.
  • the second arithmetic unit is configured to calculate the system model as a function of the fused sensor signal output by the first arithmetic unit and as a function of the further system model calculated by the third arithmetic unit.
  • a plurality of first computing units is provided, wherein each of the plurality of first computing units is assigned a predeterminable number of the plurality of sensors.
  • the respective first arithmetic unit is set up to output a fused sensor signal as a function of the sensor signals of the sensors assigned to the respective first arithmetic unit. This improves the granularity and thus the modularity of the present device.
  • the respective sensor is set up to output the respective sensor signal and the associated formalized description of the sensor signal.
  • the respective sensor can directly output the associated formalized description.
  • Alternatives to this are in those embodiments in which the formalized description is provided on a different path of the first arithmetic unit. Examples of such other ways include the use of a USB stick or a downloadable from the Internet file that can use the first processing unit.
  • the USB stick is for example with a
  • Linkable engineering system via which the contents of the USB stick can then be transferred to the first processing unit.
  • the respective unit for example arithmetic unit or control unit, can be implemented in terms of hardware and / or software technology.
  • the respective unit may act as a device or be designed as part of a device, for example as a computer or as a microprocessor or as a control computer of a vehicle.
  • the respective unit may be part of a computer program product, a function, a routine, part of a
  • Program codes or be designed as an executable object.
  • a driver assistance system for a vehicle which has a device as described above.
  • a vehicle which has a device for a driver assistance system of a vehicle as described above.
  • a method for operating a driver assistance system for a vehicle with a number of driver assistance applications has the following steps: In a first step, a plurality of sensor signals are received by a plurality of sensors, wherein an associated formalized description of the sensor signal is associated with each of the sensor signals. In a second step, the sensor signals received by the sensors are fused based on the associated formalized descriptions for outputting a fused sensor signal. In a third step, a system model is calculated as a function of the output fused sensor signal.
  • a computer program product which causes the execution of the method as explained above on a program-controlled device.
  • a computer program product such as a computer program means, for example, as a storage medium, such as memory card, USB stick, CD-ROM, DVD or in the form of a
  • Downloadable file can be provided or delivered by a server in a network. This can be done, for example, in a wireless communication network by transmitting a corresponding file with the computer program product or the computer program means.
  • FIG. 1 shows a schematic block diagram of a first exemplary embodiment of a device for a driver assistance system
  • Fig. 2 is a schematic view of an example of a
  • FIG. 3 is a schematic view of an example of a
  • FIG. 4 is a schematic block diagram of a second
  • FIG. 5 shows a schematic block diagram of an exemplary embodiment of a driver assistance system
  • FIG. 6 is a flowchart of an embodiment of a
  • FIG. 1 shows a schematic block diagram of a first exemplary embodiment of a device 100 for a driver assistance system 300 of a vehicle 200.
  • the device 100 has a plurality of sensors 101,
  • FIG. 1 Without limiting the generality, two sensors 101, 102, in particular different sensors 101, 102, are shown in FIG.
  • the respective sensor 101, 102 is configured to output a sensor signal S1, S2.
  • Each of the sensor signals Sl, S2 is associated with an associated formalized description Bl, B2 of the sensor signal Sl, S2.
  • the formalized description Bl is assigned to the sensor signal S1.
  • the sensor signal S2 is assigned the formalized description S2.
  • the formalized descriptions B1, B2 of the sensor signals S1, S2 are designed, for example, as metadata of a predetermined format.
  • the formalized descriptions Bl, B2 are such metadata th that they can be processed by the processing unit 110 to be processed.
  • the formalized descriptions B1, B2 are designed as probabilistic descriptions and include, for example, the variance of the sensor signal S1, S2 and the probability density function of the sensor signal S1, S2.
  • 2 and 3 show a schematic view of an example of a formalized description B1 of the first signal S1 or of the formalized description B2 of the second sensor signal B2.
  • FIG. 2 shows that the formalized description Bl the variance VI of the sensor signal Sl, the probability density function Wl of the sensor signal Sl, an indication of the physical unit PI of the sensor signal Sl, a sensor model ME1 of the physical properties of the sensor 101, a time information Tl for indicating the time of detection of the sensor signal Sl and an indication of the clock Ul used in detecting the time.
  • FIG. 3 shows that the formalized description B2 of the second sensor signal S2 can be constructed analogously.
  • the formalized descriptions Bl and B2 can also be structured differently.
  • the respective sensor 101, 102 may preferably be set up to output the associated formalized description B1, B2 in addition to the sensor signal S1.
  • An alternative to the output of the formalized description Bl, B2 by the respective sensor 101, 102 is that the formalized descriptions Bl, B2 of the computing unit 110 are provided via a different path, for example via a USB stick or as a downloadable file from a server over the internet.
  • the respective sensor 101, 102 can be used, for example, as an ultrasonic sensor, as a radar, as a lidar, as a wheel rotation sensor, as an inertial sensor, as an acceleration sensor, as a rotation rate sensor, as a temperature sensor, as an air humidity sensor, as a po- Position sensor for determining at least one parameter of the driving dynamics of the vehicle 200, as a seat occupancy sensor for detecting a seat occupancy of a seat in the vehicle 200, as a rangefinder for determining a distance between the vehicle 200 and a predetermined object of the environment or be designed as a camera ,
  • the first arithmetic unit 110 is designed to fuse the sensor signals S1, S2 output by the sensors 101, 102 based on the associated formalized descriptions B1, B2, and to output a fused sensor signal FS dependent thereon.
  • the fused sensor signal FS can have analog characteristics such as the sensor signals S1, S2. Alternatively, it may also be a more abstract representation of a sensor signal.
  • the fused sensor signal FS may also be formed as part of a system model or as a system model.
  • the formalized descriptions B1, B2 are compatible with the computing unit 110. That is, the arithmetic unit 110 may also process different formalized descriptions B1, B2. However, the formalized descriptions B1, B2 can preferably also be mutually compatible and thus convertible.
  • the second arithmetic unit 120 receives the fused sensor signal FS on the input side and calculates a system model SM at least in dependence thereon.
  • the system model SM includes, for example, a vehicle model for modeling at least part of the vehicle 200, an environment model for modeling at least part of the environment of the vehicle 200, a driver model for modeling at least one predetermined characteristic of the driver of the vehicle 200, and / or a number of Sensor models ME1, ME2 for modeling the sensors 101, 102.
  • the environment model of the vehicle 200 is based for example on a grid map or on an object map of the surroundings of the vehicle 200.
  • the control unit 130 is configured to control at least one of the driver assistance applications FA of the driver assistance system 300 on the basis of the calculated system model SM.
  • the control unit 130 may also be configured to control at least two of the number of vehicle applications FA or all vehicle applications FA based on the calculated system model SM.
  • 4 shows a schematic block diagram of a second exemplary embodiment of a device 100 for a driver assistance system 300 of a vehicle 200.
  • the device 100 of FIG. 4 comprises the following different types of units: first sensors 101-103, first arithmetic units 111, 112, second arithmetic units 121, 122, control units 131-134, further sensors 141 and 142, third arithmetic units 151 and 152 and a fourth arithmetic unit 160.
  • the sensors 101-103 are configured to output a respective sensor signal S1-S3.
  • the respective sensor signal S1-S3 is assigned a respective formalized description Bl-B3.
  • the further sensors 141-142 output a respective sensor signal S4, S5.
  • the sensor signals S4, S5 are conventional and have no associated formalized description.
  • the first computing unit 111 receives the sensor signals S1 and S2 from the sensors 101 and 102.
  • the sensor signal S1 is assigned the formalized description B1.
  • the sensor signal S2 is assigned the formalized description B2.
  • the first arithmetic unit 111 fuses the sensor signals S1, S2 output by the sensors 101, 102 on the basis of the associated formalized descriptions B1, B2 and outputs a fused sensor signal FS1 on the output side as a function thereof.
  • the first computing unit 112 receives the sensor signals S2, S3 output from the sensors 102, 103 and merges them based on the associated formalized descriptions B2, B3. Depending on this, the first arithmetic unit 112 outputs a fused sensor signal FS2.
  • Each of the further sensors 141, 142 is associated with exactly one third arithmetic unit 151, 152.
  • the respective third arithmetic unit 151, 152 is set up to calculate a further system model WS1, WS2 based on the sensor signal S4, S5 output by the associated further sensor 141, 142.
  • the second arithmetic unit 121 is set up to calculate the system model SM1 as a function of the fused sensor signal FS1 output by the first arithmetic unit 111 and in dependence on the further system model WS1 calculated by the third arithmetic unit 151.
  • the control unit 131 controls the driver assistance applications FA1 and FA2 based on the calculated system model SM1.
  • the second arithmetic unit 122 calculates the system model SM2 as a function of the fused sensor signal FS2 output by the first arithmetic unit 112.
  • the control unit 132 controls the driver assistance applications FA3 and FA4 based on the calculated system model SM2.
  • the fourth arithmetic unit 160 is configured to calculate the system model SM3 based on the system models SM1 and SM2.
  • the control unit 134 is then configured to control the driver assistance application FA6 based on the calculated system model SM3.
  • the third computing unit 152 calculates a further system model WS2 as a function of the sensor signal S5 from the further sensor 142.
  • the control unit 133 controls the driver assistant application F5 based on the further system model WS2.
  • FIG. 5 shows a schematic block diagram of an exemplary embodiment of a driver assistance system 300 for a vehicle 200.
  • the driver assistance system 300 has a device 100.
  • the device 100 is formed, for example, according to the first embodiment of FIG. 1 or according to the second embodiment of FIG. 4.
  • FIG. 6 shows a flow chart of an exemplary embodiment of a method for operating a driver assistance system 300 for a vehicle 200 having a number of driver assistance applications FA.
  • step 601 a plurality of sensor signals S1, S2 are received by a plurality of sensors, wherein an associated formalized description B1, B2 of the sensor signal S1, S2 is associated with each of the sensor signals S1, S2.
  • step 602 the sensor signals S1, S2 received by the sensors 101, 102 are fused to output a fused sensor signal based on the associated formalized descriptions B1, B2.
  • step 603 a system model SM is calculated in response to the output fused sensor signal.
  • step 604 at least one of the driver assistance applications FA is controlled based on the calculated system model.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Geometry (AREA)
  • Automation & Control Theory (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Analysis (AREA)
  • Computer Hardware Design (AREA)
  • Computational Mathematics (AREA)
  • Mechanical Engineering (AREA)
  • Transportation (AREA)
  • Mathematical Optimization (AREA)
  • Pure & Applied Mathematics (AREA)
  • Aviation & Aerospace Engineering (AREA)
  • Evolutionary Computation (AREA)
  • General Engineering & Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Traffic Control Systems (AREA)
  • Control Of Driving Devices And Active Controlling Of Vehicle (AREA)
  • Stored Programmes (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Es wird eine Vorrichtung (100) für ein Fahrerassistenzsystem (300) eines Fahrzeuges (200) vorgeschlagen, wobei das Fahrerassistenzsystem (300) eine Anzahl von Fahrerassistenzapplikationen (FA) umfasst. Die Vorrichtung (100) weist eine Mehrzahl von Sensoren (101, 102), eine erste Recheneinheit (110), eine zweite Recheneinheit (120) und eine Steuerungseinheit (130) auf. Der jeweilige Sensor (101, 102) ist zur Ausgabe eines Sensorsignals (S1, S2) eingerichtet ist, wobei dem jeweiligen Sensorsignal (S1, S2) eine zugehörige formalisierte Beschreibung (B1, B2) des Sensorsignals (S1, S2) zugeordnet ist. Die erste Recheneinheit (110) ist dazu eingerichtet, die von den Sensoren (101, 102) ausgegebenen Sensorsignale (S1, S2) basierend auf den zugehörigen formalisierten Beschreibungen (B1, B2) zu fusionieren und abhängig davon ein fusioniertes Sensorsignal (FS) auszugeben. Die zweite Recheneinheit (120) ist dazu eingerichtet, ein Systemmodell (SM) zumindest in Abhängigkeit von dem ausgegebenen fusionierten Sensorsignal (FS) zu berechnen. Die Steuerungseinheit (130) ist dazu eingerichtet, zumindest eine der Fahrerassistenzapplikationen (FA) basierend auf dem berechneten Systemmodell (SM) zu steuern. Durch die Verwendung der formalisierten Beschreibungen ist eine modulare und hybride Fusionierung von Sensorsignalen unterschiedlicher Sensoren möglich. Ferner werden ein Fahrerassistenzsystem, ein Verfahren sowie ein Computerprogrammprodukt zum Betreiben eines Fahrerassistenzsystems vorgeschlagen.

Description

Beschreibung
Vorrichtung und Verfahren für ein Fahrerassistenzsystem eines Fahrzeuges
Die vorliegende Erfindung betrifft eine Vorrichtung und ein Verfahren für ein Fahrerassistenzsystem eines Fahrzeuges mit einer Anzahl von Fahrerassistenzapplikationen. In einem Fahrzeug werden häufig mehrere solcher Fahrerassistenzapplikationen oder Applikationen integriert. Da die Applikationen von unabhängigen Herstellern stammen können und unabhängig voneinander entwickelt werden können, sind die von einer bestimmten Applikation verwendeten Sensoren stammenden Sensorsignale von einer anderen Applikation nicht verwendbar. Wesentlicher Grund hierfür ist die vertikale Integration der Applikationen, das heißt die Applikationen inklusive der dafür notwendigen Hardware und Software werden unabhängig voneinander entwickelt und in das Fahrzeug eingebaut . So hat die jeweilige Applikation eigens vorgesehene Sensoren, ein eigenes Systemmodell und eine eigene Ausgabe, nämlich die Anwendung der jeweiligen Fahrerassistenzapplikation. Damit entsteht insbesondere in Fahrzeugen mit einem hohen Ausstattungsgrad eine unnötige Redundanz von Sensoren, Hardware und Software. Die unnötige Redundanz ist insbesondere deshalb unnötig, da sie keinen Mehrwert, wie beispielsweise Ausfallsicherheit, auf Grund der rein vertikalen Integration liefern kann . Die enge Kopplung von Sensoren und Applikationen führt dazu, dass die einzelnen Bearbeitungsschritte von der Erfassung der Umwelt durch den Sensor bis hin zur Reaktion, das heißt der Anwendung der Fahrerassistenzapplikation, häufig nicht getrennt werden, sondern als ein Block umgesetzt werden. Dieser Block umfasst herkömmlicherweise drei Ebenen, nämlich die Erfassung der Umwelt durch den Sensor, die Interpretation der Sensorwerte auf Basis eines Systemmodelles und die Reaktion durch die Fahrerassistenzapplikation. In den meisten heutigen Systemen sind diese drei Ebenen nicht explizit vorhanden, sondern eng miteinander verbunden, sodass eine Wiederverwendung einer einzelnen Ebene nahezu unmöglich ist. Eine Kooperation der verschiedenen Sensoren, Systemmodelle und Applikationen ist deshalb sehr schwierig beziehungsweise unmöglich. Das jeweilige Systemmodell ist ferner zumeist in den jeweiligen Sensor und die Applikation
eincodiert und nicht explizit vorhanden.
Das heißt die Interpretation der Sensorsignale beziehungsweise Messwerte zu internen, wahrgenommen Modellen sowie die Implementierung der eigentlichen Applikation auf Grund dieser internen Modelle liegt herkömmlicherweise in der Hand des je- weiligen Entwicklers.
Wie dabei die Sensorsignale in Bezug auf den Modelltyp zu interpretieren sind, bleibt dabei der Erfahrung und dem Fingerspitzengefühl des jeweiligen Entwicklers überlassen. Der je- weilige Entwickler muss die Eigenheiten der eingesetzten Sensoren und den Typ des wahrgenommen Modells genau kennen.
Die Umrechnungsvorschrift, nach der die Sensordaten in das Systemmodell hinein umgerechnet werden, ist dabei herkömmli- cherweise in einem Fusionsalgorithmus integriert. Wenn ein neuer Sensortyp in das System integriert werden soll, muss der gesamte Fusionsalgorithmus wieder aufgeschnürt werden. Dann muss der Fusionsalgorithmus wieder unter Berücksichtigung des neuen Sensortyps neu formuliert werden. Auch hierzu muss der Entwickler wieder die Eigenheiten dieses neuen Sensortyps genau kennen.
Das Dokument DE 10 2004 052 242 AI zeigt ein Sensorfusions - System und Fahrzeugsteuersystem mit einem Sensorfusionssys - tem. Jede von mehreren Wahrscheinlichkeitsverteilungs- Ausgabeeinheiten berechnet eine Wahrscheinlichkeitsverteilung eines Datenwerts, der von einem entsprechenden Sensor oder Algorithmus in einer Bilderkennungsverarbeitung erfasst wird. Die jeweiligen Wahrscheinlichkeitsverteilungen der mehreren Wahrscheinlichkeitsverteilungs-Ausgabeeinheiten werden als Ausgabe zu einer Synthesebestimmungs-Bearbeitungseinheit gegeben. Datenformate der Ausgaben der Synthesebestimmungs - Verarbeitungseinheit können dadurch standardisiert werden.
Daher wird die Synthesebestimmungs -Verarbeitungseinheit davon ausgenommen, zu berücksichtigen, auf welchem Typ des Sensors oder Algorithmus jede der Ausgaben basiert. Auch dann, wenn ein Sensor oder Algorithmus hinzugefügt oder geändert wird, kann der gleiche datenfusionierende Algorithmus in der Syn- thesebestimmungs-Verarbeitungseinheit eingesetzt werden. Allerdings sind hier Wahrscheinlichkeitsverteilungs- Ausgabeeinheiten und eine Synthesebestimmungs - Verarbeitungseinheit nötig.
Das Dokument WO 2007/017308 AI zeigt ein Verfahren zum Erstellen von Umwelthypothesen für Fahrerassistenzfunktionen.
Demnach ist es eine Aufgabe der vorliegenden Erfindung, ein verbessertes Fahrerassistenzsystem für ein Fahrzeug zu schaffen .
Demgemäß wird eine Vorrichtung für ein Fahrerassistenzsystem eines Fahrzeuges vorgeschlagen, wobei das Fahrerassistenzsys- tem eine Anzahl von Fahrerassistenzapplikationen umfasst. Die Vorrichtung weist eine Mehrzahl von Sensoren, eine erste Recheneinheit, eine zweite Recheneinheit und eine Steuerungs- einheit auf. Der jeweilige Sensor ist zur Ausgabe eines Sensorsignals eingerichtet, wobei dem jeweiligen Sensorsignal eine zugehörige formalisierte Beschreibung des Sensorsignals zugeordnet ist. Die erste Recheneinheit ist dazu eingerichtet, die von den Sensoren ausgegebenen Sensorsignale basierend auf den zugehörigen formalisierten Beschreibungen zu fusionieren und abhängig davon ein fusioniertes Sensorsignal auszugeben. Die zweite Recheneinheit ist dazu eingerichtet, ein Systemmodell zumindest in Abhängigkeit von dem ausgegebenen fusionierten Sensorsignal zu berechnen. Die Steuerungs- einheit ist dazu eingerichtet, zumindest eine der Fahreras- sistenzapplikationen basierend auf dem berechneten Systemmodell zu steuern.
Durch die Verwendung der formalisierten Beschreibungen ist eine modulare und hybride Fusionierung von Sensorsignalen unterschiedlicher Sensoren möglich. Insbesondere muss dabei der Entwickler der ersten Recheneinheit die spezifischen Eigenschaften des jeweiligen Sensors nicht kennen oder erforschen, da er die formalisierte Beschreibung entweder direkt von dem Sensor oder auf einen anderen Weg, zum Bespiel über einen
USB-Stick oder als herunterladbare Datei über das Internet, erhält .
Des Weiteren ist es hierbei möglich, einen Sensor für eine Mehrzahl von Fahrerassistenzapplikationen zu nutzen, da vorliegend die strikte Kopplung zwischen Sensor und Fahrerassistenzapplikation aufgebrochen ist. Folglich wird Redundanz im Gesamtsystem Fahrerassistenzsystem besser ausgenutzt. Daher ist die vorliegende Vorrichtung modularer aufgebaut als her- kömmliche Vorrichtungen für Fahrerassistenzsysteme.
Ein weiterer Aspekt neben der Möglichkeit der Nutzung von Redundanz ist, dass die für das Fahrerassistenzsystem notwenige Hardware reduziert werden kann, da einzelne Sensoren mehrfach genutzt werden. Auch ist die Komplexität des Gesamtsystem
Fahrerassistenzsystem einfacher zu beherrschen. Des Weiteren ermöglichen die formalisierten Beschreibungen, dass getrennt arbeitende Gruppen von Entwicklern, beispielsweise für die Sensoren, die erste Recheneinheit, die zweite Recheneinheit und die Steuerungseinheit, mittels definierter Schnittstellen, nämlich der formalisierten Beschreibungen, zusammenarbeiten .
Einerseits werden durch die Verwendung von Softwarekomponen- ten, hier insbesondere die erste Recheneinheit, die zweite
Recheneinheit und die Steuerungseinheit, die Entwicklungszeiten neuer Fahrerassistenzsysteme drastisch verkürzt. Andererseits können die Herstellungskosten für weitere oder neue Fahrerassistenzapplikationen auf Grund der Möglichkeit der Wiederverwendung von bereits im Fahrzeug verbauten Sensoren reduziert werden. Ferner ist es möglich, eine Anzahl erster Recheneinheiten und eine Anzahl zweiter Recheneinheiten in einer Datenfusionsschicht abzubilden, mittels welcher automatisch neue Sensoren zur Verbesserung der Umwelterkennung des Fahrzeuges integriert werden können. Somit kann ein Fahrzeug auch nachträg- lieh mit neuen komplexen Fahrerassistenzfunktionen nachgerüstet werden.
Ein weiterer Vorteil liegt in der Möglichkeit, Fahrerassistenzsysteme durch die geschaffene erhöhte Modularität schrittweise weiter zu entwickeln. Statt wie herkömmlich jede Applikation mit eigenen Sensoren auszustatten, können die bestehenden Sensoren wieder verwendet werden. Der Mehrpreis einer neuen Fahrerassistenzapplikation orientiert sich dann nur noch an den gegebenenfalls zusätzlich verbauten Sensoren und den Kosten für neue Software.
Auf Grund der redundanten Verwendung bereits bestehender Sensoren und bereits bestehender Software, insbesondere die ersten und zweiten Recheneinheiten, werden die Gesamtkosten ver- mindert. Des Weiteren kann auch ein Evolutionspfad zu immer komplexer werdenden Fahrerassistenzapplikationen bis hin zum autonomen Fahren geschaffen werden.
Durch die Differenzierung von erster Recheneinheit und zwei- ter Recheneinheit ist es möglich, das Fusionsmodell, also wie sich die Sensorsignale eines bestimmten Sensortyps auf die Einträge in einen bestimmten Typ eines Systemmodells auswirken, aus dem eigentlichen Fusionsalgorithmus zur Generierung des Systemmodells heraus zu trennen.
Durch diese Differenzierung ist es möglich, die Eigenschaften von Eingangs- und Ausgangssignalen der eingesetzten Modelle, hier fusioniertes Sensorsignal und Systemmodell, sowie ihrer internen Zustände explizit zu beschreiben, so dass unterschiedliche Entwickler die unterschiedlichen Einheiten entwickeln können und dennoch die Entwurfssicherheit gegeben ist. Ferner können die Sensormodelle unabhängig von ihrer jeweili- gen spezifischen Verwendung entwickelt werden. Dies ermöglicht insbesondere der Einsatz der formalisierten Beschreibung für das jeweilige Sensorsignal.
Bei einer Ausführungsform sind die formalisierten Beschrei- bungen der Sensorsignale als Metadaten eines vorbestimmten
Formats ausgebildet. Die Metadaten beschreiben vorteilhafterweise Eigenschaften und Merkmale des zugeordneten Sensorsignals . Bei einer weiteren Ausführungsform sind die formalisierten
Beschreibungen als probabilistische Beschreibungen ausgebildet .
Probabilistische Beschreibungen sind besonders geeignet, Sen- sorsignale unterschiedlicher Sensoren mit unterschiedlichen Modalitäten, zum Beispiel Radarsensor und Lasersensor, auf ein Modell oder ein fusioniertes Sensorsignal zu fusionieren.
Bei einer weiteren Ausführungsform umfasst die jeweilige probabilistische Beschreibung die Varianz des Sensorsignals und/oder die Wahrscheinlichkeitsdichtefunktion des Sensorsignals .
Die Varianzen oder Wahrscheinlichkeitsdichtefunktion sind be- sonders geeignete Parameter zum Vergleichen und damit auch zum Kombinieren von Sensorsignalen unterschiedlicher Sensoren .
Bei einer weiteren Ausführungsform umfassen die formalisier- ten Beschreibungen jeweils die Varianz des Sensorsignals, die Wahrscheinlichkeitsdichtefunktion des Sensorsignals, eine Angabe der physikalischen Einheit des Sensorsignals, ein Sensormodell der physikalischen Eigenschaften des Sensors, eine Zeitinformation zur Angabe des Zeitpunktes des Erfassens des Sensorsignals und/oder eine Angabe der verwendeten Uhr bei dem Erfassen des Zeitpunktes. Durch die jeweilige Angabe der physikalischen Einheit des jeweiligen Sensorsignals ist es möglich, Sensorsignale unterschiedlicher Sensoren ineinander umzurechnen. Das Sensormodell beschreibt vorteilhafterweise, welchen Messwert ein bestimmter Sensor in einer bestimmten Umgebung produziert. Das kann auch statistische Eigenschaften der Messwerte beinhalten .
Zur Synchronisation der Sensorsignale unterschiedlicher Sensoren sind die Zeitinformationen wichtig. Auch ist hierfür die jeweilige Referenz, das heißt die jeweils verwendete Uhr wichtig, um die Synchronisation korrekt ausführen zu können.
Bei einer weiteren Ausführungsform ist der jeweilige Sensor dazu eingerichtet, einen Zustand des Fahrzeuges, zumindest einen Teil der Umgebung des Fahrzeuges und/oder einen Zustand des Fahrers des Fahrzeuges zu erfassen.
Der Zustand des Fahrzeuges, die Umgebung des Fahrzeuges und der Zustand des Fahrers können zur Optimierung des Systemmo- dells beitragen.
Bei einer weiteren Ausführungsform umfasst das Systemmodell ein Fahrzeugmodell zur Modellierung zumindest eines Teils des Fahrzeuges, ein Umgebungsmodell zur Modellierung zumindest eines Teils der Umgebung des Fahrzeuges, insbesondere basierend auf einer Gitterkarte und/oder einer Objektkarte, ein Fahrermodell zur Modellierung zumindest einer vorbestimmten Eigenschaft des Fahrers des Fahrzeuges und/oder eine Anzahl von Sensormodellen zur Modellierung einer Anzahl der Senso- ren.
Das Fahrzeugmodell beschreibt insbesondere, wo sich die Sensoren relativ zum Fahrzeug befinden. In erster Linie sind da- bei geometrische Verhältnisse relevant. Es können aber auch elektrische Verhältnisse verwendet werden, wenn zum Beispiel gemäß Sensormodell Schwankungen in der VersorgungsSpannung zu einem erhöhten Rauschen bei den Messwerten führen können. In diesem Fall kann auch die VersorgungsSpannung, gegebenenfalls als Zufallsvariable, als Teil des Fahrzeugmodells verwendet werden .
Das Umgebungsmodell oder physikalische Umgebungsmodell ent- hält diejenigen physikalischen Eigenschaften der Umgebung, die zur Simulation oder Herleitung der „ground truth" eines wahrgenommenen Umgebungsmodells benötigt werden. Für jedes physikalische Sensormodell, das verwendet werden soll, werden im physikalischen Umgebungsmodell die entsprechenden physika- lischen Eigenschaften der Umgebung berücksichtigt. Für eine Videokamera sind das beispielsweise die Geometrie und die Texturen der Objekte. Für einen Ultraschallsensor kann eine Approximation der Geometrie zusammen mit den akustischen Reflexionseigenschaften ausreichen. Die Formate, in denen zum einen das physikalische Sensormodell und zum anderen das physikalische Umgebungsmodell aufgestellt werden, sind auf die jeweiligen Recheneinheiten abgestimmt. Hierzu kann eine Standardisierung eingesetzt werden. Ein aussichtsreiches Beispiel für eine solche Standardisierung ist eine probabilistische Formulierung, das heißt die entsprechenden Parameter werden als Zufallsvariable aufgefasst.
Bei einer weiteren Ausführungsform umfasst die Mehrzahl der Sensoren zumindest einen Ultraschallsensor, ein Radar, ein Lidar, einen Raddrehungssensor, einen Inertialsensor, einen Beschleunigungssensor, einen Drehratensensor, einen Temperatursensor, einen Luftfeuchtesensor, einen Positionssensor zur Bestimmung zumindest eines Parameters der Fahrdynamik des Fahrzeuges, einen Sitzbelegungssensor, einen Entfernungssen- sor und/oder zumindest eine Kamera.
Bei einer weiteren Ausführungsform ist die Steuerungseinheit dazu eingerichtet, zumindest zwei der Anzahl der Fahrzeugap- plikationen, vorzugsweise alle Fahrzeugapplikationen, basierend auf dem berechneten Systemmodell zu steuern.
Bei einer weiteren Ausführungsform ist die Steuerungseinheit dazu eingerichtet, alle Fahrzeugapplikationen basierend auf dem berechneten Systemmodell zu steuern.
Die Steuerungseinheit kann vorteilhafterweise eine Mehrzahl von Fahrzeugapplikationen steuern. Ferner kann auch eine Mehrzahl von Steuerungseinheiten vorgesehen sein.
Bei einer weiteren Ausführungsform weist die Vorrichtung eine Anzahl weiterer Sensoren zum Ausgeben von Sensorsignalen auf. Dabei ist einem jeden der Anzahl der weiteren Sensoren genau eine dritte Recheneinheit zugeordnet. Die jeweilige dritte Recheneinheit ist dazu eingerichtet, ein weiteres Systemmodell basierend auf dem von dem zugeordneten weiteren Sensor ausgegebenen Sensorsignal zu berechnen.
Die weiteren Sensoren sind dazu eingerichtet, herkömmliche Sensorsignale ohne zugeordnete formalisierte Beschreibung auszugeben. Folglich ist es möglich, bei der vorliegenden Vorrichtung sowohl herkömmliche Sensorsignale als auch Sensorsignale mit zugeordneter formalisierter Beschreibung einzusetzen .
Bei einer weiteren Ausführungsform ist die zweite Recheneinheit dazu eingerichtet, das Systemmodell in Abhängigkeit von dem von der ersten Recheneinheit ausgegebenen fusionierten Sensorsignal und in Abhängigkeit von dem von der dritten Re- cheneinheit berechneten weiteren Systemmodell zu berechnen.
Somit können bei der Berechnung des Systemmodells unterschiedliche Eingabeparameter verwendet werden, solche die auf herkömmlichen Daten (weiteres Systemmodell) beruhen und sol- che die auf dem vorliegenden fusionierten Sensorsignal beruhen . Bei einer weiteren Ausführungsform ist eine Mehrzahl von ersten Recheneinheiten vorgesehen, wobei einer jeden der Mehrzahl der ersten Recheneinheiten eine vorbestimmbare Anzahl der Mehrzahl von Sensoren zugeordnet ist. Dabei ist die je- weilige erste Recheneinheit dazu eingerichtet, ein fusionier- tes Sensorsignal in Abhängigkeit von den Sensorsignalen der der jeweiligen ersten Recheneinheit zugeordneten Sensoren auszugeben . Hierdurch werden die Granularität und damit die Modularität der vorliegenden Vorrichtung verbessert.
Bei einer weiteren Ausführungsform ist der jeweilige Sensor zur Ausgabe des jeweilige Sensorsignals und der zugehörigen formalisierten Beschreibung des Sensorsignals eingerichtet.
Bei dieser Ausführungsform kann der jeweilige Sensor die zugeordnete formalisierte Beschreibung direkt ausgeben. Alternativen hierzu liegen in solchen Ausführungsformen, in wel- chen die formalisierte Beschreibung auf einem anderen Weg der ersten Recheneinheit bereitgestellt wird. Beispiele für solche andere Wege umfassen die Verwendung eines USB-Sticks oder eine von dem Internet herunterladbare Datei, welche die erste Recheneinheit nutzen kann. Der USB-Stick ist beispielsweise mit einem
Engineering-System koppelbar, über welches die Inhalte des USB-Sticks dann an die erste Recheneinheit übertragen werden können . Bei einer weiteren Ausführungsform sind die formalisierten
Beschreibungen zueinander kompatibel. Vorteilhafterweise können hierbei die einzelnen formalisierten Beschreibungen auch ineinander umgerechnet werden. Die jeweilige Einheit, zum Beispiel Recheneinheit oder Steuerungseinheit, kann hardwaretechnisch und/oder auch softwaretechnisch implementiert sein. Bei einer hardwaretechnischen Implementierung kann die jeweilige Einheit als Vorrichtung oder als Teil einer Vorrichtung, zum Beispiel als Computer oder als Mikroprozessor oder als Steuerrechner eines Fahrzeuges ausgebildet sein. Bei einer softwaretechnischen Implementierung kann die jeweilige Einheit als Computerprogrammpro- dukt , als eine Funktion, als eine Routine, als Teil eines
Programmcodes oder als ausführbares Objekt ausgebildet sein.
Ferner wird ein Fahrerassistenzsystem für ein Fahrzeug vorgeschlagen, welches eine wie oben beschriebene Vorrichtung auf- weist.
Des Weiteren wird ein Fahrzeug vorgeschlagen, welches eine wie oben beschriebene Vorrichtung für ein Fahrerassistenzsystem eines Fahrzeuges aufweist.
Weiter wird ein Verfahren zum Betreiben eines Fahrerassistenzsystems für ein Fahrzeug mit einer Anzahl von Fahrerassistenzapplikationen vorgeschlagen. Das Verfahren hat die folgenden Schritte : In einem ersten Schritt wird eine Mehrzahl von Sensorsignalen von einer Mehrzahl von Sensoren empfangen, wobei einem jeden der Sensorsignale eine zugehörige formalisierte Beschreibung des Sensorsignals zugeordnet ist. In einem zweiten Schritt werden die von den Sensoren empfangenen Sensorsignale basierend auf den zugehörigen formalisierten Beschreibungen zur Ausgabe eines fusionierten Sensorsignals fusioniert. In einem dritten Schritt wird ein Systemmodell in Abhängigkeit von dem ausgegebenen fusionierten Sensorsignal berechnet .
In einem vierten Schritt wird zumindest eine der Fahrerassis- tenzapplikationen basierend auf dem berechneten Systemmodell gesteuert . Weiterhin wird ein Computerprogrammprodukt vorgeschlagen, welches auf einer programmgesteuerten Einrichtung die Durchführung des wie oben erläuterten Verfahrens veranlasst. Ein Computerprogrammprodukt wie ein Computerprogramm-Mittel kann beispielsweise als Speichermedium, wie Speicherkarte, USB-Stick, CD-ROM, DVD oder auch in Form einer
herunterladbaren Datei von einem Server in einem Netzwerk bereitgestellt oder geliefert werden. Dies kann zum Beispiel in einem drahtlosen Kommunikationsnetzwerk durch die Übertragung einer entsprechenden Datei mit dem Computerprogrammprodukt oder dem Computerprogramm-Mittel erfolgen.
Außerdem wird ein Datenträger mit einem gespeicherten Compu- terprogramm mit Befehlen vorgeschlagen, welche die Durchführung des wie oben erläuterten Verfahrens auf einer programmgesteuerten Einrichtung veranlasst.
Die oben beschriebenen Eigenschaften, Merkmale und Vorteile dieser Erfindung sowie die Art und Weise, wie diese erreicht werden, werden klarer und deutlicher verständlich im Zusammenhang mit der folgenden Beschreibung der Ausführungsbei - spiele, die im Zusammenhang mit den Zeichnungen näher erläutert werden. Dabei zeigen:
Fig. 1 ein schematisches Blockschaltbild eines ersten Ausführungsbeispiels einer Vorrichtung für ein Fahrerassistenzsystem;
Fig. 2 eine schematische Ansicht eines Beispiels einer
formalisierten Beschreibung eines ersten Sensorsignals ; Fig. 3 eine schematische Ansicht eines Beispiels einer
formalisierten Beschreibung eines zweiten Sensor- Signals ; Fig. 4 ein schematisches Blockschaltbild eines zweiten
Ausführungsbeispiels einer Vorrichtung für ein Fahrerassistenzsystem;
Fig. 5 ein schematisches Blockschaltbild eines Ausführungsbeispiels eines Fahrerassistenzsystems; und
Fig. 6 ein Ablaufdiagramm eines Ausführungsbeispiels eines
Verfahrens zum Betreiben eines Fahrerassistenzsys - tems .
In den Figuren sind gleiche oder funktionsgleiche Elemente mit denselben Bezugszeichen versehen worden, sofern nichts anderes angegeben ist.
In Fig. 1 ist ein schematisches Blockschaltbild eines ersten Ausführungsbeispiels einer Vorrichtung 100 für ein Fahrerassistenzsystem 300 eines Fahrzeuges 200 dargestellt. Die Vorrichtung 100 weist eine Mehrzahl von Sensoren 101,
102, eine erste Recheneinheit 110, eine zweite Recheneinheit 120 sowie eine Steuerungseinheit 130 auf.
Ohne Einschränkung der Allgemeinheit sind in Fig. 1 zwei Sen- soren 101, 102, insbesondere unterschiedliche Sensoren 101, 102, gezeigt.
Der jeweilige Sensor 101, 102 ist dazu eingerichtet, ein Sensorsignal Sl, S2 auszugeben. Einem jeden der Sensorsignale Sl, S2 ist eine zugehörige formalisierte Beschreibung Bl, B2 des Sensorsignals Sl, S2 zugeordnet. So ist beispielsweise dem Sensorsignal Sl die formalisierte Beschreibung Bl zugeordnet. Demgegenüber ist dem Sensorsignal S2 die formalisierte Beschreibung S2 zugeordnet. Die formalisierten Beschrei- bungen Bl, B2 der Sensorsignale Sl, S2 sind beispielsweise als Metadaten eines vorbestimmten Formats ausgebildet. Die formalisierten Beschreibungen Bl, B2 sind derartige Metada- ten, dass sie von der zu verarbeitenden Recheneinheit 110 verarbeitet werden können.
Insbesondere sind die formalisierten Beschreibungen Bl, B2 als probabilistische Beschreibungen ausgebildet und umfassen beispielsweise die Varianz des Sensorsignals Sl, S2 und die Wahrscheinlichkeitsdichtefunktion des Sensorsignals Sl, S2. Hierzu zeigen die Fig. 2 und 3 eine schematische Ansicht eines Beispiels einer formalisierten Beschreibung Bl des ersten Signals Sl bzw. der formalisierten Beschreibung B2 des zweiten Sensorsignals B2.
Hierbei zeigt Fig. 2, dass die formalisierte Beschreibung Bl die Varianz VI des Sensorsignals Sl, die Wahrscheinlichkeits- dichtefunktion Wl des Sensorsignals Sl, eine Angabe der physikalischen Einheit PI des Sensorsignals Sl, ein Sensormodell ME1 der physikalischen Eigenschaften des Sensors 101, eine Zeitinformation Tl zur Angabe des Zeitpunkts des Erfassens des Sensorsignals Sl und eine Angabe der verwendeten Uhr Ul bei dem Erfassen des Zeitpunktes umfasst . Fig. 3 zeigt, dass die formalisierte Beschreibung B2 des zweiten Sensorsignals S2 analog aufgebaut sein kann. Die formalisierten Beschreibungen Bl und B2 können auch unterschiedlich aufgebaut sein. Vorzugsweise kann der jeweilige Sensor 101, 102 dazu eingerichtet sein, neben dem Sensorsignal Sl auch die zugehörige formalisierte Beschreibung Bl, B2 auszugeben. Eine Alternative zur Ausgabe der formalisierten Beschreibung Bl, B2 durch den jeweiligen Sensor 101, 102 liegt darin, dass die formali- sierten Beschreibungen Bl, B2 der Recheneinheit 110 über einen anderen Weg bereitgestellt werden, beispielsweise über einen USB-Stick oder auch als herunterladbare Datei von einem Server über das Internet . Der jeweilige Sensor 101, 102 kann beispielsweise als Ultraschallsensor, als Radar, als Lidar, als Raddrehungssensor, als Inertialsensor, als Beschleunigungssensor, als Drehratensensor, als Temperatursensor, als Luftfeuchtesensor, als Po- sitionssensor zur Bestimmung zumindest eines Parameters der Fahrdynamik des Fahrzeuges 200, als Sitzbelegungssensor zur Detektion einer Sitzbelegung eines Sitzes in dem Fahrzeug 200, als ein Entfernungsmesser zur Bestimmung einer Entfer- nung zwischen dem Fahrzeug 200 und einem vorbestimmten Objekt der Umgebung oder als eine Kamera ausgebildet sein.
Weiter mit Bezug zu Fig. 1 ist die erste Recheneinheit 110 dazu ausgebildet, die von den Sensoren 101, 102 ausgegebenen Sensorsignale Sl, S2 basierend auf den zugehörigen formalisierten Beschreibungen Bl, B2 zu fusionieren und abhängig davon ein fusioniertes Sensorsignal FS auszugeben. Das fusionierte Sensorsignal FS kann im einfachsten Fall analoge Eigenschaften wie die Sensorsignale Sl, S2 haben. Alternativ kann es auch eine abstraktere Darstellung eines Sensorsignals sein. Beispielsweise kann das fusionierte Sensorsignal FS auch als Teil eines Systemmodells oder als ein Systemmodell ausgebildet sein. Die formalisierten Beschreibungen Bl, B2 sind zu der Recheneinheit 110 kompatibel. D.h., die Recheneinheit 110 kann auch unterschiedliche formalisierte Beschreibungen Bl, B2 verarbeiten. Allerdings können die formalisierten Beschreibungen Bl, B2 vorzugsweise auch zueinander kompatibel und damit umrechenbar sein.
Die zweite Recheneinheit 120 empfängt eingangsseitig das fusionierte Sensorsignal FS und berechnet zumindest in Abhängigkeit davon ein Systemmodell SM. Das Systemmodell SM um- fasst beispielsweise ein Fahrzeugmodell zur Modellierung zumindest eines Teils des Fahrzeuges 200, ein Umgebungsmodell zur Modellierung zumindest eines Teils der Umgebung des Fahrzeuges 200, ein Fahrermodell zur Modellierung zumindest einer vorbestimmten Eigenschaft des Fahrers des Fahrzeuges 200 und/oder eine Anzahl von Sensormodellen ME1, ME2 zur Modellierung der Sensoren 101, 102. Das Umgebungsmodell des Fahrzeuges 200 basiert beispielsweise auf einer Gitterkarte oder auf einer Objektkarte der Umgebung des Fahrzeuges 200. Die Steuerungseinheit 130 ist dazu eingerichtet, zumindest eine der Fahrerassistenzapplikationen FA des Fahrerassistenz - Systems 300 basierend auf dem berechneten Systemmodell SM zu steuern. Die Steuerungseinheit 130 kann auch dazu eingerichtet sein, zumindest zwei der Anzahl der Fahrzeugapplikationen FA oder alle Fahrzeugapplikationen FA basierend auf dem berechneten Systemmodell SM zu steuern. Fig. 4 zeigt ein schematisches Blockschaltbild eines zweiten Ausführungsbeispiels einer Vorrichtung 100 für ein Fahrerassistenzsystem 300 eines Fahrzeuges 200.
Die Vorrichtung 100 der Fig. 4 umfasst folgende unterschied- liehe Typen von Einheiten: erste Sensoren 101-103, erste Recheneinheiten 111, 112, zweite Recheneinheiten 121, 122, Steuerungseinheiten 131-134, weitere Sensoren 141 und 142, dritte Recheneinheiten 151 und 152 und eine vierte Recheneinheit 160.
Die Sensoren 101-103 sind dazu eingerichtet, ein jeweiliges Sensorsignal S1-S3 auszugeben. Dabei ist dem jeweiligen Sensorsignal S1-S3 eine jeweilige formalisierte Beschreibung Bl- B3 zugeordnet. Die weiteren Sensoren 141-142 geben ein jewei- liges Sensorsignal S4, S5 aus. Die Sensorsignale S4, S5 sind herkömmlich und haben keine zugeordnete formalisierte Beschreibung .
Die erste Recheneinheit 111 empfängt die Sensorsignale Sl und S2 von den Sensoren 101 und 102. Dem Sensorsignal Sl ist die formalisierte Beschreibung Bl zugeordnet. Dem Sensorsignal S2 ist die formalisierte Beschreibung B2 zugeordnet. Die erste Recheneinheit 111 fusioniert die von den Sensoren 101, 102 ausgegebene Sensorsignale Sl, S2 basierend auf den zugehöri- gen formalisierten Beschreibungen Bl, B2 und gibt ausganssei- tig in Abhängigkeit davon ein fusioniertes Sensorsignal FS1 aus . Die erste Recheneinheit 112 empfängt die von den Sensoren 102, 103 ausgegebene Sensorsignale S2, S3 und fusioniert diese basierend auf den zugehörigen formalisierten Beschreibungen B2, B3. Abhängig davon gibt die erste Recheneinheit 112 ein fusioniertes Sensorsignal FS2 aus.
Jedem der weiteren Sensoren 141, 142 ist genau eine dritte Recheneinheit 151, 152 zugeordnet. Die jeweilige dritte Recheneinheit 151, 152 ist dazu eingerichtet, ein weiteres Sys- temmodell WS1, WS2 basierend auf dem von dem zugeordneten weiteren Sensor 141, 142 ausgegebenen Sensorsignal S4 , S5 zu berechnen .
Weiter ist die zweite Recheneinheit 121 dazu eingerichtet, das Systemmodell SM1 in Abhängigkeit von dem von der ersten Recheneinheit 111 ausgegebenen fusionierten Sensorsignal FS1 und in Abhängigkeit von dem von der dritten Recheneinheit 151 berechneten weiteren Systemmodel WS1 zu berechnen. Die Steuerungseinheit 131 steuert die Fahrerassistenzapplikationen FAl und FA2 basierend auf dem berechneten Systemmodell SM1.
Die zweite Recheneinheit 122 berechnet das Systemmodell SM2 in Abhängigkeit von dem von der ersten Recheneinheit 112 ausgegebenen fusionierten Sensorsignal FS2. Die Steuerungseinheit 132 steuert die Fahrerassistenzapplikationen FA3 und FA4 basierend auf dem berechneten Systemmodell SM2. Die vierte Recheneinheit 160 ist dazu eingerichtet, das Systemmodell SM3 basierend auf den Systemmodellen SM1 und SM2 zu berechnen. Die Steuerungseinheit 134 ist dann dazu eingerichtet, die Fahrerassistenzapplikation FA6 basierend auf dem berechneten Systemmodell SM3 zu steuern.
Die dritte Recheneinheit 152 berechnet ein weiteres Systemmodell WS2 in Abhängigkeit des Sensorsignals S5 von dem weiteren Sensor 142. Die Steuerungseinheit 133 steuert die Fahrer- assistenzapplikation F5 basierend auf dem weiteren Systemmodell WS2.
Fig. 5 zeigt ein schematisches Blockschaltbild eines Ausfüh- rungsbeispiels eines Fahrerassistenzsystems 300 für ein Fahrzeug 200. Das Fahrerassistenzsystem 300 weist eine Vorrichtung 100 auf. Die Vorrichtung 100 ist beispielsweise gemäß dem ersten Ausführungsbeispiel der Fig. 1 oder gemäß dem zweiten Ausführungsbeispiel der Fig. 4 ausgebildet.
In Fig. 6 ist ein Ablaufdiagramm eines Ausführungsbeispiels eines Verfahrens zum Betreiben eines Fahrerassistenzsystems 300 für ein Fahrzeug 200 mit einer Anzahl von Fahrerassistenzapplikationen FA dargestellt.
In Schritt 601 wird eine Mehrzahl von Sensorsignalen Sl, S2 von einer Mehrzahl von Sensoren empfangen, wobei einem jeden der Sensorsignale Sl, S2 eine zugehörige formalisierte Beschreibung Bl, B2 des Sensorsignals Sl, S2 zugeordnet ist.
In Schritt 602 werden die von den Sensoren 101, 102 empfangenen Sensorsignale Sl, S2 basierend auf den zugehörigen formalisierten Beschreibungen Bl, B2 zur Ausgabe eines fusionierten Sensorsignals fusioniert.
In Schritt 603 wird ein Systemmodell SM in Abhängigkeit von dem ausgegebenen fusionierten Sensorsignal berechnet.
In Schritt 604 wird zumindest einer der Fahrerassistenzappli- kationen FA basierend auf dem berechneten Systemmodell gesteuert .
Obwohl die Erfindung im Detail durch das bevorzugte Ausführungsbeispiel näher illustriert und beschrieben wurde, so ist die Erfindung nicht durch die offenbarten Beispiele eingeschränkt und andere Variationen können vom Fachmann hieraus abgeleitet werden, ohne den Schutzumfang der Erfindung zu verlassen .

Claims

Patentansprüche
1. Vorrichtung (100) für ein Fahrerassistenzsystem (300) eines Fahrzeuges (200) mit einer Anzahl von Fahrerassistenz - applikationen ( FA, FA1 - FA6 ) , mit:
einer Mehrzahl von Sensoren (101, 102, 103), wobei der jeweilige Sensor (101, 102, 103) zur Ausgabe eines Sensorsignals (Sl, S2, S3 ) eingerichtet ist, wobei einem jeden der Sensorsignale (Sl, S2, S3) eine zugehörige formalisierte Be- Schreibung (Bl, B2) des Sensorsignals (Sl, S2, S3) zugeordnet ist ,
einer ersten Recheneinheit (110, 111, 112), welche dazu eingerichtet ist, die von den Sensoren (101, 102, 103) ausgegebenen Sensorsignale (Sl, S2, S3) basierend auf den zugehö- rigen formalisierten Beschreibungen (Bl, B2) zu fusionieren und abhängig davon ein fusioniertes Sensorsignal (FS, FS1, FS2) auszugeben,
einer zweiten Recheneinheit (120, 121, 122), welche dazu eingerichtet ist, ein Systemmodell (SM, SM1, SM2) zumindest in Abhängigkeit von dem ausgegebenen fusionierten Sensorsignal (FS, FS1, FS2) zu berechnen, und
eine Steuerungseinheit (130, 131, 132), welche dazu eingerichtet ist, zumindest eine der Fahrerassistenzapplikationen (FA,FA1-FA6) basierend auf dem berechneten Systemmodell (SM) zu steuern.
2. Vorrichtung nach Anspruch 1,
dadurch gekennzeichnet,
dass die formalisierten Beschreibungen (Bl, B2) der Sensor- Signale (Sl, S2, S3) als Metadaten eines vorbestimmten Formats ausgebildet sind.
3. Vorrichtung nach Anspruch 1 oder 2,
dadurch gekennzeichnet,
dass die formalisierten Beschreibungen (Bl, B2) als
probabilistische Beschreibungen ausgebildet sind.
4. Vorrichtung nach Anspruch 3, dadurch gekennzeichnet,
dass die jeweilige probabilistische Beschreibung (Bl, B2) die Varianz des Sensorsignals (Sl, S2, S3) und/oder die Wahrscheinlichkeitsdichtefunktion des Sensorsignals (Sl, S2, S3) umfasst.
5. Vorrichtung nach einem der Ansprüche 1 bis 4,
dadurch gekennzeichnet,
dass die formalisierten Beschreibungen (Bl, B2) jeweils die Varianz (VI, V2) des Sensorsignals (Sl, S2), die Wahrscheinlichkeitsdichtefunktion (Wl, W2) des Sensorsignals (Sl, S2), eine Angabe der physikalischen Einheit (PI, P2) des Sensorsignals (Sl, S2) , ein Sensormodell (ME1, ME2) der physikalischen Eigenschaften des Sensors (101, 102), eine Zeitinforma- tion (Tl, T2) zur Angabe des Zeitpunktes des Erfassens des Sensorsignals (Sl, S2) und/oder eine Angabe der verwendeten Uhr (Ul, U2) bei dem Erfassen des Zeitpunktes umfasst.
6. Vorrichtung nach einem der Ansprüche 1 bis 5,
dadurch gekennzeichnet,
dass der jeweilige Sensor (101, 102, 103) dazu eingerichtet ist, einen Zustand des Fahrzeuges (200) , zumindest einen Teil der Umgebung des Fahrzeuges (200) und/oder einen Zustand des Fahrers des Fahrzeuges (200) zu erfassen.
7. Vorrichtung nach einem der Ansprüche 1 bis 6,
dadurch gekennzeichnet,
dass das Systemmodell (SM, SM1, SM2) ein Fahrzeugmodell zur Modellierung zumindest eines Teils des Fahrzeuges (200) , ein Umgebungsmodell zur Modellierung zumindest eines Teils der Umgebung des Fahrzeuges (200) , insbesondere basierend auf einer Gitterkarte und/oder einer Objektkarte, ein Fahrermodell zur Modellierung zumindest einer vorbestimmten Eigenschaft des Fahrers des Fahrzeuges (200) und/oder eine Anzahl von Sensormodellen (ME1, ME2) zur Modellierung einer Anzahl der Sensoren (101, 102, 103) umfasst.
8. Vorrichtung nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet,
dass die Mehrzahl der Sensoren (101, 102, 103) zumindest einen Ultraschallsensor, ein Radar, ein Lidar, einen Raddrehungssensor, einen Inertialsensor, einen Beschleunigungssen- sor, einen Drehratensensor, einen Temperatursensor, einen Luftfeuchtesensor, einen Positionssensor zur Bestimmung zumindest eines Parameters der Fahrdynamik des Fahrzeuges, einen Sitzbelegungssensor, einen Entfernungssensor und/oder zumindest eine Kamera umfasst.
9. Vorrichtung nach einem der Ansprüche 1 bis 8,
dadurch gekennzeichnet,
dass die Steuerungseinheit (130, 131, 132) dazu eingerichtet ist, zumindest zwei der Anzahl der Fahrzeugapplikationen (FA1, FA2 ) , vorzugsweise alle Fahrzeugapplikationen, basierend auf dem berechneten Systemmodell (SM, SM1, SM2) zu steuern .
10. Vorrichtung nach einem der Ansprüche 1 bis 9,
gekennzeichnet durch
eine Anzahl weiterer Sensoren (141, 142) zum Ausgeben von Sensorsignalen (S4, S5), wobei einem jeden der Anzahl der weiteren Sensoren (141, 142) genau eine dritte Recheneinheit (151, 152) zugeordnet ist, welche dazu eingerichtet ist, ein weiteres Systemmodell (WS1, WS2) basierend auf dem von dem zugeordneten weiteren Sensor (141, 142) ausgegebenen Sensorsignal (S4, S5) zu berechnen.
11. Vorrichtung nach Anspruch 10,
dadurch gekennzeichnet,
dass die zweite Recheneinheit (121) dazu eingerichtet ist, das Systemmodell (SM1) in Abhängigkeit von dem von der ersten Recheneinheit (111) ausgegebenen fusionierten Sensorsignal (FS1) und in Abhängigkeit von dem von der dritten Rechenein- heit (151) berechneten weiteren Systemmodell (WS1) zu berechnen .
12. Vorrichtung nach einem der Ansprüche 1 bis 11, gekennzeichnet durch
eine Mehrzahl von ersten Recheneinheiten (111, 112), wobei einer jeden der Mehrzahl der ersten Recheneinheiten (111, 112) eine vorbestimmbaren Anzahl der Mehrzahl von Sensoren (101, 102, 103) zugeordnet ist, wobei die jeweilige erste Recheneinheit (111, 112) dazu eingerichtet ist, ein fusionier- tes Sensorsignal (FS1, FS2) in Abhängigkeit von den Sensorsignalen (Sl, S2; S2, S3) der der jeweiligen ersten Recheneinheit (111, 112) zugeordneten Sensoren (101, 102; 102, 103) auszugeben.
13. Fahrerassistenzsystem (300) für ein Fahrzeug, welches eine Vorrichtung nach einem der Ansprüche 1 bis 12 aufweist.
14. Verfahren zum Betreiben eines Fahrerassistenzsystems (300) für ein Fahrzeug (200) mit einer Anzahl von Fahrerassistenzapplikationen (FA, FA1-FA6) , mit den Schritten:
Empfangen (601) einer Mehrzahl von Sensorsignalen (Sl, S2, S3) von einer Mehrzahl von Sensoren (101, 102, 103), wo- bei einem jeden der Sensorsignale (Sl, S2, S3) eine zugehörige formalisierte Beschreibung (Bl, B2) des Sensorsignals (Sl, S2, S3) zugeordnet ist,
Fusionieren (602) der von den Sensoren (101, 102, 103) empfangenen Sensorsignale (Sl, S2, S3) basierend auf den zu- gehörigen formalisierten Beschreibungen (Bl, B2) zur Ausgabe eines fusionierten Sensorsignals (FS, FS1, FS2) ,
Berechnen (603) eines Systemmodells (SM, SM1, SM2) zumindest in Abhängigkeit von dem ausgegebenen fusionierten Sensorsignal (FS, FS1, FS2), und
Steuern (604) zumindest einer der Fahrerassistenzapplikationen (FA, FA1-FA6) basierend auf dem berechneten Systemmodell (SM, SM1, SM2) .
15. Computerprogrammprodukt, welches auf einer programmgesteuerten Einrichtung die Durchführung eines Verfahrens nach Anspruch 14 veranlasst .
PCT/EP2014/057619 2013-05-16 2014-04-15 Vorrichtung und verfahren für ein fahrerassistenzsystem eines fahrzeuges WO2014183949A1 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
DE102013209148.6 2013-05-16
DE102013209148 2013-05-16
DE102013215032.6 2013-07-31
DE201310215032 DE102013215032A1 (de) 2013-05-16 2013-07-31 Vorrichtung und Verfahren für ein Fahrerassistenzsystem eines Fahrzeuges

Publications (1)

Publication Number Publication Date
WO2014183949A1 true WO2014183949A1 (de) 2014-11-20

Family

ID=51831426

Family Applications (5)

Application Number Title Priority Date Filing Date
PCT/EP2014/057611 WO2014183948A2 (de) 2013-05-16 2014-04-15 Sensorprodukt, simulator und verfahren zur simulation von sensormessungen, zur fusion von sensormessungen, zur validierung eines sensormodells und zum entwurf eines fahrerassistenzsystems
PCT/EP2014/057600 WO2014183945A1 (de) 2013-05-16 2014-04-15 Entwurfssystem und verfahren zum entwurf eines fahrerassistenzsystems
PCT/EP2014/057619 WO2014183949A1 (de) 2013-05-16 2014-04-15 Vorrichtung und verfahren für ein fahrerassistenzsystem eines fahrzeuges
PCT/EP2014/057585 WO2014183944A1 (de) 2013-05-16 2014-04-15 Entwurfssystem und verfahren zum entwurf eines fahrerassistenzsystems
PCT/EP2014/057867 WO2014183953A1 (de) 2013-05-16 2014-04-17 Anordnung und verfahren zur sensorfusion sowie herstellungsverfahren zur erstellung eines fusionsmodells

Family Applications Before (2)

Application Number Title Priority Date Filing Date
PCT/EP2014/057611 WO2014183948A2 (de) 2013-05-16 2014-04-15 Sensorprodukt, simulator und verfahren zur simulation von sensormessungen, zur fusion von sensormessungen, zur validierung eines sensormodells und zum entwurf eines fahrerassistenzsystems
PCT/EP2014/057600 WO2014183945A1 (de) 2013-05-16 2014-04-15 Entwurfssystem und verfahren zum entwurf eines fahrerassistenzsystems

Family Applications After (2)

Application Number Title Priority Date Filing Date
PCT/EP2014/057585 WO2014183944A1 (de) 2013-05-16 2014-04-15 Entwurfssystem und verfahren zum entwurf eines fahrerassistenzsystems
PCT/EP2014/057867 WO2014183953A1 (de) 2013-05-16 2014-04-17 Anordnung und verfahren zur sensorfusion sowie herstellungsverfahren zur erstellung eines fusionsmodells

Country Status (2)

Country Link
DE (5) DE102013212710A1 (de)
WO (5) WO2014183948A2 (de)

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102014209340A1 (de) * 2014-05-16 2015-11-19 Siemens Aktiengesellschaft Anordnung und Verfahren zur Sensorfusion
DE102015010270B4 (de) 2015-08-08 2021-10-28 Audi Ag Verfahren zum Betrieb von Fahrerassistenzsystemen in einem Kraftfahrzeug und Kraftfahrzeug
US10229363B2 (en) 2015-10-19 2019-03-12 Ford Global Technologies, Llc Probabilistic inference using weighted-integrals-and-sums-by-hashing for object tracking
DE102016202317A1 (de) * 2016-02-16 2017-08-17 Continental Teves Ag & Co. Ohg Verfahren zum steuern von fahrzeugfunktionen durch ein fahrerassistenzsystem, fahrerassistenzsystem und fahrzeug
DE102016205392A1 (de) * 2016-03-31 2017-10-05 Siemens Aktiengesellschaft Verfahren und System zur Validierung eines Hinderniserkennungssystems
CN107310550B (zh) * 2016-04-27 2019-09-17 腾讯科技（深圳）有限公司 道路交通工具行驶控制方法和装置
EP3260999B1 (de) * 2016-06-24 2021-08-04 Sick Ag System zum simulieren von sensoren
US10377375B2 (en) 2016-09-29 2019-08-13 The Charles Stark Draper Laboratory, Inc. Autonomous vehicle: modular architecture
WO2018063250A1 (en) * 2016-09-29 2018-04-05 The Charles Stark Draper Laboratory, Inc. Autonomous vehicle with modular architecture
US10599150B2 (en) 2016-09-29 2020-03-24 The Charles Stark Kraper Laboratory, Inc. Autonomous vehicle: object-level fusion
US10101745B1 (en) 2017-04-26 2018-10-16 The Charles Stark Draper Laboratory, Inc. Enhancing autonomous vehicle perception with off-vehicle collected data
DE102017208692B4 (de) 2017-05-23 2023-02-02 Audi Ag Verfahren zum Bereitstellen von Trainingsdaten für eine Funktionsprüfung einer Erkennungseinrichtung sowie Datenbanksystem
DE102017116016A1 (de) * 2017-07-17 2019-01-17 Valeo Schalter Und Sensoren Gmbh Kraftfahrzeug-Sensorvorrichtung mit mehreren Sensoreinheiten und einem neuronalen Netz zum Erzeugen einer integrierten Repräsentation einer Umgebung
DE102017116017A1 (de) * 2017-07-17 2019-01-17 Valeo Schalter Und Sensoren Gmbh Kraftfahrzeug-Sensorvorrichtung mit mehreren Sensoreinheiten und mehreren neuronalen Netzen zum Erzeugen einer kombinierten Repräsentation einer Umgebung
DE102018205804A1 (de) * 2018-04-17 2019-10-17 Conti Temic Microelectronic Gmbh Steuergerätetesteinrichtung zum Testen, Absichern und Entwickeln von Funktionen
DE102018206326B4 (de) * 2018-04-24 2020-01-09 Zf Friedrichshafen Ag Verfahren zum Erweitern einer Datenbasis eines Bayesschen Netzes
DE102018123779A1 (de) * 2018-09-26 2020-03-26 HELLA GmbH & Co. KGaA Verfahren und Vorrichtung zum Verbessern einer Objekterkennung eines Radargeräts
DE102018123735A1 (de) * 2018-09-26 2020-03-26 HELLA GmbH & Co. KGaA Verfahren und Vorrichtung zum Verbessern einer Objekterkennung eines Radargeräts
CN109634426B (zh) * 2018-12-20 2020-08-14 南京钟山虚拟现实技术研究院有限公司 基于Unity3D的高自由度实验类三维虚拟仿真方法和系统
US11249184B2 (en) 2019-05-07 2022-02-15 The Charles Stark Draper Laboratory, Inc. Autonomous collision avoidance through physical layer tracking
DE102019210448A1 (de) * 2019-07-16 2021-01-21 Audi Ag Verfahren zur Ermittlung einer Verbauposition eines umfeldüberwachenden Umfeldsensors eines Kraftfahrzeugs, Recheneinrichtung, Computerprogramm und elektronisch lesbarer Datenträger
DE102019124504A1 (de) * 2019-09-12 2021-04-01 Bayerische Motoren Werke Aktiengesellschaft Verfahren und Vorrichtung zur Simulation und Bewertung eines Sensorsystems für ein Fahrzeug sowie Verfahren und Vorrichtung zum Entwurf eines Sensorsystems zur Umfelddetektion für ein Fahrzeug
DE102020130748A1 (de) 2020-11-20 2022-05-25 Bayerische Motoren Werke Aktiengesellschaft Verfahren, System sowie ein Computerprogramm zum Erzeugen einer virtuellen Umgebung eines Fahrzeugs
DE102020215657A1 (de) 2020-12-10 2022-06-15 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und System zum Testen eines Steuergeräts eines Fahrzeugs
DE102022209080A1 (de) 2022-09-01 2024-03-07 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Kalibrieren eines Sensors, Recheneinheit und Sensorsystem

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102004052242A1 (de) 2003-11-28 2005-06-30 Denso Corp., Kariya Sensorfusionssystem und Fahrzeugsteuersystem mit diesem
WO2007017308A1 (de) 2005-08-05 2007-02-15 Robert Bosch Gmbh Verfahren zum erzeugen von umwelthypothesen für fahrerassistenzfunktionen
EP2107503A1 (de) * 2008-03-31 2009-10-07 Harman Becker Automotive Systems GmbH Verfahren und Vorrichtung zur Erzeugung eines Umgebungsmodells für Fahrzeuge in Echtzeit

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102005008714A1 (de) 2005-02-25 2006-09-07 Robert Bosch Gmbh Verfahren und System zur Bereitstellung von Sensor-Daten
US8739049B2 (en) * 2010-05-24 2014-05-27 GM Global Technology Operations LLC Vehicle system modeling systems and methods
DE102011086342A1 (de) * 2011-11-15 2013-05-16 Robert Bosch Gmbh Vorrichtung und verfahren zum betreiben eines fahrzeugs

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102004052242A1 (de) 2003-11-28 2005-06-30 Denso Corp., Kariya Sensorfusionssystem und Fahrzeugsteuersystem mit diesem
WO2007017308A1 (de) 2005-08-05 2007-02-15 Robert Bosch Gmbh Verfahren zum erzeugen von umwelthypothesen für fahrerassistenzfunktionen
EP2107503A1 (de) * 2008-03-31 2009-10-07 Harman Becker Automotive Systems GmbH Verfahren und Vorrichtung zur Erzeugung eines Umgebungsmodells für Fahrzeuge in Echtzeit

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Sensor and Data Fusion", 1 February 2009, I-TECH EDUCATION AND PUBLISHING, ISBN: 978-3-90-261352-3, article MANISH KUMAR ET AL: "Multi-Sensor Data Fusion in Presence of Uncertainty and Inconsistency in Data", pages: 225 - 244, XP055137367, DOI: 10.5772/6580 *

Also Published As

Publication number Publication date
WO2014183953A1 (de) 2014-11-20
DE102013218678A1 (de) 2014-11-20
WO2014183944A1 (de) 2014-11-20
DE102013215032A1 (de) 2014-11-20
DE102013213807A1 (de) 2014-11-20
WO2014183945A1 (de) 2014-11-20
WO2014183948A2 (de) 2014-11-20
DE102013215115A1 (de) 2014-11-20
DE102013212710A1 (de) 2014-11-20

Similar Documents

Publication Publication Date Title
WO2014183949A1 (de) Vorrichtung und verfahren für ein fahrerassistenzsystem eines fahrzeuges
DE102018124499A1 (de) Dreifache Ausfallsicherheitsredundanz für Lenksysteme
DE102017200180A1 (de) Verfahren und Testeinheit zur Bewegungsprognose von Verkehrsteilnehmern bei einer passiv betriebenen Fahrzeugfunktion
DE102020106262A1 (de) Vorrichtung und Verfahren zum Steuern eines autonomen Fahrzeugs
EP3376330A1 (de) Fehlertolerantes verfahren zur erkennung von fehlern in einem elektronischen system zur steuerung eines kontrollierten objektes
DE102016225915A1 (de) System und Verfahren zur Umfelderfassung eines Fahrzeugs
DE102015218361A1 (de) Verfahren und Testeinheit zur Verifizierung einer Fahrzeugfunktion
EP3008660A1 (de) Assistenzvorrichtung und verfahren zum unterstützen eines fahrers des fahrzeugs
DE102017218438A1 (de) Verfahren und System zum Betreiben eines Fahrzeugs
EP3945338A2 (de) Signalverarbeitungspfad, vorrichtung zur umfelderkennung und verfahren zur validierung eines automatisiert betreibbaren fahrsystems
DE102017208462A1 (de) Verfahren und Vorrichtung zum Ermitteln von Betriebsdaten für ein automatisiertes Fahrzeug
DE102018133670A1 (de) Verfahren und Vorrichtung zum Erzeugen von Steuersignalen zum Unterstützen von Insassen eines Fahrzeugs
DE102012205593A1 (de) Verfahren zum Betreiben einer Transportmaschine, Diensterbringungsrechner und Transportmaschine
Kibalama et al. AV/ADAS Safety-Critical Testing Scenario Generation from Vehicle Crash Data
DE102018209108A1 (de) Schnelle Fehleranalyse für technische Vorrichtungen mit maschinellem Lernen
DE112020000166T5 (de) Fahrzeugsteuervorrichtung und Fahrzeugsteuersystem
DE102019207518A1 (de) Risikoreduzierung im Straßenverkehr
DE102021210000A1 (de) Verfahren zum Beurteilen eines Beschleunigungsvorgangs eines Fahrzeugs, sowie Beschleunigungssystem und Fahrzeug
EP4288953A1 (de) Vorrichtung zum infrastrukturgestützten assistieren eines kraftfahrzeugs
DE102011083777A1 (de) Fahrerassistenzsystem und Verfahren zum Betreiben eines Fahrerassistenzsystems
DE102017214610B4 (de) Verfahren zum Überprüfen von zumindest einer Fahrzeugfunktion sowie Prüfvorrichtung
DE102019120778A1 (de) Verfahren und Vorrichtung zur Lokalisierung eines Fahrzeugs in einer Umgebung
EP3092536A1 (de) Verfahren und steuersystem
DE102017000693A1 (de) Vorrichtung und Verfahren zum Überwachen eines automatisierten Fahrzeugs in einem Verkehrssystem
DE102021201512A1 (de) Verfahren zur Modellierung der Umgebung eines automatisierten Fahrzeugs

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14718952

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14718952

Country of ref document: EP

Kind code of ref document: A1