• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    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, where the simple software is executed on a fault-tolerant hardware and where multiple diverse versions of the complex software are executed simultaneously on independent fault-containment units (FCUs) and where the complex software results from a decision-making entity , which is realized by means of a simple software, a result is selected which is forwarded to the actuators.
    公开号:AT519165A2
    申请号:T50737/2016
    申请日:2016-08-16
    公开日:2018-04-15
    发明作者:
    申请人:Fts Computertechnik Gmbh；
    IPC主号:
    专利说明:

    Fault-tolerant method and device for controlling an autonomous technical installation by means of diversified trajectory planning
    Quoted literature
    Patents: [1] US Pat. Application 20160033965 Device and Method for the Autonomous Control of Vehicles, published Feb. 4, 2016
    Other: [2] Wikipedia, Autonomous Driving, accessed on Aug 11, 2016 [3] Wikipedia, Automotive Safety Integrity Levels ISO 26262, retrieved on Aug 11, 2016 [4] FAA. Advisory Circular System Safety Assessment for Part 23 Airplanes. URL: http://www.faa.gov/documentLibrary/media/Advisory_Circular/AC%2023.1309 -IE.pdf accessed on Aug 11, 2016 [5] Avizienis, A. The N-Version Approach to Fault-Tolerant Software, IEEE Trans , on Software Engineering, Vol 11, pp. 1491-1501. Dec. 1985, [6] Kopetz, H. Real-Time Systems, Design Principles for Distributed Embedded Applications. Springer Verlag. 2011th
    Technical environment
    The present invention is in the field of computer technology. It relates to a method and an electronic system for fault-tolerant control of an autonomous technical installation, in particular of a vehicle.
    Brief description of the invention
    The developments in sensor technology and computer technology make it possible to largely autonomously control a technical system or a vehicle that autonomously controls its destination.
    According to Wikipedia [2] the classification of autonomous driving is done in six stages: • Level 0: "Driver only", the driver drives, steers, accelerates, brakes, etc. • Level 1: Certain assistance systems help with vehicle operation (ia ACC). • Level 2: partial automation. Et al automatic parking, lane keeping, general longitudinal guidance, accelerate, decelerate, etc. are taken over by the assistance systems (including traffic jam assistant). • Level 3: high automation. The driver does not have to constantly monitor the system. The vehicle autonomously performs functions such as triggering the turn signal, lane change and tracking. The driver can turn to other things, but is prompted by the system if necessary within a warning time to take the lead. This form of autonomy is technically feasible on motorways. Legislators work to allow Level 3 vehicles. We speak of a time frame until 2020. • Level 4: full automation. The guidance of the vehicle is permanently taken over by the system. If the system no longer copes with 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 and the vehicle can move while driving.
    Level 2 vehicles are currently being made available on the market. At level 2, the driver is required 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 made fault tolerant to ensure the safety of the vehicle even in the event of a computer system failure.
    In the ISO 26262 standard, an electronic system (hardware plus software) in a vehicle is assigned to one of four levels of integrity (level ASIL A to ASIL D), where level ASIL D represents the highest level of integrity [3] Fully Automated Vehicle Control (Level 4 and Level 5) must be ASIL D compliant. While in ASIL B the likelihood of a dangerous fault having a serious impact on the safety of a vehicle must be less than 10 "6 per hour (ie 103 FIT), this probability for ASIL D must be less than 10'8 per hour (ie 10 FIT).
    The cause of the failure of an electronic system may be a physical fault of the hardware or a design fault.
    An aging fault occurs when a package that was fully functional at the beginning of its lifetime fails due to hardware aging processes. For state of the art automotive chips, the permanent error rate for aging errors is <100 FIT. Through the use of 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 may be included in the hardware or in the software. The consequences of hardware design errors can be overcome by active redundancy of diverse hardware.
    Actions that reduce the likelihood of undetected design flaws in the software are more systematic
    Design process, verification and validation, especially through extensive testing. One of the main causes of software design errors 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 of ASIL B, but not of ASIL D can be achieved.
    The present invention discloses a method and hardware architecture for increasing the reliability of a complex electronic system. The targeted use of hardware and software redundancy significantly increases the reliability of the electronic system.
    In the field of aerospace safety technology, a distinction is made between simple and complex software [4]. If the software used is simple and can be formally reviewed and / or extensively tested, it is assumed that the required error rate by ASIL D can be achieved through a careful development process.
    If the software being used is complex, it is assumed that the probability of design errors occurring corresponds to ASIL B. By software redundancy, i. 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 the software reliability through active redundancy (TMR) by means of diverse software is described in [5]. However, this method can not be used if the diversified software versions are not replica-deterministic.
    Diversity software is not replica-deterministic if there is a Non-Deterministic Design Construct (NDDC) [6, pl28] in the software. An NDDC decides between two correct but incompatible scenarios. In general, it can not be assumed that two different versions of software with NDDCs produce comparable results.
    If e.g. On a road is a boulder and the decision is to make, whether this boulder is to be avoided by a vehicle left or right, it can not be generally 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 guidance of a motor vehicle requires a software system for image recognition, environmental modeling and trajectory planning. This software system is not simple but complex and includes NDDCs.
    According to the invention, it is proposed to identify the NDDCs contained in the entire software system and to detach them from the software system. An NDDC that makes a decision between presented alternatives is realized by means of a simple software without software redundancy. The simple software runs on fault tolerant hardware to mask any hardware errors that occur.
    The reliability of the remaining complex software without NDDCs is significantly increased by comparing the results of several diverse versions of the complex software running on independent fault-containment units (FCUs). The complex software determines several alternatives that are passed to a decision-making body 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 leadership of an autonomous vehicle, can be realized. A distinction is made between simple and complex software, where the simple software is executed on a fault-tolerant hardware and where multiple diverse versions of the complex software are executed simultaneously on independent fault-containment units (FCUs) and where the complex software results from a decision-making entity , which is realized by means of a simple software, a result is selected which is to be forwarded to the actuators.
    Brief description of the drawings
    The present invention will be explained in detail with reference to the following drawings.
    Fig. 1 shows a data flow diagram of a complex electronic system for the autonomous control of a vehicle.
    FIG. 2 shows a possible hardware architecture for realizing the complex electronic system of FIG. 1 with a TMR hardware for executing the NDDC.
    FIG. 3 shows a possible hardware architecture for realizing the complex electronic system of FIG. 1 with self-checking hardware for executing the NDDC.
    Description of a realization
    The following concrete description of a realization 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.
    A controlled object (CO, for short) 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 given environmental conditions over time. Examples of COs are: a vehicle, an airplane, an agricultural machine, a robot, or a drone.
    An environmental model is a digital data structure that at a given time represents the characteristics of the environment that are essential to the given task. An example of an environmental model is the description of a road and the objects on the road at the selected time.
    A trajectory is a path that CO can perform over time to accomplish the given task. The characteristics of the trajectories of a CO depend on the design of the CO, the given task and the current environmental conditions. For example, a possible path that a vehicle can perform under given environmental conditions to reach its destination is called a trajectory.
    A software process is understood to mean the execution of a program system on one or more computers.
    A Fault Containment Unit (FCU) is an assembly that isolates the immediate consequences of a failure cause (6, pl55)
    The term fault-tolerant hardware is understood to mean a hardware architecture which masks occurring hardware errors according to the existing error hypothesis. Examples of such hardware architectures are Triple Modular Redundancy (TMR) or the parallel execution of the software on self-checking devices as described in (6, p.156). It is state of the art that the redundant FCUs have at least two independent ones
    Communication channels receive their input data and pass on at least two independent communication channels their output data
    A data flow path (OFT) is a sequence of software processes wherein the first software process reads input data and the output data of an upstream software process represents 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 cycled. Between the cycles of a DFP, the internal state [6, p.84] of a software process can be stored. In many real-time data processing applications, the first software process of a DFP takes over the sensor data and the final software process of a DFP produces the setpoint values for the actuators.
    Two DFPs are diverse if they pursue the same goal, but the software processes of the DFPs use different algorithms (algorithm diversity) and / or different input data (data diversity).
    Environmental Modeling is a software process that creates an environmental model based on the static data of the environment and the dynamic data collected by various sensors.
    A trajectory design is a software process that determines one or more possible trajectories that solve the given task based on a given environmental model.
    An arbitration instance is an application-specific software process that receives a set of suggestions as input data, analyzes those proposals, and has the freedom to decide which - possibly modified - proposal is selected. In many cases, a decision maker is an NDDC. For example, a decision maker receives as input a number of suggestions of possible trajectories of a vehicle and chooses a possibly modified trajectory to be executed.
    For example, under "observed data", the data resulting from the observation can be understood.
    Fig. 1 shows a data flow diagram of a complex electronic system for the autonomous control of a vehicle. The vertical connecting lines 100 of the boxes of Fig. 1 show the data flow from top to bottom.
    In Fig. 1, three diverse DFPs 110, 120 and 130 are shown. Each of the DFPs has its own sensors to monitor the environment of the vehicle. The sensors are read cyclically. DFP 110 has sensors 111, DFP 120 has sensors 121 and DFP 130 has sensors 131. Examples of sensors of a vehicle are cameras, radar sensor, LID AR sensors and ultrasonic sensors. In the first processing stage of the DFP, the raw sensor data is read out and preprocessed. 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) which are supplied with different input data (Dalen-Diversilät).
    It is advantageous if the sensors 111, 121 and 131 observe the environment at the same time. The concurrent observation can be accomplished with a distributed trigger signal derived from a fault tolerant global time.
    In the second processing stage of the DFP, based on the received sensor data and information about the static parameters of the environment (e.g., from the present map material of the navigation system), environmental modeling is performed. 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) with different ones
    Input data (data diversity).
    In the third processing stage of a DFP, the trajectory planning is performed on the basis of the formed environmental models of the second processing stage. This is software process 114 in DFP 110, software process 124 in DFP 120, and software process 134 in DFP 130.
    It is advantageous if the software processes 114, 124 and 134 use different algorithms (algorithm diversity) with different ones
    Input data (data diversity).
    The trajectory planning in the third processing stage develops several alternative trajectories for goal achievement which are offered to the following software process, the decision-making entity 150. The proposed trajectories are evaluated by trajectory planning from the point of view of safety and effectiveness in terms of target achievement. The decision authority 150 thus receives several various evaluated proposals for trajectories of the trajectory planning 114, 124, and 134 and chooses a trajectory that has been proposed and appropriately evaluated by at least two of the three trajectory planning processes 114, 124, and 134. Subsequently, the decision unit 150 determines the setpoint values for realizing the selected trajectory and sends it to the intelligent actuators 160, d.s. Steering, brake and acceleration, passed.
    It is advantageous if the transmission of the suggestions for trajectories of the software processes 114, 124 and 134 to the decision entity 150 takes place 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 DFP 110 and the DFP 120 are doing the same thing - guiding the vehicle to the intended destination - DFP 130 has the task of bringing the vehicle to a safe state as quickly as possible, e.g. Parking at the roadside. If the decision-making entity 150 does not find a trajectory consistent with one of the offered alternatives of DFP 110 and DFP 120, the decision-making body 150 adopts the proposal of the DFP 130 and gives target values to the actuators 160 which cause the vehicle to be in a safe state (eg parking at the roadside).
    By combining these two strategies, another strategy can be formed: Three DFPs to achieve the goal and another DFP to achieve a safe state.
    Fig. 2 shows a possible hardware structure for implementing the DFPs of Fig. 1. The boxes of Fig. 2 represent units. The connection lines 200 of the units of Fig. 2 show the communication channels present for the transmission of data. DFP 110 includes the sensors 111 and the assembly 210. DFP 120 includes the sensors 121 and the assembly 220. DFP 130 includes the sensors 131 and the assembly 230. The assembly 210 forms a fault-containment unit (FCU) that controls the hardware components (node computers , Data lines, memory) for executing the software processes 112, 113 and 114 of the DFP 110. The assembly 220 forms a fault-containment unit (FCU) which contains the hardware components (node computers, data lines, memory) for executing the software processes 122, 123 and 124 of the DFP 120. The assembly 230 forms a fault-containment unit (FCU) containing the hardware components (node computers, data lines, memory) for executing the software processes 132, 133 and 134 of the DFP 130.
    Decision authority 150 of FIG. 1 is simultaneously executed on the three node computers 251, 252 and 253 replica deterministically in order to be able to mask hardware errors. The results of the three node computers 251, 252 and 253 are passed to the intelligent actuator controller 260, which takes a bitwise two-out vote.
    Fig. 3 shows another hardware structure for implementing the DFPs of Fig. 1. The boxes of Fig. 2 represent units. The connection lines 200 of the units of Fig. 2 show the communication channels present for the transmission of data. In contrast to FIG. 2, in FIG. 3, the decision entity 150 is executed on the two self-checking assemblies 351 and 352. The intelligent actuator controller 360 takes on one of the results of 351 or 352. Since the software processes running on the packages 351 and 352 are replica-deterministic and the hardware of the packages 351 and 352 self-verify, the results of the packages 351 and 352 must be identical ,
    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 for economic reasons only one diversity is applied, then there are some possibilities of cost reduction.
    If the data diversity of the DFPs is omitted, a sensor can pass the collected data to multiple DFPs.
    Data diversity can be improved if the different DFPs use different coordinate systems to represent the trajectories.
    By eliminating DFP diversity diversity algorithms, the same algorithms can be used in all DFPs.
    On the fly, it is very difficult to decide if a detected deviation of one result of a DFP from the other two DFPs was due to an aging failure in the hardware or a software error. However, this distinction is insignificant at the moment the error occurs because the proposed architecture masks both types of errors.
    权利要求:
    Claims (8)
    [1]
    claims
    A method for controlling a technical process embedded in a changing environment, wherein the electronic system performing the control sensors, in particular a plurality of sensors, actuators and node computers, in particular a plurality of node computers that exchange data via a real-time communication system, characterized in that a distinction is made between complex and simple software, wherein the complex software is executed concurrently on at least two independent data flow paths (DFP) (110, 120), each DFP with sensors cyclically observing and observing the technical process and its environment Data using algorithms builds a model of the technical process and its environment and performs a trajectory planning to create one or more possible trajectories that correspond to the given objective under the given environmental conditions, wherein - the obobach Diverse data and the algorithms used in the DFP are diversified, 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 these decision-making (150) trajectories developed by the DFPs, the decision-making entity (150) being implemented by means of simple software, and wherein the decision-making entity (150) selects a trajectory proposed by the majority of the DFPs and where the decision-making entity (150) passes the selected trajectory to an actuator controller, and where the decision-making entity (150) executes on a fault-tolerant hardware.
    [2]
    A method according to claim 1, characterized in that the trajectories given to the decision authority (150) are evaluated in terms of security and effectiveness.
    [3]
    3. The method according to any one of claims 1 or 2, characterized in that at least two independent data flow paths (DFP) (110,120) process software processes that correspond to the predetermined objective, and another DFP (130) has the task of the technical process in a secure state, and where, in the event that the decision-making entity (150) does not find a trajectory that corresponds to the given objective, that trajectory is selected which leads the technical process to a safe state.
    [4]
    A method according to any one of claims 1 to 3, characterized in that structural units, e.g. the node computers, the communication system, sensors, actuators, preferably all of the assemblies, have access to a fault-tolerant global time and the control of the data flow between the node computers is derived from the progression of the global time.
    [5]
    5. The method according to any one of claims 1 to 4, characterized in that the data diversity of the DFPs is dispensed with and the data collected by the sensors are transferred to multiple DFPs.
    [6]
    6. The method according to any one of claims 1 to 5, characterized in that waiving algorithm diversity of the DFPs and in all DFPs the same algorithms are used.
    [7]
    7. The method according to any one of claims 1 to 6, characterized in that the data diversity is improved by using different coordinate systems to represent the trajectories.
    [8]
    8. An electronic system for controlling a technical process embedded in a changing environment, the electronic system comprising sensors, in particular a multiplicity of sensors, actuators and node computers, in particular a plurality of node computers exchanging data via a real-time communication system, characterized in that a distinction is made between complex and simple software, wherein the complex software is executed simultaneously on at least two independent data flow paths (DFP) (110,120), each DFP with sensors cyclically observing the technical process and its environment and from the observed data by means of algorithms build a model of the technical process and its environment and carry out a trajectory planning to create one or more possible trajectories that correspond to the given objective under the given environmental conditions, wherein - the observed data diver 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 these are of the DFPs developed decision-making (150) trajectories are passed for decision, where the decision-making entity (150) is implemented using simple software, and where the decision-making entity (150) selects a trajectory proposed by the majority of DFPs and where the decision-making body (150) passes the selected trajectory to an actuator controller, and where the decision authority (150) executes on a fault-tolerant hardware.
    类似技术:
    公开号 | 公开日 | 专利标题
    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
    EP3376390B1|2019-10-30|Fault tolerant method for controlling an autonomous controlled object
    DE102012111991A1|2014-05-22|Method for a driver assistance application
    EP0675420B1|1999-06-02|Monitoring device for monitoring the safety of airplanes
    DE102014205180A1|2015-09-24|Method and device for operating a vehicle
    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
    DE19919504A1|2001-03-22|Engine controller, engine and method for controlling an engine
    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
    EP3642717A1|2020-04-29|Device and method for controlling a vehicle module
    DE102018216423A1|2020-03-26|Determination of a control signal for a semi-autonomous vehicle
    DE102017218438A1|2019-04-18|Method and system for operating a vehicle
    DE102017109175A1|2018-10-31|Control device, driver assistance system, motor vehicle and method for controlling a driver assistance function
    DE102008000669A1|2009-09-17|Errors identifying method for control system utilized for controlling and/or regulating functions of vehicle i.e. motor vehicle, involves selecting and evaluating error responses and releasing error response with highest priority rank
    DE102020209985A1|2022-02-10|Device and method for determining environmental information
    DE102018222720B4|2022-01-05|Monitoring of driving functions based on neural networks
    DE102019214471A1|2021-03-25|Method for remote control of a motor vehicle
    DE102014113759B4|2017-03-30|Method and device for checking an instruction set of at least one arithmetic unit
    DE102012210793A1|2014-01-02|Method for validating propulsion of e.g. hybrid vehicle, involves determining actual propulsion acceleration of vehicle in travel direction, and verifying actual propulsion acceleration based on target propulsion acceleration
    WO2020177980A1|2020-09-10|Method and device for operating an automated vehicle
    WO2014012776A1|2014-01-23|Automated reconfiguration of a discrete event control loop
    WO2021104904A1|2021-06-03|Module-prioritization method, module-prioritization module, motor vehicle
    同族专利:
    公开号 | 公开日
    AT519165A3|2018-10-15|
    EP3285163B1|2020-10-21|
    US10359772B2|2019-07-23|
    EP3285163A1|2018-02-21|
    US20180052453A1|2018-02-22|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    DE102010042048B4|2010-10-06|2020-11-12|Robert Bosch Gmbh|Device and method for assisting a driver of a motor vehicle in a driving maneuver|
    AT511805B1|2011-11-09|2013-03-15|Fts Computertechnik Gmbh|METHOD OF OPTIMIZING THE WITHDRAWAL PERIOD IN REPLICA-DETERMINISTIC SYSTEMS|
    JP6442129B2|2013-03-14|2018-12-19|エフティーエス コンピューターテクニク ジーエムビーエイチ|Apparatus and method for autonomous control of automobile|
    WO2016033629A2|2014-09-05|2016-03-10|Fts Computertechnik Gmbh|Computer system and method for safety-critical applications|
    EP3057275B1|2015-02-10|2020-08-05|TTTech Computertechnik AG|Extended distribution unit|
    US10233745B2|2015-03-26|2019-03-19|Chevron U.S.A. Inc.|Methods, apparatus, and systems for steam flow profiling|
    US10142909B2|2015-10-13|2018-11-27|The Board Of Trustees Of The University Of Alabama|Artificial intelligence-augmented, ripple-diamond-chain shaped rateless routing in wireless mesh networks with multi-beam directional antennas|
    AT519164A3|2016-08-16|2018-10-15|Fts Computertechnik Gmbh|Fault-tolerant method and device for controlling an autonomous technical plant on the basis of a consolidated environmental model|
    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|
    EP3376330B1|2017-03-17|2020-11-04|TTTech Auto AG|Fault-tolerant method for detecting faults in an electronic system for controlling a controlled object|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|
    EP3376330B1|2017-03-17|2020-11-04|TTTech Auto AG|Fault-tolerant method for detecting faults in an electronic system for controlling a controlled object|
    EP3376390B1|2017-03-17|2019-10-30|TTTech Auto AG|Fault tolerant method for controlling an autonomous controlled object|
    EP3495218B1|2017-12-07|2020-06-24|TTTech Auto AG|Fault-tolerant computer system for assisted and autonomous driving|
    DE102018210585A1|2018-06-28|2020-01-02|Conti Temic Microelectronic Gmbh|Driver assistance system for selecting a movement parameter set|
    CN112230572B|2019-06-30|2021-09-03|比亚迪股份有限公司|Integrated control chip, control method thereof, storage medium, and vehicle|
    EP3760507A1|2019-07-04|2021-01-06|TTTech Auto AG|Safe trajectory selection for autonomous vehicles|
    CN112526961B|2020-08-18|2021-08-27|中国汽车技术研究中心有限公司|New energy automobile function fault tolerance testing device and testing method|
    法律状态:
    优先权:
    申请号 | 申请日 | 专利标题
    ATA50737/2016A|AT519165A3|2016-08-16|2016-08-16|Fault-tolerant method and device for controlling an autonomous technical installation by means of diversified trajectory planning|ATA50737/2016A| AT519165A3|2016-08-16|2016-08-16|Fault-tolerant method and device for controlling an autonomous technical installation by means of diversified trajectory planning|
    EP17184468.1A| EP3285163B1|2016-08-16|2017-08-02|Fault-tolerant method and device for controlling an autonomous technical plant by means of diverse trajector planning|
    US15/677,878| US10359772B2|2016-08-16|2017-08-15|Fault-tolerant method and device for controlling an autonomous technical system through diversified trajectory planning|
    [返回顶部]