DE102013218678A1 - Design system and method for designing a driver assistance system - Google Patents

Design system and method for designing a driver assistance system

Info

Publication number
DE102013218678A1
DE102013218678A1 DE201310218678 DE102013218678A DE102013218678A1 DE 102013218678 A1 DE102013218678 A1 DE 102013218678A1 DE 201310218678 DE201310218678 DE 201310218678 DE 102013218678 A DE102013218678 A DE 102013218678A DE 102013218678 A1 DE102013218678 A1 DE 102013218678A1
Authority
DE
Germany
Prior art keywords
modules
system
semantic
driver assistance
model
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE201310218678
Other languages
German (de)
Inventor
Dr. Feiten Wendelin
Michael Fiegert
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to DE102013209148.6 priority Critical
Priority to DE102013209148 priority
Application filed by Siemens AG filed Critical Siemens AG
Priority to DE201310218678 priority patent/DE102013218678A1/en
Publication of DE102013218678A1 publication Critical patent/DE102013218678A1/en
Application status is Withdrawn legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00Digital computing or data processing equipment or methods, specially adapted for specific functions
    • G06F17/50Computer-aided design
    • G06F17/5095Vehicle design, e.g. aircraft or automotive design
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60WCONJOINT 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/00Details 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/02Ensuring safety in case of control system failures, e.g. by diagnosing, circumventing or fixing failures
    • B60W50/0205Diagnosing or detecting failures; Failure detection models
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60WCONJOINT 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/00Details 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/02Ensuring safety in case of control system failures, e.g. by diagnosing, circumventing or fixing failures
    • B60W50/0205Diagnosing or detecting failures; Failure detection models
    • B60W2050/0215Sensor drifts or sensor failures

Abstract

The design system processes machine-readable semantic modules (130) which semantically describe system modules (101) of a driver assistance system (100), and checks validity of system outputs (102) of the driver assistance system (100) on the basis of the semantic modules (130). This provides for the first time a uniform, consistent and formal description of the methods and system modules (101) in the design process of driver assistance systems by means of semantic modules. This has, inter alia, the advantage that the sensors installed in the vehicle basically become available for all driver assistance functions or applications to be implemented on the vehicle. Furthermore, the design process is significantly simplified and accelerated. The system modules (101) with the associated semantic modules (130) are reusable beyond the specific design and can be further developed as such. Your validation can be decoupled from the special application. The formal specification of the properties of the system modules (101) in the semantic modules (130) allows a formal analysis of the entire system based on these properties. From the validation of the individual modules can therefore be concluded on the validity of the resulting overall system. The verification and / or validation using the semantic modules (130) can replace many experimental validations of subsystems and experimental setups during development, thus providing significant design acceleration and cost savings.

Description

  • For the following explanations, the terms "model" and "representation" must be defined differently. In the following, 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. Such models are usually created by experts with great care and a lot of time.
  • Deviating from this, the term "representation" is intended to denote those estimated assumptions and beliefs that software, such as a sensor fusion algorithm, itself must form over an environment. Such a representation is thus the result of the work of a computer program and must necessarily remain in both the level of detail and reliability of the models mentioned above.
  • Accordingly, in the following 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. In contrast, hereinafter an environment representation denotes an internal representation of an environment, which is generated, for example, by a sensor fusion algorithm as a grid map and must necessarily remain in both its level of detail and its reliability relative to the environment model. The terms environment representation and internal environment representation are to be understood as synonymous. The terms measured values, sensor data and sensor signals are also used synonymously.
  • Analogously, in the following 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. On the other hand, in the following, a vehicle representation denotes estimated states of the vehicle, for example, whether or not there is a skid.
  • Furthermore, in the following, 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. On the other hand, in the following, a driver's representation denotes estimated states of the driver, for example, whether he is tired or not.
  • Often the environment will be an environment of a vehicle. As a special case, however, the environment can also be the vehicle itself or its driver. Unless specified otherwise, the term environment model should therefore also include the special cases vehicle model and driver model below. Similarly, unless otherwise specified, the term environmental representation should also include the special cases of vehicle representation and driver representation below.
  • However, the algorithms described below can also use an environment model, a vehicle model and / or a driver model and an environment representation, a vehicle representation and / or a driver representation side by side, which then exist in separate modules and work together in a suitable manner.
  • The 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.
  • First, 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 a suitable environmental representation, vehicle representation and driver representation is 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.
  • From physical sensors to control signals and driver information, many different domains of knowledge need to be integrated.
  • An explicit description of the meaning of variables can be found in CAD systems, for example in the new one Standard Step AP 242 and can be seen from the document "Schemas", available on the Internet on 25.07.2013 at http://www.steptools.com/support/stdev_docs/express/ap242/htm l / index.html. Here a type system is used in which a physical meaning of a variable is expressed by a type of variable. These types also include SI units and units derived therefrom.
  • For sensor networks, semantic descriptions of the sensors and signals have been developed in connection with geoinformation systems, as described, inter alia, in US Pat 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, December 2012, p. 25-32, ISSN 1570-8268 , It is provided that, together with the sensors properties of the measurements are stored, such as accuracy.
  • In the WO 2007017308 A1 describes an approach to first describe the sensor data in a "sensor language" that contains no information about the vehicle or the driver assistance function, and later translate the phenomena described in this sensor language into a "functional language", which does not rely on the specific sensors received. In this functional language then takes place the merger. This is illustrated there using the example of an adaptive cruise control.
  • In the WO 2006089941 A1 An information exchange module is described in which sensor information is collected and made available to applications.
  • It is an object to provide a design system and a method for designing a driver assistance system, which simplify the design of the driver assistance system.
  • This object is achieved according to the invention by a design system for a driver assistance system,
    • Comprising a memory on which machine-readable semantic modules are stored, each of which systematically model system modules of a driver assistance system, in particular hardware modules and / or software modules, and
    • Comprising a microprocessor which is programmed for processing the semantic modules and for verifying and / or validating the system modules and / or the driver assistance system on the basis of the semantic modules.
  • The object is further achieved according to the invention by a method for designing a driver assistance system,
    • - in which system modules of a driver assistance system, in particular hardware modules and / or software modules, are each semantically modeled by machine-readable semantic modules, and
    • In which a microprocessor processes the semantic modules in a computer-aided manner and verifies and / or validates the system modules and / or the driver assistance system on the basis of the semantic modules.
  • 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.
  • The advantages and explanations given below do not necessarily relate to the subject matters of the independent patent claims. Rather, these may also be advantages or aspects which relate only to individual embodiments, variants or developments.
  •  A formalization of the design process of driver assistance systems by means of the semantic modules as well as a support of this design process by a corresponding design system is proposed.
  •  The system modules with the associated semantic modules are reusable beyond the special design and can be further developed as such. Your validation can be decoupled from the special application. The formal specification of the properties of the system modules in the semantic modules enables a formal analysis of the entire system based on these properties. From the validation of the individual modules can therefore be concluded on the validity of the resulting overall system.
  •  The verification and / or validation using the semantic modules can replace many experimental validations of subsystems and experimental setups during development, thus significantly accelerating design and cost savings.
  • This provides for the first time a uniform, consistent and formal description of the system modules of driver assistance systems by means of the semantic modules. This has, inter alia, the advantage that the sensors installed in the vehicle basically become available for all driver assistance functions or applications to be implemented on the vehicle. Furthermore, the design process is significantly simplified and accelerated.
  • For example, the system modules are hardware and software modules such as sensor hardware, data fusion methods, environment models, vehicle models, driver models, internal representations of the environment, the condition of the vehicle and the condition of the driver.
  • For the first time it is now possible that these system modules are provided by different providers. Because their integration is supported by the description as semantic modules on a semantic meta-level.
  • Furthermore, all findings gained through a system module are documented in a formal framework as a semantic module and are therefore permanently available for modifications and further developments of the overall system. Another advantage is that the characteristics of the driver assistance system can be predicted from the properties of the semantic modules and their combination.
  • For this purpose, all aspects of the system modules must be formally recorded in the semantic modules, which the developers must know in order to be able to meaningfully integrate the given system module into their design and to predict the resulting overall performance of the driver assistance system.
  • Using the semantic modules, all essential properties of the system modules are explicitly recorded, modeled and published. The semantic modules are present in electronic, machine readable and processable form. Those properties of the system modules are essential here, the knowledge of which enables the reuse of the gained expertise via system modules in the design of the driver assistance system. The semantic modules are used to machine and provide a wide range of knowledge and in-depth knowledge of a development team, so that the best expertise can be used.
  • The semantic modules make it possible for the various steps in the design process to be decoupled from one another by driver assistance systems and to be processed independently by different processors. The specialist knowledge of the processors of the individual steps flows into the semantic modules and is thus kept ready for the overall design, without the developers having to be involved in every single further development or modification of the overall system.
  • The modules as well as further required arithmetic units, simulators, etc. can be implemented in terms of hardware and / or software. In a hardware implementation, 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. In a software implementation, 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 is provided or delivered in a network. This can be done, for example, in a wireless communication network by transmitting the appropriate file.
  • According to a further development, a design system results,
    • In which the semantic modules are based on at least one ontology, in particular OWL.
  • In a special development, a design system results,
    • - In which the microprocessor is programmed for verification and / or validation of validity of outputs of individual system modules and / or system outputs of the driver assistance system.
  • According to one embodiment, a design system results
    • - where the microprocessor is programmed for verification
    • A specification of accuracy in the semantic modules,
    • A specification of a transit time of signals in the semantic modules, and / or
    • A specification of an interface in the semantic modules,
    • - and to determine the validity, quality, speed and / or accuracy of outputs of individual system modules and / or system outputs of the driver assistance system based on the previous review of the specifications of the semantic modules.
  • In a further development, a design system results,
    • - In which the microprocessor is programmed to verify a compatibility of a system module with other system modules and / or the driver assistance system
    • By checking a specification of interfaces in the associated semantic module, and / or
    • By checking a specification of a need for computation time and / or storage space in the associated semantic module.
  • This training helps developers to properly use the system modules by automatically checking the compatibility of the semantic modules when connecting system modules in the design system.
  • According to one embodiment, a design system results
    • - In which the microprocessor is programmed for verification and / or validation of the driver assistance system based on a simulation of the system modules by means of the semantic modules.
  • This has the advantage that the system modules are simulated on the basis of the formal specifications in the semantic modules on a meta-level. The simulation is supported, for example, by semantic modules with formal descriptions of physical sensors on the one hand and the physical environment, driver and vehicle on the other hand. Such system modules, which are provided with compatible semantic modules, can then come from different suppliers and still be integrated by the developer of the driver assistance function.
  • In a further development, a design system results,
    • In which the design system comprises format converters which establish compatibility between semantic modules with different specifications of their interfaces.
  • The various system modules are described in such comprehensive form by means of the semantic modules in the design of the driver assistance system that two system modules which are to interact with one another can be made compatible with one another within the design system. Ideally, the associated semantic modules conform to a common convention or, in the design system, there are suitable algorithms that can perform the required format conversions and that can verify that the compatibility of the system modules with them is adequate for the required interaction. If necessary, a warning is issued.
  • According to one embodiment, a design system results
    • In which the semantic modules semantically model several or all of the system modules enumerated below:
    • At least one sensor model, designed to generate virtual sensor data,
    • - at least one environment model, in particular
    • A model of a real environment,
    • A vehicle model and / or
    • - a driver model,
    • At least one sensor simulator,
    • - At least one environmental representation, in particular
    • A representation of an environment,
    • A vehicle representation and / or
    • A driver representation,
    • At least one environmental representation type,
    • At least one inference machine, set up for the computer-assisted filling of the environmental representation from the virtual sensor data,
    • - at least one fusion model, and / or
    • - at least one driver assistance application.
  • Advantageous embodiments of the method are characterized by the features of the corresponding subclaims and correspond in each case to the already mentioned developments and embodiments of the design system.
  • In the following, embodiments of the invention will be explained in more detail with reference to figures. In the figures, identical or functionally identical elements are provided with the same reference numerals, unless stated otherwise. Show it:
  • 1 System modules of a driver assistance system,
  • 2 a first embodiment of a design system for a driver assistance system, and
  • 3 A second embodiment of a design system for a driver assistance system.
  • 1 shows system modules of a driver assistance system and in particular the construction of an environment representation 6 from real sensor data 4 , A sensor 1 performs a real measurement 3 in a real environment 2 through and generates the real sensor data 4 , For the translation of the real sensor data 4 in the environment representation 6 is basically always a sensor data fusion 5 required. Because from the second measurement, a temporal merger must already be made. Multiple sensors in different locations require a local fusion of the real sensor data 4 , Furthermore, different types of sensors, such as ultrasound and camera, under special Consideration of their properties through the sensor data fusion 5 be merged.
  • Without limitation of generality, the in 1 architecture already be understood as a design system for driver assistance systems. With this architecture comes the sensor data fusion 5 a central role too. She is responsible for this, from the sequence of real sensor data 4 different sensors 1 the environment representation 6 , ie, as defined above, derive an internal representation of the environment, the vehicle condition and / or the condition of the driver. The entries in the environment representation 6 thus come from observations, ie the real sensor data 4 ,
  • Mostly this is an environment representation type 7 ie the type of environment representation 6 , pre-determined by the developer. The environment representation type 7 For example, it may be an occupancy grid map or an object list, it may specify parameters of the vehicle state, or specify a set of possible states for the driver ("tired", "awake", "equanimous", "tense", ...).
  • The stateful entries in the environment representation 6 are modified, depending on what the sensors 1 measure up. For example, the occupancy probability in a cell of an occupancy lattice map may be increased when the sensor 1 measures a distance to an obstacle at an appropriate distance. The entries in the environment representation 6 , such as a probability of occupancy, usually express an uncertainty of 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. Mostly, probability calculus is used and the entries are random variables. For reasons of efficiency, a parametric probability density distribution is often used as the basis, but it is also possible to choose a sample-based representation, as is customary in the field of autonomous robots.
  • The rule of calculation according to which the entries in the environment representation 6 based on the real sensor data 4 to be modified is in 1 as a fusion model 8th entered.
  • The sensor 1 is a system module of the driver assistance system, which is designed as a hardware module or electrical device. In the sensor data fusion 5 , the environment representation 6 and the fusion model 8th These are also system modules of the driver assistance system, but they are implemented as software modules.
  • In extreme cases, the design is as in 1 shown with a physical sensor 1 and a real environment 2 carried out. But this means that the developers have to experimentally check the driver assistance function as a whole. This makes the development process slow and expensive: for each modification and every development, the developers must build a vehicle, a task-related real environment 2 search or self-construct, write data fusion algorithms and application algorithms, then analyze and modify them until the vehicle's behavior meets expectations.
  • When all system modules are edited by a development group, there is also a lack of explicit modeling in some places. This can in particular be the underlying sensor hardware and the description of properties of the sensors 1 but also the properties of the real sensor data 4 at the meta level.
  • Another consequence of this approach is that development statuses or knowledge levels for individual system modules can only be exchanged between development groups at great expense. Therefore, in such design methodology, often large parts of the development work are redone with each driver assistance function. Even more important is that the hardware can not be shared by different driver assistance functions in this development methodology.
  • 2 shows a semantic modeling of the system modules of the driver assistance system by semantic modules. In detail, properties of a sensor with a sensor model 10 , an environment with an environment model 20 , a representation of the environment with an environment representation type 7 and the environment representation 6 each semantically modeled. In the design process, these semantic modules decouple the required expertise about the sensor hardware from expertise to application areas.
  • The first semantic module, the sensor model 10 , models the physical (electrical, optical, acoustic, mechanical, high-frequency) properties of the sensor. Which specifications are required here depends on the respective sensor types. The following are specifications in a semantic module, the sensor model 10 , for an ultrasonic distance sensor, in which only the first incoming echo is evaluated, or is returned to the corresponding distance value.
  • In the semantic module, 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 characteristics, the transmission energy and the reception sensitivity.
  • Similarly, for the integration into the mechanical and electrical design, the dimensions, the weight, the electrical connection values (supply voltage including tolerance ranges, supply power) in the sensor model 10 be listed.
  • This information must be clear in itself, so in all physical values also the units and possible fluctuations must be mentioned. It is advantageous to model them as random variables, as mathematically recognized, meaningful models and algorithms are available for this purpose.
  • At the transmission frequency, therefore, as an unit for an ultrasonic sensor, e.g. Specify HZ or KHz, for radar sensors one will specify MHz or GHz. Decisive for the semantic description in the semantic module is that the physical unit is specified.
  • Not only is the frequency relevant to the measurement process, but also the frequency and amplitude of the transmitted signal can vary over time. In this case, formal information of this signal is required. It is essential that the format in which these signals are described explicitly in the semantic description in the sensor model 10 is called.
  • The sensor model 10 , a vehicle model not shown, and the environment model 20 - also semantic modules - enable the simulation of virtual measurements 30 , from which virtual sensor data 40 result. The previously mentioned decoupling happens because in the sensor model 10 On the one hand the sensor hardware is physically modeled in such detail that by means of a suitable simulation and due to the corresponding detailed environment model 20 the virtual measurements 30 can be simulated for the sensor. In this case, not a deterministic, ie always the same measured value is determined, but the virtual sensor data 40 are subject to the same random fluctuations as the real sensor data obtained in experiments.
  • The environment model 20 As a semantic module, it contains the physical properties of the environment that are needed to simulate or derive the "ground truth" of the internal environment representation: For each sensor model 10 that should be used must be in the environment model 20 the corresponding physical properties of the environment can be described semantically.
  • For a video camera as a sensor, these properties include the geometry and textures (optical reflection properties) of the objects. Many very well-developed examples of such environment models 20 can be found in the areas of computer animation for movies, computer games, architectural simulation, etc. in these environment models 20 In some cases, properties of the transmission medium are also simulated (fog, rain, snow, ...) as well as properties of the lighting.
  • For the simulation of an ultrasonic sensor ranges as environmental model 20 an approximation of the geometry together with the acoustic reflection properties. Depending on the simulation principle, the objects are in the environment model 20 modeled so that sections can be calculated with rays, or that the reflection of waves on the surfaces can be calculated. For this purpose the normals on the surfaces are needed.
  • The formats of the contents of semantic descriptions in the sensor model 10 and environment model 20 must match the corresponding simulators. For this purpose, 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.
  • In this context, the vehicle model, as another semantic module, describes where the sensors are relative to the vehicle. First and foremost, the geometric relationships are relevant here. However, electrical conditions can also become relevant if, for example, according to the sensor model 10 Voltage fluctuations in the supply voltage can lead to increased noise in the measured values. In this case, the supply voltage (possibly as a random variable) is part of the vehicle model.
  • The sensor simulation created from the sensor model 10 and the environment model 20 the same virtual sensor data 40 as they would generate the real sensors in a real environment of use. The simulation can process random variables as input values, as well as the virtual sensor data 40 are random variables, and their probability density distribution is simulated with.
  • According to a first variant of the present embodiment, the semantic modules are sensor models 10 and environment model 20 sufficiently detailed to give experts an understanding of which readings a given sensor can make in a given situation, what errors and spreads these readings have, how often readings fail, how often readings are returned that can not be attributed to any physical phenomenon, etc ..
  • In another variant of the present embodiment, the semantic modules are not suitable, the same virtual sensor data 40 How to generate the real sensors in a real environment. For example, the semantic modules contain information on accuracies, runtimes or formats of signals, but not information in depth, which would be required for a complete simulation of the respective system module. Nevertheless, a simulation based on the semantic modules can simulate individual aspects, such as accuracies, runtimes or formats of the signals, and formally check whether valid system outputs are generated. Possibly. Such a simulation can even provide information on the accuracy, speed and quality of system outputs.
  • The simulation can therefore be carried out at very different levels of accuracy, which usually results in an even higher storage space and computing time required, the more accurate the simulation. In the following, we will discuss the variant that the semantic modules contain very detailed semantic descriptions that allow a comprehensive or even complete simulation of the respective system modules.
  • On the basis of such a complete formal description of the physical properties of the sensor hardware on the one hand and the correspondingly complete formal descriptions of the environment of the vehicle, the state of the vehicle and possibly the condition of the driver through the semantic module sensor model 10 , Environment model 20 , Vehicle model and driver model, it is possible to virtual sensor data 40 by simulation of virtual measurements 30 to investigate. Here, not only the actual measured values are simulated, but by looking at a large number of such simulated measured values, properties of the measured values or of the sensors on a meta-level are also determined. These features include, for example, the measurement rate, the latency, the likelihood that measurements will fail, or the measurements that can not be attributed to a phenomenon in the environment or to the vehicle or driver. Likewise, a probability density distribution of the sensor measured values is determined given the environmental situation (including vehicle and driver).
  • The random scattering of the measured values can result from the environmental representation 6 ignored, but the measured value still influencing properties of the environment, vehicle or driver models. If the statistical properties are identical across a class of use cases, and if a given use case can be assigned to such a class, then the statistical properties of the class can also be used to simulate individual measurements without a detailed simulation. Likewise, these properties can be taken from the specifications of the semantic modules for the derivation of an overall evaluation of the overall system.
  • The possibility of these values in the sensor model is used to simulate incorrect measured values 10 filed, as far as the causes of these incorrect measurements in the physics of the sensor 1 lie.
  • By agreeing formats, semantic modules such as the sensor model 10 , the environment model 20 and the vehicle model - as well as associated system modules, which are to be implemented as hardware or software modules based on the specifications in the semantic modules - come from different suppliers and nevertheless fit together. Similar de facto standards already exist in the area of CAD (eg the STEP format). In the context of the embodiments, standards are needed in which the probability density functions can also be described.
  • The sensor data fusion 5 is also a semantic module that semantically describes a fusion algorithm, in particular its inputs and outputs; The same applies to the fusion model 8th , as well as for the environmental representation 6 and the environmental representation type 7 , The specifications of these semantic modules are derived from the desired driver assistance application gene and include the aspects of type representation, required accuracy, update rate or latency between changing a situation and changing the corresponding representation, etc.
  • For example, the design system provides a library of classes of data fusion algorithms. In these algorithms, the requirements on the semantic meta-level become the input quantities in the semantic modules sensor data fusion 5 and / or fusion model 8th noted, as well as the characterization of the Results of the data fusion on the semantic meta-level. This supports the developer in the selection and parameterization of the algorithms for data fusion.
  • Finally shows 2 as a semantic module, the driver assistance application 9 , The decision, what specification of the environment representation 6 for which specification of the driver assistance application 9 required or sufficiently well-suited, requires considerable knowledge of the driver assistance application 9 itself, in the case of driver assistance systems over traffic situations, behavior of vehicles, control and regulation of vehicles, up to behavior of drivers. This knowledge is used in the semantic module driver assistance application 9 deposited. The specification of the environment representation 6 depends on the specifications of the driver assistance application 9 , The driver assistance application 9 is therefore formally specified as a semantic module analogous to the sensors and the environment. In the case of a driver assistance application 9 For automatic parking, the semantic module contains specifications for a required size of a parking space (possibly depending on dimensions and steering geometry of the vehicle), type and distribution of obstacles, and time spent by the driver assistance application 9 on average needed for parking (possibly staggered again according to ambient conditions).
  • The mentioned semantic modules and simulation methods assist the expert in choosing a suitable specification for the semantic module environment representation 6 , as their basic form (eg occupancy grid map, object list, or others) and individual expression (eg, number and size of the cells of the occupancy grid card) according to the specifications of the driver assistance function to be implemented, which in the semantic module driver assistance application 9 are specified.
  • Based on the semantic module Environment Representation 6 can for the task, from given sensor data an occupancy for the environment representation 6 Again, regardless of the specific knowledge of the physical properties of the sensors or the environment, the vehicle model and the model of the driver, from a library of semantic modules to the fusion model 8th to get voted. This library contains as semantic modules eg fusion models 8th based on fuzzy reasoning, artificial neural networks, the Dempster-Shafer calculus or, most commonly, methodically best worked out probabilistic inference. The methods developed on the formal basis of the respective semantic module and optimized for the given case of application can be validated by simulation and, analogously to the procedure for modeling the sensors and the surroundings of the vehicle and the driver, finally by experiments.
  • The execution of the driver assistance application 9 depends among other things on the specifications in the semantic module environment representation 6 , The specification of the environment representation 6 So check it out to see if the driver assistance application 9 can be executed. Practically, this can be done by having an instance of the environment representation 6 according to the meta-properties formally described in the semantic module, and then the behavior of the vehicle is simulated on the basis of this instance. Using the example of parking this means, for example, that according to the statistical properties of the random variable, which represents the occupancy rate of a cell of an occupancy grid card (given the environment model 20 ), an instance of such a map can be generated and then the vehicle makes a simulated parking maneuver based on that instance. On the success or failure of this maneuver can be checked whether the specification of the statistical properties, the grid cell size, etc. the requirements or specifications of the driver assistance application 9 enough.
  • 3 shows a further embodiment of a design system for a driver assistance system 100 , its system modules 101 also by semantic modules 130 semantically modeled. The semantic modules 130 each contain specifications 131 and are machine-readable stored in an electronic memory on which a microprocessor 120 accesses.
  • This in 3 shown design system allowed as before in the context of 2 described a modularization in the design of the driver assistance system 100 through semantic modeling of its system modules 101 , At the system modules 101 For example, these are those in the context of 1 described hardware and software modules; at the semantic modules 130 on the other hand, they are, for example, those in the context of 2 described semantic modules, which about the system modules 1 semantically model.
  • The semantic modules can be implemented eg by the use of ontologies. Ontologies describe the meaning of concepts in a domain and how these concepts relate to one another. The most widely used description language for ontologies today is the Web Ontology Language (OWL), which was developed by the World Wide Web consortium standardized and recommended. The logical concept of the OWL is usually the so-called "Description Logic" (DL), or suitable specializations of the DL.
  • A domain is described by a set of triples of the form (Concept1, Role, Concept2) - often with the meaning (subject, predicate, object). Relative to the present embodiment is in a semantic module 130 for ultrasonic sensors as specification 131 For example, registered that the measured value of the ultrasonic sensor means a distance measurement by entering in the ontology: (ultrasonic sensor, has measured value type, distance measurement). This applies to every ultrasonic sensor, so it is a description of the class.
  • Furthermore, in a semantic module 130 for a particular ultrasonic sensor, which is the unit of the distance measurement of a specific ultrasonic sensor, such as: (Ultrasonic sensor 123 , has distance reading unit, centimeters).
  • In a semantic module 130 , which semantically models an algorithm, it is noted accordingly which input variables the algorithm requires and which output variables it generates. Requirements on the meaning of the sizes, if necessary on the unit of measurement, etc. are also included. In particular, statistical properties can also be described.
  • Based on the semantic modules 130 can be the driver assistance system 100 semantically model as a whole by according to the system modules used 101 Instances of the corresponding semantic modules 130 formed from ontology.
  • Advantageous in the approach for semantic modeling with ontologies, in particular OWL, is that already a large number of extensive ontologies for different domains are available, including the sensors in meteorology (SensorML), SI units, CAD description formats or terms from the Probability calculation, generally in OWL format.
  • Another advantage is that there are numerous algorithms that can check the consistency and completeness of an ontology (so-called inference algorithms, or "solver"). So if the ontology, the concepts of a domain "modular driver assistance systems" and from the instances of the respective semantic modules 130 There is a specific driver assistance system 100 describe, is inconsistent or incomplete, the inference algorithm can identify the error and name it to a user so that he can correct his design.
  • The goal is the domain "modular driver assistance systems" with the semantic modules 130 modeled so completely in an ontology that if the design is consistent in terms of ontology, it also provides a faultless driver assistance system 100 describes.
  • The inference algorithm is used by the microprocessor 120 executed. A user can take no, single or a variety of decisions and steps in the respective verification and / or validation process, for which the microprocessor prompts the user for respective inputs.
  • The microprocessor 120 thus processes the semantic modules 130 and verifies or validates the system modules 101 or the driver assistance system 100 based on the semantic modules 130 in that the inference algorithm described above checks the respective ontology for consistency and completeness. In the same way can also validity of expenses of individual system modules 101 or system issues 102 of the driver assistance system 100 be verified or validated.
  • This can also be a specification 131 an accuracy, a transit time of signals, and an interface in the semantic modules 130 be checked. From this can be a validity, quality, speed or accuracy of outputs of individual system modules 101 or system issues 102 of the driver assistance system 100 derived.
  • Furthermore, a compatibility of a system module 101 with other system modules 101 or the driver assistance system 100 be verified by reviewing a specification 131 of interfaces in the associated semantic module 130 , or by reviewing a specification 131 a need for computation time or storage in the associated semantic module 130 ,
  • The described forms of verification or validation may additionally or alternatively also be based on a simulation of the system modules 101 by means of the semantic modules 130 be carried out in the context of 2 has already been explained.
  • Furthermore, the design system can use format converters to provide compatibility between semantic modules 130 with different specifications 131 their interfaces. For example, such a format converter automatically converts the unit of measure of degrees Celsius into Fahrenheit.
  • The formal description of the system modules 101 through the semantic modules 130 remains basically expandable. For each extension, the person or organization proposing the extension must also provide the appropriate mechanisms necessary to use the extension in the design system.
  • All in the design of the driver assistance system 100 used system modules 101 are through the semantic modules 130 formally described in a compatible manner. The type of formal description is publicly available and gives all interested parties the option of semantic modules 130 for their system modules 101 so that they can be included in the design process described here.
  • The semantic modules 130 contain the necessary information to support all stages of the design. These stages preferably include at least the steps of sensor simulation, environment models, internal representations, and driver assistance application as described in the context of 2 have been described.
  • The described embodiments, embodiments, variants and developments can be combined freely with each other.
  • QUOTES INCLUDE IN THE DESCRIPTION
  • This list of the documents listed by the applicant has been generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.
  • Cited patent literature
    • WO 2007017308 A1 [0013]
    • WO 2006089941 A1 [0014]
  • Cited non-patent literature
    • Standard Step AP 242 [0011]
    • http://www.steptools.com/support/stdev_docs/express/ap242/htm l / index.html. [0011]
    • 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, December 2012, p. 25-32, ISSN 1570-8268 [0012]

Claims (18)

  1. Design system for a driver assistance system ( 100 ), Comprising - a memory ( 110 ) on which machine-readable semantic modules ( 130 ) are stored, which respectively system modules ( 101 ) of a driver assistance system ( 100 ), in particular hardware modules and / or software modules, semantically model, and - comprising a microprocessor ( 120 ), which is used to process the semantic modules ( 130 ) and for the verification and / or validation of the system modules ( 101 ) and / or the driver assistance system ( 100 ) based on the semantic modules ( 130 ) is programmed.
  2. Design system according to claim 1, - in which the semantic modules ( 130 ) based on at least one ontology, in particular OWL.
  3. Design system according to claim 1 or 2, - in which the microprocessor ( 120 ) is programmed for the verification and / or validation of a validity of outputs of individual system modules ( 101 ) and / or system outputs ( 102 ) of the driver assistance system ( 100 ).
  4. Design system according to claim 3, - in which the microprocessor ( 120 ) is programmed to check - a specification ( 131 ) accuracy in the semantic modules ( 130 ), - a specification ( 131 ) a transit time of signals in the semantic modules ( 130 ), and / or - a specification ( 131 ) an interface in the semantic modules ( 130 ), And to determine the validity, quality, speed and / or accuracy of outputs of individual system modules ( 101 ) and / or system outputs ( 102 ) of the driver assistance system ( 100 ) based on the previous review of the specifications ( 131 ) of the semantic modules ( 130 ).
  5. Design system according to one of the preceding claims, - in which the microprocessor ( 120 ) is programmed to verify compatibility of a system module ( 101 ) with other system modules ( 101 ) and / or the driver assistance system ( 100 ) - based on a review of a specification ( 131 ) of interfaces in the associated semantic module ( 130 ), and / or - based on a review of a specification ( 131 ) a need for computation time and / or storage space in the associated semantic module ( 130 ).
  6. Design system according to one of the preceding claims, - in which the microprocessor ( 120 ) is programmed for verification and / or validation of the driver assistance system ( 100 ) based on a simulation of the system modules ( 101 ) by means of the semantic modules ( 130 ).
  7. Design system according to one of the preceding claims, - in which the design system comprises format converters which provide compatibility between semantic modules ( 130 ) with different specifications ( 131 ) of their interfaces.
  8. Design system according to one of the preceding claims, - in which the semantic modules ( 130 ) several or all of the system modules listed below ( 101 ) semantically: - at least one sensor model ( 10 ) set up to generate virtual sensor data ( 40 ), - at least one environment model ( 20 ), in particular - a model of a real environment, - a vehicle model ( 15 ) and / or - a driver model, - at least one sensor simulator, - at least one environmental representation ( 6 ), in particular - a representation of an environment, - a vehicle representation and / or - a driver representation, - at least one environment representation type ( 7 ), - at least one inference machine, set up for the computer-aided filling of the environmental representation ( 6 ) from the virtual sensor data ( 40 ), - at least one fusion model ( 8th ), and / or - at least one driver assistance application ( 9 ).
  9. Method for designing a driver assistance system ( 100 ), - in the system modules ( 101 ) of a driver assistance system ( 100 ), in particular hardware modules and / or software modules, in each case by machine-readable semantic modules ( 130 ) are semantically modeled, and - in which a microprocessor ( 120 ) the semantic modules ( 130 ) processed computer-aided and the system modules ( 101 ) and / or the driver assistance system ( 100 ) based on the semantic modules ( 130 ) verified and / or validated.
  10. Method according to Claim 9, - in which the semantic modules ( 130 ) are modeled based on at least one ontology, in particular OWL.
  11. Method according to Claim 9 or 10, - in which the microprocessor ( 120 ) validity of expenses of individual system modules ( 101 ) and/ or system outputs ( 102 ) of the driver assistance system ( 100 ) verified and / or validated.
  12. Method according to Claim 11, - in which the microprocessor ( 120 ) - a specification ( 131 ) accuracy in the semantic modules ( 130 ), - a specification ( 131 ) a transit time of signals in the semantic modules ( 130 ), and / or - a specification ( 131 ) an interface in the semantic modules ( 130 ), and the validity, quality, speed and / or accuracy of outputs of individual system modules ( 101 ) and / or system outputs ( 102 ) of the driver assistance system ( 100 ) based on the previous review of the specifications ( 131 ) of the semantic modules ( 130 ).
  13. Method according to one of Claims 9 to 12, - in which the microprocessor ( 120 ) compatibility of a system module ( 101 ) with other system modules ( 101 ) and / or the driver assistance system ( 100 ) - based on a review of a specification ( 131 ) of interfaces in the associated semantic module ( 130 ), and / or - based on a review of a specification ( 131 ) a need for computation time and / or storage space in the associated semantic module ( 130 ).
  14. Method according to one of Claims 9 to 13, - in which the microprocessor ( 120 ) the driver assistance system ( 100 ) based on a simulation of the system modules ( 101 ) by means of the semantic modules ( 130 ) verified and / or validated.
  15. Method according to one of Claims 9 to 14, - in which the design system uses format converters to ensure compatibility between semantic modules ( 130 ) with different specifications ( 131 ) of their interfaces.
  16. Method according to one of Claims 9 to 15, - in which the semantic modules ( 130 ) several or all of the system modules listed below ( 101 ) semantically: - at least one sensor model ( 10 ) set up to generate virtual sensor data ( 40 ), - at least one environment model ( 20 ), in particular - a model of a real environment, - a vehicle model ( 15 ) and / or - a driver model, - at least one sensor simulator, - at least one environmental representation ( 6 ), in particular - a representation of an environment, - a vehicle representation and / or - a driver representation, - at least one environment representation type ( 7 ), - at least one inference machine, set up for the computer-aided filling of the environmental representation ( 6 ) from the virtual sensor data ( 40 ), - at least one fusion model ( 8th ), and / or - at least one driver assistance application ( 9 ).
  17.  Computer readable medium, - On which a computer program is stored, which carries out the method according to one of claims 9 to 16, when it is processed in a microprocessor.
  18.  Computer program - Which is processed in a microprocessor and thereby carries out the method according to one of claims 9 to 16.
DE201310218678 2013-05-16 2013-09-18 Design system and method for designing a driver assistance system Withdrawn DE102013218678A1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
DE102013209148.6 2013-05-16
DE102013209148 2013-05-16
DE201310218678 DE102013218678A1 (en) 2013-05-16 2013-09-18 Design system and method for designing a driver assistance system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE201310218678 DE102013218678A1 (en) 2013-05-16 2013-09-18 Design system and method for designing a driver assistance system
PCT/EP2014/057585 WO2014183944A1 (en) 2013-05-16 2014-04-15 Design system and method of designing a driver-assist system

Publications (1)

Publication Number Publication Date
DE102013218678A1 true DE102013218678A1 (en) 2014-11-20

Family

ID=51831426

Family Applications (5)

Application Number Title Priority Date Filing Date
DE201310212710 Withdrawn DE102013212710A1 (en) 2013-05-16 2013-06-28 Sensor product, simulator and method for simulating sensor measurements, merging sensor measurements, validating a sensor model and designing a driver assistance system
DE201310213807 Ceased DE102013213807A1 (en) 2013-05-16 2013-07-15 Arrangement and method for sensor fusion and manufacturing method for creating a fusion model
DE201310215032 Pending DE102013215032A1 (en) 2013-05-16 2013-07-31 Device and method for a driver assistance system of a vehicle
DE201310215115 Ceased DE102013215115A1 (en) 2013-05-16 2013-08-01 Design system and method for designing a driver assistance system
DE201310218678 Withdrawn DE102013218678A1 (en) 2013-05-16 2013-09-18 Design system and method for designing a driver assistance system

Family Applications Before (4)

Application Number Title Priority Date Filing Date
DE201310212710 Withdrawn DE102013212710A1 (en) 2013-05-16 2013-06-28 Sensor product, simulator and method for simulating sensor measurements, merging sensor measurements, validating a sensor model and designing a driver assistance system
DE201310213807 Ceased DE102013213807A1 (en) 2013-05-16 2013-07-15 Arrangement and method for sensor fusion and manufacturing method for creating a fusion model
DE201310215032 Pending DE102013215032A1 (en) 2013-05-16 2013-07-31 Device and method for a driver assistance system of a vehicle
DE201310215115 Ceased DE102013215115A1 (en) 2013-05-16 2013-08-01 Design system and method for designing a driver assistance system

Country Status (2)

Country Link
DE (5) DE102013212710A1 (en)
WO (5) WO2014183949A1 (en)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102014209340A1 (en) * 2014-05-16 2015-11-19 Siemens Aktiengesellschaft Arrangement and method for sensor fusion
DE102015010270A1 (en) 2015-08-08 2017-02-09 Audi Ag Method for operating driver assistance systems in a motor vehicle and motor vehicle
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 (en) * 2016-02-16 2017-08-17 Continental Teves Ag & Co. Ohg Method for controlling vehicle functions through a driver assistance system, driver assistance system and vehicle
DE102016205392A1 (en) * 2016-03-31 2017-10-05 Siemens Aktiengesellschaft Method and system for validating an obstacle detection system
CN107310550B (en) * 2016-04-27 2019-09-17 腾讯科技(深圳)有限公司 Road vehicles travel control method and device
EP3260999A1 (en) * 2016-06-24 2017-12-27 Sick Ag System for simulating sensors
US10377375B2 (en) 2016-09-29 2019-08-13 The Charles Stark Draper Laboratory, Inc. Autonomous vehicle: modular architecture
WO2018063250A1 (en) * 2016-09-29 2018-04-05 The Charles Stark Draper Laboratory, Inc. Autonomous vehicle with modular architecture
DE102017208692A1 (en) 2017-05-23 2018-11-29 Audi Ag Method for providing training data for a functional test of a recognition device and database system
DE102017116017A1 (en) * 2017-07-17 2019-01-17 Valeo Schalter Und Sensoren Gmbh An automotive sensor device having a plurality of sensor units and a plurality of neural networks for generating a combined representation of an environment
DE102017116016A1 (en) * 2017-07-17 2019-01-17 Valeo Schalter Und Sensoren Gmbh A motor vehicle sensor device having a plurality of sensor units and a neural network for generating an integrated representation of an environment
DE102018205804A1 (en) * 2018-04-17 2019-10-17 Conti Temic Microelectronic Gmbh ECU testing device for testing, securing and developing functions
DE102018206326A1 (en) * 2018-04-24 2019-10-24 Zf Friedrichshafen Ag Method for expanding a database of a Bayesian network

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006089941A1 (en) 2005-02-25 2006-08-31 Robert Bosch Gmbh Method and system for the provision of sensor data
WO2007017308A1 (en) 2005-08-05 2007-02-15 Robert Bosch Gmbh Method for the creation of environmental hypotheses for driver assistance functions

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3931879B2 (en) 2003-11-28 2007-06-20 株式会社デンソー Sensor fusion system and vehicle control apparatus using the same
EP2107503A1 (en) * 2008-03-31 2009-10-07 Harman Becker Automotive Systems GmbH Method and device for generating a real time environment model for vehicles
US8739049B2 (en) * 2010-05-24 2014-05-27 GM Global Technology Operations LLC Vehicle system modeling systems and methods
DE102011086342A1 (en) * 2011-11-15 2013-05-16 Robert Bosch Gmbh Device and method for operating a vehicle

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006089941A1 (en) 2005-02-25 2006-08-31 Robert Bosch Gmbh Method and system for the provision of sensor data
WO2007017308A1 (en) 2005-08-05 2007-02-15 Robert Bosch Gmbh Method for the creation of environmental hypotheses for driver assistance functions

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
http://www.steptools.com/support/stdev_docs/express/ap242/htm l/index.html.
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
Standard Step AP 242

Also Published As

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

Similar Documents

Publication Publication Date Title
CN102062619B (en) For being come method system and the device of Analysis of Complex system by Forecast reasoning
Ehlers Formal verification of piece-wise linear feed-forward neural networks
Tenne et al. Computational intelligence in expensive optimization problems
Katz et al. Reluplex: An efficient SMT solver for verifying deep neural networks
Martins et al. Multidisciplinary design optimization: a survey of architectures
US20050143962A1 (en) Computational design methods
Friedenthal et al. A practical guide to SysML: the systems modeling language
WO2014109973A1 (en) Automatic driver modeling for integration of human-controlled vehicles into an autonomous vehicle network
Allison et al. Special section on multidisciplinary design optimization: multidisciplinary design optimization of dynamic engineering systems
Bacchus et al. Reasoning about noisy sensors in the situation calculus
Rajhans et al. Supporting heterogeneity in cyber-physical systems architectures
Bühler et al. Evolutionary functional testing
Hülsen et al. Traffic intersection situation description ontology for advanced driver assistance
Dreossi et al. Compositional falsification of cyber-physical systems with machine learning components
Madni et al. Systems integration: Key perspectives, experiences, and challenges
Wang et al. Formal security analysis of neural networks using symbolic intervals
Behere et al. A functional reference architecture for autonomous driving
Fränzle et al. Efficient proof engines for bounded model checking of hybrid systems
Li et al. Damage identification for beams using ANN based on statistical property of structural responses
JP2015081083A (en) Confidence estimation for predictive driver assistance systems based on plausibility rules
Tudorache Employing ontologies for an improved development process in collaborative engineering
Graves et al. Using formal methods with SysML in aerospace design and engineering
Ding et al. A neural network model for driver’s lane-changing trajectory prediction in urban traffic flow
Gechter et al. Virtual intelligent vehicle urban simulator: Application to vehicle platoon evaluation
Bayarri et al. Predicting vehicle crashworthiness: Validation of computer models for functional and hierarchical data

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee