• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    The present invention describes an innovative method such as a complex electronic system for controlling a safety-critical technical process, e.g. the leadership of an autonomous vehicle, can be realized. A distinction is made between simple and complex software, whereby the simple software is executed on a fault-tolerant hardware and where several diverse versions of the complex software are simultaneously executed on independent fault-containment units (FCUs). From a number of diverse environmental models, a consolidated environmental model is developed that forms the basis for trajectory planning.
    公开号:AT519164A2
    申请号:T50738/2016
    申请日:2016-08-16
    公开日:2018-04-15
    发明作者:
    申请人:Fts Computertechnik Gmbh；
    IPC主号:
    专利说明:

    Summary
    The present invention describes an innovative method such as a complex electronic system for controlling a safety-critical technical process, e.g. the management of an autonomous vehicle can be realized. A distinction is made between simple and complex software, whereby the simple software is executed on fault-tolerant hardware and where several diverse versions of the complex software are executed simultaneously on independent fault containment units (FCU). From a number of diverse environmental models, a consolidated environmental model is developed that forms the basis for trajectory planning.
    Fig. 1/12
    - 1 Fault-tolerant method and device for
    Control of an autonomous technical system based on a consolidated environmental model
    Literature cited
    patents:
    [1] US Pat. Application 20160033965 Device and Method for the Autonomous
    Control of Vehicles, published Feb. 4, 2016
    other:
    [2] Wikipedia, Autonomous Driving, retrieved on August 11, 2016 [3] Wikipedia, Automotive Safety Integrity LevelsISO 26262, retrieved on August 11, 2016 [4] FAA, Advisory Circular System Safety Assessment for Part 23 Airplanes. URL: http://www.faa.gov/documentLibrary/media/Advisory_Circular/AC%2023.13091E.pdf retrieved on August 11, 2016 [5] Avizienis, A. The N-Version Approach to Fault-Tolerant Software, IEEE Trans. on Software Engineering, Vol 11, pp. From 1491 to 1501. Dec. 1985, [6] Kopetz, H. Real-Time Systems, Design Principles for Distributed Embedded Applications. Springer publishing house. 2011th
    Technical environment
    The present invention is in the field of computer technology. It relates to a method and a device for fault-tolerant control of an autonomous technical system, in particular a vehicle, which is guided autonomously through the existing environment by a distributed computer system equipped with sensors.
    Brief description of the invention
    The developments in sensor technology and computer technology enable the largely autonomous control of a technical system or a vehicle that autonomously controls its target.
    According to Wikipedia [2], autonomous driving is classified in six stages:
    • Level 0: "Driver only", the driver drives, steers, accelerates, brakes etc.
    / 12 • Level 1: Certain assistance systems help with vehicle operation (including ACC).
    • Level 2: partial automation. Et al automatic parking,
    Lane keeping function, general longitudinal guidance, accelerate, brake etc. are taken over by the assistance systems (including traffic jam assistant).
    • Level 3: high automation. The driver does not have to continuously monitor the system. The vehicle independently performs functions such as activating the turn signal, changing lanes and keeping lanes. The driver can turn to other things, but if required, the system prompts the system to take the lead within a warning period. This form of autonomy is technically feasible on motorways. Legislators are working to approve Level 3 vehicles. One speaks of a time frame until 2020.
    • Level 4: full automation. The system takes over the management of the vehicle permanently. If the system no longer manages the driving tasks, the driver can be asked to take the lead.
    • Level 5: The complete autonomy of the vehicle. The vehicle is equipped without a steering wheel, the vehicle can move without a driver.
    Level 2 is currently being implemented in vehicles available on the market. At level 2, the driver is obliged to continuously monitor the proper functioning of the computer system and to intervene immediately in the event of a fault. At the higher levels of automation, the computer system must be fault-tolerant in order to ensure the safety of the vehicle even in the event of a fault in the computer system.
    In the ISO 26262 standard, an electronic system (hardware plus software) in a vehicle is assigned to one of four integrity levels (level ASIL A to ASIL D), level ASIL D being the highest level of integrity [3]. The integrity of electronic systems for fully automated vehicle control (Level 4 and Level 5) must correspond to ASIL D. While at ASIL B the probability of a dangerous fault occurring which has serious consequences for the safety of a vehicle must be less than 10 -6 per hour (ds 10 3 FIT), this probability must be less than 10 -8 per at ASIL D Hour (ds 10 FIT).
    The cause of an electronic system failure can be an aging fault (physical fault) of the hardware or a design fault (design fault).
    An aging error occurs when a unit that was fully functional at the beginning of its lifetime fails due to the aging processes of the hardware. With state of the art automotive chips, the permanent error rate for aging errors is <100 FIT. By using active redundancy (TMR or self-checking components), the required error rate of ASIL D (less than 10) FIT in the hardware can be achieved.
    Design errors can be included in the hardware or software. The consequences of hardware design errors can be mastered through active redundancy of diverse hardware.
    / 12
    - 3 measures that reduce the likelihood of an undetected design error in the software are a systematic design process, verification and validation, especially through extensive testing. A major cause of design errors in the software is the complexity of the software. According to the state-of-the-art, it is possible to validate a complex software system so thoroughly that the required error rate can be achieved by ASIL B, but not by ASIL D.
    The present invention discloses a method and hardware architecture to increase the reliability of a complex electronic system. Through the targeted use of hardware and software redundancy, the reliability of the electronic system is significantly increased.
    In the area of security technology in the aerospace industry, a distinction is made between simple and complex software [4]. If the software that is used is simple and can be formally checked and / or tested extensively, it is assumed that the required error rate of ASIL D can be achieved through a careful development process.
    If the software used is complex, we assume that the likelihood of design errors is ASIL B. Through software redundancy, i.e. The parallel execution of two or more diverse ASIL B software systems with a subsequent application-specific comparison of the results can significantly increase the reliability of the software. A method for increasing software reliability through active redundancy (TMR) using diversified software is described in [5]. However, this method cannot be used if the diverse software versions do not behave in a replica-deterministic manner.
    Diverse software is not replica deterministic if the software has a NonDeterministic Design Construct (NDDC) [6, p128]. An NDDC decides between two correct but incompatible scenarios. In general, it must not be assumed that two diverse versions of the software with NDDCs come to comparable results.
    If e.g. there is a boulder on a road and the decision is to be made whether a vehicle should drive around this boulder on the left or right, so it cannot generally be assumed that two diverse software versions come to the same result. Although both results are correct, they are not replica deterministic. As a result, the fault tolerance is lost.
    The autonomous management of a motor vehicle requires a software system for image recognition, environmental model formation and trajectory planning. The software for image recognition and environmental modeling is very complex.
    According to the invention, it is proposed to implement at least two diverse versions of the complex software for image recognition and environmental model formation and to consolidate the results of these versions in order to be able to carry out the trajectory planning on the basis of a uniform, consolidated environmental model.
    In the event that the trajectory planning can be implemented using simple software, it is proposed to execute a single software version of the trajectory planning on fault-tolerant hardware.
    / 12
    - 4 If the software for trajectory planning is not simple, but complex, it is proposed to implement at least two diverse versions of the trajectory planning and to transfer the results of this multiple trajectory planning to a decision-making body to determine a single consolidated trajectory.
    According to the invention, it is also proposed to identify the NDDCs contained in the entire software system and to remove them from the software system. An NDDC that makes a decision between the alternatives presented is implemented using simple software without software redundancy. The simple software is run on fault-tolerant hardware in order to mask occurring hardware errors.
    The reliability of the complex software without NDDCs is significantly increased by comparing the results of several diverse versions of the complex software. The complex software identifies several alternatives that are passed to the NDDCs for decision.
    Summary
    The present invention describes an innovative method such as a complex electronic system for controlling a safety-critical technical process, e.g. the management of an autonomous vehicle can be realized. A distinction is made between simple and complex software, whereby the simple software is executed on fault-tolerant hardware and where several diverse versions of the complex software are executed simultaneously on independent fault containment units (FCU). From a number of diverse environmental models, a consolidated environmental model is developed that forms the basis for trajectory planning.
    Brief description of the drawings
    The present invention is explained in detail with reference to the following drawings.
    1 shows a data flow diagram of a complex electronic system for autonomous control of a vehicle with diversified environmental model formation and non-redundant trajectory planning.
    2 shows data flow diagram of a complex electronic system for autonomous control of a vehicle with diversified environmental model formation and with diversified trajectory planning.
    Description of a realization
    The following concrete description of an implementation deals with one of the many possible implementations of the new method using the example of an autonomous vehicle control system. The description uses terms that are described in detail below.
    / 12
    - 5 A controlled object (abbreviated CO) is a technical system that is controlled by a computer system and / or a human being, with the aim of fulfilling the given task under the given environmental conditions over time. Examples of COs are: a vehicle, an aircraft, an agricultural machine, a robot, or a drone.
    An environmental model is a digital data structure that, at a given point in time, represents the characteristics of the environment that are essential for the given task. An example of an environmental model is the description of a street and the objects on the street at the selected point in time.
    A trajectory is a path that a CO can take over time to accomplish the given task. The characteristics of the trajectories of a CO depend on the construction of the CO, the given task and the current environmental conditions. For example, a possible path that a vehicle can take under the given environmental conditions to achieve its goal is called a trajectory.
    A software process is understood to be the execution of a program system on one or more computers.
    A Fault Containment Unit (FCU) is a unit that encapsulates the immediate consequences of a cause of a fault (6, p155)
    The term fault-tolerant hardware is understood to mean a hardware architecture that masks occurring hardware faults in accordance with the present fault hypothesis. Examples of such hardware architectures are TripleModular Redundancy (TMR) or the parallel execution of the software on self-checking modules as described in (6, p.156). It corresponds to the state-of-the-art that the redundant FCUs receive their input data via at least two independent communication channels and pass on their output data via at least two independent communication channels
    A data flow path (DFP) is a sequence of software processes, the first software process reading input data and the output data of an upstream software process representing the input data for the subsequent software process. The output data of the last software process is the result data of the DFP. In many real-time data processing applications, a DFP is run through cyclically. The internal state [6, p.84] of a software process can be saved between the cycles of a DFP. In many real-time data processing applications, the first software process of a DFP takes over the sensor data and the last software process of a DFP produces the setpoints for the actuators.
    Two DFPs are diverse if they pursue the same objective, but the software processes of the DFPs use different algorithms (algorithm diversity) and / or different input data (data diversity).
    An environmental model is a software process that creates an environmental model based on the static data of the environment and the dynamic data of the environment captured by various sensors.
    A consolidated environmental model is an environmental model that integrates a number of independently created environmental models into a single environmental model.
    / 12
    - 6 A trajectory planning is a software process that, based on a given model of the environment, defines one or more possible trajectories that solve the given task.
    A decision-making body is a software process that receives a number of suggestions as input data, analyzes these suggestions and is free to make a decision as to which - possibly modified - proposal is selected. In many cases, a decision-making body is an NDDC. For example, a decision-making entity receives a number of suggestions for possible trajectories of a vehicle as input and decides on a possibly modified - trajectory that is carried out.
    For example, “observed data” can be understood to mean the data that result from the observation.
    1 shows a data flow diagram of a complex electronic system for autonomous control of a vehicle. The simply framed boxes 100 show software processes that are executed on non-redundant hardware. The double-framed boxes 101 show software processes that are executed on fault-tolerant hardware. The vertical connecting lines between the boxes of Fig. 1 show the data flow from top to bottom.
    1 shows three diverse DFPs 110, 120 and 130. Each of the DFPs has its own sensors for monitoring the environment of the vehicle. The sensors are read out cyclically. DFP 110 has sensors 111, DFP 120 has sensors 121 and DFP 130 has sensors 131. Examples of sensors in a vehicle are cameras, radar sensors, LIDAR sensors and ultrasonic sensors. In the first processing stage of the DFP, the raw sensor data are read out and pre-processed. This is software process 112 in DFP 110, software process 122 in DFP 120, and software process 132 in DFP 130.
    It is advantageous if the software processes 112, 122 and 132 use different algorithms (algorithm diversity) that are supplied with different input data (data diversity).
    It is advantageous if the sensors 111, 121 and 131 observe the surroundings at the same time. The simultaneous observation can be achieved by a distributed trigger signal derived from a fault-tolerant global time.
    In the second processing stage of the DFP, environmental model formation is carried out on the basis of the received sensor data and information about the static parameters of the environment (e.g. from the map material of the navigation system). This is software process 113 in DFP 110, software process 123 in DFP 120 and software process 133 in DFP 130.
    It is advantageous if the software processes 113, 123 and 133 use different algorithms (algorithm diversity) that are supplied with different input data (data diversity).
    In Fig. 1 it is assumed that the software for trajectory planning is simple and can therefore be implemented without software diversity. In the third processing stage 150 of FIG. 1, a uniform consolidated environmental model is first created from the various received environmental models, which represents the basis for the following non-redundant trajectory planning. The / 12
    - 7 trajectory planning determines the setpoints for the intelligent actuator control 160. The software processes of the processing stage 150 and the actuator control 160 are executed on fault-tolerant hardware.
    2 it is assumed that the software for trajectory planning is complex and therefore cannot be implemented without software diversity. In the processing stage 240 of FIG. 2, a uniform consolidated environmental model is first created from the various environmental models received, which represents the basis for the following non-redundant trajectory planning. Processing stage 240 is executed on fault tolerant hardware.
    In the following parallel processing stages 241, 242 and 243, several diverse versions of the trajectory planning are carried out. Each version of the trajectory planning determines one or more trajectories and evaluates the determined trajectories in terms of effectiveness for target achievement and security.
    The decision-making body 250 thus receives a number of various evaluated suggestions for trajectories of the trajectory planning 241, 242 and 243 and decides on a trajectory that was proposed and appropriately evaluated by at least two of the three planning processes 241, 242 and 243. The setpoint values for realizing the selected trajectory are then determined by the decision-making entity 250 and transferred to the intelligent actuators 160. Decision authority 250 is executed on fault tolerant hardware.
    It is advantageous if the suggestions for trajectories of the software processes 114, 124 and 134 are transmitted to the decision-making body 250 almost simultaneously. This can be achieved by deriving the trigger signals for actions from the progression of a fault-tolerant global time.
    The following section describes an example of another strategy. While the trajectory planning 241 and the trajectory planning 242 pursue the same task - guiding the vehicle to the planned destination - the trajectory planning 243 has the task of leading the vehicle to a safe state as quickly as possible, e.g. Park on the side of the road. If decision authority 250 does not find a trajectory that is in line with one of the offered alternatives from 241 and 242, decision authority 250 accepts the suggestion from 243 and gives setpoints to actuators 260 that lead the vehicle into a safe state (e.g., parking beside the road).
    The diversity of the complex software can be achieved either by data diversity or by algorithm diversity or by both data diversity and algorithm diversity. It is a great advantage if both data diversity and algorithm diversity are realized.
    If only diversity is used for economic reasons, there are several ways to reduce costs.
    If data diversity is dispensed with, a sensor can transfer the recorded data to several diverse software processes. Data diversity can also be achieved by transforming the model representation - e.g. the representation of the trajectories in different coordinate systems - can be achieved.
    If the diversity algorithm is dispensed with, all software processes can use the same algorithms.
    / 12
    - 8 During operation it is very difficult to decide whether a determined deviation of a result of a DFP from the other two DFPs was caused by an aging error in the hardware or a software error. However, this distinction is insignificant at the moment the error occurs, since the proposed architecture masks both types of error.
    / 12
    权利要求:
    Claims (12)
    [1]
    claims
    1. Method for controlling a technical process which is embedded in a changing environment, the electronic system performing the control sensors, in particular a large number of sensors, actuators and node computers, in particular a large number of node computers, which exchange data via a real-time communication system, characterized in that a distinction is made between complex and simple software, the complex software being executed simultaneously on at least two independent data flow paths (DFP) (110, 120), each DFP with sensors observing the technical process and its environment cyclically and from the observed data using algorithms creates an environmental model of the technical process, whereby
    - the observed data are diverse and the algorithms used in the DFP are diverse, or
    - the observed data are not diverse and the algorithms used in the DFP are diverse, or
    - The observed data are diverse and the algorithms used in the DFP are not diverse, and in a subsequent processing step from a number of different environmental models using simple software, a single consolidated environmental model is built for trajectory planning, this simple software being executed on fault-tolerant hardware ,
    [2]
    2. The method according to claim 1, characterized in that in the event that the software for the trajectory planning is simple, a non-redundant trajectory planning defines a trajectory in the consolidated model of the environment and the target values corresponding to this trajectory to a, preferably intelligent, actuator control passes.
    [3]
    3. The method according to claim 1, characterized in that in the event that the software for the trajectory planning is complex, at least two diverse trajectory plans (241, 242, 243) in the consolidated environmental model define one or more trajectories for goal achievement and these trajectories a simple one Pass decision-making body (250) for selection.
    [4]
    4. The method according to any one of claims 1 to 3, characterized in that the trajectory planning (241, 242, 243) evaluate the determined trajectories from the point of view of target achievement and security.
    [5]
    5. The method according to any one of claims 1 to 4, characterized in that the decision-making entity (150) selects a trajectory that is proposed by at least two trajectory plans, the decision-making entity (150) calculating the target values for the actuators and sending them to one, preferably intelligent , Actuator control (160) passes.
    10/12
    [6]
    6. The method according to any one of claims 1 to 5, characterized in that the trajectory planning and the decision-making entity (150) are carried out on fault-tolerant hardware.
    [7]
    7. The method according to any one of claims 1 to 6, characterized in that the decision instance (150) is executed on fault-tolerant hardware.
    [8]
    8. The method according to any one of claims 1 to 7, characterized in that data diversity of the DFPs is dispensed with and the data recorded by the sensors are transferred to a plurality of DFPs.
    [9]
    9. The method according to any one of claims 1 to 8, characterized in that algorithm diversity of the DFPs is dispensed with and the same algorithms are used in all DFPs.
    [10]
    10. The method according to any one of claims 1 to 9, characterized in that the data diversity is achieved by using different coordinate systems in the diverse software processes.
    [11]
    11. The method according to any one of claims 1 to 10, characterized in that structural units, e.g. the node computers, the communication system, sensors, actuators, preferably all units, have access to a fault-tolerant global time and the control of the data flow between the node computers is derived from the progress of the global time.
    [12]
    12. Electronic system for controlling a technical process which is embedded in a changing environment, the electronic system comprising sensors, in particular a large number of sensors, actuators and node computers, in particular a large number of node computers, which exchange data via a real-time communication system, characterized in that a distinction is made between complex and simple software, the complex software being executed simultaneously on at least two independent data flow paths (DFP) (110, 120), each DFP with sensors observing the technical process and its environment cyclically and from the observed data created an environmental model of the technical process using algorithms, whereby
    - the observed data are diverse and the algorithms used in the DFP are diverse, or
    - the observed data are not diverse and the algorithms used in the DFP are diverse, or
    - The observed data are diverse and the algorithms used in the DFP are not diverse, and in a subsequent processing step from a number of different environmental models using simple software, a single consolidated environmental model is built for the trajectory planning, this simple software being executed on fault-tolerant hardware ,
    11/12
    1.1
    HO 120 130
    类似技术:
    公开号 | 公开日 | 专利标题
    EP3285163B1|2020-10-21|Fault-tolerant method and device for controlling an autonomous technical plant by means of diverse trajector planning
    EP3287902B1|2020-01-01|Fault-tolerant method and device of controlling an autonomous technical plant on the basis of a consolidated environmental model
    EP3376330B1|2020-11-04|Fault-tolerant method for detecting faults in an electronic system for controlling a controlled object
    DE102014205180A1|2015-09-24|Method and device for operating a vehicle
    EP3376390B1|2019-10-30|Fault tolerant method for controlling an autonomous controlled object
    DE102017118401B4|2021-09-23|METHOD AND SYSTEM FOR PERFORMING AUTONOMOUS OPERATION OF A VEHICLE
    DE102012111991A1|2014-05-22|Method for a driver assistance application
    EP3271231A1|2018-01-24|Method and device for monitoring a target trajectory to be travelled by a vehicle for absence of collisions
    DE102011005844A1|2012-09-27|Method for automatic controlling of vehicle, involves processing transverse movement of vehicle by decision tree and processing longitudinal movement of vehicle by another decision tree
    DE102017214531A1|2019-02-21|Method and device for operating a motor vehicle in an automated driving operation and motor vehicle
    WO2003075104A2|2003-09-12|Device and method for assessing the safety of systems and for obtaining safety in systems, and corresponding computer program
    DE102017208462A1|2018-11-22|Method and device for determining operating data for an automated vehicle
    DE202017105656U1|2017-10-10|Predictive measuring system, actuator control system and apparatus for operating the predictive measuring system and / or the actuator control system
    EP3642717A1|2020-04-29|Device and method for controlling a vehicle module
    DE102019118607A1|2020-01-16|ANOMALY DETECTOR FOR VEHICLE CONTROL SIGNALS
    DE10133670A1|2003-01-30|Method for automatic generation of a knowledge base for a technical system diagnosis system from a model of the technical system, e.g. for fault monitoring and diagnosis of a motor vehicle onboard control system
    DE102017218143A1|2019-04-11|Method and device for driving a vehicle electronic planning module
    DE102017120366A1|2019-03-07|Method, apparatus, computer program and computer program product for motion planning of a system
    DE102017109175A1|2018-10-31|Control device, driver assistance system, motor vehicle and method for controlling a driver assistance function
    DE102020209985A1|2022-02-10|Device and method for determining environmental information
    DE102020201984A1|2021-08-19|Method for enabling a journey of a motor vehicle
    DE102020202305A1|2021-08-26|Method for recognizing the surroundings of a vehicle and method for training a fusion algorithm for a vehicle system
    DE102018222720B4|2022-01-05|Monitoring of driving functions based on neural networks
    EP3968213A1|2022-03-16|Method for determining a track-bound railway track in a track system and device for carrying out this method
    DE102018125712A1|2020-04-23|Driving support method for a vehicle
    同族专利:
    公开号 | 公开日
    EP3287902A1|2018-02-28|
    EP3287902B1|2020-01-01|
    US10571920B2|2020-02-25|
    AT519164A3|2018-10-15|
    US20180052465A1|2018-02-22|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    DE102019202059A1|2019-02-15|2020-08-20|Zf Friedrichshafen Ag|Sensor device and method for an autonomous motor vehicle and autonomous motor vehicle|US8464102B2|2010-12-23|2013-06-11|GM Global Technology Operations LLC|Methods and systems for diagnosing hardware and software faults using time-stamped events|
    DE102011117113A1|2011-10-27|2013-05-02|Diehl Bgt Defence Gmbh & Co. Kg|Method for operating a control device for at least partially autonomous operation of a vehicle and control device for carrying out such a method|
    US9407696B2|2011-12-27|2016-08-02|Fts Computertechnik Gmbh|Method for combining results of periodically operating EDP components at the correct time|
    JP6442129B2|2013-03-14|2018-12-19|エフティーエス コンピューターテクニク ジーエムビーエイチ|Apparatus and method for autonomous control of automobile|
    DE102013213169A1|2013-07-04|2015-01-08|Robert Bosch Gmbh|Method and device for operating a motor vehicle in an automated driving operation|
    US9915950B2|2013-12-31|2018-03-13|Polysync Technologies, Inc.|Autonomous vehicle interface system|AT519165A3|2016-08-16|2018-10-15|Fts Computertechnik Gmbh|Fault-tolerant method and device for controlling an autonomous technical installation by means of diversified trajectory planning|
    DE102018210585A1|2018-06-28|2020-01-02|Conti Temic Microelectronic Gmbh|Driver assistance system for selecting a movement parameter set|
    EP3885226A1|2020-03-25|2021-09-29|Aptiv Technologies Limited|Method and system for planning the motion of a vehicle|
    法律状态:
    优先权:
    申请号 | 申请日 | 专利标题
    ATA50738/2016A|AT519164A3|2016-08-16|2016-08-16|Fault-tolerant method and device for controlling an autonomous technical plant on the basis of a consolidated environmental model|ATA50738/2016A| AT519164A3|2016-08-16|2016-08-16|Fault-tolerant method and device for controlling an autonomous technical plant on the basis of a consolidated environmental model|
    EP17184470.7A| EP3287902B1|2016-08-16|2017-08-02|Fault-tolerant method and device of controlling an autonomous technical plant on the basis of a consolidated environmental model|
    US15/678,181| US10571920B2|2016-08-16|2017-08-16|Fault-tolerant method and device for controlling an autonomous technical system based on a consolidated model of the environment|
    [返回顶部]