WO2014183948A2 - Sensorprodukt, simulator und verfahren zur simulation von sensormessungen, zur fusion von sensormessungen, zur validierung eines sensormodells und zum entwurf eines fahrerassistenzsystems - Google Patents

Sensorprodukt, simulator und verfahren zur simulation von sensormessungen, zur fusion von sensormessungen, zur validierung eines sensormodells und zum entwurf eines fahrerassistenzsystems Download PDF

Info

Publication number
WO2014183948A2
WO2014183948A2 PCT/EP2014/057611 EP2014057611W WO2014183948A2 WO 2014183948 A2 WO2014183948 A2 WO 2014183948A2 EP 2014057611 W EP2014057611 W EP 2014057611W WO 2014183948 A2 WO2014183948 A2 WO 2014183948A2
Authority
WO
WIPO (PCT)
Prior art keywords
sensor
model
environment
real
virtual
Prior art date
Application number
PCT/EP2014/057611
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 WO2014183948A2 publication Critical patent/WO2014183948A2/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

  • model and “representation” must be defined differently.
  • data structures are referred to as models which largely largely accurately model aspects of a real environment and can therefore be used as reliable input and / or specification for algorithms for sensor fusion as well as for their training.
  • models are usually created by experts with great care and a great deal of time.
  • an environment model denotes a largely exact model of a real environment, which an expert has created, for example, by exact manual measurement of a test environment and subsequent construction of a finely resolved polygon model.
  • an environment representation denotes an internal representation of an environment, which is generated, for example, by a sensor fusion algorithm as a grid map and must necessarily remain in both its level of detail and its reliability relative to the environment model.
  • the terms environment representation and internal environment representation are synonymous with this. stand.
  • the terms measured values, sensor data and sensor signals are also used synonymously.
  • a vehicle model refers to a largely exact model of a vehicle, for example in the form of a high-resolution 3D model or blueprint.
  • a vehicle representation denotes estimated states of the vehicle, for example, whether or not there is a skid.
  • a driver model designates a largely exact model of a driver, for example in the form of an animated humanoid 3D model, which shows realistic head, eye and eyelid movements.
  • a driver's representation denotes estimated states of the driver, for example, whether he is tired or not.
  • the environment will be an environment of a vehicle.
  • the environment can also be the vehicle itself or its driver.
  • the term environment model should therefore also include the special cases vehicle model and driver model below.
  • the term environment representation if not specified more precisely, should also include the special cases of vehicle representation and driver representation in the following.
  • the algorithms described below can also use an environment model, a vehicle model and / or a driver model and an environment representation, a vehicle representation and / or a driver representation side by side, which then exist in separate modules and work together in a suitable manner.
  • the applications come from independent manufacturers and independent Developed from each other, the sensor signals used by a particular application of another application can not be used.
  • 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 environment representation and its own output, namely the application of the respective driver assistance application.
  • this block comprises three levels, namely the detection of the environment by the sensor, the interpretation of the sensor values based on an environmental representation and the reaction by the driver assistance application.
  • the conversion rule according to which the sensor data is converted into the environment representation is included 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.
  • 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. Therefore, 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.
  • probability distribution output units and a synthesis determination processing unit are necessary.
  • the document WO 2007/017308 A1 shows a method for creating environmental hypotheses for driver assistance functions.
  • an essential step in the design of driver assistance systems is the derivation of internal representations of the environment, of the vehicle and of the driver from the measured values of one or more sensors. So far, flat-rate models are formed, in which both in-depth knowledge of the physics of the sensor as well as the characteristics of the environment of use.
  • the object is to specify a sensor product and a simulator and methods for simulating sensor measurements, for merging sensor measurements, for validating a sensor model and for designing a driver assistance system, which increase the reusability of the corresponding products and methods and / or use simplify the corresponding products and processes.
  • a sensor product comprising a sensor configured to generate real measurements which generate real sensor data which at least partially represent a real environment
  • the real environment is in particular an environment of a vehicle, a vehicle with states and / or a driver of a vehicle,
  • the senor in particular a 2D or 3D camera, an ultrasonic sensor, a 2D or 3D laser scanner, a
  • 2D or 3D 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 a vehicle, a seat occupancy sensor or a distance sensor,
  • a program code or XML document which, in particular as a program code or XML document, is stored on a data medium, in particular on a memory of the sensor, on a mobile data carrier or on a mass memory of a server or in a cloud,
  • the simulator includes a computing unit which is programmed to simulate virtual measurements of at least one sensor of the sensor product in at least one environment model based on the sensor model of the sensor product.
  • the object is achieved according to the invention by a method for simulating sensor measurements
  • a computing unit reads in a sensor model from a data carrier
  • the sensor model describes and / or virtually models a hardware and / or physical properties of a sensor, wherein the sensor is set up to image a real environment by means of real measurements which generate real sensor data,
  • the real environment is in particular an environment of a vehicle, a vehicle with states or a driver of a vehicle,
  • the arithmetic unit simulates virtual measurements of the sensor in an environment model on the basis of the sensor model
  • the object is achieved according to the invention by a method for the fusion of sensor measurements
  • real measurements can be carried out in a real environment with at least one sensor product, whereby real sensor data are generated, or
  • a computing unit uses probability density functions contained in the sensor model of the sensor product to store the real sensor data or virtual sensor data as random variable and / or probability density functions in an environmental representation of a predetermined type
  • the real sensor data or virtual sensor data are generated at different times and time-fused in the environment representation
  • Sensors are generated with different positions and locally fused in the environmental representation, and / or
  • the real sensor data or virtual sensor data are generated for sensors of different types and fused in the environment representation, and
  • the predetermined type of environment representation is, in particular, a 2D or 3D grid map, an object list or a list of states.
  • the object is achieved according to the invention by a method for validating a sensor model
  • the sensor measurement simulation method simulates virtual sensor measurements in an environment model that mimics the real environment, thereby generating virtual sensor data
  • the object is achieved according to the invention by a method for designing a driver assistance system,
  • a suitable type for the environment representation 6 for the driver assistance system is selected, and in which the sensor product is integrated into the mechanical and electrical design, information relating to this in the Sensor model can be used.
  • a computer program is stored, which executes one of the methods, when it is processed in a microprocessor.
  • the computer program is executed in a microprocessor and executes one of the methods.
  • the sensor product makes it possible to model the different areas of influence for the sensor model separately from one another.
  • An overall model results from simulation of the sensor measurements based on the separately set up models - in particular the sensor model and separately from an environmental model - and a suitable simulation system.
  • the environment model contains those physical properties of the environment that are used to simulate or derive the "ground truth” of an environmental representation are needed.
  • ground truth is meant the actual truth, which underlies a measurement.
  • an object is first measured with a very high-quality sensor in order to obtain an exact measurement (“ground truth”) in advance. Thereafter, a large number of measurements are made with the final sensor, resulting in, for example, a Gaussian curve of measured values in relation to the previously determined exact measurement (“ground truth").
  • ground truth results directly from the environment model.
  • the environment model takes into account the physical properties of the environment. For a video camera, for example, these are the geometry and textures of the objects. For an ultrasonic sensor, an approximation of the geometry together with the acoustic reflection properties may suffice.
  • the sensor model can be developed independently of its specific use. This makes it possible, in particular, to use a formalized description for the respective sensor signal.
  • the division between sensor model and environment model is not common in this way, however, leads to the fact that the special knowledge of the developer of the sensor hardware and the knowledge of the application domain need not be united in one person or in a team, but recorded independently and can be used or reused. In addition to increasing reusability, this also simplifies the use of the respective products and processes.
  • the sensor models enable a modular and hybrid fusion of sensor signals from different sensors. In particular, a developer does not have to know or require the specific properties of the respective sensor since he receives the sensor model either directly from the sensor or in another way, for example via a USB stick or as a downloadable file via the Internet.
  • 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 driver assistance system is easier to control.
  • the sensor models allow separate groups of developers - for example for the sensors, the sensor simulation, the sensor fusion and the design - to work together using defined interfaces such as the sensor models.
  • 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 suitable type for the environment representation for the driver assistance system is selected, for example, from the following selected: 2D grid map, 3D grid or cube map, polygon model, object lists (list of center points of objects or rectangle envelopes with size specification) or simple lists of states.
  • the respective sensor can output the sensor model directly in order to fulfill a corresponding certification.
  • Alternatives to this are in those embodiments in which the sensor model is provided in a different way. Examples of such other ways include the use of a USB stick or a file downloadable from the Internet.
  • the USB stick can be coupled, for example, with an engineering system.
  • the sensor could provide a secure hash sum even in this case, through which the authenticity of the sensor model can be verified.
  • the arithmetic unit can be implemented in hardware and / or software technology.
  • the arithmetic unit can be designed as a device or 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.
  • the computer-readable data carrier is, for example, a memory card, a USB stick, a CD-ROM, a DVD or even a data carrier of a server, from which a file with the computer program in a network is provided or delivered. This can be done, for example, in a wireless communication network by transmitting the appropriate file.
  • the sensor model has a predetermined format and / or an interface of a predetermined format.
  • the predetermined format of the sensor model is, for example, an XML schema.
  • the description and / or virtual modeling of the hardware and / or the physical properties of the sensor is at least partially a probabilistic description with probability density functions.
  • Probabilistic descriptions are particularly suitable for fusing sensor data from different sensors with different modalities, for example radar sensor and laser sensor, to an environmental representation or a fused sensor signal.
  • the sensor model models random deviations in the real sensor data whose causes lie in a hardware of the sensor as a probability density function.
  • the sensor model models random deviations in the real sensor data whose causes lie in fluctuations in a transmission medium or different imaged materials, modeled as a probability density function.
  • the sensor is an ultrasonic distance sensor
  • a sensor product results, which additionally comprises at least one environment model which is stored on a data carrier, in particular on a memory of the sensor, on a mobile data carrier or on a mass memory of a server or in a
  • the environment model includes a description of a virtual environment that allows a simulator to simulate virtual measurements of the sensor in the virtual environment based on the sensor model
  • the virtual environment is in particular a virtual world, a driver in a vehicle cockpit or a vehicle with internal states,
  • environment model is modularly separate and independent of the sensor model
  • the environment model has a standardized format that allows the use of the environment model with different sensor models and / or simulators.
  • a sensor product results, in which the sensor is a camera and the environment model allows a simulator to simulate a camera image in which the environment model contains, in particular:
  • Turbidity of the transmission medium due to fog, rain or snow, and / or
  • the senor is an ultrasonic sensor and the environmental model allows a simulator to simulate an ultrasound image
  • the environment model contains a 3D model that approximates and simplifies a real-world model, and where the 3D model contains polygons and information about Contains reflection properties and / or surface normals of the polygons.
  • a sensor product results, which additionally comprises a modular simulator software which is stored on a data medium, in particular on a memory of the sensor, on a mobile data carrier or on a mass memory of a server or in a cloud, and which is adapted to simulate virtual measurements of the sensor in the environment model after reading the sensor model.
  • a modular simulator software which is stored on a data medium, in particular on a memory of the sensor, on a mobile data carrier or on a mass memory of a server or in a cloud, and which is adapted to simulate virtual measurements of the sensor in the environment model after reading the sensor model.
  • a sensor simulation module which is set up to read in the sensor model from the data carrier, whereby program code for the sensor simulation module is provided, or
  • the senor is simulated by the sensor simulation module
  • the sensor simulation module comprises its own hardware and / or is executed virtually in a computing unit as program code.
  • the sensor simulator module reads in a sensor model encoded in XML and then behaves like the real sensor.
  • a method results for Si simulation of sensor measurements
  • a vehicle model indicates a geometric position of the sensor relative to a vehicle and in particular a supply voltage with which the sensor is powered by the vehicle
  • the vehicle model in which the vehicle model is taken into account in the simulation.
  • the vehicle model describes where the sensors are relative to the vehicle. In the first place geometric relationships are relevant.
  • 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.
  • Beam intersections calculated with polygons in the environment model, in particular normal vectors of the polygons are considered at the intersections in the determination of an ultrasonic echo.
  • Figure 2A-2D typical ingredients of a modeling of
  • FIG. 2A shows a probability density function p hit of FIG
  • FIG. 2B actually determined distance measurements due to non-static objects in the environment
  • FIG. 2C shows a case in which no echo is measured at all
  • FIG. 3 shows a distribution resulting from FIGS. 2A-2D for the modeling of ultrasound measurements
  • FIG. 4 shows a flow diagram of a simulation of virtual
  • Figure 5 flowchart for validation of a sensor model.
  • the appropriate interpretation of the measured values of the sensors in different operating environments is a crucial prerequisite for the function of the driver assistance system. It is therefore important to understand as precisely as possible which phenomena lead to which measured values, so that conclusions can then be drawn from the measured values on the phenomena, i. so that an internal representation of the environment, the vehicle or the driver can be derived from the measured values in the vehicle or in the driver assistance system.
  • the properties of the real sensor data 4-beyond the actual measured values, ie on a meta-level-relate in particular to the scattering of the data, the occurrence of random values apart from a physical explanation that can be followed in detail, limitations of the measured values, etc.
  • a sensor data fusion 5 is basically always required. Because from the second measurement, a temporal merger must already be made. Several sensors at different locations require a local fusion of the real sensor data 4. Furthermore, different sensor types, such as ultrasound and camera, under special
  • a first embodiment relates to a sensor model for ultrasonic sensors in a driver assistance function for automatic parking.
  • This example is based on the representations in Thrun, Burgard and Fox: “Probabilistic Robotics", MIT Press 2005, chap. 6.
  • the automatic parking application needs a map of the surroundings as an internal environment representation in which a parking space can be identified and then a path can be planned into this parking space.
  • This card will usually be an occupancy grid card.
  • the plane in which the vehicle is located is usually divided into square cells of the same size, for which it is recorded whether this cell is occupied or not.
  • the edge length of a cell is usually between 0.05 m and 1.0 m, but can also be smaller or larger.
  • Such a grid map is an example of an environmental representation m of the environment.
  • the environmental representation may be static over a period of time, ie, it should model the parts of the real environment e that are Do not change over a period of time.
  • a dynamic environment representation is available, in which objects are entered with their direction of movement and speed. The measurement depends on the real environment e.
  • this is often taken synonymously with the information in the environmental representation m, ie the map of the environment.
  • FIGS. 2A to 2D show four typical ingredients (based on Thrun, Burgard and Fox: “Probabilistic Robotics", MIT Press 2005, Chapter 6).
  • the vertical axis denotes p (z ⁇
  • the horizontal axis indicates the measured distance and reaches halfway the actual distance ,
  • FIG. 2A shows the probability density function p hit of the measured value with undisturbed measurement on an object.
  • the measured value is not always equal to the actual distance He scatters depending on non-modeled and thus uncontrollable influencing variables (wind, humidity, temperature, reflection properties of the object, ).
  • This scattering is modeled by a normal distribution. It mainly reflects the physical properties of the sensor.
  • Fig. 2B actually detected distance measurements due to non-static objects in the environment (leaves passing by, pedestrians, etc.) are detected. Because multiple objects can occur simultaneously and independently of each other, and because of several objects, the next is always seen and the others are not, this probability accumulates at shorter distance values. This probability p S hort depends on the environment.
  • FIG. 2C detects the fact that many ultrasound sensor systems return a fixed maximum value in the event that no echo is measured at all. This contribution p max depends both on the hardware of the sensor and on the environment, so in reality there are two components: eg which material is not perceived by the sensor, and how often does this material occur in the environment.
  • FIG. 2D it is modeled that some sensors occasionally produce purely random measured values.
  • the cause could be anything: EMC problems in the vehicle, electromagnetic or acoustic interference from the environment or similar.
  • the expert does not necessarily investigate the lack of data and, in the absence of sufficiently stringent examination conditions, why p ran d a ls background noise remains in the model.
  • the aggregated forward sensor model that is the estimation of the measurements given the environment and the state of the vehicle in the environment, can not be made by the sensor hardware expert alone, nor by the domain expert alone. Rather, this requires expertise from both areas.
  • the corresponding competencies are brought together in the development team for the respective module, and then the models are adapted by engineering until they correspond to the sensor behavior in the targeted environment.
  • a separate and explicit modeling of the sensor properties (sensor model), the environmental properties (environment model) and the type and content of the internal environment representation is now carried out. In the design process, the required expertise on the sensor hardware is decoupled from expertise to application areas.
  • FIG. 4 shows a sensor model 10, a vehicle model 15 and an environment model 20, which enable the simulation of a virtual measurement 30, resulting in virtual sensor data 40.
  • the above-mentioned decoupling occurs in that the sensor hardware is modeled physically so extensively in the sensor model 10 that the virtual measurements 30 for the sensor can be simulated by means of a suitable simulation and due to the correspondingly detailed environment model 20.
  • the virtual sensor data 40 are subject to the same random fluctuations as the real sensor data determined in experiments (see FIG.
  • the sensor model 10 contains the physical properties of the sensor. Which these are depends of course on the respective different sensor types. In the following, the requirements for the sensor model 10 are illustrated using the example of an ultrasonic distance sensor, in which only the first incoming echo is evaluated or returned to the corresponding distance value.
  • the first type of causes of random deviations in the measured values lies in the sensor hardware. Different physical dependencies of the measured values of either unmodeled or undetectable phenomena within the sensor can underlie this. This can e.g. Fluctuations in the supply voltage, random variations in the behavior of analog circuit components such as amplifiers or filters, discretization noise due to accidental shifts of sampling instants, or similar. Such phenomena can produce pseudo-measurements that do not correspond to any external physical facts.
  • Another type of causes of random deviations may be in the transmission medium. In ultrasonic measurements, the speed of sound and thus the distance measurement depend on the air temperature, air pressure and humidity (and on the wavelength of the signal). Likewise, the wind conditions have a significant impact. These influences are often unknown. Often it is also not possible to estimate these quantities from other measurements since the phenomenon itself is random, e.g. in strongly changing wind conditions. These causes can lead to seemingly random deviations, but also to complete failure of measurements.
  • these include the transmission and reception frequency ranges or frequency responses, as well as the directional characteristic, the filter characteristics, the transmission energy, the reception sensitivity.
  • the sensor model must go far beyond the usual specifications.
  • the sensor model 10 which influence the different states of the transmission medium can have, whereby this influence is most suitably modeled as a probability density distribution over the measured value given the distance to a normalized object. Since many different influences are superimposed here, the measured value, given an object at a certain distance, is often approximately normally distributed.
  • the dimensions, the weight, the electrical connection values should be listed in the sensor model 10.
  • the environment model 20 contains the physical properties of the environment needed to simulate or derive the ground truth of the internal environment representation. For each sensor model 10 to be used, the environmental model 20 must include the corresponding physical properties of the environment be.
  • these properties include the geometry and textures (optical reflection properties) of the objects.
  • environment models 20 can be found in the areas of computer animation for movies, computer games, architectural simulation, etc. In these environment models 20, there are some examples. also simulated properties of the transmission medium (fog, rain, snow, ...) as well as properties of lighting.
  • the environmental model 20 For the simulation of an ultrasonic sensor, an approximation of the geometry together with the acoustic reflection properties is sufficient as the environmental model 20.
  • the objects in the environment model 20 are modeled so that sections with rays can be calculated or that the reflection of waves on the surfaces can be calculated.
  • the normals on the surfaces are needed.
  • the formats in which, on the one hand, the sensor model 10 and, on the other hand, the environment model 20 are set up, must match the corresponding simulators.
  • a standardization is recommended, but should leave a certain amount of space. Most promising candidate for this is also a probabilistic formulation, ie the corresponding parameters are considered as random variables.
  • the environmental model 20 basically represents the phenomena that lead to measurements.
  • the environment model 20 also represents the phenomena which lead to measurements, but which should not contribute to entries in the internal environment representation. For example, for planning a train to automatic
  • Parking may require an internal environmental representation of the static components of the environment of the vehicle.
  • dynamic objects would be leaves that pass by or pedestrians who pass by (see Figure 2B). These phenomena are best selected and described by the domain expert.
  • the resulting readings are noise related to the static components of the environment. If the internal environment representation is also to capture the dynamic objects, then the resulting measured values are no longer noise, but part of the signal.
  • the vehicle model 15 describes where the sensors are relative to the vehicle. First and foremost, the geometric relationships are relevant here. However, electrical conditions may also become relevant if e.g. According to sensor model 10 fluctuations in the supply voltage can lead to increased noise in the measured values. In this case, the supply voltage (possibly as a random variable) is part of the vehicle model 15th
  • the sensor simulation From the sensor model 10 and the environment model 20, the sensor simulation generates the same virtual sensor data 40 as the real sensors in a real use environment. would generate.
  • the simulation can process random variables as input values, and also the virtual sensor data 40 are random variables, and their probability density distribution is also simulated.
  • the simulation can be carried out at very different levels of accuracy, which usually results in a higher storage space and computing time required, the more accurate the simulation.
  • a very simple simulation is based on the fact that for a discrete, often very small number of rays emanating from the sensor, the intersections of these rays are formed with objects in the environment. For this purpose, the intersection points of rays with objects must be able to be formed in the environment model 20. This simulation neglects the reflec- tion of acoustic waves on surfaces and thus provides more measured values than the physical sensor. In another simulation method, in addition to the intersection of the rays with the surfaces, the normal vectors on the surfaces at the intersections are also taken into account. This makes it possible to judge whether a sound wave is reflected towards a receiver (this can also be the transmitter) and thus an echo is measured, or whether no echo is measured.
  • Another simulation method is much more influenced by a type of internal environment representation.
  • the volume of the internal environment representation is decomposed into grid cells and the course of the pressure distribution over time is simulated.
  • This method (depending on the resolution, ie the size of the grid cells and time intervals) simulates the echoes of very jagged obstacles, and also simulates echoes that reach several different reflectors to a receiver, so-called multi-path echoes.
  • the ultrasonic sensor emits a cone-shaped signal. An echo can be described by a circle segment within this cone whose radius corresponds to the measured distance. Accordingly, a likelihood of an obstacle is increased in all cells cut by the circle segment and lowered in all cells passed by the beam on the way there.
  • the sensor model 10 By agreeing formats, the sensor model 10, the environment model 20 and the vehicle model 15 can come from different suppliers and still fit together. Similar de facto standards already exist in the area of CAD (for example the STEP format). In the context of the embodiments, standards are needed in which the probability density functions can also be described.
  • the sensor model 10 can come from the sensor manufacturer.
  • the environment model 20 may come from a company that specializes in 3D modeling.
  • the simulator can come from a company specializing in simulation. In the future, the vehicle model will be contributed by the system integrator.
  • the models and the simulator are normally used by the system integrator, ie a car manufacturer - 1er or designer.
  • FIG. 5 shows a validation method for comparing the virtual sensor data 40 with experimentally determined real sensor data 4, with each of the involved parties sharing with their own models which other models or simulation tools underlie the comparison.
  • the sensor manufacturer manufactures a number of representative test environments, ie it actually builds them. Such a test environment is shown in FIG. 5 as a real environment 2.
  • These test environments are made according to the specifications the environment model manufacturer (and ideally by an employee of an environment model manufacturer) with respect to the physical principles of the sensor 1 and the formal requirements of the simulation tools modeled.
  • these formats should be standardized.
  • the sensor 1 measures the real sensor data 4. Irrespective of this, in a simulator on the basis of a sensor model 10 and an environment model 20, virtual measurements 30 are made which yield virtual sensor data 40.
  • the real sensor data 4 are compared with the virtual sensor data 40.
  • the result of this comparison is provided by the sensor manufacturer together with its sensor model 10. This allows the system integrator to assess the quality of the approximation of the real conditions by the sensor model 10 (with the aid of environment model 20 and simulation). This quality of the approximation is relevant in the further design process of a driver assistance system.
  • the environment model 20 need not be limited to geometry, but may also include domain knowledge regarding a likelihood of events and / or relevance of objects, such as how often people appear on a lane, or that children are more relevant than parked cars ,
  • the environment model can be modularly separated into the two aforementioned components geometry and domain knowledge and provided by different manufacturers.

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)

Description

Beschreibung
Sensorprodukt, Simulator und Verfahren zur Simulation von Sensormessungen, zur Fusion von Sensormessungen, zur Validie- rung eines Sensormodells und zum Entwurf eines Fahrerassistenzsystems
Für die folgenden Ausführungen müssen die Begriffe "Modell" und "Repräsentation" unterschiedlich definiert werden. Als Modell werden im Folgenden Datenstrukturen bezeichnet, welche Aspekte einer realen Umgebung weitgehend exakt modellieren und daher als zuverlässige Eingabe und/oder Vorgabe für Algorithmen zur Sensorfusion sowie zu deren Training verwendet werden können. Derartige Modelle werden in der Regel von Ex- perten mit großer Sorgfalt und hohem Zeitaufwand erstellt.
Abweichend davon soll der Begriff "Repräsentation" diejenigen geschätzten Annahmen und Meinungen bezeichnen, welche sich eine Software, beispielsweise ein Algorithmus zur Sensorfusi- on, selbst über eine Umgebung bilden muss. Eine derartige Repräsentation ist folglich Arbeitsergebnis eines Computerprogrammablaufs und muss gegenüber den zuvor genannten Modellen notwendigerweise sowohl in ihrem Detaillierungsgrad als auch in ihrer Zuverlässigkeit zurückbleiben.
Entsprechend bezeichnet im Folgenden ein Umgebungsmodell ein weitgehend exaktes Modell einer realen Umgebung, welches ein Experte beispielsweise durch exakte manuelle Vermessung einer Testumgebung und anschließende Konstruktion eines fein aufge- lösten Polygonmodells erstellt hat. Demgegenüber bezeichnet im Folgenden eine Umgebungsrepräsentation eine interne Repräsentation einer Umgebung, welche beispielsweise durch einen Algorithmus zur Sensorfusion als Gitterkarte erzeugt wird und notwendigerweise sowohl in ihrem Detaillierungsgrad als auch in ihrer Zuverlässigkeit gegenüber dem Umgebungsmodell zurückbleiben muss. Die Begriffe Umgebungsrepräsentation und interne Umgebungsrepräsentation sind hierbei synonym zu ver- stehen. Die Begriffe Messwerte, Sensordaten und Sensorsignale werden ebenfalls synonym verwendet.
Analog hierzu bezeichnet im Folgenden ein Fahrzeugmodell ein weitgehend exaktes Modell eines Fahrzeugs, beispielsweise in Form eines hochauflösenden 3D-Modells oder Bauplans. Demgegenüber bezeichnet im Folgenden eine Fahrzeugrepräsentation geschätzte Zustände des Fahrzeugs, beispielsweise ob ein Schleudern vorliegt oder nicht.
Weiterhin bezeichnet im Folgenden ein Fahrermodell ein weitgehend exaktes Modell eines Fahrers, beispielsweise in Form eines animierten humanoiden 3D-Modells, welches realistische Kopf, Augen- und Lidbewegungen zeigt. Demgegenüber bezeichnet im Folgenden eine Fahrerrepräsentation geschätzte bzw. vermutete Zustände des Fahrers, beispielsweise ob er ermüdet ist oder nicht .
Häufig wird es sich bei der Umgebung um eine Umgebung eines Fahrzeugs handeln. Als Sonderfall kann es sich bei der Umgebung jedoch auch um das Fahrzeug selbst bzw. um dessen Fahrer handeln. Sofern nicht genauer bezeichnet, soll der Begriff Umgebungsmodell daher im Folgenden auch die Sonderfälle Fahrzeugmodell und Fahrermodell beinhalten. Ebenso soll der Be- griff Umgebungsrepräsentation, sofern nicht genauer bezeichnet, im Folgenden auch die Sonderfälle Fahrzeugrepräsentation und Fahrerrepräsentation beinhalten.
Die im Folgenden beschriebenen Algorithmen können jedoch auch ein Umgebungsmodell, ein Fahrzeugmodell und/oder ein Fahrermodell sowie eine Umgebungsrepräsentation, eine Fahrzeugrepräsentation und/oder eine Fahrerrepräsentation nebeneinander verwenden, wobei diese dann in getrennten Modulen vorliegen und in geeigneter Weise gemeinsam zusammenwirken.
In einem Fahrzeug werden heutzutage mehrere Fahrerassistenzapplikationen oder Applikationen integriert. Da die Applikationen von unabhängigen Herstellern stammen und unabhängig voneinander entwickelt werden, sind die von einer bestimmten Applikation verwendeten 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, eine eigene Umgebungsrepräsentation und eine eigene Ausgabe, nämlich die Anwendung der jeweiligen Fahrerassistenzapplikation.
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 einer Umgebungsrepräsentation und die Reaktion durch die Fahrerassistenzapplikation.
Die Übersetzung der Sensordaten in eine Umgebungsrepräsentation, welche die interne, durch die Fahrerassistenzapplikation wahrgenommene Schätzung der Umgebung darstellt, sowie die Implementierung der eigentlichen Applikation auf Grund dieser Umgebungsrepräsentation liegt herkömmlicherweise in der Hand des jeweiligen Entwicklers.
Wie dabei die Sensordaten in Bezug auf einen Typ der Umge- bungsrepräsentation (beispielsweise Gitterkarte oder Objektliste) zu interpretieren sind, bleibt dabei der Erfahrung und dem Fingerspitzengefühl des jeweiligen Entwicklers überlassen. Der jeweilige Entwickler muss die Eigenheiten der eingesetzten Sensoren und den Typ der Umgebungsrepräsentation ge- nau kennen.
Die Umrechnungsvorschrift, nach der die Sensordaten in die Umgebungsrepräsentation hinein umgerechnet werden, ist dabei herkömmlicherweise 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ück- sichtigung 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 Sensorfusionssystem. 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.
Wie bereits erläutert, ist ein wesentlicher Schritt im Entwurf von Fahrerassistenzsystemen die Herleitung von internen Repräsentationen der Umgebung, des Fahrzeugs und des Fahrers aus den Messwerten von einem oder mehreren Sensoren. Bisher werden hierzu pauschale Modelle gebildet, in welche sowohl vertiefte Kenntnisse über die Physik des Sensors als auch über die Eigenschaften der Einsatzumgebung eingehen.
Es stellt sich die Aufgabe, ein Sensorprodukt und einen Simu- lator sowie Verfahren zur Simulation von Sensormessungen, zur Fusion von Sensormessungen, zur Validierung eines Sensormodells und zum Entwurf eines Fahrerassistenzsystems anzugeben, welche eine Wiederverwendbarkeit der entsprechenden Produkte und Verfahren erhöhen und/oder einen Einsatz der entsprechen- den Produkte und Verfahren vereinfachen.
Diese Aufgabe wird erfindungsgemäß durch ein Sensorprodukt gelöst, welches einen Sensor umfasst, eingerichtet zur Erzeugung realer Messungen, welche reale Sensordaten erzeugen, die eine reale Umgebung zumindest teilweise abbilden,
wobei die reale Umgebung insbesondere eine Umgebung eines Fahrzeugs, ein Fahrzeug mit Zuständen und/oder ein Fahrer eines Fahrzeugs ist,
wobei der Sensor, insbesondere eine 2D- oder 3D-Kamera, ein Ultraschallsensor, ein 2D- oder 3D-Laserscanner, ein
2D- oder 3D-Radar, ein Lidar, ein Raddrehungssensor, ein Inertialsensor, ein Beschleunigungssensor, ein Drehratensensor, ein Temperatursensor, ein Luftfeuchtesensor, ein Positionssensor zur Bestimmung zumindest eines Parameters der Fahrdynamik eines Fahrzeuges, ein Sitzbelegungssensor oder ein Entfernungssensor ist,
gekennzeichnet durch ein Sensormodell,
welches, insbesondere als Programmcode oder XML-Dokument, auf einem Datenträger gespeichert ist, insbesondere auf einem Speicher des Sensors, auf einem mobilen Datenträger oder auf einem Massenspeicher eines Servers oder in einer Cloud,
welches eine Hardware und/oder physikalische Eigenschaften des Sensors beschreibt und/oder virtuell modelliert der- art, dass ein Simulator, welcher nicht Teil des Sensorprodukts ist, durch Einlesen des Sensormodells von dem Datenträger in die Lage versetzt wird, virtuelle Messungen des Sensors in einem Umgebungsmodell, welches nicht Teil des Sensorprodukts ist, zu simulieren, indem das Sensormodell Programmcode für den Simulator bereitstellt oder Programmcode des Simulators parametriert , und
welches von dem Umgebungsmodell, welches nicht Teil des Sensorprodukts ist, modular getrennt und unabhängig ist.
Der Simulator beinhaltet eine Recheneinheit, welche programmiert ist zur Simulation von virtuellen Messungen mindestens eines Sensors des Sensorprodukts in mindestens einem Umge- bungsmodell basierend auf dem Sensormodell des Sensorprodukts .
Weiterhin wird die Aufgabe erfindungsgemäß durch ein Verfahren zur Simulation von Sensormessungen gelöst,
- bei dem eine Recheneinheit ein Sensormodell von einem Datenträger einliest,
bei dem das Sensormodell eine Hardware und/oder physikalische Eigenschaften eines Sensors beschreibt und/oder virtuell modelliert, wobei der Sensor zur Abbildung einer re- alen Umgebung mittels realer Messungen, die reale Sensordaten erzeugen, eingerichtet ist,
wobei die reale Umgebung insbesondere eine Umgebung eines Fahrzeugs, ein Fahrzeug mit Zuständen oder ein Fahrer eines Fahrzeugs ist,
- bei dem die Recheneinheit anhand des Sensormodells virtuelle Messungen des Sensors in einem Umgebungsmodell simuliert, und
bei dem das Sensormodell von dem Umgebungsmodell modular getrennt und unabhängig ist.
Außerdem wird die Aufgabe erfindungsgemäß durch ein Verfahren zur Fusion von Sensormessungen gelöst,
bei dem
mit mindestens einem Sensorprodukt reale Messungen in einer realen Umgebung durchgeführt werden, wodurch reale Sensordaten erzeugt werden, oder
für mindestens ein Sensorprodukt virtuelle Messungen mittels der Simulator-Software nach Anspruch 10, mit- tels des Simulators nach Anspruch 11 oder 12 oder mittels des Verfahrens nach einem der Ansprüche 13 bis 15 in einem Umgebungsmodell simuliert werden, wodurch virtuelle Sensordaten erzeugt werden, und
- bei dem eine Recheneinheit Wahrscheinlichkeitsdichtefunktionen, welche in dem Sensormodell des Sensorprodukts enthalten sind, verwendet, um die realen Sensordaten oder virtuellen Sensordaten als Zufallsvariable und/oder Wahrscheinlichkeitsdichtefunktionen in einer Umgebungsreprä- sentation eines vorgegebenen Typs abzuspeichern,
bei dem
die realen Sensordaten oder virtuellen Sensordaten zu unterschiedlichen Zeitpunkten erzeugt und in der Umgebungsrepräsentation zeitlich fusioniert werden,
- die realen Sensordaten oder virtuellen Sensordaten für
Sensoren mit unterschiedlichen Positionen erzeugt und in der Umgebungsrepräsentation örtlich fusioniert werden, und/oder
die realen Sensordaten oder virtuellen Sensordaten für Sensoren unterschiedlichen Typs erzeugt und in der Umgebungsrepräsentation fusioniert werden, und
bei dem der vorgegebene Typ der Umgebungsrepräsentation insbesondere eine 2D- oder 3D-Gitterkarte, eine Objektliste oder eine Liste von Zuständen ist.
Weiterhin wird die Aufgabe erfindungsgemäß durch ein Verfahren zur Validierung eines Sensormodells gelöst,
bei dem mit dem Sensorprodukt reale Sensormessungen in einer realen Umgebung durchgeführt werden, wodurch reale Sensordaten erzeugt werden,
bei dem mit dem Verfahren zur Simulation von Sensormessungen virtuelle Sensormessungen in einem Umgebungsmodell, welches die reale Umgebung nachbildet, simuliert werden, wodurch virtuelle Sensordaten erzeugt werden,
- bei dem die realen Sensordaten mit den virtuellen Sensordaten verglichen werden, und bei dem aus dem Vergleich eine Güteinformation abgeleitet wird, welche in das Sensormodell des Sensorprodukts aufgenommen wird. Ferner wird die Aufgabe erfindungsgemäß durch ein Verfahren zum Entwurf eines Fahrerassistenzsystems gelöst,
bei dem das Sensorprodukt für den Einsatz in einem Fahrerassistenzsystem vorgesehen wird,
bei dem unter Nutzung des Verfahrens zur Simulation von Sensormessungen oder des Verfahrens zur Fusion von Sensormessungen ein geeigneter Typ für die Umgebungsrepräsentation 6 für das Fahrerassistenzsystem ausgewählt wird, und bei dem das Sensorprodukt in den mechanischen und elektrischen Entwurf integriert wird, wobei diesbezügliche Infor- mationen im Sensormodell verwendet werden.
Auf dem computerlesbaren Datenträger ist ein Computerprogramm gespeichert, welches eines der Verfahren ausführt, wenn es in einem Mikroprozessor abgearbeitet wird.
Das Computerprogramm wird in einem Mikroprozessor abgearbeitet und führt dabei eines der Verfahren aus.
Die im Folgenden genannten Vorteile müssen nicht notwendiger- weise durch die Gegenstände der unabhängigen Patentansprüche erzielt werden. Vielmehr kann es sich hierbei auch um Vorteile handeln, welche lediglich durch einzelne Ausführungsformen, Varianten oder Weiterbildungen erzielt werden. Das Sensorprodukt erlaubt es, die verschiedenen Einflussbereiche für das Sensormodell getrennt voneinander zu modellieren. Ein Gesamtmodell ergibt sich durch Simulation der Sensormessungen aufgrund der getrennt aufgestellten Modelle - insbesondere dem Sensormodell und getrennt hiervon einem Um- gebungsmodell - und eines geeigneten Simulationssystems.
Das Umgebungsmodell enthält diejenigen physikalischen Eigenschaften der Umgebung, die zur Simulation oder Herleitung der "ground truth" einer Umgebungsrepräsentation benötigt werden. Unter "ground truth" wird hierbei die tatsächliche Wahrheit verstanden, welche einer Messung zugrunde liegt. Um etwa Messvarianzen eines kostengünstigen Sensors zu ermitteln, wird zunächst ein Objekt mit einem sehr hochwertigen Sensor vermessen, um vorab eine exakte Messung ("ground truth") zu erhalten. Danach wird mit dem endgültigen Sensor eine Vielzahl von Messungen vorgenommen, wodurch sich z.B. eine Gauß- kurve von Messwerten in Relation zu der vorab ermittelten exakten Messung ("ground truth") ergibt. Bei der Simulation von Sensormessungen ergibt sich die "ground truth" unmittelbar aus dem Umgebungsmodell.
Für jede Art von Sensormodell, die verwendet werden soll, werden im Umgebungsmodell die entsprechenden physikalischen 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 Reflexionsei - genschaften ausreichen.
Indem das Umgebungsmodell aus dem Sensormodell ausgeklammert wird, kann das Sensormodell unabhängig von seiner jeweiligen spezifischen Verwendung entwickelt werden. Dies ermöglicht insbesondere einen Einsatz einer formalisierten Beschreibung für das jeweilige Sensorsignal.
Die Aufteilung zwischen Sensormodell und Umgebungsmodell ist in dieser Weise bisher nicht üblich, führt jedoch dazu, dass das spezielle Wissen der Entwickler der Sensor-Hardware und das Wissen über die Applikationsdomäne nicht in einer Person oder in einem Team vereint sein müssen, sondern unabhängig voneinander erfasst und verwendet bzw. wiederverwendet werden können. Neben der Erhöhung der Wiederverwendbarkeit wird hierdurch auch der Einsatz der jeweiligen Produkte und Verfahren vereinfacht . Durch die Sensormodelle ist eine modulare und hybride Fusionierung von Sensorsignalen unterschiedlicher Sensoren möglich. Insbesondere muss dabei ein Entwickler die spezifischen Eigenschaften des jeweiligen Sensors nicht kennen oder erfor- sehen, da er das Sensormodell 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 die strikte Kopplung zwischen Sensor und Fahrerassistenzapplikation durch das modular wiederverwendbare Sensormodell aufgebrochen ist. Folglich wird Redundanz im Gesamtsystem Fahrerassistenzsystem besser ausgenutzt.
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 Gesamtsystems Fahrerassistenzsystem einfacher zu beherrschen. Des Weiteren ermöglichen die Sensormodelle, dass getrennt arbeitende Gruppen von Entwicklern - beispielsweise für die Sensoren, die Sensorsimulation, die Sensorfusion und den Entwurf - mittels definierter Schnittstellen wie den Sensormodellen zusammenar- beiten.
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.
Bei dem Verfahren zum Entwurf eines Fahrerassistenzsystems wird der geeignete Typ für die Umgebungsrepräsentation für das Fahrerassistenzsystem beispielsweise unter folgenden aus- gewählt: 2D-Gitterkarte , 3D-Gitter- oder Würfelkarte, Polygonmodell, Objektlisten (Liste der Mittelpunkte von Objekten oder von Rechteckhüllen mit Größenangabe) oder einfache Listen von Zuständen.
Der jeweilige Sensor kann das Sensormodell direkt ausgeben, um eine entsprechende Zertifizierung zu erfüllen. Alternativen hierzu liegen in solchen Ausführungsformen, in welchen das Sensormodell auf einem anderen Weg bereitgestellt wird. Beispiele für solche andere Wege umfassen die Verwendung eines USB-Sticks oder eine von dem Internet herunterladbare Datei. Der USB-Stick ist beispielsweise mit einem Engineering- System koppelbar. Zur Zertifizierung könnte der Sensor selbst in diesem Fall eine sichere Hash-Summe bereitstellen, über welche sich die Authentizität des Sensormodells verifizieren lässt .
Die Recheneinheit kann hardwaretechnisch und/oder auch softwaretechnisch implementiert sein. Bei einer hardwaretechni - sehen Implementierung kann die Recheneinheit 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.
Bei dem computerlesbaren Datenträger handelt es sich beispielsweise um eine Speicherkarte, einen USB-Stick, eine CD- ROM, eine DVD oder auch um einen Datenträger eines Servers, von welchem eine Datei mit dem Computerprogramm in einem Netzwerk bereitgestellt oder geliefert wird. Dies kann zum Beispiel in einem drahtlosen Kommunikationsnetzwerk durch die Übertragung der entsprechenden Datei erfolgen.
Gemäß einer Ausführungsform der Erfindung weist das Sensormodell ein vorbestimmtes Format und/oder eine Schnittstelle eines vorbestimmten Formats auf. Das vorbestimmte Format des Sensormodells ist beispielsweise ein XML-Schema. In einer Weiterbildung ist die Beschreibung und/oder virtuelle Modellierung der Hardware und/oder der physikalischen Eigenschaften des Sensors zumindest teilweise eine proba- bilistische Beschreibung mit Wahrscheinlichkeitsdichtefunktionen .
Probabilistische Beschreibungen sind besonders geeignet, Sensordaten unterschiedlicher Sensoren mit unterschiedlichen Modalitäten, zum Beispiel Radarsensor und Lasersensor, auf eine Umgebungsrepräsentation oder ein fusioniertes Sensorsignal zu fusionieren.
Gemäß einer Ausführungsform modelliert das Sensormodell zufällige Abweichungen in den realen Sensordaten, deren Ursachen in einer Hardware des Sensors liegen, als Wahrschein- lichkeitsdichtefunktion .
In einer Weiterbildung modelliert das Sensormodell zufällige Abweichungen in den realen Sensordaten, deren Ursachen in Schwankungen in einem Übertragungsmedium oder unterschiedli- chen abgebildeten Materialien liegen, als Wahrscheinlichkeitsdichtefunktion modelliert.
Gemäß einer Ausführungsform ergibt sich ein Sensorprodukt, bei dem der Sensor ein Ultraschall-Entfernungssensor ist, und
bei dem das Sensormodell mehrere oder alle der folgenden physikalischen Eigenschaften des Sensors modelliert:
Sende- und Empfangsfrequenzbereiche bzw. Frequenzgänge,
Richtcharakteristik,
- Filtereigenschaften,
Sendeenergie, und
Empfangsempfindlichkeit. In einer Weiterbildung ergibt sich ein Sensorprodukt, welches zusätzlich mindestens ein Umgebungsmodell umfasst, welches auf einem Datenträger, insbesondere auf einem Speicher des Sensors, auf einem mobilen Datenträger oder auf einem Massenspeicher eines Servers oder in einer
Cloud, gespeichert ist,
wobei das Umgebungsmodell eine Beschreibung einer virtuellen Umgebung enthält, welche einem Simulator erlaubt, anhand des Sensormodells virtuelle Messungen des Sensors in der virtuellen Umgebung zu simulieren,
wobei die virtuelle Umgebung insbesondere eine virtuelle Welt, ein Fahrer in einem Fahrzeugcockpit oder ein Fahrzeug mit internen Zuständen ist,
wobei das Umgebungsmodell von dem Sensormodell modular ge- trennt und unabhängig ist, und
wobei das Umgebungsmodell ein standardisiertes Format aufweist, welches die Verwendung des Umgebungsmodells mit unterschiedlichen Sensormodellen und/oder Simulatoren erlaubt .
Gemäß einer Ausführungsform ergibt sich ein Sensorprodukt, bei dem der Sensor eine Kamera ist und das Umgebungsmodell einem Simulator erlaubt, ein Kamerabild zu simulieren, bei dem das Umgebungsmodell insbesondere enthält:
- ein 3D-Modell mit texturierten Polygonen, welches ein reales Vorbild approximiert,
Trübungen des Übertragungsmediums durch Nebel, Regen oder Schnee, und/oder
Beleuchtungsverhältnisse.
In einer Weiterbildung ergibt sich ein Sensorprodukt,
bei dem der Sensor ein Ultraschallsensor ist und das Umgebungsmodell einem Simulator erlaubt, ein Ultraschallbild zu simulieren,
- indem das Umgebungsmodell insbesondere ein 3D-Modell enthält, welches ein reales Vorbild approximiert und vereinfacht, und wobei das 3D-Modell Polygone und Angaben zu Reflexionseigenschaften und/oder Oberflächennormalen der Polygone enthält.
Gemäß einer Ausführungsform ergibt sich ein Sensorprodukt, - welches zusätzlich eine modulare Simulator-Software um- fasst, welche auf einem Datenträger, insbesondere auf einem Speicher des Sensors, auf einem mobilen Datenträger oder auf einem Massenspeicher eines Servers oder in einer Cloud, gespeichert ist, und welche zu einer Simulation von virtuellen Messungen des Sensors in dem Umgebungsmodell nach einem Einlesen des Sensormodells eingerichtet ist.
In einer Weiterbildung ergibt sich ein Simulator,
mit einem Sensor-Simulationsmodul, welches dazu eingerichtet ist, das Sensormodell von dem Datenträger einzulesen, wodurch Programmcode für das Sensor-Simulationsmodul bereitgestellt wird, oder
wodurch Programmcode des Sensor-Simulationsmoduls para- metriert wird, und
wobei der Sensor durch das Sensor-Simulationsmodul simuliert wird, und
wobei das Sensor-Simulationsmodul eine eigene Hardware um- fasst und/oder virtuell in einer Recheneinheit als Programmcode ausgeführt wird.
Das Sensor-Simulatormodul liest also beispielsweise ein in XML kodiertes Sensormodell ein und verhält sich daraufhin wie der reale Sensor.
Gemäß einer Ausführungsform ergibt sich ein Verfahren zur Si mulation von Sensormessungen,
bei dem ein Fahrzeugmodell eine geometrische Position des Sensors relativ zu einem Fahrzeug und insbesondere eine VersorgungsSpannung angibt, mit der der Sensor von dem Fahrzeug versorgt wird, und
bei dem das Fahrzeugmodell bei der Simulation berücksichtigt wird. Das Fahrzeugmodell beschreibt insbesondere, wo sich die Sensoren relativ zum Fahrzeug befinden. In erster Linie sind dabei 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.
In einer Weiterbildung ergibt sich ein Verfahren zur Simulation von Sensormessungen,
bei dem die Recheneinheit zur Simulation der virtuellen Messungen für eine Anzahl von von dem Sensor ausgehenden
Strahlen Schnittpunkte mit Polygonen im Umgebungsmodell berechnet, wobei insbesondere Normalenvektoren der Polygone an den Schnittpunkten bei der Ermittlung eines Ultraschall-Echos berücksichtigt werden.
Im Folgenden werden Ausführungsbeispiele der Erfindung anhand von Figuren näher erläutert. In den Figuren sind gleiche oder funktionsgleiche Elemente mit denselben Bezugszeichen versehen, sofern nichts anderes angegeben ist. Es zeigen:
Figur 1 einen Stand der Technik beim Aufbau einer Umgebungsrepräsentation aus Sensordaten,
Figur 2A-2D typische Ingredienzien einer Modellierung von
Ultraschallmessungen,
Figur 2A eine Wahrscheinlichkeitsdichtefunktion phit eines
Messwertes bei ungestörter Messung auf ein Ob- j ekt ,
Figur 2B tatsächlich ermittelte Entfernungsmessungen, die auf nicht statische Objekte in der Umgebung zurückzuführen sind, Figur 2C einen Fall, in dem gar kein Echo gemessen wird
Figur 2D zufällige Messwerte
Figur 3 aus den Figuren 2A-2D resultierende Verteilung für die Modellierung von Ultraschallmessungen,
Figur 4 ein Ablaufdiagramm einer Simulation virtueller
Messungen, und
Figur 5 Ablaufdiagramm zur Validierung eines Sensor modells . Bei der Entwicklung von Fahrerassistenzsystemen ist die angemessene Interpretation der Messwerte der Sensoren in verschiedenen Einsatzumgebungen eine entscheidende Voraussetzung für die Funktion des Fahrerassistenzsystems. Es kommt also darauf an, möglichst genau zu verstehen, welche Phänomene zu welchen Messwerten führen, damit dann aus den Messwerten auf die Phänomene zurückgeschlossen werden kann, d.h. damit aus den Messwerten eine im Fahrzeug bzw. im Fahrerassistenzsystem interne Repräsentation der Umgebung, des Fahrzeugs oder des Fahrers hergeleitet werden kann.
Bisher werden im Entwurf von Fahrerassistenzsystemen die Verfahren zur Fusionierung der Messwerte bzw. Sensordaten zu einer internen Repräsentation aufgrund von Erfahrungswissen und Ingenieurskunst der Entwickler aufgestellt. Die Details die- ser Verfahren hängen stark ab von den Eigenschaften der Sensordaten, d.h. davon, welche Messwerte die Sensoren erzeugen, gegeben die spezifische Sensor-Hardware und die spezifische Einsatzumgebung . Der bisherige Stand beim Aufbau einer Umgebungsrepräsentation aus Sensordaten wird grob in Figur 1 gezeigt . Ein Sensor 1 führt eine reale Messung 3 in einer realen Umgebung 2 durch und erzeugt hierbei reale Sensordaten 4. Die realen Sensorda- ten 4 bzw. ihre Eigenschaften über eine Anzahl von Anwendungen hinweg werden also experimentell ermittelt. Die Eigenschaften der realen Sensordaten 4 - über die eigentlichen Messwerte hinaus, also auf einer Meta-Ebene - betreffen dabei insbesondere die Streuung der Daten, das Vorkommen von Zufallswerten abseits einer im Detail nachvollziehbaren physikalischen Erklärung, Begrenzungen der Messwerte etc.
Für die Übersetzung der realen Sensordaten 4 in eine Umge- bungsrepräsentation 6 ist im Grunde immer eine Sensordatenfusion 5 erforderlich. Denn ab der zweiten Messung muss bereits eine zeitliche Fusion vorgenommen werden. Mehrere Sensoren an unterschiedlichen Orten erfordern eine örtliche Fusion der realen Sensordaten 4. Weiterhin müssen auch unterschiedliche Sensortypen, etwa Ultraschall und Kamera, unter besonderer
Berücksichtigung ihrer Eigenschaften durch die Sensordatenfusion 5 fusioniert werden.
Ein erstes Ausführungsbeispiel betrifft ein Sensormodell für Ultraschallsensoren in einer Fahrerassistenzfunktion zum automatischen Einparken. Dieses Beispiel ist angelehnt an die Darstellungen in Thrun, Burgard und Fox: "Probabilistic Robotics", MIT Press 2005, Kap. 6. Die Applikation zum automatischen Einparken braucht als interne Umgebungsrepräsenta- tion eine Karte der Umgebung, in der eine Parklücke identifiziert werden kann und dann eine Bahn in diese Parklücke hinein geplant werden kann. Diese Karte wird in der Regel eine Belegungsgitterkarte sein. Dazu wird die Ebene, in der sich das Fahrzeug befindet, meistens in quadratische, gleich große Zellen aufgeteilt, für die festgehalten wird, ob diese Zelle belegt ist oder nicht. Die Kantenlänge einer Zelle liegt meist zwischen 0.05 m und 1.0 m, kann aber auch kleiner oder größer sein. Eine solche Gitterkarte ist ein Beispiel für eine Umgebungsrepräsentation m der Umgebung.
Die Umgebungsrepräsentation kann beispielsweise über einen gewissen Zeitraum hinweg statisch sein, d.h. in ihr sollen die Teile der realen Umgebung e modelliert sein, die sich über eine gewisse Zeit hinweg nicht ändern. Alternativ bietet sich eine dynamische Umgebungsrepräsentation an, bei der Objekte mit ihrer Bewegungsrichtung und Geschwindigkeit eingetragen werden. Die Messung hängt ab von der realen Umgebung e. Bei der Herleitung der Umgebungsrepräsentation, z.B. nach Figur 2A-2D und Figur 3, wie auch sonst in der Literatur, wird dies gerne synonym genommen zu der Information in der Umgebungsrepräsentation m, also der Karte der Umgebung. Im Folgenden fassen wir die Modellierung der Sensormesswerte zusammen, wie sie aus der Robotik bekannt ist (Thrun, Burgard und Fox: "Probabilistic Robotics", MIT Press 2005, Kap. 6). Um die passenden Algorithmen zur Herleitung einer internen Umgebungsrepräsentation aus Sensormesswerten zu entwickeln, versucht man zu modellieren, wie wahrscheinlich eine Messung ist, wenn das Fahrzeug an einer Position xt in der Umgebung m ist, also die Wahrscheinlichkeitsdichtefunktion p(z^|xt,m). Dabei hängt diese Wahrscheinlichkeitsdichtefunktion sowohl von den Eigenschaften des jeweiligen Sensors ab, als auch von Merkmalen der realen Umgebung.
In den Figuren 2A bis 2D werden vier typische Ingredienzien gezeigt (angelehnt an Thrun, Burgard und Fox: "Probabilistic Robotics", MIT Press 2005, Kap. 6). Die vertikale Achse be- zeichnet jeweils p(z^|xt,m). Die horizontale Achse bezeichnet den gemessenen Abstand und erreicht auf halbem Weg den tatsächlichen Abstand
Figure imgf000019_0001
.
In Figur 2A ist die Wahrscheinlichkeitsdichtefunktion phit des Messwertes bei ungestörter Messung auf ein Objekt gezeigt.
Auch hier ist der Messwert nicht immer gleich dem tatsächlichen Abstand
Figure imgf000019_0002
, sondern er streut abhängig von nicht modellierten und damit auch nicht kontrollierbaren Einflussgrößen (Wind, Luftfeuchtigkeit, Temperatur, Reflexionseigenschaften des Objekts, ...) . Diese Streuung wird durch eine Normalverteilung modelliert. Sie spiegelt hauptsächlich physikalische Eigenschaften des Sensors wieder. In Figur 2B sind tatsächlich ermittelte Entfernungsmessungen erfasst, die auf nicht statische Objekte in der Umgebung zurückzuführen sind (Blätter, die vorbei wehen, Fußgänger etc.) . Weil mehrere Objekte gleichzeitig und unabhängig von- einander auftreten können, und weil von mehreren Objekten immer das nächste gesehen wird und die anderen nicht, häuft sich diese Wahrscheinlichkeit bei kürzeren Abstandswerten. Diese Wahrscheinlichkeit pShort ist von der Umgebung abhängig. In Figur 2C ist die Tatsache erfasst, dass viele Ultraschallsensorsysteme in dem Fall, dass gar kein Echo gemessen wird, einen festen Maximalwert zurückgeben. Dieser Beitrag pmax ist sowohl von der Hardware des Sensors als auch von der Umgebung abhängig, besteht in Wirklichkeit also aus zwei Be- standteilen: z.B. welches Material wird vom Sensor nicht wahrgenommen, und wie häufig kommt dieses Material in der Umgebung vor .
In Figur 2D wird schließlich modelliert, dass manche Sensoren gelegentlich rein zufällige Messwerte produzieren. Die Ursache könnte alles Mögliche sein: EMV-Probleme im Fahrzeug, elektromagnetische oder akustische Störstrahlung aus der Umgebung oder ähnliches. Der Fachmann geht dem mangels Daten und mangels hinreichend strenger Untersuchungsbedingungen nicht unbedingt nach, weshalb prand als Grundrauschen im Modell verbleibt.
Diese Komponenten werden mit nicht negativen Gewichten
zhit' zshort' zmax' zrand zu einer Mixture Distribution zusammenge- fasst (wobei die Summe der Gewichte 1 ergibt) : 1 1) = zhit ' Phit{zt \xt
Figure imgf000020_0001
zmax ' V max ist
Diese Verteilung ist gezeigt in Figur 3 (angelehnt an Thrun, Burgard und Fox: " Probabilistic Robotics", MIT Press 2005, Kap. 6) . Alternativ lassen sich die Parameter in den Beiträgen aus Figur 2A bis Figur 2D und die Gewichte auch durch ei- ne Maximum-Likelihood-Estimation aus den Messwerten ermitteln .
Es zeigt sich also deutlich, dass das aggregierte Vorwärts - Sensormodell, also die Schätzung der Messwerte, gegeben die Umgebung und den Zustand des Fahrzeugs in der Umgebung, nicht vom Sensor-Hardware-Experten allein erstellt werden kann, ebenso wenig wie vom Domänen-Experten allein. Vielmehr ist hierzu Expertise aus beiden Bereichen notwendig. In der Pra- xis werden die entsprechenden Kompetenzen im Entwicklungsteam für das jeweilige Modul zusammengeführt, und dann werden die Modelle durch Ingenieurskunst so lange angepasst, bis sie dem Sensorverhalten in der anvisierten Umgebung entsprechen. Gemäß den folgenden Ausführungsbeispielen erfolgt nun eine separate und explizite Modellierung der Sensoreigenschaften (Sensormodell) , der Umgebungseigenschaften (Umgebungsmodell) und des Typs und Inhalts der internen Umgebungsrepräsentation. Dabei wird im Entwurfsprozess die erforderliche Expertise über die Sensorhardware von der Expertise über Anwendungsbereiche entkoppelt.
Figur 4 zeigt ein Sensormodell 10, ein Fahrzeugmodell 15 und ein Umgebungsmodell 20, welche die Simulation einer virtuel- len Messung 30 ermöglichen, woraus virtuelle Sensordaten 40 resultieren. Die zuvor angesprochene Entkopplung geschieht dadurch, dass im Sensormodell 10 zum Einen die Sensorhardware so ausführlich physikalisch modelliert wird, dass mittels einer geeigneten Simulation und aufgrund des entsprechend aus- führlichen Umgebungsmodells 20 die virtuelle Messungen 30 für den Sensor simuliert werden können. Dabei wird nicht etwa ein deterministischer, also immer gleicher Messwert ermittelt, sondern die virtuellen Sensordaten 40 unterliegen den gleichen zufälligen Schwankungen wie die in Experimenten er- mittelten realen Sensordaten (vgl. Figur 1) .
Das Sensormodell 10 enthält die physikalischen Eigenschaften des Sensors. Welche das sind, hängt natürlich von den jewei- ligen Sensortypen ab. Im Folgenden werden die Anforderungen an das Sensormodell 10 am Beispiel eines Ultraschall- Entfernungssensors illustriert, bei dem nur das erste eintreffende Echo ausgewertet, bzw. der dem entsprechende Ab- standswert zurückgeliefert wird.
Die erste Art von Ursachen der zufälligen Abweichungen in den Messwerten liegt dabei in der Sensor-Hardware. Hier können unterschiedliche physikalische Abhängigkeiten der Messwerte von entweder nicht modellierten oder nicht ermittelbaren Phänomenen innerhalb des Sensors zu Grunde liegen. Dies können z.B. Schwankungen in der VersorgungsSpannung sein, zufällige Streuungen im Verhalten von analogen Schaltungsteilen wie Verstärkern oder Filtern, Diskretisierungsrauschen durch zu- fällige Verschiebungen von Abtastzeitpunkten, oder ähnliche mehr. Durch solche Phänomene können Pseudo-Messungen entstehen, die gar keinem äußeren physikalischen Sachverhalt entsprechen . Eine weitere Art von Ursachen der zufälligen Abweichungen kann im Übertragungsmedium liegen. So hängen bei Ultraschallmessungen die Schallgeschwindigkeit und damit die Entfernungsmessung ab von Lufttemperatur, Luftdruck und Luftfeuchtigkeit (sowie von der Wellenlänge des Signals) . Ebenso haben die Windverhältnisse einen wesentlichen Einfluss. Diese Einflüsse sind oft nicht bekannt. Oft ist auch nicht möglich, diese Größen aus anderen Messwerten zu schätzen, da das Phänomen selbst sich zufallsmäßig verhält, wie z.B. bei stark wechselnden Windverhältnissen. Diese Ursachen können zu scheinbar zufallsmäßigen Abweichungen, aber auch zum vollständigen Ausfall von Messungen führen.
Bei vielen Sensoren wird in dem Fall, dass gar keine Messung durchgeführt wird, dieses Ergebnis kodiert als "maximaler Ab- stand" (vgl. Figur 2C) . Dieser ist im Grunde dann ebenfalls ein "abweichender" Messwert, da diesem Wert kein Objekt in der Umgebung entspricht. Diese Arten von Ursachen für abweichende Messwerte fallen in den Kompetenzbereich der Entwickler der Sensor-Hardware und der sensornahen Signalverarbeitungssoftware. Diese Experten können die entsprechenden Eigenschaften der von ihnen entwi- ekelten Sensorhardware und Sensorsoftware am besten modellieren. Folglich werden diese Faktoren durch das Sensormodell 10 modelliert und dort beispielsweise durch Wahrscheinlichkeits - dichtefunktionen repräsentiert. Im Sensormodell 10 müssen weiterhin die informationstheoretisch wichtigen Eigenschaften aufgeführt werden. Im Falle eines Ultraschallsensors umfassen diese die Sende- und Empfangsfrequenzbereiche bzw. Frequenzgänge, wie auch die Richtcharakteristik, die Filtereigenschaften, die Sendeenergie, die Empfangsempfindlichkeit. Das Sensormodell muss zum Zweck der aussagefähigen Simulation der Signale deutlich über die bisher üblichen Angaben hinausgehen.
Weiterhin sollte im Sensormodell 10 modelliert werden, wel- chen Einfluss die unterschiedlichen Zustände des Übertragungsmediums haben können, wobei dieser Einfluss am geeignetsten als Wahrscheinlichkeitsdichteverteilung über den Messwert, gegeben den Abstand zu einem normalisierten Objekt, modelliert wird. Da sich hier viele unterschiedliche Einflüs- se überlagern, ist der Messwert, gegeben ein Objekt in einer bestimmten Entfernung, oft annähernd normalverteilt.
Ebenso sollten für die Integration in den mechanischen und elektrischen Entwurf die Abmessungen, das Gewicht, die elekt- rischen Anschlusswerte (Versorgungsspannung inkl. Toleranzbereichen, Versorgungsleistung) im Sensormodell 10 aufgeführt werden .
Diese Angaben sollten möglichst aus sich heraus unmissver- ständlich sein, also sollten bei allen physikalischen Werten auch die Einheiten und möglichen Schwankungen mit genannt sein. Vorteilhaft ist es, sie als Zufallsvariable zu model- lieren, da dafür aus der Mathematik anerkannte, aussagefähige Modelle und Algorithmen zur Verfügung stehen.
Das Umgebungsmodell 20 enthält diejenigen physikalischen Ei- genschaften der Umgebung, die zur Simulation bzw. Herleitung der "ground truth" der internen Umgebungsrepräsentation benötigt werden: Für jedes Sensormodell 10, das verwendet werden soll, müssen im Umgebungsmodell 20 die entsprechenden physikalischen Eigenschaften der Umgebung enthalten sein.
Für eine Videokamera als Sensor umfassen diese Eigenschaften die Geometrie und die Texturen (optischen Reflexionseigenschaften) der Objekte. Zahlreiche sehr weit entwickelte Beispiele für solche Umgebungsmodelle 20 finden sich in den Be- reichen Computeranimation für Filme, Computerspiele, Architektursimulation, etc. Bei diesen Umgebungsmodellen 20 werden z.T. auch Eigenschaften des Übertragungsmediums mit simuliert (Nebel, Regen, Schnee, ...) sowie Eigenschaften der Beleuchtung .
Für die Simulation eines Ultraschallsensors reicht als Umgebungsmodell 20 eine Approximation der Geometrie zusammen mit den akustischen Reflexionseigenschaften. Je nach Simulationsprinzip werden die Objekte im Umgebungsmodell 20 so model- liert, dass Schnitte mit Strahlen berechnet werden können, oder dass die Reflektion von Wellen an den Oberflächen berechnet werden kann. Dazu werden dann auch die Normalen auf den Oberflächen benötigt. Die Formate, in denen zum Einen das Sensormodell 10 und zum Anderen das Umgebungsmodell 20 aufgestellt sind, müssen zu den entsprechenden Simulatoren passen. Hierzu empfiehlt sich eine Standardisierung, die allerdings einen gewissen Freiraum lassen sollte. Aussichtsreichster Kandidat dafür ist auch hier eine probabilistische Formulierung, d.h. die entsprechenden Parameter werden als Zufallsvariable aufgefasst. Im Umgebungsmodell 20 werden grundsätzlich die Phänomene repräsentiert, die zu Messungen führen. Das ist natürlich in jedem Fall eine Approximation, da in der Regel nicht jedes Blatt eines Baumes einzeln modelliert werden kann. Hier gilt es dann, geeignete approximative Modelle zu formulieren und zu validieren, z.B. dass ein Gebüsch Ultraschallsignale in alle Richtungen reflektieren wird, die allerdings aufgrund von Dämpfung oder nicht genau passenden Flächennormalen nur mit einer gewissen Wahrscheinlichkeit als Echo aufgenommen werden.
Es werden im Umgebungsmodell 20 auch die Phänomene repräsentiert, die zu Messungen führen, die aber nicht zu Einträgen in die interne Umgebungsrepräsentation beitragen sollen. Zum Beispiel kann für die Planung einer Bahn zum automatischen
Einparken eine interne Umgebungsrepräsentation der statischen Anteile der Umgebung des Fahrzeugs erforderlich sein. Dynamische Objekte wären dagegen Blätter, die vorbeiwehen, oder Fußgänger, die vorbeigehen (vgl. Figur 2B) . Diese Phänomene kann am besten der Domänenexperte auswählen und beschreiben.
Die resultierenden Messwerte sind Rauschen in Bezug auf die statischen Anteile der Umgebung. Soll die interne Umgebungsrepräsentation auch die dynamischen Objekte erfassen, dann sind die resultierenden Messwerte nicht mehr Rauschen, son- dern Teil des Signals.
In diesem Kontext beschreibt das Fahrzeugmodell 15, wo sich die Sensoren relativ zum Fahrzeug befinden. In erster Linie sind hier die geometrischen Verhältnisse relevant. Es können aber auch elektrische Verhältnisse relevant werden, wenn z.B. laut Sensormodell 10 Schwankungen in der VersorgungsSpannung zu erhöhtem Rauschen bei den Messwerten führen können. In diesem Fall ist auch die VersorgungsSpannung (ggf. als Zufallsvariable) Teil des Fahrzeugmodells 15.
Die Sensorsimulation erstellt aus dem Sensormodell 10 und dem Umgebungsmodell 20 die gleichen virtuellen Sensordaten 40, wie sie auch die echten Sensoren in einer realen Einsatzumge- bung erzeugen würden. Die Simulation kann als Eingangswerte Zufallsvariable verarbeiten, und auch die virtuellen Sensordaten 40 sind Zufallsvariable, und ihre Wahrscheinlichkeits - dichteverteilung wird mit simuliert.
Die Simulation kann dabei auf sehr unterschiedlichen Genauigkeitsstufen erfolgen, wobei in der Regel ein umso höherer Speicherplatz- und Rechenzeitbedarf entsteht, je genauer die Simulation ist.
Eine sehr einfache Simulation beruht darauf, dass für eine diskrete, oft sehr kleine Zahl von vom Sensor ausgehenden Strahlen die Schnittpunkte dieser Strahlen mit Objekten in der Umgebung gebildet werden. Dazu müssen also im Umgebungs- modell 20 die Schnittpunkte von Strahlen mit Objekten gebildet werden können. Diese Simulation vernachlässigt die Ref- lektion von akustischen Wellen an Flächen und liefert somit mehr Messwerte als der physikalische Sensor. In einer anderen Simulationsmethode werden zusätzlich zu den Schnittpunkten der Strahlen mit den Oberflächen auch die Normalenvektoren auf den Oberflächen an den Schnittpunkte berücksichtigt. Dadurch kann man beurteilen, ob eine Schallwelle zu einem Empfänger hin reflektiert wird (dies kann auch der Sender sein) und somit ein Echo gemessen wird, oder ob kein Echo gemessen wird.
Eine weitere Simulationsmethode wird deutlich stärker von einem Typ der internen Umgebungsrepräsentation geprägt. Konkret wird hier das Volumen der internen Umgebungsrepräsentation in Gitterzellen zerlegt und der Verlauf der Druckverteilung über die Zeit simuliert. Dieses Verfahren (je nach Auflösung, d.h. Größe der Gitterzellen und Zeitintervalle) simuliert die Echos von sehr zerklüfteten Hindernissen, und simuliert auch Echos die über mehrere Reflektoren zu einem Empfänger gelangen, so genannte Multi-Path Echos. Beispielsweise sendet der Ultraschallsensor ein kegelförmiges Signal aus. Ein Echo kann durch einen Kreissegment innerhalb dieses Kegels beschrieben werden, dessen Radius der gemessenen Entfernung entspricht. Entsprechend wird eine Wahrschein- lichkeit eines Hindernisses in allen Zellen erhöht, die von dem Kreissegment geschnitten werden, und in allen Zellen erniedrigt, die auf dem Weg dorthin vom Strahl passiert wurden.
Durch die Vereinbarung von Formaten können das Sensormodell 10, das Umgebungsmodell 20 und das Fahrzeugmodell 15 von verschiedenen Lieferanten stammen und dennoch zusammenpassen. Ähnliche de facto Standards existieren bereits im Bereich CAD (z.B. das STEP Format) . Im Kontext der Ausführungsbeispiele werden Standards benötigt, in denen auch die Wahrscheinlich- keitsdichtefunktionen beschrieben werden können.
Bei der expliziten Trennung der Modellierung kann das Sensormodell 10 vom Sensorhersteller stammen. Das Umgebungsmodell 20 kann von einer Firma stammen, die sich auf die 3D Model - lierung spezialisiert hat. Der Simulator kann wiederum von einer Firma stammen, die sich auf Simulation spezialisiert hat. Das Fahrzeugmodell steuert in Zukunft der Systemintegrator bei. Verwendet werden die Modelle und der Simulator normalerweise vom Systemintegrator, also einem Automobilherstel - 1er oder -designer.
Damit auf die Aussagefähigkeit der Sensormodelle Verlass ist, sollen diese Modelle validiert werden. Figur 5 zeigt ein Validierungsverfahren, die virtuellen Sensordaten 40 mit expe- rimentell ermittelten realen Sensordaten 4 zu vergleichen, wobei jede der beteiligten Parteien mit ihren eigenen Modellen zusammen mitteilt, welche anderen Modelle bzw. Simulationstools dem Vergleich zugrunde liegen. Der Sensorhersteller z.B. stellt eine Reihe von repräsentativen Testumgebungen her, d.h. er baut sie tatsächlich auf. Eine solche Testumgebung ist in Figur 5 als reale Umgebung 2 eingezeichnet . Diese Testumgebungen werden nach den Maßgaben der Umgebungsmodellhersteller (und idealerweise von einem Mitarbeiter eines Umgebungsmodellherstellers) im Hinblick auf die physikalischen Wirkprinzipien des Sensors 1 und auf die formalen Anforderungen der Simulationstools modelliert. Hier zeigt sich dann bereits, dass diese Formate standardisiert sein sollten.
Der Sensor 1 misst in einer realen Messung 3 in der realen Umgebung 2 die realen Sensordaten 4. Unabhängig davon werden in einem Simulator anhand eines Sensormodells 10 und eines Umgebungsmodell 20 virtuelle Messungen 30 durchgeführt, die virtuelle Sensordaten 40 ergeben.
Schließlich werden die realen Sensordaten 4 mit den virtuel- len Sensordaten 40 verglichen. Das Ergebnis dieses Vergleichs stellt der Sensorhersteller zusammen mit seinem Sensormodell 10 zur Verfügung. Das erlaubt dem Systemintegrator, die Güte der Approximation der realen Verhältnisse durch das Sensormodell 10 (unter Mitwirken von Umgebungsmodell 20 und Simulati- on) zu beurteilen. Diese Güte der Approximation ist relevant bei dem weiteren Entwurfsprozess eines Fahrerassistenzsystems .
Durch die getrennte Modellierung (im Sensormodell 10) und physikalische Simulation (im Umgebungsmodell 20) lassen sich die verschiedenen Beiträge von physikalischer Sensorhardware und von Sensorsignalkonditionierung (Sensormodell 10) auf der Ebene der Systemintegration trennen von den Einflüssen aus der Einsatzumgebung (Umgebungsmodell 20) . Dabei braucht der Systemintegrator keine Expertise mehr über die Sensorhardware, da diese im Sensormodell 10 erfasst ist. Durch die Simulation des Gesamtsystems (Sensormodell 10 + Fahrzeugmodel 15 + Umgebungsmodell 20) wird so das für die gegebene Applikation relevante Vorwärtssensormodell entwickelt.
Davon unbenommen bleibt die Möglichkeit, das simulierte Vorwärtssensormodell an echten Daten zu validieren bzw. Parameter in diesem Modell zu schätzen. Das Umgebungsmodell 20 muss sich nicht auf eine Geometrie beschränken, sondern kann auch Domänenwissen bezüglich einer Wahrscheinlichkeit von Ereignissen und/oder Relevanz von Ob- jekten enthalten, beispielsweise, wie häufig Personen auf einer Fahrbahn auftauchen, oder dass Kindern eine höhere Relevanz als geparkten Autos zukommt.
Ferner kann das Umgebungsmodell modular in die beiden zuvor genannten Komponenten Geometrie und Domänenwissen aufgetrennt und von verschiedenen Herstellern bereitgestellt werden.
Die beschriebenen Ausführungsbeispiele, Ausführungsformen, Varianten und Weiterbildungen lassen sich frei miteinander kombinieren.

Claims

Patentansprüche
1. Sensorprodukt,
umfassend einen Sensor (1), eingerichtet zur Erzeugung re- aler Messungen (3), welche reale Sensordaten (4) erzeugen, die eine reale Umgebung (2) zumindest teilweise abbilden, wobei die reale Umgebung insbesondere eine Umgebung eines Fahrzeugs, ein Fahrzeug mit Zuständen und/oder ein Fahrer eines Fahrzeugs ist,
- wobei der Sensor insbesondere eine 2D- oder 3D-Kamera, ein Ultraschallsensor, ein 2D- oder 3D-Laserscanner, ein 2D- oder 3D-Radar, ein Lidar, ein Raddrehungssensor, ein Inertialsensor, ein Beschleunigungssensor, ein Drehratensensor, ein Temperatursensor, ein Luftfeuchtesensor, ein Positionssensor zur Bestimmung zumindest eines Parameters der Fahrdynamik eines Fahrzeuges, ein Sitzbelegungssensor oder ein Entfernungssensor ist,
gekennzeichnet durch ein Sensormodell (10),
welches, insbesondere als Programmcode oder XML-Dokument, auf einem Datenträger gespeichert ist, insbesondere auf einem Speicher des Sensors, auf einem mobilen Datenträger oder auf einem Massenspeicher eines Servers oder in einer Cloud,
welches eine Hardware und/oder physikalische Eigenschaften des Sensors (1) beschreibt und/oder virtuell modelliert derart, dass ein Simulator, welcher nicht Teil des Sensorprodukts ist, durch Einlesen des Sensormodells (10) von dem Datenträger in die Lage versetzt wird, virtuelle Messungen (30) des Sensors (1) in einem Umgebungsmodell (20) , welches nicht Teil des Sensorprodukts ist, zu simulieren, indem das Sensormodell (10) Programmcode für den Simulator bereitstellt oder Programmcode des Simulators paramet - riert, und
welches von dem Umgebungsmodell (20), welches nicht Teil des Sensorprodukts ist, modular getrennt und unabhängig ist . Sensorprodukt nach Anspruch 1,
bei dem das Sensormodell (10) ein vorbestimmtes Format und/oder eine Schnittstelle eines vorbestimmten Formats aufweist .
Sensorprodukt nach Anspruch 1 oder 2,
bei dem die Beschreibung und/oder virtuelle Modellierung der Hardware und/oder der physikalischen Eigenschaften des Sensors (1) zumindest teilweise eine probabilistische Beschreibung mit Wahrscheinlichkeitsdichtefunktionen ist.
Sensorprodukt nach Anspruch 3 ,
bei dem das Sensormodell (10) zufällige Abweichungen in den realen Sensordaten (4), deren Ursachen in einer Hardware des Sensors (1) liegen, als Wahrscheinlichkeitsdichtefunktion modelliert.
Sensorprodukt nach Anspruch 3 oder 4,
bei dem das Sensormodell (10) zufällige Abweichungen in den realen Sensordaten (4), deren Ursachen in Schwankungen in einem Übertragungsmedium oder unterschiedlichen abgebildeten Materialien liegen, als Wahrscheinlichkeitsdichtefunktion modelliert.
Sensorprodukt nach einem der vorangegangenen Ansprüche, bei dem der Sensor (1) ein Ultraschall -Entfernungssensor ist, und bei dem das Sensormodell (10) mehrere oder alle der folgenden physikalischen Eigenschaften des Sensors (1) modelliert :
Sende- und Empfangsfrequenzbereiche bzw. Frequenzgänge,
Richtcharakteristik,
Filtereigenschaften,
Sendeenergie, und
Empfangsempfindlichkeit; oder
bei dem der Sensor (1) eine Kamera ist, und bei dem das Sensormodell (10) mehrere oder alle der folgenden physikalischen Eigenschaften des Sensors (1) modelliert:
Auflösung, FärbSpektrum,
Brennweite, und
Blende und Verschlusszeit. 7. Sensorprodukt nach einem der vorangegangenen Ansprüche, welches zusätzlich mindestens ein Umgebungsmodell (20) um- fasst, welches auf einem Datenträger, insbesondere auf einem Speicher des Sensors, auf einem mobilen Datenträger oder auf einem Massenspeicher eines Servers oder in einer Cloud, gespeichert ist,
wobei das Umgebungsmodell (20) eine Beschreibung einer virtuellen Umgebung enthält, welche einem Simulator erlaubt, anhand des Sensormodells (10) virtuelle Messungen (30) des Sensors (1) in der virtuellen Umgebung zu simu- lieren,
wobei die virtuelle Umgebung insbesondere eine virtuelle Welt, ein Fahrer in einem Fahrzeugcockpit oder ein Fahrzeug mit internen Zuständen ist,
wobei das Umgebungsmodell (20) von dem Sensormodell (10) modular getrennt und unabhängig ist, und
wobei das Umgebungsmodell (20) ein standardisiertes Format aufweist, welches die Verwendung des Umgebungsmodells (20) mit unterschiedlichen Sensormodellen (10) und/oder Simulatoren erlaubt .
8. Sensorprodukt nach Anspruch 7,
bei dem der Sensor (1) eine Kamera ist und das Umgebungs- modell (20) einem Simulator erlaubt, ein Kamerabild zu simulieren,
- bei dem das Umgebungsmodell (20) insbesondere enthält: ein 3D-Modell mit texturierten Polygonen, welches ein reales Vorbild approximiert,
Trübungen des Übertragungsmediums durch Nebel, Regen oder Schnee, und/oder
- Beleuchtungsverhältnisse.
9. Sensorprodukt nach Anspruch 7, bei dem der Sensor (1) ein Ultraschallsensor ist und das Umgebungsmodell (20) einem Simulator erlaubt, ein Ultraschallbild zu simulieren,
indem das Umgebungsmodell insbesondere ein 3D-Modell ent- hält, welches ein reales Vorbild approximiert und vereinfacht, und wobei das 3D-Modell Polygone und Angaben zu Reflexionseigenschaften und/oder Oberflächennormalen der Polygone enthält. 10. Sensorprodukt nach einem der Ansprüche 7 bis 9,
welches zusätzlich eine modulare Simulator-Software um- fasst, welche auf einem Datenträger, insbesondere auf einem Speicher des Sensors, auf einem mobilen Datenträger oder auf einem Massenspeicher eines Servers oder in einer Cloud, gespeichert ist, und welche zu einer Simulation von virtuellen Messungen (30) des Sensors (1) in dem Umgebungsmodell (20) nach einem Einlesen des Sensormodells (10) eingerichtet ist. 11. Simulator,
mit einer Recheneinheit, welche programmiert ist zur Simulation von virtuellen Messungen (30) mindestens eines Sensors (1) eines Sensorprodukts nach einem der Ansprüche 1 bis 10 in mindestens einem Umgebungsmodell (20) basierend auf dem Sensormodell (10) des Sensorprodukts.
12. Simulator nach Anspruch 11,
mit einem Sensor-Simulationsmodul, welches dazu eingerichtet ist, das Sensormodell (10) von dem Datenträger einzu- lesen,
wodurch Programmcode für das Sensor-Simulationsmodul bereitgestellt wird, oder
wodurch Programmcode des Sensor-Simulationsmoduls para- metriert wird, und
- wobei der Sensor (1) durch das Sensor-Simulationsmodul simuliert wird, und wobei das Sensor-Simulationsmodul eine eigene Hardware um- fasst und/oder virtuell in einer Recheneinheit als Programmcode ausgeführt wird.
3. Verfahren zur Simulation von Sensormessungen,
bei dem eine Recheneinheit ein Sensormodell (10) von einem Datenträger einliest,
bei dem das Sensormodell (10) eine Hardware und/oder physikalische Eigenschaften eines Sensors (1) beschreibt und/oder virtuell modelliert, wobei der Sensor (1) zur Abbildung einer realen Umgebung (2) mittels realer Messungen (3), die reale Sensordaten (4) erzeugen, eingerichtet ist, wobei die reale Umgebung insbesondere eine Umgebung eines Fahrzeugs, ein Fahrzeug mit Zuständen oder ein Fahrer eines Fahrzeugs ist,
bei dem die Recheneinheit anhand des Sensormodells (10) virtuelle Messungen (30) des Sensors (1) in einem Umgebungsmodell (20) simuliert, und
bei dem das Sensormodell (10) von dem Umgebungsmodell (20) modular getrennt und unabhängig ist.
4. Verfahren nach Anspruch 13,
bei dem ein Fahrzeugmodell (15) eine geometrische Position des Sensors (1) relativ zu einem Fahrzeug und insbesondere eine VersorgungsSpannung angibt, mit der der Sensor (1) von dem Fahrzeug versorgt wird, und
bei dem das Fahrzeugmodell (15) bei der Simulation berücksichtigt wird.
5. Verfahren nach Anspruch 13 oder 14,
bei dem die Recheneinheit zur Simulation der virtuellen Messungen (30) für eine Anzahl von von dem Sensor (1) ausgehenden Strahlen Schnittpunkte mit Polygonen im Umgebungsmodell (20) berechnet, wobei insbesondere
Normalenvektoren der Polygone an den Schnittpunkten bei der Ermittlung eines Ultraschall-Echos berücksichtigt werden .
16. Verfahren zur Fusion von Sensormessungen, bei dem
mit mindestens einem Sensorprodukt nach einem der Ansprüche 1 bis 10 reale Messungen (3) in einer realen Umgebung (2) durchgeführt werden, wodurch reale Sensordaten (4) erzeugt werden, oder
für mindestens ein Sensorprodukt nach einem der Ansprüche 1 bis 10 virtuelle Messungen (30) mittels der Simulator-Software nach Anspruch 10, mittels des Simulators nach Anspruch 11 oder 12 oder mittels des Verfahrens nach einem der Ansprüche 13 bis 15 in einem Umgebungs- modell (20) simuliert werden, wodurch virtuelle Sensordaten (40) erzeugt werden, und
bei dem eine Recheneinheit Wahrscheinlichkeitsdichtefunk- tionen, welche in dem Sensormodell (10) des Sensorprodukts enthalten sind, verwendet, um die realen Sensordaten (4) oder virtuellen Sensordaten (40) als Zufallsvariable und/oder Wahrscheinlichkeitsdichtefunktionen in einer Umgebungsrepräsentation (6) eines vorgegebenen Typs abzu- speichern,
bei dem
die realen Sensordaten (4) oder virtuellen Sensordaten (40) zu unterschiedlichen Zeitpunkten erzeugt und in der Umgebungsrepräsentation (6) zeitlich fusioniert werden,
die realen Sensordaten (4) oder virtuellen Sensordaten (40) für Sensoren (1) mit unterschiedlichen Positionen erzeugt und in der Umgebungsrepräsentation (6) örtlich fusioniert werden, und/oder
- die realen Sensordaten (4) oder virtuellen Sensordaten
(40) für Sensoren (1) unterschiedlichen Typs erzeugt und in der Umgebungsrepräsentation (6) fusioniert werden, und
bei dem der vorgegebene Typ der Umgebungsrepräsentation (6) insbesondere eine 2D- oder 3D-Gitterkarte, eine Objektliste oder eine Liste von Zuständen ist.
17. Verfahren zur Validierung eines Sensormodells (10), bei dem mit einem Sensorprodukt nach einem der Ansprüche 1 bis 10 reale Sensormessungen (3) in einer realen Umgebung (2) durchgeführt werden, wodurch reale Sensordaten (4) erzeugt werden,
- bei dem mit dem Verfahren nach einem der Ansprüche 13 bis 15 virtuelle Sensormessungen (30) in einem Umgebungsmodell (20), welches die reale Umgebung (2) nachbildet, simuliert werden, wodurch virtuelle Sensordaten (40) erzeugt werden, bei dem die realen Sensordaten (4) mit den virtuellen Sen- sordaten (40) verglichen werden, und
bei dem aus dem Vergleich eine Güteinformation abgeleitet wird, welche in das Sensormodell (10) des Sensorprodukts nach einem der Ansprüche 1 bis 10 aufgenommen wird. 18. Verfahren zum Entwurf eines Fahrerassistenzsystems,
bei dem ein Sensorprodukt nach einem der Ansprüche 1 bis 10 für den Einsatz in einem Fahrerassistenzsystem vorgesehen wird,
bei dem unter Nutzung des Simulationsverfahrens nach einem der Ansprüche 13 bis 15 und/oder des Fusionsverfahren nach
Anspruch 16
ein geeigneter Typ für die Umgebungsrepräsentation (6) für das Fahrerassistenzsystem ausgewählt wird, und/oder geeignete Typen und/oder geeignete Positionen für Sen- soren für das Fahrerassistenzsystem ausgewählt werden, und
bei dem das Sensorprodukt in den mechanischen und elektrischen Entwurf integriert wird, wobei diesbezügliche Informationen im Sensormodell (10) verwendet werden.
19. Computerlesbarer Datenträger,
auf dem ein Computerprogramm gespeichert ist, welches das Verfahren nach einem der Ansprüche 13 bis 18 ausführt, wenn es in einem Mikroprozessor abgearbeitet wird.
20. Computerprogramm, welches in einem Mikroprozessor abgearbeitet wird und dabei das Verfahren nach einem der Ansprüche 13 bis 18 ausführt .
PCT/EP2014/057611 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 WO2014183948A2 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
DE102013209148 2013-05-16
DE102013209148.6 2013-05-16
DE201310212710 DE102013212710A1 (de) 2013-05-16 2013-06-28 Sensorprodukt, Simulator und Verfahren zur Simulation von Sensormessungen, zur Fusion von Sensormessungen, zur Validierung eines Sensormodells und zum Entwurf eines Fahrerassistenzsystems
DE102013212710.3 2013-06-28

Publications (1)

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

Family

ID=51831426

Family Applications (5)

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/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/057619 WO2014183949A1 (de) 2013-05-16 2014-04-15 Vorrichtung und verfahren für ein fahrerassistenzsystem eines fahrzeuges
PCT/EP2014/057600 WO2014183945A1 (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 (1)

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

Family Applications After (3)

Application Number Title Priority Date Filing Date
PCT/EP2014/057619 WO2014183949A1 (de) 2013-05-16 2014-04-15 Vorrichtung und verfahren für ein fahrerassistenzsystem eines fahrzeuges
PCT/EP2014/057600 WO2014183945A1 (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) WO2014183944A1 (de)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017167528A1 (de) * 2016-03-31 2017-10-05 Siemens Aktiengesellschaft Verfahren und system zur validierung eines hinderniserkennungssystems
US10229363B2 (en) 2015-10-19 2019-03-12 Ford Global Technologies, Llc Probabilistic inference using weighted-integrals-and-sums-by-hashing for object tracking
DE102022209080A1 (de) 2022-09-01 2024-03-07 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Kalibrieren eines Sensors, Recheneinheit und Sensorsystem

Families Citing this family (23)

* 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
DE102016202317A1 (de) * 2016-02-16 2017-08-17 Continental Teves Ag & Co. Ohg Verfahren zum steuern von fahrzeugfunktionen durch ein fahrerassistenzsystem, fahrerassistenzsystem und fahrzeug
CN107310550B (zh) * 2016-04-27 2019-09-17 腾讯科技（深圳）有限公司 道路交通工具行驶控制方法和装置
EP3260999B1 (de) * 2016-06-24 2021-08-04 Sick Ag System zum simulieren von sensoren
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
US10377375B2 (en) 2016-09-29 2019-08-13 The Charles Stark Draper Laboratory, Inc. Autonomous vehicle: modular architecture
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
FR3088041B1 (fr) * 2018-11-02 2020-10-16 Renault Sas Procede d’elaboration d’une consigne de pilotage d’un vehicule automobile
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

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3931879B2 (ja) 2003-11-28 2007-06-20 株式会社デンソー センサフュージョンシステム及びそれを用いた車両制御装置
DE102005008714A1 (de) 2005-02-25 2006-09-07 Robert Bosch Gmbh Verfahren und System zur Bereitstellung von Sensor-Daten
DE102005036953A1 (de) 2005-08-05 2007-02-08 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
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

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10229363B2 (en) 2015-10-19 2019-03-12 Ford Global Technologies, Llc Probabilistic inference using weighted-integrals-and-sums-by-hashing for object tracking
WO2017167528A1 (de) * 2016-03-31 2017-10-05 Siemens Aktiengesellschaft Verfahren und system zur validierung eines hinderniserkennungssystems
CN109311497A (zh) * 2016-03-31 2019-02-05 西门子移动有限公司 用于验证障碍物识别***的方法和***
US11427239B2 (en) 2016-03-31 2022-08-30 Siemens Mobility GmbH Method and system for validating an obstacle identification system
DE102022209080A1 (de) 2022-09-01 2024-03-07 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Kalibrieren eines Sensors, Recheneinheit und Sensorsystem

Also Published As

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

Similar Documents

Publication Publication Date Title
WO2014183948A2 (de) Sensorprodukt, simulator und verfahren zur simulation von sensormessungen, zur fusion von sensormessungen, zur validierung eines sensormodells und zum entwurf eines fahrerassistenzsystems
EP3438901A1 (de) Testfahrtszenario-datenbanksystem für realitätsnahe virtuelle testfahrtszenarien
EP3200428B1 (de) Computerimplementiertes verfahren zur implementierung einer v2x-anwendung
DE102018100469A1 (de) Generierten von simulierten sensordaten zum trainieren und überprüfen von erkennungsmodellen
DE102019102205A1 (de) System und verfahren zur end-to-end-validierung von autonomen fahrzeugen
DE102018121018A1 (de) Erweitern von realen sensoraufnahmen mit simuliertem sensordatenhintergrund
DE102016220670A1 (de) Verfahren und System zum Testen von Software für autonome Fahrzeuge
EP3438856A1 (de) Verfahren zum modellieren eines kraftfahrzeug-sensors in einer virtuellen testumgebung
DE102014118622A1 (de) Verfahren zum simulativen Bestimmen einer Interaktion zwischen einem Sensor eines Kraftfahrzeugs und einem virtuellen Objekt in einem virtuellen Umgebungsbereich des Kraftfahrzeugs sowie Recheneinrichtung
DE102019105337A1 (de) Ultraschallmesssystem im Fahrzeug zur Erkennung und Klassifizierung von Objekten im Umfeld des Fahrzeugs mit Hilfe eines Deep-Learning Verfahrens
DE102019215903A1 (de) Verfahren und Vorrichtung zum Erzeugen von Trainingsdaten für ein Erkennungsmodell zum Erkennen von Objekten in Sensordaten eines Sensors insbesondere eines Fahrzeugs, Verfahren zum Trainieren und Verfahren zum Ansteuern
DE102019213546A1 (de) Erzeugung synthetischer Lidarsignale
DE102011015094B4 (de) Verfahren zum simulativen Ermitteln von Messeigenschaften eines Sensors eines Kraftfahrzeugs und Rechensystem
DE102020128978A1 (de) Trainieren von tiefen neuronalen netzwerken mit synthetischen bildern
WO2019162317A1 (de) Verfahren zur erzeugung von sensordaten für sicherheitskritische automobil-steuergeräte
WO2022122339A1 (de) Verfahren und system zum testen eines steuergeräts eines fahrzeugs
DE102019130096A1 (de) Verfahren zur Ermittlung einer Radarinformation, Simulationsverfahren, Klassifizierungsverfahren, Computerprogramm und Berechnungssystem
DE102020214596A1 (de) Verfahren zum Erzeugen von Trainingsdaten für ein Erkennungsmodell zum Erkennen von Objekten in Sensordaten einer Umfeldsensorik eines Fahrzeugs, Verfahren zum Erzeugen eines solchen Erkennungsmodells und Verfahren zum Ansteuern einer Aktorik eines Fahrzeugs
DE102018207566A1 (de) System zum Durchführen von simulierten Kollisionsszenarios von einem Kraftfahrzeug mit einem nicht-motorisierten Verkehrsteilnehmer
DE102020101060B4 (de) Selbstlernendes Ultraschallmesssystem im Fahrzeug zur Erkennung und Klassifizierung von Objekten im Umfeld des Fahrzeugs mit einem Multiplanar-Reformatierer
DE102017201796A1 (de) Steuervorrichtung zum Ermitteln einer Eigenbewegung eines Kraftfahrzeugs sowie Kraftfahrzeug und Verfahren zum Bereitstellen der Steuervorrichtung
DE102014118624A1 (de) Verfahren zum simulativen Bestimmen einer Interaktion zwischen einem Sensor eines Kraftfahrzeugs und einem virtuellen Objekt in einem virtuellen Umgebungsbereich des Kraftfahrzeugs sowie Recheneinrichtung
DE102008055932A1 (de) Verfahren zur modellbasierten Simulation eines Verhaltens eines Sensors
DE102020101036B4 (de) Selbstlernendes Ultraschallmesssystem im Fahrzeug zur Erkennung und Klassifizierung von Objekten im Umfeld des Fahrzeugs mit einem Volumenrenderer
DE102021213538A1 (de) Simulation zur Validierung einer automatisierenden Fahrfunktion für ein Fahrzeug

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: 14718050

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase in:

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14718050

Country of ref document: EP

Kind code of ref document: A2