WO2014183945A1 - Entwurfssystem und verfahren zum entwurf eines fahrerassistenzsystems - Google Patents

Entwurfssystem und verfahren zum entwurf eines fahrerassistenzsystems Download PDF

Info

Publication number
WO2014183945A1
WO2014183945A1 PCT/EP2014/057600 EP2014057600W WO2014183945A1 WO 2014183945 A1 WO2014183945 A1 WO 2014183945A1 EP 2014057600 W EP2014057600 W EP 2014057600W WO 2014183945 A1 WO2014183945 A1 WO 2014183945A1
Authority
WO
WIPO (PCT)
Prior art keywords
information unit
time stamp
data
time
design system
Prior art date
Application number
PCT/EP2014/057600
Other languages
English (en)
French (fr)
Inventor
Wendelin Feiten
Michael Fiegert
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 WO2014183945A1 publication Critical patent/WO2014183945A1/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 lot of time.
  • representation is intended to denote those estimated assumptions and opinions that software, such as a sensor fusion algorithm, itself must form over an environment, such a representation being the result of a computer program flow and must be compared to the models previously mentioned necessarily remain both in their level of detail and in their reliability.
  • 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 represented by a
  • 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 environmental representation should also include the special cases of vehicle representation and driver representation below.
  • 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.
  • driver assistance systems The design process of driver assistance systems is characterized by the fact that a very broad spectrum of expert knowledge must be represented in the development team. The reason for this is that the structure and performance of a driver assistance system depend on many aspects.
  • an environment of a vehicle possibly also an internal state of the vehicle and a state of the driver are detected physically or chemically by means of sensors. From these sensor data, an appropriate environmental representations, vehicle representation and driver representation are derived. Suitable here means that one or more assistance functions or applications based on the mentioned representations can generate control signals for the vehicle and / or optical or acoustic signals for the driver which lead to a desired behavior of the vehicle or information for the driver ,
  • WO 2007017308 A1 describes an approach to initially describe the sensor data in a "sensor language", which does not contain information about the vehicle or the driver assistance function, and later translates the phenomena described in this sensor language into a "functional language” which does not address the specific sensors. In this functional language then takes place the merger. This is illustrated there using the example of a distance control torque.
  • WO 2006089941 A1 describes an information exchange module in which sensor information is collected and applications made available.
  • the design system is characterized in that
  • the design system for computer-aided processing of machine-readable semantic metadata is set up, which describes properties of the real sensor data and / or of the virtual sensor data and / or of data in the environment representation, and
  • the design system is set up for computer-aided checking and / or ensuring validity of data in the environment representation on the basis of the semantic metadata.
  • the object is further achieved according to the invention in that at least one module generates real sensor data or virtual sensor data, at least one module derived from the real sensor data or virtual sensor data computer-aided environmental representation.
  • the method is characterized in that
  • the design system processes machine-readable semantic metadata in a computer-aided manner, which describes properties of the real sensor data and / or the virtual sensor data and / or the environmental representation, and - the design system uses the semantic metadata to check and / or ensure a validity of data in the environmental representation.
  • a computer program is stored on the computer-readable medium, which executes the method when it is executed in a microprocessor.
  • the computer program is executed in a microprocessor and executes the procedure.
  • This provides for the first time a uniform, consistent and formal description of the procedures and data in the design process of driver assistance systems by means of semantic metadata.
  • This has, inter alia, the advantage that the sensors installed in the vehicle can be used in principle for all driver assistance functions to be implemented on the vehicle. Applications become available. Furthermore, the design process is significantly simplified and accelerated.
  • each module can be designed as a device or as part of a device, for example as a computer, as a microprocessor or as a control computer of a vehicle.
  • the respective unit may be designed as a computer program product, as a function, as a routine, as part of a program code or 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.
  • each information unit has a header containing at least some of the following semantic metadata describing characteristics of the payload: a timestamp indicating at what time the payload is or was valid,
  • an indication of origin which denotes a sensor from which the payload data was generated
  • the header contains all of the aforementioned semantic metadata.
  • a design system results, in which a time format of the time stamp is stored in the header or in the time stamp, and
  • a design system results, in which the microprocessor is programmed to check for all information units, whether the time stamp is present and the time format of the time stamp is known, and
  • microprocessor is programmed
  • microprocessor is programmed to check whether the time format of the time stamp of the first information unit matches the time format of the time stamp of the second information unit, and otherwise for converting the time stamp of the first information unit into the time format of the time stamp of the second information unit,
  • microprocessor is programmed to check whether the clock of the time stamp of the first information unit is identical to the clock of the time stamp of the second information unit, and otherwise to convert the time stamp of the first information unit based on a known deviation of the clocks, so that he also refers to the clock of the time stamp of the second unit of information, and
  • microprocessor is programmed to normalize the time stamp of the first information unit and the time stamp of the second information unit in consideration of the time scales of the first information unit and the second information unit to a common new time stamp, and to store the common new time stamp in the header of the third information unit in the memory.
  • each information unit comprises a header containing at least some of the following semantic metadata describing characteristics of the payload: a timestamp indicating at what time the payload is or has been valid,
  • - designates a sensor from which the payload was generated, or at least one operator and source
  • a time scale which indicates how the plausibility of the user data develops over time. According to a particular embodiment, a method results
  • a clock to which the time stamp refers is specified in the header or in the timestamp.
  • the design system computer-aided checks for all information units whether the timestamp is present and the timestamp time format is known, and - wherein the design system associates a first and a second information unit with a derivation operator and thereby derives a third information unit, wherein the design system verifies whether the time format of the time stamp of the first information unit agrees with the time format of the time stamp of the second information unit, and otherwise converts the time stamp of the first information unit into the time format of the time stamp of the second information unit,
  • the design system checks if the clock of the
  • Time stamp of the first information unit is identical to the clock of the time stamp of the second information unit, and the time stamp of the first information otherwise converted based on a known deviation of the clocks, so that it also refers to the clock of the time stamp of the second unit of information, and
  • the design system normalizes the time stamp of the first information unit and the time stamp of the second information unit in consideration of the time scales of the first information unit and the second information unit to a common new time stamp which is stored in the header of the third information unit.
  • the design system recursively draws a derivation graph for an information unit based on the indication of origin and the indications of origin in the source information units from which the information unit was derived
  • design system identifies, by graph algorithms, reconvergent branches in the derivation graph, and
  • the design system compensates dependencies resulting from the reconvergent branches in the derivation graph by a modification of the derivation of the information unit.
  • the design system associates a first and a second information unit with a derivation operator and thereby derives a third information unit, and wherein the design system calculates the plausibility of the third information unit from the plausibilities of the first and second information units in dependence on the derivation operator.
  • the design system proposes to a developer, when defining a new information unit in which the variable is to be stored, the appropriate time scale for entry as a time scale in the header.
  • FIG. 1 shows an architecture of a driver assistance system
  • FIG. 2 shows an exemplary embodiment of a design system for a driver assistance system
  • FIG. 3 shows an exemplary embodiment of an information unit, an exemplary embodiment of a time stamp, an exemplary embodiment of an indication of origin, and FIG. 3
  • FIG. 6 shows an exemplary embodiment of a data structure for
  • User data. 1 shows an architecture of a driver assistance system and in particular the construction of an environmental representation 6 of real sensor data 4.
  • a sensor 1 performs a real measurement 3 in a real environment 2 and generates the real sensor data 4 basically a sensor data fusion 5 is always required in the environmental representation 6. Because from the second measurement, a temporal merger must already be made. Require multiple sensors in different locations a local fusion of the real sensor data 4. Furthermore, different sensor types, such as ultrasound and camera, must be fused by the sensor data fusion 5 with special consideration of their properties.
  • the architecture shown in FIG. 1 can also be understood as a design system for driver assistance systems.
  • Sensor data fusion 5 plays a central role in this architecture. It is responsible for determining the environmental representation 6 from the sequence of the real sensor data 4 of different sensors 1, i. As defined above, derive an internal representation of the environment, the vehicle state and / or the condition of the driver. The entries in the environmental representation 6 thus stem from observations, i. the real sensor data 4.
  • an environment representation type 7 i. the type of environmental representation 6, pre-determined by the developer.
  • the environmental representation type 7 may be e.g. an assignment grid map or an object list, he can set parameters of the vehicle state or specify a set of possible states for the driver ("tired”, "awake”,
  • the state-dependent entries in the environment representation 6 are modified, depending on what the sensors 1 measure. For example, the occupancy probability in a cell of an occupancy lattice map may be increased if the sensor 1 measures a distance to an obstacle at a corresponding distance.
  • the entries in the environment representation 6, such as an occupancy probability usually express an uncertainty of the information. Therefore, they usually correspond to one of the known uncertainty calculus, in particular from the fuzzy theory, the Dempster-Shafer calculus or the probability calculus. Usually, probability calculus is used and the entries are random variables. For reasons of efficiency, a parametric truth is often However, it is also possible to choose a sample-based representation, as is usual in the field of autonomous robots.
  • the calculation rule according to which the entries in the environmental representation 6 are modified on the basis of the real sensor data 4 is entered in FIG. 1 as a fusion model 8.
  • driver assistance application 9 is a driver assistance function for automatic parking. This
  • the driver assistance application 9 for automatic parking needs as environment representation 6 a map of the surroundings in which a parking space can be identified and then a path can be planned into this parking space.
  • the environmental representation type 7 of this card will typically be an occupancy lattice 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.05m and 1.0m, but can also be smaller or larger.
  • Such a grid map is an example of an environmental representation 6 of the environment.
  • the environmental representation 6 should basically be static over a period of time, i. in it the parts of the real environment 2 are to be modeled, which do not change over a certain time. The measurement actually depends on the real environment 2.
  • this is often taken synonymously in the literature to the information in the environmental representation 6, ie the map of the environment.
  • the design is carried out as shown in FIG. 1 without simulation of the sensor 1 and the real environment 2. But that means that the developers function as a whole must be experimentally verified. This makes the development process slow and expensive: for each modification and further development, the developers must build a vehicle, locate or build a task-specific real environment 2, write data fusion algorithms and application algorithms, and then analyze and change the behavior of the vehicle meets expectations.
  • the developers When all modules are edited by a development group, there is also a lack of explicit modeling in some places. This can relate in particular to the underlying sensor hardware and the description of properties of the sensors 1, but also the intrinsic shadows of the real sensor data 4 on the meta-level.
  • FIG. 2 shows a separate and explicit modeling of the sensor properties with a sensor model 10, the environmental properties with an environment model 20, the environment representation type 7 and the environment representation 6 itself.
  • the sensor model 10 contains the physical properties of the sensor. Which these are, of course, depends on the respective sensor types. The following will describe the requirements for the sensor model 10 using the example of an ultrasound Distance sensor illustrated in which only the first incoming echo is evaluated, or is returned to the corresponding distance value.
  • the information-theoretically important properties must be listed. In the case of an ultrasonic sensor, these include the transmission and reception frequency ranges or frequency responses, as well as the directional characteristic, the filter properties, the transmission energy, the reception sensitivity.
  • the dimensions, the weight, the electrical connection values (supply voltage including tolerance ranges, supply power) in the sensor model 10 should be listed for integration into the mechanical and electrical design.
  • the sensor model 10, a vehicle model, not shown, and the environment model 20 enable the simulation in this case virtual measurements 30, resulting in virtual sensor data 40.
  • the above-mentioned decoupling is achieved by physically modeling the sensor hardware in the sensor model 10 in such a way 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 environment model 20 contains those 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 environment model 20 must include the corresponding physical properties of the environment. For a video camera as a sensor, these properties include the geometry and textures (optical reflection properties) of the objects. Numerous very well-developed examples of such environment models 20 can be found in the areas of computer animation for films, computer games, architectural simulation, etc. In some of these environment models 20, properties of the transmission medium are also simulated (fog, rain, snow, ...) as well Properties of the lighting. 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 vehicle model describes where the sensors are relative to the vehicle.
  • the geometric relationships are relevant here.
  • 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.
  • the supply voltage (possibly as a random variable) is part of the vehicle model.
  • the sensor simulation creates the same virtual sensor data 40 from the sensor model 10 and the environment model 20 as would the real sensors in a real use environment.
  • 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.
  • each information unit 90 contains a header 92 which, in addition to an identifier, contains at least some of the following semantic metadata which describe as semantic annotations properties of the payload data 91:
  • time stamp 93 indicating at which time the payload data 91 is or was valid
  • source 94 which
  • a plausibility 95 which indicates the extent to which subsequent inference steps may be based on the payload data 91, and / or
  • a time scale 96 which indicates how the plausibility 95 of the useful data 91 develops over time, i. for how persistent the payload 91 is kept.
  • FIG. 4 shows the time stamp 93 from FIG. 3 in detail.
  • the real sensor data 4, virtual sensor data 40, and environmental representations 6 described in the context of FIGS. 1 and 2 thus have validity only at a certain point in time, and as a result can only be interpreted with regard to this point in time. Therefore, all real sensor data 4, virtual sensor data 40, and, consequently, any information derived from the sensor data, e.g. are provided in the environment representation 6 with the time stamp 93, which indicates at what time this information can be considered valid. This is particularly necessary if information that was valid at different times should be fused together. In these cases, the time scale 96 shown in FIG. 3 must additionally be taken into account.
  • time format 932 of the time stamp 93 is explicitly specified within the information unit 90 in order to avoid interpretation errors.
  • time stamp 93 it must be noted in the time stamp 93 to which clock 931 the time stamp 93 relates. Modules (e.g., sensors) in which time stamps 93 are assigned often have their own clock 931. In this case, this clock 931 must be specified in the time stamp 93. In order to check in the design system whether two timestamps 93 are compatible with each other, and whether or how the information units 90 annotated by these timestamps 93 merge, the respective clocks must be called 931 and uniquely identified.
  • the design system it is possible to search for a currently valid information which makes a statement about the time difference between the clocks 931 involved, i. a statement about the calibration of the clocks 931. Since this calibration is itself usually the result of a measurement, the time difference between two clocks 931 is generally a random variable.
  • the design system may further check whether each header 92 of an information unit 90 in the system has a time stamp 93 in a known format.
  • the design system can check whether both timestamp formats are the same or can be brought into the same format by format converters present in the design system. It is also checked whether both time stamps 93 relate to the same clock 931, or if there is information about the synchronicity of the two clocks used in the design system, which allows both time stamps 93 to be the same Obtain clock 931, which can then also be used for an information unit derived from the two information units.
  • FIG. 5 shows the indication of origin 94 from FIG. 3 in detail. It must be considered whether information units that are merged in a module have a common origin. Otherwise, the security of the resulting information is usually overestimated.
  • the source of the information is noted in the source 94.
  • the indication of source 94 includes either the sensor which provided the corresponding measured value or, as shown in FIG. 5, an operator 940, by means of which the useful data 91 was derived, as well as the source information units 941... 94n incorporated in this operation.
  • the design system obtains, through the composition of these indications of source 94, a network of derivations and derivations in which, in very many cases, the individual random variables can be calculated accurately. Especially in the current research field of the "Graphical Models", good progress has been made in recent years, which can be used by the design system for driver assistance systems.
  • a simple example is the derivation of a normally distributed random variable (eg, a length measurement) based on three normally distributed observations ⁇ z 1 , z 2 , z 3 ⁇ in two steps.
  • the observation or derived size distribution thus has the Zj ⁇ JV (ij, Z j).
  • the fused information of z and z 2 is normally distributed with the mean value
  • i 4 ( ⁇ 1 + ⁇ 2 1 ) "1 ⁇ ⁇ 2 ⁇ + ( ⁇ 1 + ⁇ 2 ⁇ ⁇ 1 ⁇ i 2
  • ⁇ 4 ( ⁇ 1 + ⁇ 2 1 ) "1 .
  • i s ( ⁇ 2 1 + ⁇ 3 ⁇ ) 1 ⁇ ⁇ 3 ⁇ i 2 + ( ⁇ 2 1 + ⁇ 3 ⁇ ) 1 ⁇ ⁇ 2 ⁇ i 3
  • ⁇ 5 ( ⁇ 2 1 + ⁇ 3 1 ) "1 .
  • ⁇ 7 ( ⁇ 1 + ⁇ 2 1 + ⁇ 3 1 ) "1 ,
  • the design system After the design system has determined the dependencies as described above, it can thus determine the correct result from the fusion result, assuming independence, by deducting the double-used information once again.
  • the design system supports the discovery and compensation of hidden dependencies in the derivation by the analysis of the derivation graph constructed from the formally given indications of origin 94 over the source of the information units 90. In this graph, appropriate graphene algorithms are used to discover reconvergent branches and thus dependencies.
  • the design system can contain algorithms from the field of "graphical models", which derive the correct information on the basis of the determined dependencies analogously to the example given in the previous section.
  • Those user data 91 which either consist directly of sensor data or are derived from sensor data are generally not secure. They may be noisy and have a certain variability, or they may not correspond to any physical phenomenon (i.e., they are artifacts), or they may correspond to a phenomenon of the physical world, but not mirrored in a given environmental representation 6.
  • the plausibility 95 can also be represented as a uniformly distributed component of a mixed distribution.
  • plausibility 95 is required as part of header 92 for each information unit 90 in the design system.
  • the plausibility 95 is also linked in the case of fusion, linking or further processing of the information units 90.
  • the connection rules to be used in this case are not fixed a priori, but they depend on the contents of the payload data 91. The design system therefore calculates according to the appropriate for the respective payload 91
  • the plausibility logic rules 95 to be applied to a given type of payload 91 of the information units 90 are stored in the design system.
  • the design system thus supports the correct composition of derivations in the overall system of the various driver assistance systems.
  • time stamp 93 For each information unit 90 is noted in the time stamp 93, at which time the respective user data 91 should be considered valid. When two (or more) information units 90 are to be merged, these times must match. However, the time stamps 93 will generally not match completely. Therefore, information units 90 to be merged must be normalized to a common new time stamp 93. For this purpose, the time scale 96 in the header 92 is required.
  • the time scale 96 of an information unit 90 indicates in which way and to what extent the payload data 91 is "outdated.” This depends on the content of the payload data 91. For example, if the payload 91 relates to the position of a building, then the time scale is 96 "long ": It is not expected that the actual position of the building will change within the duration of the execution of the driver assistance function.
  • the payload data 91 relates to one vehicle, such as an estimate of the location of another vehicle, then the displacement of moving vehicles will become increasingly inaccurate the longer the corresponding measurement is taken.
  • a special case of this consideration is the process noise in the Kalman filter, which expresses the increase in uncertainty due to the addition of additional noise.
  • the time scale 96 can be implemented as a mapping 0: (x t , AT) ->% t + AT of a random variable x t to one Random variable Xt + ⁇ > where the second random variable usually has a larger spread.
  • the design system may propose to a developer appropriate time scales 96 for the respective random variable contained as payload data 91 in the information unit 90. This proposal may be based on long-term observations of the actual typical course of the random variable with this particular interpretation at the meta-level. The time scales 96 can therefore be learned.
  • FIG. 6 shows the useful data 91 from FIG. 3 in detail. This can be different information. On the one hand, the contents of the driver assistance systems themselves are modeled or provided with semantic meta information. On the other hand, various aspects of the environment, the vehicle or the driver are modeled. Since the useful data 91 can thus be of very different kind, are in the
  • Payload 91 contain case by case other structural elements. It is essential that the uncertainty of the user data 91 is adequately represented.
  • User data 91 which reflect physical facts (eg a measured distance), can generally not be recorded with a number, but are mostly random variables obtained from measurements. Therefore, these variables are also modeled as random variables and entered as a value 915 in the payload 91, that the probability density function is explicitly specified. As an approximation to extremely few scattering random variables, the Dirac distribution is also permissible. Analogously, this also applies to non-strictly physical facts, such as a state of fatigue of the driver, degree of impatience of another road user, etc.
  • a unit for the physical quantity ie for a distance value, for example, the SI unit m
  • the comment field 911 is included in the data structure of the user data 91 in the comment field 911.
  • the data structure of the payload data 91 must specify a coding 914 of the payload data 91, provided that there are different possibilities for this (for example, a linear or a logarithmic scale for length measurement). Also in the description of position and orientation in space, there are a large number of well-known encodings. Here, the specification in field Coding 914 is required to avoid errors.
  • the data structure of the payload data 91 must also specify a formal specification of a context of the payload data 91 - e.g. at a distance value, the object from which to measure and the object to which the measurement is made, as will be described below.
  • Information on resolution, discretization, and possible data types in the implementation, as well as on a computational need for a data processing step may also be required and are, for example, deposited in the comment field 911.
  • an example of the configuration of an information unit 90 with a header 92 and user data 91 for the purposes of a distance indication is shown below with reference to FIGS. 3 to 6.
  • a distance indication denotes a distance between two different objects. Since the objects do not have to stay in the same place, the distance indication also includes the time at which a certain distance was given. Likewise, it can be seen from the circumstances, which validity period is to be attributed to the statement made about the distance.
  • These aspects relate to all statements made by sensors directly or by way of derivation within driver assistance functions, and therefore they are summarized in header 92, as previously explained.
  • the different aspects of a measurement or of a statement derived from the measurements can be found in the user data 91 itself. For example, various sensor measurements show that the (shortest) distance between the vehicle and an obstacle in the environment (eg tree no from an object list) is 5.32m.
  • the header 92 contains as a plausibility 95 that this statement applies (for example in a range from 0 to 1 the plausibility value 0.99 in the field Plausibility 95).
  • the time stamp 93 indicates that the statement was valid at the time 2013/01/26/17/59/234/345 (as parameter 933 from FIG. 4) CEST (as time format 932 from FIG. 4) after the clock of the navigation computer in the vehicle ( as clock 931 of Figure 4). From the vehicle speed and the type of the object is to follow that the plausibility 95 of this statement is halved every 0.2s. This information is stored as time scale 96 in the header 92. Origin indication 94 indicates that the distance value is inferred from a sequence of measurements, indicating as operator 940 (see Figure 5) the fusion operator that performed the last inference step; Furthermore, all source information units 941 ... 94n (see FIG. 5) are listed, from which the operator 940 has formed the inference.
  • the useful data 91 themselves contain the specific details for this statement and are shown in their schematic structure in FIG. 6 on the left side.
  • reference 912 i. as a reference point, the vehicle and as
  • Referencer 913 ie an object which refers to the reference point, a tree no. 15 entered in the data structure.
  • the distance value is a random variable - the true distance may possibly be on average. given value, deviations are possible. Therefore, an approximate probability density distribution (WDV) is given as the value 915.
  • the value 915 is shown in detail in the right part of FIG.
  • WDV comment field 916 a normal distribution is entered as WDV type 917, for example, and a mean value 5.32 and a variance 0.1 are entered as WDV parameter 918.
  • the design system assists a developer, for example, by checking the plausibility and consistency of derived quantities by inference of the previously explained meta information taken from the respective information units 90. For a position estimate resulting from composition of two position estimates, the design system checks to see if the first position estimate locator is equal to the second position estimate reference, ie, if the composition is in the correct order.
  • the data in the environmental representation 6 shown in FIG. 2 are also explicitly described on the meta-level as explained in the context of FIGS. 3 to 6. This also applies to the time stamp 93, for which information is considered valid and for the time scale 96.
  • the environment representation 6 is an occupancy grid map. Then, in the payload data 91, the size of the grid cells, the number of grid cells, and the occupancy probability are also noted. For the occupancy probability different options are possible, which are selected depending on the intended use. As with the statements about the distance, the type of the probability density distribution is explicitly named.
  • the information unit 90 contains useful data 91 sensor data or, for example, a distance indication may contain. By derivation of such information units 90, more complex information units 90 can be formed, which contain higher aggregate user data 91 than the information units 90 used in the derivation.
  • the derived information unit 90 can contain an object hypothesis, while the infiltrated information units 90 contain individual features. In this sense, an information unit 90 may also include a grid map and thus the environment representation 6 itself. Alternatively, each individual grid cell can also be modeled by an information unit 90.

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)
  • Stored Programmes (AREA)
  • Control Of Driving Devices And Active Controlling Of Vehicle (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Das Entwurfssystem verarbeitet maschinenlesbare semantische Metadaten (92), welche beispielsweise Eigenschaften realer oder virtueller Sensordaten (4, 40) beschreiben, und stellt anhand der semantischen Metadaten (92) eine Gültigkeit von Nutzdaten (91) in einer Umgebungsrepräsentation (1) eines Fahrerassistenzsystems sicher. Hierdurch wird erstmals eine einheitliche, durchgängige und formale Beschreibung der Verfahren und Daten im Entwurfsprozess von Fahrerassistenzsystemen mittels semantischer Metadaten (92) bereitgestellt. Dies hat unter anderem den Vorteil, dass die im Fahrzeug verbauten Sensoren grundsätzlich für alle auf dem Fahrzeug zu realisierenden Fahrerassistenzfunktionen bzw. Applikationen verfügbar werden. Weiterhin wird der Entwurfsprozess deutlich vereinfacht und beschleunigt. Die semantischen Metadaten (92) enthalten beispielsweise einen Zeitstempel (93), eine Herkunftsangabe (94), eine Plausibilität (95) und eine Zeitskala (96), welche angibt, wie sich die Plausibilität (95) der Nutzdaten (91) zeitlich entwickelt.

Description

Beschreibung
Entwurfssystem und Verfahren 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 Experten 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 Sensorfusion, selbst über eine Umgebung bilden muss. Eine derartige Repräsentation ist folglich Arbeitsergebnis eines Computerpro- grammablaufs 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 aufgelö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 verstehen. 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 Begriff 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.
Der Entwurfsprozess von Fahrerassistenzsystemen ist dadurch geprägt, dass ein sehr breites Spektrum von Expertenwissen im Entwicklungsteam vertreten sein muss. Der Grund dafür ist, dass Aufbau und Leistungsvermögen eines Fahrerassistenzsystems von sehr vielen Aspekten abhängen. Zunächst wird in der Regel eine Umgebung eines Fahrzeugs, ggf. auch ein interner Zustand des Fahrzeugs und ein Zustand des Fahrers mittels Sensoren physikalisch oder chemisch er- fasst. Aus diesen Sensordaten wird eine geeignete Umgebungs- repräsentationen, Fahrzeugrepräsentation und Fahrerrepräsentation hergeleitet. Geeignet bedeutet hier, dass eine oder mehrere Assistenzfunktionen bzw. Applikationen auf Grundlage der genannten Repräsentationen Steuersignale für das Fahrzeug und/oder optische oder akustische Signale für den Fahrer er- zeugen können, die zu einem erwünschten Verhalten des Fahrzeugs oder einer Information für den Fahrer führen.
In diesem weiten Bogen von physikalischen Sensoren hin zu Steuersignalen und Informationen für den Fahrer müssen viele unterschiedliche Wissensdomänen integriert werden.
Eine explizite Beschreibung der Bedeutung von Variablen findet sich in CAD-Systemen zum Beispiel in dem neuen Standard Step AP 242 und ist aus dem Dokument "Schemas" ersichtlich, erhältlich im Internet am 25.07.2013 unter
http : //www . steptools . com/support/stdev_docs/express/ap242/htm 1/index . html . Hier wird ein Typsystem verwendet, in dem eine physikalische Bedeutung einer Variablen durch einen Typ der Variablen ausgedrückt wird. Diese Typen umfassen auch SI- Einheiten und davon abgeleitete Einheiten.
Für Sensornetze sind im Zusammenhang mit Geoinformationssys - temen semantische Beschreibungen der Sensoren und Signale entwickelt worden, wie unter anderem beschrieben in Michael Compton et. al., "The SSN ontology of the W3C semantic sensor network incubator group", Web Semantics: Science, Services and Agents on the World Wide Web, Volume 17, Dezember 2012, p. 25-32, ISSN 1570-8268. Hierbei ist vorgesehen, dass zusammen mit den Sensoren Eigenschaften der Messungen abgelegt werden, wie zum Beispiel die Genauigkeit.
In der WO 2007017308 AI wird ein Ansatz beschrieben, die Sensordaten zunächst in einer "Sensorsprache" zu beschreiben, die keine Angaben über das Fahrzeug bzw. die Fahrerassistenz - funktion enthält, und die in dieser Sensorsprache beschriebenen Phänomene später in eine "Funktionssprache" zu übersetzen, welche nicht auf die spezifischen Sensoren eingeht. In dieser Funktionssprache findet dann auch die Fusionierung statt. Dies wird dort am Beispiel eines Abstandsregeltempoma- ten illustriert.
In der WO 2006089941 AI wird ein Informationsaustauschmodul beschrieben, in dem Sensorinformationen gesammelt und Applikationen zur Verfügung gestellt werden.
Es stellt sich die Aufgabe, ein Entwurfssystem und ein Verfahren zum Entwurf eines Fahrerassistenzsystems anzugeben, welche den Entwurf des Fahrerassistenzsystems vereinfachen.
Diese Aufgabe wird erfindungsgemäß durch ein Entwurfssystem für ein Fahrerassistenzsystem gelöst,
umfassend mindestens ein Modul, eingerichtet zur Erzeugung realer Sensordaten oder virtueller Sensordaten, und umfassend mindestens ein Modul, eingerichtet zur rechnergestützten Ableitung einer Umgebungsrepräsentation aus den realen Sensordaten oder virtuellen Sensordaten. Das Entwurfssystem ist dadurch gekennzeichnet, dass
das Entwurfssystem zur rechnergestützten Verarbeitung maschinenlesbarer semantischer Metadaten eingerichtet ist, welche Eigenschaften der realen Sensordaten und/oder der virtuellen Sensordaten und/oder von Daten in der Umge- bungsrepräsentation beschreiben, und
das Entwurfssystem eingerichtet ist zur rechnergestützten Überprüfung und/oder Sicherstellung einer Gültigkeit von Daten in der Umgebungsrepräsentation anhand der semantischen Metadaten.
Die Aufgabe wird ferner erfindungsgemäß dadurch gelöst, dass mindestens ein Modul reale Sensordaten oder virtuelle Sensordaten erzeugt, mindestens ein Modul aus den realen Sensordaten oder virtuellen Sensordaten rechnergestützt eine Umgebungsrepräsentation ableitet. Das Verfahren ist dadurch gekennzeichnet, dass
das Entwurfssystem maschinenlesbare semantische Metadaten rechnergestützt verarbeitet, welche Eigenschaften der realen Sensordaten und/oder der virtuellen Sensordaten und/oder der Umgebungsrepräsentation beschreiben, und - das Entwurfssystem anhand der semantischen Metadaten rechnergestützt eine Gültigkeit von Daten in der Umgebungsrepräsentation überprüft und/oder sicherstellt.
Auf dem computerlesbaren Datenträger ist ein Computerprogramm gespeichert, welches das Verfahren ausführt, wenn es in einem Mikroprozessor abgearbeitet wird.
Das Computerprogramm wird in einem Mikroprozessor abgearbeitet und führt dabei das Verfahren aus.
Die im Folgenden ausgeführten Vorteile und Erläuterungen müssen nicht notwendigerweise die Gegenstände der unabhängigen Patentansprüche betreffen. Vielmehr kann es sich hierbei auch um Vorteile oder Aspekte handeln, welche lediglich einzelne Ausführungsformen, Varianten oder Weiterbildungen betreffen.
Es wird eine Formalisierung des Entwurfsprozesses von Fahrerassistenzsystemen mittels der semantischen Metadaten sowie eine Unterstützung dieses Entwurfsprozesses durch ein ent- sprechendes Entwurfssystem vorgeschlagen.
Hierdurch wird erstmals eine einheitliche, durchgängige und formale Beschreibung der Verfahren und Daten im Entwurfspro- zess von Fahrerassistenzsystemen mittels semantischer Metada- ten bereitgestellt. Dies hat unter anderem den Vorteil, dass die im Fahrzeug verbauten Sensoren grundsätzlich für alle auf dem Fahrzeug zu realisierenden Fahrerassistenzfunktionen bzw. Applikationen verfügbar werden. Weiterhin wird der Entwurfs- prozess deutlich vereinfacht und beschleunigt.
Die Module sowie weitere benötigte Recheneinheiten, Simulato- ren etc. können hardwaretechnisch und/oder auch softwaretechnisch implementiert werden. Bei einer hardwaretechnischen Implementierung kann jedes Modul als Vorrichtung oder als Teil einer Vorrichtung, zum Beispiel als Computer, als Mikroprozessor oder als Steuerrechner eines Fahrzeuges ausgebildet sein. Bei einer softwaretechnischen Implementierung kann die jeweilige Einheit als Computerprogrammprodukt, 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 Weiterbildung ergibt sich ein Entwurfssystem, mit einem Speicher und mit einem Mikroprozessor, welcher programmiert ist zur Abspeicherung
der realen Sensordaten oder der virtuellen Sensordaten, oder
von Daten in der Umgebungsrepräsentation, oder
von weiteren Daten, welche in den Modulen enthalten sind,
jeweils als Nutzdaten in einer Informationseinheit in dem Speicher,
wobei jede Informationseinheit einen Header aufweist, welcher zumindest einige der folgenden semantischen Metadaten enthält, welche Eigenschaften der Nutzdaten beschreiben: ein Zeitstempel, welcher angibt, zu welchem Zeitpunkt die Nutzdaten gültig sind oder waren,
eine Herkunftsangabe, welche einen Sensor bezeichnet, von dem die Nutzdaten erzeugt wurden, oder
mindestens einen Operator und Quell -
Informationseinheiten angibt, anhand derer die Nutz- daten hergeleitet wurden,
eine Plausibilität , welche angibt, in welchem Umfang sich nachfolgende Inferenzschritte auf die Nutzdaten stützen dürfen, und/oder
eine Zeitskala, welche angibt, wie sich die Plausibili- tat der Nutzdaten zeitlich entwickelt. einer besonderen Weiterbildung ergibt sich ein Entwurfs - System,
bei dem der Header sämtliche der zuvor genannten semanti sehen Metadaten enthält .
Gemäß einer Ausführungsform ergibt sich ein Entwurfssystem, bei dem in dem Header oder in dem Zeitstempel ein Zeitfor mat des Zeitstempels abgespeichert ist, und
bei dem in dem Header oder in dem Zeitstempel eine Uhr, auf welche sich der Zeitstempel bezieht, angegeben ist. einer Weiterbildung ergibt sich ein Entwurfssystem, bei dem der Mikroprozessor programmiert ist zur Überprüfung für alle Informationseinheiten, ob der Zeitstempel vorhanden ist und das Zeitformat des Zeitstempels bekannt ist, und
bei dem der Mikroprozessor programmiert ist
zur Verknüpfung einer ersten und einer zweiten Informa tionseinheit mit einem Herleitungsoperator,
zur Herleitung einer dritten Informationseinheit aus der Verknüpfung, und
zur Abspeicherung der dritten Informationseinheit in dem Speicher,
wobei der Mikroprozessor programmiert ist zur Überprüfung, ob das Zeitformat des Zeitstempels der ersten In formationseinheit mit dem Zeitformat des Zeitstempels der zweiten Informationseinheit übereinstimmt, und an- dernfalls zur Konvertierung des Zeitstempels der ersten Informationseinheit in das Zeitformat des Zeitstempels der zweiten Informationseinheit,
wobei der Mikroprozessor programmiert ist zur Überprü- fung, ob die Uhr des Zeitstempels der ersten Informationseinheit mit der Uhr des Zeitstempels der zweiten Informationseinheit identisch ist, und andernfalls zur Umrechnung des Zeitstempels der ersten Informationseinheit anhand einer bekannten Abweichung der Uhren, so- dass er sich ebenfalls auf die Uhr des Zeitstempels der zweiten Informationseinheit bezieht, und
wobei der Mikroprozessor programmiert ist zur Normalisierung des Zeitstempels der ersten Informationseinheit und des Zeitstempels der zweiten Informationseinheit unter Berücksichtigung der Zeitskalen der ersten Informationseinheit und der zweiten Informationseinheit auf einen gemeinsamen neuen Zeitstempel, und zur Abspeicherung des gemeinsamen neuen Zeitstempels im Header der dritten Informationseinheit im Speicher.
Gemäß einer Ausführungsform ergibt sich ein Verfahren,
bei dem das Entwurfssystem
die realen Sensordaten oder die virtuellen Sensordaten oder
- Daten in der Umgebungsrepräsentation oder
weitere Daten, welche in den Modulen enthalten sind, jeweils als Nutzdaten in einer Informationseinheit speichert ,
wobei jede Informationseinheit einen Header aufweist, wel- eher zumindest einige der folgenden semantischen Metadaten enthält, welche Eigenschaften der Nutzdaten beschreiben: ein Zeitstempel, welcher angibt, zu welchem Zeitpunkt die Nutzdaten gültig sind oder waren,
eine Herkunftsangabe, welche
- einen Sensor bezeichnet, von dem die Nutzdaten erzeugt wurden, oder mindestens einen Operator und Quell -
Informationseinheiten angibt, anhand derer die Nutz- daten hergeleitet wurden,
eine Plausibilität , welche angibt, in welchem Umfang sich nachfolgende Inferenzschritte auf die Nutzdaten stützen dürfen, und/oder
eine Zeitskala, welche angibt, wie sich die Plausibilität der Nutzdaten zeitlich entwickelt. Gemäß einer besonderen Ausführungsform ergibt sich ein Verfahren,
bei dem der Header sämtliche der zuvor genannten semantischen Metadaten enthält . In einer Weiterbildung ergibt sich ein Verfahren,
bei dem in dem Header oder in dem Zeitstempel ein Zeitformat des Zeitstempels abgespeichert wird, und
bei dem in dem Header oder in dem Zeitstempel eine Uhr, auf welche sich der Zeitstempel bezieht, angegeben wird.
Gemäß einer Ausführungsform ergibt sich ein Verfahren,
bei dem das Entwurfssystem rechnergestützt für alle Informationseinheiten überprüft, ob der Zeitstempel vorhanden ist und das Zeitformat des Zeitstempels bekannt ist, und - bei dem das Entwurfssystem eine erste und eine zweite Informationseinheit mit einem Herleitungsoperator verknüpft und dadurch eine dritte Informationseinheit herleitet, wobei das Entwurfssystem überprüft, ob das Zeitformat des Zeitstempels der ersten Informationseinheit mit dem Zeitformat des Zeitstempels der zweiten Informationseinheit übereinstimmt, und den Zeitstempel der ersten Informationseinheit andernfalls in das Zeitformat des Zeitstempels der zweiten Informationseinheit konvertiert ,
- wobei das Entwurfssystem überprüft, ob die Uhr des
Zeitstempels der ersten Informationseinheit mit der Uhr des Zeitstempels der zweiten Informationseinheit identisch ist, und den Zeitstempel der ersten Informations- einheit andernfalls anhand einer bekannten Abweichung der Uhren umrechnet, sodass er sich ebenfalls auf die Uhr des Zeitstempels der zweiten Informationseinheit bezieht, und
wobei das Entwurfssystem den Zeitstempel der ersten Informationseinheit und den Zeitstempel der zweiten Informationseinheit unter Berücksichtigung der Zeitskalen der ersten Informationseinheit und der zweiten Informationseinheit auf einen gemeinsamen neuen Zeitstempel normalisiert, welcher im Header der dritten Informationseinheit abgespeichert wird.
In einer Weiterbildung ergibt sich ein Verfahren,
bei dem das Entwurfssystem für eine Informationseinheit anhand der Herkunftsangabe sowie der Herkunftsangaben in den Quell - Informationseinheiten, aus denen die Informationseinheit hergeleitet wurde, rekursiv einen Herleitungsgraphen erstellt,
bei dem das Entwurfssystem durch Graphenalgorithmen rekonvergente Zweige in dem Herleitungsgraphen identifiziert, und
bei dem das Entwurfssystem Abhängigkeiten, welche sich aus den rekonvergenten Zweigen im Herleitungsgraphen ergeben, durch eine Modifikation der Herleitung der Informationseinheit kompensiert.
Gemäß einer Ausführungsform ergibt sich ein Verfahren,
bei dem das Entwurfssystem eine erste und eine zweite Informationseinheit mit einem Herleitungsoperator verknüpft und dadurch eine dritte Informationseinheit herleitet, und bei dem das Entwurfssystem in Abhängigkeit von dem Herleitungsoperator die Plausibilität der dritten Informationseinheit aus den Plausibilitäten der ersten und der zweiten Informationseinheit berechnet. einer Weiterbildung ergibt sich ein Verfahren,
bei dem das Entwurfssystem anhand einer Langzeitbeobachtung eines typischen Verlaufs einer Zufallsvariable eine geeignete Zeitskala durch maschinelles Lernen ermittelt und
bei dem das Entwurfssystem einem Entwickler bei der Def nition einer neuen Informationseinheit, in welcher die fallsvariable abgespeichert werden soll, die geeignete Zeitskala zur Eintragung als Zeitskala im Header vorschlägt .
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 eine Architektur eines Fahrerassistenzsystems,
Figur 2 ein Ausführungsbeispiel für ein Entwurfssystem für ein Fahrerassistenzsystem,
Figur 3 ein Ausführungsbeispiel für eine Informationsein- heit, ein Ausführungsbeispiel für einen Zeitstempel, ein Ausführungsbeispiel für eine Herkunftsangabe und
Figur 6 ein Ausführungsbeispiel für eine Datenstruktur für
Nutzdaten . Figur 1 zeigt eine Architektur eines Fahrerassistenzsystems und insbesondere den Aufbau einer Umgebungsrepräsentation 6 aus realen Sensordaten 4. Ein Sensor 1 führt eine reale Messung 3 in einer realen Umgebung 2 durch und erzeugt hierbei die realen Sensordaten 4. Für die Übersetzung der realen Sen- sordaten 4 in die Umgebungsreprä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.
Ohne Einschränkung der Allgemeinheit kann die in Figur 1 gezeigte Architektur auch als Entwurfssystem für Fahrerassistenzsysteme verstanden werden. Bei dieser Architektur kommt der Sensordatenfusion 5 eine zentrale Rolle zu. Sie ist dafür verantwortlich, aus der Folge der realen Sensordaten 4 verschiedener Sensoren 1 die Umgebungsrepräsentation 6, d.h. wie eingangs definiert eine interne Repräsentation der Umgebung, des Fahrzeugzustandes und/oder des Zustandes des Fahrers herzuleiten. Die Einträge in der Umgebungsrepräsentation 6 stam- men folglich aus Beobachtungen, d.h. den realen Sensordaten 4.
Meist wird dabei ein Umgebungsrepräsentations -Typ 7 , d.h. der Typ der Umgebungsrepräsentation 6, vom Entwickler vorab fest- gelegt. Der Umgebungsrepräsentations -Typ 7 kann z.B. eine Belegungsgitterkarte sein oder eine Objektliste, er kann Parameter des Fahrzeugzustandes festlegen oder eine Menge möglicher Zustände für den Fahrer vorgeben ("müde", "wach",
"gleichmütig", "angespannt", ...) .
Die zustandsabhängigen Einträge in der Umgebungsrepräsentation 6 werden modifiziert, je nachdem, was die Sensoren 1 messen. Z.B. kann die Belegungswahrscheinlichkeit in einer Zelle einer Belegungsgitterkarte erhöht werden, wenn der Sensor 1 einen Abstand zu einem Hindernis in entsprechendem Abstand misst. Die Einträge in der Umgebungsrepräsentation 6, wie z.B. eine Belegungswahrscheinlichkeit, drücken in der Regel eine Unsicherheit der Information aus. Daher entsprechen sie meist einem der bekannten Unsicherheitskalküle, insbesondere aus der Fuzzy-Theorie , dem Dempster-Shafer-Kalkül oder der Wahrscheinlichkeitsrechnung. Meistens wird Wahrscheinlichkeitsrechnung verwendet, und die Einträge sind Zufallsvariable. Aus Effizienzgründen wird oft eine parametrische Wahr- scheinlichkeitsdichteverteilung zugrunde gelegt, es kann aber auch eine stichprobenbasierte Darstellung gewählt werden, wie es im Gebiet der autonomen Roboter üblich ist. Die Rechenregel, nach der die Einträge in der Umgebungsrepräsentation 6 aufgrund der realen Sensordaten 4 modifiziert werden, ist in Figur 1 als Fusionsmodell 8 eingetragen.
Ein Beispiel für die Fahrerassistenz -Anwendung 9 ist eine Fahrerassistenzfunktion zum automatischen Einparken. Dieses
Beispiel ist angelehnt an die Darstellungen in Thrun, Burgard und Fox: "Probabilistic Robotics", MIT Press 2005, Kap. 6. Die Fahrerassistenz -Anwendung 9 zum automatischen Einparken braucht als Umgebungsrepräsentation 6 eine Karte der Umge- bung, in der eine Parklücke identifiziert werden kann und dann eine Bahn in diese Parklücke hinein geplant werden kann. Der Umgebungsrepräsentations -Typ 7 dieser 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.05m und 1.0m, kann aber auch kleiner oder größer sein. Eine solche Gitterkarte ist ein Beispiel für eine Umgebungsrepräsentation 6 der Umgebung.
Die Umgebungsrepräsentation 6 soll in diesem Beispiel also grundsätzlich über einen gewissen Zeitraum hinweg statisch sein, d.h. in ihr sollen die Teile der realen Umgebung 2 modelliert sein, die sich über eine gewisse Zeit hinweg nicht ändern. Die Messung hängt eigentlich ab von der realen Umgebung 2. Bei der Herleitung der Umgebungsrepräsentation 6, wird dies in der Literatur häufig synonym genommen zu der Information in der Umgebungsrepräsentation 6, also der Karte der Umgebung .
Im Extremfall wird der Entwurf wie in Figur 1 gezeigt ohne Simulation des Sensors 1 und der realen Umgebung 2 durchgeführt. Das bedeutet aber, dass die Entwickler die Fahreras- sistenzfunktion als Ganzes experimentell überprüfen müssen. Dies macht den Entwicklungsprozess langsam und teuer: für jede Modifikation und jede Weiterentwicklung müssen die Entwickler ein Fahrzeug aufbauen, eine aufgabengemäße reale Um- gebung 2 suchen oder selbst aufbauen, Datenfusionsalgorithmen und Applikationsalgorithmen schreiben und dann so lange analysieren und ändern, bis das Verhalten des Fahrzeugs den Erwartungen entspricht. Wenn alle Module von einer Entwicklungsgruppe bearbeitet werden, fehlt es auch an einigen Stellen an der Notwendigkeit zur expliziten Modellierung. Dies kann insbesondere die zugrundegelegte Sensorhardware und die Beschreibung von Eigenschaften der Sensoren 1 betreffen, aber auch die Eigen- schatten der realen Sensordaten 4 auf der Metaebene.
Eine weitere Folge dieser Herangehensweise ist daher, dass Entwicklungsstände bzw. Kenntnisstände für einzelne Module nur mit hohem Aufwand zwischen Entwicklergruppen ausgetauscht werden können. Deswegen werden bei solcher Entwurfsmethodik oft große Teile der Entwicklungsarbeiten mit jeder Fahrerassistenzfunktion neu geleistet. Noch schwerer wiegt, dass bei dieser Entwicklungsmethodik auch die Hardware nicht von verschiedenen Fahrerassistenzfunktionen gemeinsam genutzt werden kann.
Figur 2 zeigt eine separate und explizite Modellierung der Sensoreigenschaften mit einem Sensormodell 10, der Umgebungseigenschaften mit einem Umgebungsmodell 20, des Umgebungsrep- räsentations-Typs 7 und der Umgebungsrepräsentation 6 selbst. Dabei wird im Entwurfsprozess die erforderliche Expertise über die Sensorhardware von der Expertise über Anwendungsbereiche entkoppelt. Das Sensormodell 10 enthält die physikalischen Eigenschaften des Sensors. Welche das sind, hängt natürlich von den jeweiligen 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 Abstandswert zurückgeliefert wird. Im Sensormodell 10 müssen die informationstheoretisch wichtigen Eigenschaften aufgeführt werden. Im Falle eines Ultraschallsensors umfassen diese die Sende- und Empfangsfrequenz - bereiche bzw. Frequenzgänge, wie auch die Richtcharakteristik, die Filtereigenschaften, die Sendeenergie, die Empfangs- empfindlichkeit .
Ebenso sollten für die Integration in den mechanischen und elektrischen Entwurf die Abmessungen, das Gewicht, die elektrischen Anschlusswerte (Versorgungsspannung inkl. Toleranzbe- reichen, Versorgungsleistung) im Sensormodell 10 aufgeführt werden .
Diese Angaben müssen aus sich heraus unmissverstandlich sein, also müssen bei allen physikalischen Werten auch die Einhei- ten und möglichen Schwankungen mit genannt sein. Vorteilhaft ist es, sie als Zufallsvariable zu modellieren, da dafür aus der Mathematik anerkannte, aussagefähige Modelle und Algorithmen zur Verfügung stehen. Bei der Sendefrequenz ist für einen Ultraschallsensor also als Einheit z.B. Hz anzugeben oder KHz, bei Radarsensoren wird man MHz oder GHz spezifizieren. Entscheidend ist, dass die physikalische Einheit mit angegeben wird. Nicht nur die Frequenz ist für den Messvorgang relevant, sondern ebenso können Frequenz und Amplitude des gesendeten Signals über die Zeit variieren. In diesem Fall sind formale Angaben dieses Signals erforderlich. Dabei ist es wesentlich, dass das Format, in dem diese Signale beschrieben sind, ex- plizit genannt wird.
Das Sensormodell 10, ein nicht gezeigtes Fahrzeugmodell und das Umgebungsmodell 20 ermöglichen hierbei die Simulation virtueller Messungen 30, 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 ei- ner geeigneten Simulation und aufgrund des entsprechend ausführlichen Umgebungsmodells 20 die virtuellen 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 ermittelten realen Sensordaten (vgl. Figur 1) .
Das Umgebungsmodell 20 enthält diejenigen physikalischen Eigenschaften 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 Bereichen Computeranimation für Filme, Computerspiele, Archi- tektursimulation, 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 modelliert, 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.
In diesem Kontext beschreibt das Fahrzeugmodell, 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.
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 Einsatzumgebung 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.
Im in Figur 3 gezeigten Ausführungsbeispiel werden die realen Sensordaten 4 aus Figur 1, die virtuellen Sensordaten 40 und die Daten in der Umgebungsrepräsentation 6 aus Figur 2 und/oder weitere Daten, beispielsweise Signale und Variable, welche von den Modulen bereitgestellt oder verarbeitet werden, jeweils als Nutzdaten 91 in einer Informationseinheit 90 abgespeichert. Jede Informationseinheit 90 enthält einen Header 92, welcher neben einem Identifikator zumindest einige der folgenden semantischen Metadaten enthält, welche als se- mantische Annotationen Eigenschaften der Nutzdaten 91 beschreiben :
ein Zeitstempel 93, welcher angibt, zu welchem Zeitpunkt die Nutzdaten 91 gültig sind oder waren, eine Herkunftsangabe 94, welche
einen Sensor bezeichnet, von dem die Nutzdaten 91 erzeugt wurden, oder
mindestens einen Operator und Quell - Informationseinheiten angibt, anhand derer die Nutz- daten 91 hergeleitet wurden,
eine Plausibilität 95, welche angibt, in welchem Umfang sich nachfolgende Inferenzschritte auf die Nutzdaten 91 stützen dürfen, und/oder
- eine Zeitskala 96, welche angibt, wie sich die Plausibilität 95 der Nutzdaten 91 zeitlich entwickelt, d.h. für wie persistent die Nutzdaten 91 gehalten werden.
Figur 4 zeigt den Zeitstempel 93 aus Figur 3 im Detail. Im Bereich Fahrerassistenzfunktionen hat man es in aller Regel mit zeitlich veränderlichen Zuständen der Umgebung, des Fahrzeugs und des Fahrers zu tun. Die im Kontext der Figuren 1 und 2 beschriebenen realen Sensordaten 4, virtuellen Sensordaten 40, und Umgebungsrepräsentationen 6 haben somit lediglich zu einem bestimmten Zeitpunkt Gültigkeit, und sind infolgedessen nur im Hinblick auf diesen Zeitpunkt interpretierbar. Daher müssen alle realen Sensordaten 4, virtuellen Sensordaten 40, und in Konsequenz auch jede aus den Sensordaten hergeleiteten Information z.B. in der Umgebungsrepräsentation 6 mit dem Zeitstempel 93 versehen werden, welcher angibt, zu welchem Zeitpunkt diese Information als gültig betrachtet werden kann. Dies ist insbesondere dann erforderlich, wenn Informationen, die zu unterschiedlichen Zeitpunkten gültig waren, miteinander fusioniert werden sollen. In diesen Fällen ist zusätzlich noch die in Figur 3 gezeigte Zeitskala 96 zu berücksichtigen.
Für ein in Figur 4 gezeigtes Zeitformat 932 der durch Parameter 933 gebildeten Zeitangabe des Zeitstempels 93 sind sehr viele Konventionen möglich. Zu nennen sind hier die Normen
ISO 8601, eine Fülle damit verwandter nationaler Normen oder die "Unix-Time". Eine für die Datenverarbeitung geeignete Systematisierung der Zeitformate mittels einer Ontologie wird in dem Dokument "Time Ontology in OWL" beschrieben, erhältlich im Internet am 27.07.2013 unter
http://www.w3.org/TR/owl-time. Ob mit dieser oder einer anderen Formalisierung, wichtig ist, dass das Zeitformat 932 des Zeitstempels 93 innerhalb der Informationseinheit 90 explizit angegeben wird, um Interpretationsfehler zu vermeiden.
Ebenso muss im Zeitstempel 93 vermerkt sein, auf welche Uhr 931 sich der Zeitstempel 93 bezieht. Module (z.B. Sensoren), in denen Zeitstempel 93 vergeben werden, haben häufig ihre eigene Uhr 931. In diesem Fall muss diese Uhr 931 im Zeitstempel 93 angegeben werden. Damit im Entwurfssystem überprüft werden kann, ob zwei Zeitstempel 93 zu einander kompatibel sind, und ob bzw. wie sich die durch diese Zeitstempel 93 annotierten Informationseinheiten 90 fusionieren lassen, müssen die jeweiligen Uhren 931 genannt und eindeutig identifiziert sein.
Dann kann im Entwurfssystem nach einer aktuell gültigen In- formation gesucht werden, die eine Aussage über die Zeitdifferenz zwischen den beteiligten Uhren 931 macht, d.h. eine Aussage über die Kalibrierung der Uhren 931. Da diese Kalibrierung meist selbst das Ergebnis einer Messung ist, ist die Zeitdifferenz zwischen zwei Uhren 931 im Allgemeinen eine Zu- fallsvariable.
Das Entwurfssystem kann ferner überprüfen, ob jeder Header 92 einer Informationseinheit 90 im System einen Zeitstempel 93 in einem bekannten Format aufweist.
Bei der Verknüpfung von zwei Informationseinheiten kann das Entwurfssystem überprüfen, ob beide Zeitstempel-Formate gleich sind oder durch im Entwurfssystem vorhandene Formatumsetzer in das gleiche Format gebracht werden können. Ebenso wird überprüft, ob beide Zeitstempel 93 sich auf die gleiche Uhr 931 beziehen, oder ob im Entwurfssystem eine Information über die Synchronizität der beiden verwendeten Uhren vorliegt, die es erlaubt, beide Zeitstempel 93 auf die gleiche Uhr 931 zu beziehen, die dann auch für eine aus den beiden Informationseinheiten hergeleitete Informationseinheit verwendet werden kann. Figur 5 zeigt die Herkunftsangabe 94 aus Figur 3 im Detail. Es muss berücksichtigt werden, ob Informationseinheiten, die in einem Modul zusammengeführt werden, eine gemeinsame Herkunft aufweisen. Andernfalls wird in der Regel die Sicherheit der resultierenden Information überschätzt. Im Falle, dass die fusionierten Informationen durch Normalverteilungen dargestellt werden, ergibt sich unter der Annahme der Unabhängigkeit eine stärker konzentrierte Kovarianzmatrix, als wenn die Abhängigkeit berücksichtigt würde. Daher wird für jede Informationseinheit, die entweder Sensordaten enthält oder direkt oder indirekt von Sensordaten hergeleitet wird, die Herkunft der Information in der Herkunftsangabe 94 vermerkt. Die Herkunftsangabe 94 beinhaltet entweder den Sensor, der den entsprechenden Messwert geliefert hat, oder - wie in Figur 5 gezeigt - einen Operator 940, mittels dem die Nutzdaten 91 hergeleitet wurden, sowie die in diese Operation eingeflossenen Quell-Informationseinheiten 941...94n. Das Entwurfssystem erhält durch Zusammensetzung dieser Herkunftsangaben 94 ein Netz der Herleitungen und Abhängigkeiten, in dem in sehr vielen Fällen die einzelnen Zufallsvariablen genau berechnet werden können. Insbesondere im aktuellen Forschungsgebiet der "Graphical Models" sind hierzu in den letzten Jahren gute Fortschritte erzielt worden, die von dem Entwurfssystem für Fahrerassistenzsysteme genutzt werden können .
Ein einfaches Beispiel ist die Herleitung einer normalver- teilten Zufallsvariablen (z. B. einer Längenmessung), die auf drei normalverteilten Beobachtungen {z1,z2,z3} beruht, in zwei Schritten. Die Beobachtung bzw. hergeleitete Größe hat also die Verteilung Zj~JV(ij, Zj) . Mit der üblichen Fusionierung nach dem Prinzip der "Maximum Likelihood Estimation" ist die fusionierte Information aus z^nd z2 normalverteilt mit dem Mittelwert
i4 = (ΣΓ1 + Σ2 1)"1 · Σ2 · + (Σ 1 + Σ2 · Σ1 · i2
und der Kovarianzmatrix
Σ4 = (ΣΓ1 + Σ2 1)"1.
Entsprechend ergibt die Fusionierung von z2und z3 die normal - verteilte Zufallsvariable z5 mit
is = (Σ2 1 + Σ3 Χ) 1 · Σ3 · i2 + (Σ2 1 + Σ3 Χ) 1 · Σ2 · i3
und
Σ5 = (Σ2 1 + Σ3 1)"1 .
Fusioniert man diese beiden Zwischenergebnisse unter der An- nähme der Unabhängigkeit, dann erhält man die Kovarianzmatrix Σ6 = (Σί1 + Σ5 = (Σ 1 + 2 · Σ2 1 + .
Fusioniert man die Informationen unter Berücksichtigung der Abhängigkeiten, dann erhält man
Σ7 = (Σ 1 + Σ2 1 + Σ3 1)"1,
man sieht also, dass die zweite Information doppelt verwendet wurde .
Nachdem das Entwurfssystem wie oben beschrieben die Abhängig- keiten ermittelt hat, kann es also aus dem Fusionsergebnis unter Annahme der Unabhängigkeit das richtige Ergebnis dadurch ermitteln, dass es die doppelt verwendete Information einmal wieder abzieht. Das Entwurfssystem unterstützt die Entdeckung und Kompensation von verborgenen Abhängigkeiten in der Herleitung durch die Analyse des Herleitungsgraphen, der aus den formal gegebenen Herkunftsangaben 94 über die Quelle der Informationseinheiten 90 aufgebaut wird. In diesem Graphen werden durch entspre- chende Graphenalgorithmen rekonvergente Zweige und damit Abhängigkeiten entdeckt. Weiter kann das EntwurfsSystem Algorithmen aus dem Gebiet der "Graphical Models" enthalten, die analog dem im vorigen Abschnitt gegebenen Beispiel die korrekte Information aufgrund der ermittelten Abhängigkeiten herleiten.
Im Folgenden wird erneut auf Figur 3 Bezug genommen. Diejenigen Nutzdaten 91, die entweder unmittelbar aus Sensordaten bestehen oder aus Sensordaten hergeleitet werden, sind in der Regel nicht sicher. Sie sind möglicherweise verrauscht und weisen eine gewisse Streuungsbreite auf, oder sie entsprechen gar keinem physikalischen Phänomen (d.h. sie sind Artefakte), oder sie entsprechen einem Phänomen der physikalischen Welt, das aber in einer gegebenen Umgebungsrepräsentation 6 nicht gespiegelt wird.
Es ist also sinnvoll, mit der Plausibilität 95 im Header 92 eine Metainformation darüber zu geben, wie sehr einer gegebenen Informationseinheit 90 bzw. deren Nutzdaten 91 getraut werden soll. Falls die Nutzdaten 91 eine Wahrscheinlichkeits - dichteverteilung aufweisen, kann die Plausibilität 95 auch als gleichverteilte Komponente einer Mischverteilung repräsentiert werden. Nachdem aber auch Aspekte der Welt beschrieben werden sollen, die am besten durch Relationen ausgedrückt werden, welchen nicht ohne weiteres auf natürliche Weise eine Wahrscheinlichkeitsdichteverteilung zugewiesen werden kann, wird die Plausibilität 95 als Bestandteil des Headers 92 für jede Informationseinheit 90 im Entwurfssystem gefordert. Die Plausibilität 95 wird bei Fusionierung, Verknüpfung oder Weiterverarbeitung der Informationseinheiten 90 ebenfalls verknüpft. Die hierbei anzuwendenden VerknüpfungsregeIn liegen dabei nicht a priori fest, sondern sie richten sich nach den Inhalten der Nutzdaten 91. Das Entwurfssystem berechnet daher nach den für die jeweiligen Nutzdaten 91 geeigneten
Verknüpfungsregeln zur Herleitung einer neuen Informationseinheit 90 eine Plausibilität 95 ausgehend von den Plausibi- litäten 95 der in die Herleitung einfließenden Informationseinheiten 90.
Die Verknüpfungsregeln für die Plausibilität 95, die für ei- nen gegebenen Typ von Nutzdaten 91 der Informationseinheiten 90 angewendet werden sollen, sind im Entwurfssystem abgelegt. Damit unterstützt das Entwurfssystem die korrekte Komposition von Herleitungen im Gesamtsystem der verschiedenen Fahrerassistenzsysteme .
Für jede Informationseinheit 90 wird im Zeitstempel 93 vermerkt, zu welchem Zeitpunkt die jeweiligen Nutzdaten 91 für gültig gehalten werden sollen. Wenn zwei (oder mehr) Informationseinheiten 90 fusioniert werden sollen, müssen diese Zeitpunkte zusammenpassen. Allerdings werden in der Regel die Zeitstempel 93 nicht völlig übereinstimmen. Daher müssen Informationseinheiten 90, die fusioniert werden sollen, auf einen gemeinsamen neuen Zeitstempel 93 normalisiert werden. Hierzu wird die Zeitskala 96 im Header 92 benötigt.
Die Zeitskala 96 einer Informationseinheit 90 gibt an, in welcher Weise und in welchem Ausmaß die Nutzdaten 91 „veralten". Dies hängt vom Inhalt der Nutzdaten 91 ab. Wenn die Nutzdaten 91 z.B. die Position eines Gebäudes betreffen, dann ist die Zeitskala 96 "lang": es ist nicht zu erwarten, dass sich die tatsächliche Position des Gebäudes innerhalb der Dauer einer Ausführung der Fahrerassistenzfunktion verändert.
Wenn die Nutzdaten 91 dagegen ein Fahrzeug betreffen, etwa eine Schätzung des Ortes eines anderen Fahrzeugs, dann wird bei bewegten Fahrzeugen die Ortsschätzung zunehmend unzutreffender, je länger die entsprechende Messung zurückliegt. Ein Spezialfall dieser Betrachtung ist das Prozessrauschen im Kaimanfilter, das die Zunahme der Unsicherheit durch die Ad- dition eines zusätzlichen Rauschens ausdrückt.
Technisch kann die Zeitskala 96 implementiert werden als eine Abbildung 0:(xt,AT)—> %t+AT einer Zufallsvariablen xt auf eine Zufallsvariable Xt+ΔΤ > wobei die zweite Zufallsvariable in der Regel eine größere Streuung aufweist.
Da die Informationseinheiten 90 im Entwurfssystem auf einer Metaebene ihrer Bedeutung nach durch die Header 92 charakterisiert werden, kann das Entwurfssystem einem Entwickler geeignete Zeitskalen 96 für die jeweilige Zufallsvariable, welche als Nutzdaten 91 in der Informationseinheit 90 enthalten ist, vorschlagen. Dieser Vorschlag kann auf Langzeitbeobach- tungen des tatsächlichen typischen Verlaufs der Zufallsvariablen mit dieser bestimmten Interpretation auf der Metaebene beruhen. Die Zeitskalen 96 können also gelernt werden.
Figur 6 zeigt die Nutzdaten 91 aus Figur 3 im Detail. Hierbei kann es sich um unterschiedliche Informationen handeln. Zum Einen werden die Inhalte der Fahrerassistenzsysteme selbst modelliert bzw. mit semantischer Metainformation versehen. Zum Anderen werden auch verschiedene Aspekte der Umwelt, des Fahrzeugs oder des Fahrers modelliert. Da die Nutzdaten 91 somit von sehr verschiedener Art sein können, sind in den
Nutzdaten 91 von Fall zu Fall andere Strukturelemente enthalten. Wesentlich dabei ist, dass die Unsicherheit der Nutzdaten 91 angemessen repräsentiert wird. Nutzdaten 91, die physikalische Sachverhalte wiederspiegeln (z.B. eine gemessene Distanz), lassen sich im Allgemeinen nicht mit einer Zahl erfassen, sondern sind meistens aus Messungen gewonnene Zufallsvariablen. Daher werden diese Variablen auch als Zufallsvariablen modelliert und so als Wert 915 in die Nutzdaten 91 eingetragen, dass auch die Wahrscheinlichkeitsdichtefunktion explizit angegeben wird. Als Approximation an extrem wenig streuende Zufallsvariablen ist auch die Dirac -Verteilung zulässig. Analog gilt das auch für nicht streng physikalische Sachverhalte, wie z.B. einen Ermüdungs- zustand des Fahrers, Grad der Ungeduld eines anderen Verkehrsteilnehmers, etc. Für Nutzdaten 91, die physikalische Gegebenheiten beschreiben, wird eine Einheit für die physikalische Größe (also z.B. für einen Entfernungswert die SI -Maßeinheit m) beispielsweise im Kommentarfeld 911 in die Datenstruktur der Nutzdaten 91 aufgenommen .
Weiterhin muss die Datenstruktur der Nutzdaten 91 eine Kodierung 914 der Nutzdaten 91 angeben, sofern hierfür unterschiedliche Möglichkeiten vorliegen (z.B. für Längenmessung eine lineare oder eine logarithmische Skala) . Auch bei der Beschreibung von Position und Orientierung im Raum gibt es eine große Anzahl durchaus geläufiger Kodierungen. Hier ist die Angabe im Feld Kodierung 914 erforderlich um Fehler zu vermeiden .
Ggf. muss die Datenstruktur der Nutzdaten 91 auch eine formale Spezifikation eines Kontexts der Nutzdaten 91 angeben - z.B. bei einem Abstandswert das Objekt, von dem aus gemessen wird, und das Objekt, bis zu dem hin gemessen wird, wie im Folgenden noch beschrieben wird.
Angaben zu Auflösung, Diskretisierung und mögliche Datentypen in der Implementierung, sowie zu einem Rechenbedarf eines Datenverarbeitungsschrittes (z.B. Schätzung der Anzahl der Ope- rationen in einem Rechenwerk und der Anzahl der Speicherzugriffe) können ebenfalls erforderlich sein und werden beispielsweise im Kommentarfeld 911 hinterlegt.
Ohne Einschränkung der Allgemeinheit wird im Folgenden anhand der Figuren 3 bis 6 ein Beispiel für die Ausgestaltung einer Informationseinheit 90 mit einem Header 92 und Nutzdaten 91 zum Zwecke einer Entfernungsangabe dargestellt.
Eine Entfernungsangabe bezeichnet einen Abstand zwischen zwei verschiedenen Objekten. Nachdem die Objekte nicht am gleichen Ort bleiben müssen, gehört zur Entfernungsangabe auch der Zeitpunkt, zu dem eine gewisse Entfernung gegeben war. Ebenso lässt sich den Umständen entnehmen, welche Gültigkeitsdauer der getroffenen Aussage über die Entfernung beizumessen ist. Diese Aspekte betreffen alle Aussagen, die von Sensoren direkt oder auf dem Wege der Herleitung innerhalb von Fahrerassistenzfunktionen getroffen werden, und sie werden deshalb im Header 92 zusammengefasst , wie dies bereits zuvor erläutert wurde. Die jeweils unterschiedlichen Aspekte einer Messung bzw. einer aus den Messungen hergeleiteten Aussage finden sich hingegen in den Nutzdaten 91 selbst. Beispielsweise geht aus verschiedenen Sensormessungen hervor, dass der (kürzeste) Abstand zwischen Fahrzeug und einem Hindernis in der Umgebung (z.B. Baum Nr. 15 aus einer Objektliste) 5.32m beträgt. Dann enthält der Header 92 als Plausibili- tät 95, dass diese Aussage gilt (z.B. in einem Bereich von 0 bis 1 den Plausibilitätswert 0.99 im Feld Plausibiltät 95).
Im Zeitstempel 93 wird eingetragen, dass die Aussage galt zum Zeitpunkt 2013/05/26/17/59/234/345 (als Parameter 933 aus Figur 4) MESZ (als Zeitformat 932 aus Figur 4) nach der Uhr des Navigationsrechners im Fahrzeug (als Uhr 931 aus Figur 4) . Aus der Fahrzeuggeschwindigkeit und dem Typ des Objekts soll folgen, dass die Plausibilität 95 dieser Aussage sich alle 0.2s halbiert. Diese Information wird als Zeitskala 96 im Header 92 hinterlegt. Die Herkunftsangabe 94 zeigt an, dass der Abstandswert aus einer Folge von Messungen gefolgert wird, wobei als Operator 940 (vgl. Figur 5) der Fusionsoperator angegeben wird, der den letzten Inferenzschritt ausgeführt hat; weiter sind alle Quell - Informationseinheiten 941...94n (vgl. Figur 5) aufgelistet, aus denen der Operator 940 die Inferenz gebildet hat.
Die Nutzdaten 91 selbst hingegen enthalten die spezifischen Angaben zu dieser Aussage und sind in ihrem schematischen Aufbau in Figur 6 auf der linken Seite gezeigt. Als Referenz 912, d.h. als Bezugspunkt, wird das Fahrzeug und als
Referenzierer 913, d.h. ein Objekt, welches sich auf den Bezugspunkt bezieht, ein Baum Nr. 15 in die Datenstruktur eingetragen. Naturgemäß ist der Abstandswert eine Zufallsvariable - der wahre Abstand ist möglicherweise im Mittel der ange- gebene Wert, Abweichungen sind jedoch möglich. Es wird daher als Wert 915 eine approximierende Wahrscheinlichkeitsdichteverteilung (WDV) angegeben. Der Wert 915 ist im rechten Teil der Figur 6 detailliert gezeigt. Neben einem WDV-Kommentarfeld 916 ist als WDV-Typ 917 beispielsweise eine Normalverteilung und als WDV- Parameter 918 ein Mittelwert 5.32 und eine Varianz 0.1 eingetragen. Das Entwurfssystem unterstützt einen Entwickler zum Beispiel, indem Plausibilitat und Konsistenz hergeleiteter Größen durch Inferenz über den zuvor erläuterten Metainformationen, welche den jeweiligen Informationseinheiten 90 entnommen werden, überprüft wird. Bei einer Positionsschätzung, die sich durch Komposition zweier Positionsschätzungen ergibt, überprüft das Entwurfssystem, ob der Referenzierer der ersten Positionsschätzung gleich der Referenz der zweiten Positionsschätzung ist, d.h. ob die Komposition in der richtigen Reihenfolge ausgeführt ist.
Ebenso wie die übrigen Daten sind auch die Daten in der in Figur 2 gezeigten Umgebungsrepräsentation 6 explizit auf der Metaebene wie im Kontext der Figuren 3 bis 6 erläutert beschrieben. Dies gilt also auch für den Zeitstempel 93, zu dem Informationen für gültig gehalten werden und für die Zeitskala 96.
Beispielsweise handelt es sich bei der Umgebungsrepräsentation 6 um eine Belegungsgitterkarte. Dann werden zusätzlich in den Nutzdaten 91 die Größe der Gitterzellen, die Anzahl der Gitterzellen, und die Belegungswahrscheinlichkeit vermerkt. Für die Belegungswahrscheinlichkeit sind unterschiedliche Optionen möglich, die je nach Einsatzzweck gewählt werden. Wie auch bei den Aussagen über den Abstand wird der Typ der Wahr- scheinlichkeitsdichteverteilung explizit genannt.
Zuvor wurde beschrieben, dass die Informationseinheit 90 als Nutzdaten 91 Sensordaten oder z.B. eine Entfernungsangabe enthalten kann. Aus solchen Informationseinheiten 90 lassen sich durch Herleitung komplexere Informationseinheiten 90 bilden, welche höher aggregierte Nutzdaten 91 enthalten als die in die Herleitung eingeflossenen Informationseinheiten 90. Die hergeleitete Informationseinheit 90 kann eine Objekthypothese enthalten, während die eingeflossenen Informationseinheiten 90 einzelne Merkmale enthalten. In diesem Sinne kann eine Informationseinheit 90 auch eine Gitterkarte und somit die Umgebungsrepräsentation 6 selbst enthalten. Alter- nativ kann auch jede einzelne Gitterzelle durch eine Informationseinheit 90 modelliert werden.
Die beschriebenen Ausführungsbeispiele, Ausführungsformen, Varianten und Weiterbildungen lassen sich frei miteinander kombinieren.

Claims

Patentansprüche
1. EntwurfsSystem für ein Fahrerassistenzsystem,
umfassend mindestens ein Modul, eingerichtet zur Erzeugung realer Sensordaten (4) oder virtueller Sensordaten (40) , und
umfassend mindestens ein Modul, eingerichtet zur rechnergestützten Ableitung einer Umgebungsrepräsentation (6) aus den realen Sensordaten (4) oder virtuellen Sensordaten (40),
dadurch gekennzeichnet, dass
das Entwurfssystem zur rechnergestützten Verarbeitung maschinenlesbarer semantischer Metadaten eingerichtet ist, welche Eigenschaften der realen Sensordaten (4) und/oder der virtuellen Sensordaten (40) und/oder von Daten in der
Umgebungsrepräsentation (6) beschreiben, und
das Entwurfssystem eingerichtet ist zur rechnergestützten Überprüfung und/oder Sicherstellung einer Gültigkeit von Daten in der Umgebungsrepräsentation (6) anhand der seman- tischen Metadaten.
2. Entwurfssystem nach Anspruch 1,
mit einem Speicher und mit einem Mikroprozessor, welcher programmiert ist zur Abspeicherung
- der realen Sensordaten (4) oder der virtuellen Sensordaten (40) , oder
von Daten in der Umgebungsrepräsentation (6) , oder von weiteren Daten, welche in den Modulen enthalten sind,
jeweils als Nutzdaten (91) in einer Informationseinheit
(90) in dem Speicher,
wobei jede Informationseinheit (90) einen Header (92) aufweist, welcher zumindest einige der folgenden semantischen Metadaten enthält, welche Eigenschaften der Nutzdaten (91) beschreiben:
ein Zeitstempel (93), welcher angibt, zu welchem Zeitpunkt die Nutzdaten (91) gültig sind oder waren, eine Herkunftsangabe (94), welche einen Sensor bezeichnet, von dem die Nutzdaten (91) erzeugt wurden, oder
mindestens einen Operator (940) und Quell - Informationseinheiten (941...94n) angibt, anhand derer die Nutzdaten (91) hergeleitet wurden,
eine Plausibilität (95), welche angibt, in welchem Umfang sich nachfolgende Inferenzschritte auf die Nutzdaten (91) stützen dürfen, und/oder
eine Zeitskala (96), welche angibt, wie sich die Plausibilität (95) der Nutzdaten (91) zeitlich entwickelt.
Entwurfssystem nach Anspruch 2,
bei dem der Header (92) sämtliche der in Anspruch 2 genannten semantischen Metadaten enthält.
Entwurfssystem nach Anspruch 2 oder 3,
bei dem in dem Header (92) oder in dem Zeitstempel (93) ein Zeitformat (932) des Zeitstempels (93) abgespeichert ist, und
bei dem in dem Header (92) oder in dem Zeitstempel (93) eine Uhr (931), auf welche sich der Zeitstempel (93) bezieht, angegeben ist.
Entwurfssystem nach Anspruch 4,
bei dem der Mikroprozessor programmiert ist zur Überprüfung für alle Informationseinheiten (90), ob der Zeitstempel (93) vorhanden ist und das Zeitformat (932) des Zeitstempels (93) bekannt ist, und
bei dem der Mikroprozessor programmiert ist
zur Verknüpfung einer ersten und einer zweiten Informationseinheit mit einem Herleitungsoperator,
zur Herleitung einer dritten Informationseinheit aus der Verknüpfung, und
zur Abspeicherung der dritten Informationseinheit in dem Speicher,
wobei der Mikroprozessor programmiert ist zur Überprüfung, ob das Zeitformat (932) des Zeitstempels (93) der ersten Informationseinheit mit dem Zeitformat (932) des Zeitstempeis (93) der zweiten Informationseinheit übereinstimmt, und andernfalls zur Konvertierung des Zeit- stempels (93) der ersten Informationseinheit in das Zeitformat (932) des Zeitstempels (93) der zweiten Informationseinheit ,
wobei der Mikroprozessor programmiert ist zur Überprüfung, ob die Uhr (931) des Zeitstempels (93) der ersten Informationseinheit mit der Uhr (931) des Zeitstempels (93) der zweiten Informationseinheit identisch ist, und andernfalls zur Umrechnung des Zeitstempels (93) der ersten Informationseinheit anhand einer bekannten Abweichung der Uhren, sodass er sich ebenfalls auf die Uhr (931) des Zeitstempels (93) der zweiten Informationseinheit bezieht, und
wobei der Mikroprozessor programmiert ist zur Normalisierung des Zeitstempels (93) der ersten Informationseinheit und des Zeitstempels (93) der zweiten Informationseinheit unter Berücksichtigung der Zeitskalen (96) der ersten Informationseinheit und der zweiten Informationseinheit auf einen gemeinsamen neuen Zeitstempel, und zur Abspeicherung des gemeinsamen neuen Zeitstempels im Header (92) der dritten Informationseinheit im Speicher . 6. Verfahren zum Entwurf eines Fahrerassistenzsystems,
bei dem mindestens ein Modul reale Sensordaten (4) oder virtuelle Sensordaten (40) erzeugt,
bei dem mindestens ein Modul aus den realen Sensordaten (4) oder den virtuellen Sensordaten (40) rechnergestützt eine Umgebungsrepräsentation (6) ableitet,
dadurch gekennzeichnet, dass
das Entwurfssystem maschinenlesbare semantische Metadaten rechnergestützt verarbeitet, welche Eigenschaften der realen Sensordaten (4) und/oder der virtuellen Sensordaten (40) und/oder der Umgebungsrepräsentation (6) beschreiben, und das Entwurfssystem anhand der semantischen Metadaten rechnergestützt eine Gültigkeit von Daten in der Umgebungsrepräsentation (6) überprüft und/oder sicherstellt.
Verfahren nach Anspruch 6,
bei dem das Entwurfssystem
die realen Sensordaten (4) oder die virtuellen Sensordaten (40) oder
Daten in der Umgebungsrepräsentation (6) oder
weitere Daten, welche in den Modulen enthalten sind, jeweils als Nutzdaten (91) in einer Informationseinheit (90) speichert,
wobei jede Informationseinheit (90) einen Header (92) aufweist, welcher zumindest einige der folgenden semantischen Metadaten enthält, welche Eigenschaften der Nutzdaten (91) beschreiben :
ein Zeitstempel (93), welcher angibt, zu welchem Zeitpunkt die Nutzdaten (91) gültig sind oder waren, eine Herkunftsangabe (94), welche
einen Sensor bezeichnet, von dem die Nutzdaten (91) erzeugt wurden, oder
mindestens einen Operator (940) und Quell - Informationseinheiten (941...94n) angibt, anhand derer die Nutzdaten (91) hergeleitet wurden,
eine Plausibilität (95), welche angibt, in welchem Umfang sich nachfolgende Inferenzschritte auf die Nutzdaten (91) stützen dürfen, und/oder
eine Zeitskala (96), welche angibt, wie sich die Plausibilität (95) der Nutzdaten (91) zeitlich entwickelt.
8. Verfahren nach Anspruch 7 ,
bei dem der Header (92) sämtliche der in Anspruch 7 genannten semantischen Metadaten enthält. 9. Verfahren nach Anspruch 7 oder 8,
bei dem in dem Header (92) oder in dem Zeitstempel (93) ein Zeitformat (932) des Zeitstempels (93) abgespeichert wird, und bei dem in dem Header (92) oder in dem Zeitstempel (93) eine Uhr (931), auf welche sich der Zeitstempel (93) bezieht, angegeben wird.
Verfahren nach Anspruch 9,
bei dem das Entwurfssystem rechnergestützt für alle Informationseinheiten (90) überprüft, ob der Zeitstempel (93) vorhanden ist und das Zeitformat (932) des Zeitstempels (93) bekannt ist, und
bei dem das Entwurfssystem eine erste und eine zweite Informationseinheit mit einem Herleitungsoperator verknüpft und dadurch eine dritte Informationseinheit herleitet, wobei das Entwurfssystem überprüft, ob das Zeitformat (932) des Zeitstempels (93) der ersten Informationseinheit mit dem Zeitformat (932) des Zeitstempels (93) der zweiten Informationseinheit übereinstimmt, und den Zeitstempel (93) der ersten Informationseinheit andernfalls in das Zeitformat (932) des Zeitstempels (93) der zweiten Informationseinheit konvertiert,
wobei das Entwurfssystem überprüft, ob die Uhr (931) des Zeitstempels (93) der ersten Informationseinheit mit der Uhr (931) des Zeitstempels (93) der zweiten Informationseinheit identisch ist, und den Zeitstempel (93) der ersten Informationseinheit andernfalls anhand einer bekannten Abweichung der Uhren umrechnet, sodass er sich ebenfalls auf die Uhr (931) des Zeitstempels (93) der zweiten Informationseinheit bezieht, und wobei das Entwurfssystem den Zeitstempel (93) der ersten Informationseinheit und den Zeitstempel (93) der zweiten Informationseinheit unter Berücksichtigung der Zeitskalen (96) der ersten Informationseinheit und der zweiten Informationseinheit auf einen gemeinsamen neuen Zeitstempel normalisiert, welcher im Header (92) der dritten Informationseinheit abgespeichert wird.
11. Verfahren nach einem der Ansprüche 7 bis 10,
bei dem das Entwurfssystem für eine Informationseinheit (90) anhand der Herkunftsangabe (94) sowie der Herkunfts- angaben (94) in den Quell-Informationseinheiten (941...94n), aus denen die Informationseinheit (90) hergeleitet wurde, rekursiv einen Herleitungsgraphen erstellt,
bei dem das Entwurfssystem durch Graphenalgorithmen rekonvergente Zweige in dem Herleitungsgraphen identifiziert, und
bei dem das Entwurfssystem Abhängigkeiten, welche sich aus den rekonvergenten Zweigen im Herleitungsgraphen ergeben, durch eine Modifikation der Herleitung der Informations - einheit (90) kompensiert.
12. Verfahren nach einem der Ansprüche 7 bis 11,
bei dem das Entwurfssystem eine erste und eine zweite Informationseinheit mit einem Herleitungsoperator verknüpft und dadurch eine dritte Informationseinheit herleitet, und bei dem das Entwurfssystem in Abhängigkeit von dem Herleitungsoperator die Plausibilität (95) der dritten Informationseinheit aus den Plausibilitäten (95) der ersten und der zweiten Informationseinheit berechnet.
3. Verfahren nach einem der Ansprüche 7 bis 12,
bei dem das Entwurfssystem anhand einer Langzeitbeobachtung eines typischen Verlaufs einer Zufallsvariable eine geeignete Zeitskala durch maschinelles Lernen ermittelt, und
bei dem das Entwurfssystem einem Entwickler bei der Definition einer neuen Informationseinheit, in welcher die Zufallsvariable abgespeichert werden soll, die geeignete Zeitskala zur Eintragung als Zeitskala (96) im Header (92) vorschlägt .
4. Computerlesbarer Datenträger,
auf dem ein Computerprogramm gespeichert ist, welches das Verfahren nach einem der Ansprüche 6 bis 13 ausführt, wenn es in einem Mikroprozessor abgearbeitet wird.
15. Computerprogramm, welches in einem Mikroprozessor abgearbeitet wird und dabei das Verfahren nach einem der Ansprüche 6 bis 13 ausführt .
PCT/EP2014/057600 2013-05-16 2014-04-15 Entwurfssystem und verfahren zum entwurf eines fahrerassistenzsystems WO2014183945A1 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
DE102013209148.6 2013-05-16
DE102013209148 2013-05-16
DE201310215115 DE102013215115A1 (de) 2013-05-16 2013-08-01 Entwurfssystem und Verfahren zum Entwurf eines Fahrerassistenzsystems
DE102013215115.2 2013-08-01

Publications (1)

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

Family

ID=51831426

Family Applications (5)

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

Family Applications After (4)

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

Country Status (2)

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

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102014209340A1 (de) * 2014-05-16 2015-11-19 Siemens Aktiengesellschaft Anordnung und Verfahren zur Sensorfusion
DE102015010270B4 (de) 2015-08-08 2021-10-28 Audi Ag Verfahren zum Betrieb von Fahrerassistenzsystemen in einem Kraftfahrzeug und Kraftfahrzeug
US10229363B2 (en) 2015-10-19 2019-03-12 Ford Global Technologies, Llc Probabilistic inference using weighted-integrals-and-sums-by-hashing for object tracking
DE102016202317A1 (de) * 2016-02-16 2017-08-17 Continental Teves Ag & Co. Ohg Verfahren zum steuern von fahrzeugfunktionen durch ein fahrerassistenzsystem, fahrerassistenzsystem und fahrzeug
DE102016205392A1 (de) 2016-03-31 2017-10-05 Siemens Aktiengesellschaft Verfahren und System zur Validierung eines Hinderniserkennungssystems
CN107310550B (zh) * 2016-04-27 2019-09-17 腾讯科技（深圳）有限公司 道路交通工具行驶控制方法和装置
EP3260999B1 (de) * 2016-06-24 2021-08-04 Sick Ag System zum simulieren von sensoren
WO2018063250A1 (en) * 2016-09-29 2018-04-05 The Charles Stark Draper Laboratory, Inc. Autonomous vehicle with modular architecture
US10377375B2 (en) 2016-09-29 2019-08-13 The Charles Stark Draper Laboratory, Inc. Autonomous vehicle: modular architecture
US10599150B2 (en) 2016-09-29 2020-03-24 The Charles Stark Kraper Laboratory, Inc. Autonomous vehicle: object-level fusion
US10101745B1 (en) 2017-04-26 2018-10-16 The Charles Stark Draper Laboratory, Inc. Enhancing autonomous vehicle perception with off-vehicle collected data
DE102017208692B4 (de) 2017-05-23 2023-02-02 Audi Ag Verfahren zum Bereitstellen von Trainingsdaten für eine Funktionsprüfung einer Erkennungseinrichtung sowie Datenbanksystem
DE102017116016A1 (de) * 2017-07-17 2019-01-17 Valeo Schalter Und Sensoren Gmbh Kraftfahrzeug-Sensorvorrichtung mit mehreren Sensoreinheiten und einem neuronalen Netz zum Erzeugen einer integrierten Repräsentation einer Umgebung
DE102017116017A1 (de) * 2017-07-17 2019-01-17 Valeo Schalter Und Sensoren Gmbh Kraftfahrzeug-Sensorvorrichtung mit mehreren Sensoreinheiten und mehreren neuronalen Netzen zum Erzeugen einer kombinierten Repräsentation einer Umgebung
DE102018205804A1 (de) * 2018-04-17 2019-10-17 Conti Temic Microelectronic Gmbh Steuergerätetesteinrichtung zum Testen, Absichern und Entwickeln von Funktionen
DE102018206326B4 (de) * 2018-04-24 2020-01-09 Zf Friedrichshafen Ag Verfahren zum Erweitern einer Datenbasis eines Bayesschen Netzes
DE102018123735A1 (de) * 2018-09-26 2020-03-26 HELLA GmbH & Co. KGaA Verfahren und Vorrichtung zum Verbessern einer Objekterkennung eines Radargeräts
DE102018123779A1 (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
DE102022209080A1 (de) 2022-09-01 2024-03-07 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Kalibrieren eines Sensors, Recheneinheit und Sensorsystem

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006089941A1 (de) 2005-02-25 2006-08-31 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

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3931879B2 (ja) 2003-11-28 2007-06-20 株式会社デンソー センサフュージョンシステム及びそれを用いた車両制御装置
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

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006089941A1 (de) 2005-02-25 2006-08-31 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
WO2007017308A1 (de) 2005-08-05 2007-02-15 Robert Bosch Gmbh Verfahren zum erzeugen von umwelthypothesen für fahrerassistenzfunktionen

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
B. SCHICK ET AL: "Simulationsmethoden zur Evaluierung und Verifizierung von Funktion, Güte und Sicherheit von Fahrerassistenzsystemen im durchgängigen MIL-, SIL-, und HIL-Prozess", 3. TAGUNG AKTIVE SICHERHEIT DURCH FAHRERASSISTENZ, 31 December 2008 (2008-12-31), München, pages 1 - 14, XP055072518 *
COMPTON: "The SSN ontology of the W3C semantic sensor network incubator group", WEB SEMANTICS: SCIENCE, SERVICES AND AGENTS ON THE WORLD WIDE WEB, vol. 17, December 2012 (2012-12-01), pages 25 - 32
MATTHIAS GOEBL ET AL: "Eine leistungsfähige Hard- und Softwarearchitektur für kognitive Funktionen in Fahrzeugen", 5. WORKSHOP FAHRERASSISTENZSYSTEME (FAS), 4 April 2008 (2008-04-04), pages 30 - 37, XP055131255, Retrieved from the Internet <URL:http://home.rcs.ei.tum.de/publications/papers/rtsg/rattei/fas.pdf> [retrieved on 20140723] *
THRUN; BURGARD; FOX: "Probabilistic Robotics", 2005, MIT PRESS
TIME ONTOLOGY IN OWL, 27 July 2013 (2013-07-27), Retrieved from the Internet <URL:http://www.w3.org/TR/owl-time>

Also Published As

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

Similar Documents

Publication Publication Date Title
WO2014183945A1 (de) Entwurfssystem und verfahren zum entwurf eines fahrerassistenzsystems
DE112018006161B4 (de) System und Verfahren zum Steuern eines Fahrzeugs
WO2017016799A1 (de) Bestimmung einer anordnungsinformation für ein fahrzeug
EP3438901A1 (de) Testfahrtszenario-datenbanksystem für realitätsnahe virtuelle testfahrtszenarien
DE112017000787T5 (de) Verfahren zum Steuern der Bewegung eines Fahrzeugs und Fahrzeugsteuersystem
DE102014220843B4 (de) Vorhersage der strassencharakteristik
DE102018219773B4 (de) Verfahren zum Kartographieren einer örtlichen Verteilung von Ereignissen eines vorbestimmten Ereignistyps in einem vorbestimmten Umgebungsbereich eines Kraftfahrzeugs sowie dazu ausgelegtes Steuergerät und Kraftfahrzeug
DE102018100487A1 (de) Objektverfolgung durch unüberwachtes lernen
DE112013001803T5 (de) Selbsteinstellendes universales Lenksteuerungssystem, - verfahren und -system für Geländefahrzeuge
DE102017129501A1 (de) Autonome Kraftfahrzeug-Objekterkennung
DE102010011982A1 (de) Verfahren zum rechnergestützten Erstellen und/oder Aktualisieren einer Referenzkarte für eine satellitengestützte Ortung eines Objekts
WO2019072619A1 (de) Verfahren und vorrichtung zum ermitteln eines reibwertes einer fahrbahn
DE102020128818A1 (de) Verbesserte dimensionierung von komponenten
DE102017222568A1 (de) Verfahren zum Bestimmen eines Reibwerts für einen Kontakt zwischen einem Reifen eines Fahrzeugs und einer Fahrbahn und Verfahren zum Steuern einer Fahrzeugfunktion eines Fahrzeugs
EP2749982B1 (de) Bezugsmodellerzeugung und Aktualisierung
DE102021125773A1 (de) Verfahren zum gleichzeitigen schätzen von bewegung und form eines zielfahrzeugs mittels eines vorverteilungsmodells eines tracklets
WO2022122339A1 (de) Verfahren und system zum testen eines steuergeräts eines fahrzeugs
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
EP3105715A1 (de) Anordnung und verfahren zur sensorfusion
EP4055411B1 (de) Verfahren, vorrichtung und computerprogramm zur freigabe eines sensorsystems zur erfassung von objekten in einem umfeld eines fahrzeuges
DE102022115322A1 (de) Kalibrierung für ein verteiltes system
DE102012009688B4 (de) Verfahren, Signalfolge sowie Rechneranlage zum Erstellen, Verwalten, Komprimieren und Auswerten von 3D-Daten eines dreidimensionalen Geländemodells und ein Computerprogramm mit Programmcode zur Durchführung des Verfahrens auf einem Computer
DE102017221634A1 (de) Kraftfahrzeug mit einem Fahrzeugführungssystem, Verfahren zum Betrieb eines Fahrzeugführungssystems und Computerprogramm
WO2022012826A1 (de) Verfahren und vorrichtung zum ermitteln einer kollisionswahrscheinlichkeit eines fahrzeugs mit einem objekt im dreidimensionalen raum
EP4149813A1 (de) Verfahren und system zur vollständig automatischen führung eines kraftfahrzeugs und kraftfahrzeug

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

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14721230

Country of ref document: EP

Kind code of ref document: A1