任务识别方法、装置、车辆、可读存储介质及芯片与流程

1.本公开涉及自动驾驶领域，尤其涉及一种任务识别方法、装置、车辆、可读存储介质及芯片。


背景技术：

2.当前对车辆内域控制器的控制，主要依靠控制器域网(controller area network，can)信号进行通讯，转为服务实现的较少。而转为服务后，不可避免的面临着多端输入竞争和执行条件判断的问题。
3.当前的解决方案是通过can总线获取车辆所有的子系统的状态信息进行判断，但是定义can信号是一个繁琐且复杂的工作，而且定义过多的can信号，会对负载产生较大的影响，对后期维护也产生较大的压力。每个场景调用电子控制器(electronic control unit，ecu)的逻辑都是固定的，因此在代码中是静态的，每个场景都必须有一份独立的判断逻辑，造成调试(debug)困难以及后期修改需求时代码改动困难的问题。


技术实现要素：

4.为克服相关技术中存在的问题，本公开提供一种任务识别方法、装置、车辆、可读存储介质及芯片，以解决上述的多端输入竞争和执行条件判断问题。
5.根据本公开实施例的第一方面，提供一种任务识别方法，包括：通过面向服务架构soa服务获取车辆各个子系统对应的场景的状态信息；获取所述各个子系统对应的场景的配置文件中的状态逻辑块；结合所述状态信息及所述状态逻辑块判断目标任务是否满足执行条件。
6.可选的，所述获取所述各个子系统对应的场景的配置文件中的状态逻辑块，包括：通过所述soa服务调用组件初始化api，以确定调用的服务；根据所述调用的服务，及文件名生成规则，生成与所述调用的服务匹配的配置文件名称；根据配置文件名称查找到配置文件的位置；基于所述配置文件的位置获取所述配置文件中的所述状态逻辑块。
7.可选的，所述结合所述状态信息及所述状态逻辑块判断目标任务是否满足执行条件，包括：分析配置文件中的策略标签；将所述策略标签中的条件判断策略语句进行拆分并存入数据结构中；基于所述数据结构判断所述目标任务是否满足所述执行条件。
8.可选的，所述基于所述数据结构判断所述目标任务是否满足所述执行条件，包括：通过所述数据结构的各个节点，来判断所述目标任务是否满足所述执行条件。
9.可选的，所述通过所述数据结构的各个节点，来判断所述目标任务是否满足所述执行条件，包括：自底层向上遍历所述数据结构的各个节点，根据父节点保存的操作符以及父节点的两个子节点保存的执行条件判断所述父节点是否满足所述执行条件，直至遍历到所述根节点时判断所述根节点是否满足所述执行条件；在所述根节点不满足所述执行条件的情况下，确定所述目标任务不满足所述执行条件；在所述根节点满足所述执行条件的情况下，确定所述目标任务满足所述执行条件。
10.可选的，所述状态信息为车辆的当前状态对应的信息；所述状态逻辑块为所述目标任务的执行逻辑；所述执行条件为在所述车辆的当前状态下，所述目标任务的可执行逻辑。
11.根据本公开实施例的第二方面，提供一种任务识别装置，包括：获取模块，被配置为通过面向服务架构soa服务获取车辆各个子系统对应的场景的状态信息；所述获取模块，还被配置为获取所述各个子系统对应的场景的配置文件中的状态逻辑块；处理模块，被配置为结合所述状态信息及所述状态逻辑块判断目标任务是否满足执行条件。
12.根据本公开实施例的第三方面，提供一种车辆，包括：处理器；用于存储处理器可执行指令的存储器；其中，所述处理器被配置为执行所述可执行指令实现前述的任务识别方法的步骤。
13.根据本公开实施例的第四方面，提供一种计算机可读存储介质，其上存储有计算机程序指令，该计算机程序指令被处理器执行时实现本公开第一方面所提供的任务识别方法的步骤。
14.根据本公开实施例的第五方面，提供一种芯片，包括处理器和接口；所述处理器用于读取指令以执行前述的任务识别方法的步骤。
15.本公开的实施例提供的技术方案可以包括以下有益效果：通过面向服务架构soa服务获取车辆各个子系统对应的场景的状态信息，获取各个子系统对应的场景的配置文件中的状态逻辑块，结合状态信息及状态逻辑块判断目标任务是否满足执行条件；通过调用各个任务场景对应的soa服务来触发各个can信号，进而通过各个can信号触发各个子系统执行对应的任务，避免了通过can总线判断多端任务的执行条件，进而避免了定义繁琐且复杂can信号，降低了负载压力和后期维护压力，便于后期debug以及后期修改需求。
16.应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。
附图说明
17.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。
18.图1是根据一示例性实施例示出的一种任务识别方法的流程图。
19.图2是根据一示例性实施例示出的另一种任务识别装置的框图。
20.图3是根据一示例性实施例示出的一种任务识别装置的框图。
21.图4是一示例性实施例示出的一种车辆的功能框图示意图。
具体实施方式
22.这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。
23.可以理解的是，本公开中“多个”是指两个或两个以上，其它量词与之类似。“和/或”描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在
a，同时存在a和b，单独存在b这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。
24.进一步可以理解的是，本公开实施例中尽管在附图中以特定的顺序描述操作，但是不应将其理解为要求按照所示的特定顺序或是串行顺序来执行这些操作，或是要求执行全部所示的操作以得到期望的结果。在特定环境中，多任务和并行处理可能是有利的。
25.需要说明的是，本技术中所有获取信号、信息或数据的动作都是在遵照所在地国家相应的数据保护法规政策的前提下，并获得由相应装置所有者给予授权的情况下进行的。
26.图1是根据一示例性实施例示出的一种任务识别方法的流程图，如图1所示，任务识别方法应用于车辆，如自动驾驶车辆，该任务识别方法包括以下步骤：
27.在步骤s11中，通过面向服务架构soa服务获取车辆各个子系统对应的场景的状态信息。
28.面向服务架构(service-oriented architecture，soa)，是一种分布式运算的软件设计方法。软件的部分组件(调用者)，可以透过网络上的通用协议调用另一个应用软件组件运行、运作，让调用者获得服务。例如，调用者可以通过调用soa服务来调用某些服务，如移动车窗，通过soa服务配置车窗位置参数，然后通过车窗控制子系统发送调整车窗位置信号，调整车窗位置信号用于触发对应的can信号，can信号用于调整车窗位置。车辆各个子系统包括车窗控制子系统、车门控制子系统、空调子系统、座椅服务子系统等，这些子系统分别用于控制相应的场景下的任务执行。各个子系统对应的场景的状态信息可以是车辆的当前状态对应的信息。
29.通过soa服务获取车辆各个子系统对应的场景的状态信息，即通过soa服务实时获取车辆的当前状态对应的信息。
30.在步骤s12中，获取各个子系统对应的场景的配置文件中的状态逻辑块。
31.每个场景对应的目标任务都有一份独立的判断逻辑，判断目标任务是否可以执行的逻辑，判断逻辑包括各个场景的一些状态信息，即执行各个场景下目标任务的先决条件，将这些判断逻辑写在对应的配置文件中，即为状态逻辑块；即状态逻辑块是执行各个场景下目标任务的先决条件，因此可以根据状态逻辑块判断目标任务是否满足执行条件。
32.在步骤s13中，结合状态信息及状态逻辑块判断目标任务是否满足执行条件。
33.状态信息为车辆的当前状态对应的信息，不同的车辆子系统对应了不同的状态信息，例如对于车门控制子系统来说，对应的状态信息包括车辆处于静止状态或车辆处于运动状态，对于空调子系统来说，对应的场景可以是当前是否打开空调及空调具体的温度。
34.通过调用各个任务场景对应的soa服务来触发各个can信号，进而通过各个can信号触发各个子系统执行对应的任务，避免了通过can总线判断多端任务的执行条件，进而避免了定义繁琐且复杂can信号，降低了负载压力和后期维护压力，便于后期debug以及后期修改需求。
35.请参阅图2，图2为本公开示例性实施例示出的另一种任务识别方法的流程图。
36.需要说明的是，图2所示的任务识别方法与图1所示的任务识别方法的实施方式内容一致，图2中未提及之处可以参考图1的描述，在此不再赘述。图2所示的任务识别方法包
括以下步骤：
37.在步骤s21中，通过面向服务架构soa服务获取车辆各个子系统对应的场景的状态信息。
38.需要说明的是，soa服务下面包括多个域，每一个域下面通常有几十个原子服务或组合服务，原子服务是单独控制一个子系统，组合服务同时控制多个子系统。
39.车辆各个子系统包括车窗控制子系统、车门控制子系统、空调子系统、座椅服务子系统等，这些子系统分别用于控制相应的场景下的任务执行，例如车窗控制子系统可以控制车窗的升降，车门控制子系统可以在车辆处于静止场景下控制车门打开，空调子系统可以在车窗关闭的场景下控制空调打开，并调控空调的温度。
40.各个子系统对应的场景的状态信息可以是车辆的当前状态对应的信息，例如，对于车门控制子系统来说，对应的场景的状态信息包括车辆处于静止状态或车辆处于运动状态，对于空调子系统来说，对应的场景可以是当前是否打开空调，假设空调处于打开状态，那么对应的状态信息可以是空调具体的温度。
41.通过soa服务获取车辆各个子系统对应的场景的状态信息，即通过soa服务实时获取车辆的当前状态对应的信息，如车辆是处于静止状态还是运动状态，车辆内部的空调是否打开，车窗的位置，座椅的角度等信息。
42.由于不是通过can信号获取状态信息，所以获取到的状态信息数据包小，且不会获取到不需要的数据，减少了车内传输负载，极大的减少整车can信号的定义数量，降低了开发难度，加快了开发速度。
43.在步骤s22中，获取各个子系统对应的场景的配置文件中的状态逻辑块。
44.每个场景对应的目标任务都有一份独立的判断逻辑，判断目标任务是否可以执行的逻辑，判断逻辑包括各个场景的一些状态信息，即执行各个场景下目标任务的先决条件，将这些判断逻辑写在对应的配置文件中，即为状态逻辑块；即状态逻辑块是执行各个场景下目标任务的先决条件，因此可以根据状态逻辑块判断目标任务是否满足执行条件。配置的状态逻辑块是填写在单独的配置文件中的，因此是可以实时调整的，同一个soa服务调用可以根据各个不同的场景进行状态定制，不用修改代码，配置粒度可控，比较灵活。
45.获取各个子系统对应的场景的配置文件中的状态逻辑块包括：通过soa服务调用组件初始化应用程序接口(application program interface，api)，以确定调用的服务；根据调用的服务，及文件名生成规则，生成与调用的服务匹配的配置文件名称；根据配置文件名称查找到配置文件的位置；基于配置文件的位置获取配置文件中的状态逻辑块。
46.示例性的，可以基于用户的选择操作确定需要调用的soa服务，根据需要调用的soa服务及文件名生成规则，生成与调用的soa服务匹配的配置文件名称，在一种实施方式中，配置文件可以是xml格式的配置文件，一个api创建一个xml配置文件，xml配置文件的的命名规范可以为user_interface_《interface name》_config.xml；在得到配置文件名称后，根据配置文件名称查找到配置文件的位置，基于配置文件的位置获取配置文件中的状态逻辑块。状态逻辑块中包括一些策略标签(cond)和一些操作标签(operator)，其中cond为执行各个场景下目标任务的先决条件，operator为先决条件之间的逻辑运算关系，逻辑运算关系包括“或”和“与”两种。例如，在车辆当前状态下，车门控制子系统要控制车辆执行打开车门这个目标任务，需要判断条件1(cond1)：车辆是否处于静止状态，条件2(cond2)：
车辆是否处于有电的状态，以及判断cond1与cond2是否同时满足打开车门这个目标任务的执行条件，即判断cond1“与”cond2的逻辑运算是否满足。
47.在步骤s23中，分析配置文件中的策略标签，将策略标签中的条件判断策略语句进行拆分并存入数据结构中。
48.分析配置文件中的策略标签，将策略标签中的条件判断策略语句进行拆分并存入数据结构(二叉树)中，数据结构中一个节点就是一个策略标签，然后基于数据结构判断目标任务是否满足执行条件。执行条件为在车辆的当前状态下，目标任务的可执行逻辑。
49.在步骤s24中，基于数据结构判断目标任务是否满足执行条件。
50.基于数据结构判断目标任务是否满足执行条件可以是通过数据结构中的各个节点，来判断目标任务是否满足执行条件，其包括：根据父节点保存的操作符以及父节点的两个子节点保存的执行条件判断父节点是否满足执行条件，直至遍历到根节点时判断根节点是否满足执行条件；在根节点不满足执行条件的情况下，确定目标任务不满足执行条件；在根节点满足执行条件的情况下，确定目标任务满足执行条件。操作符是指“或”和“与”这样的逻辑运算。
51.示例性的，自底层向上遍历数据结构的各个节点，先判断相邻子节点是否满足执行条件，在相邻子节点均满足执行条件的情况下，父节点不管是“或”还是“与”的逻辑运算，父节点均满足执行条件；在相邻子节点中只有一个满足执行条件，父节点是“或”的逻辑运算的情况下，确定父节点满足执行条件；在相邻子节点中只有一个满足执行条件，父节点是“与”的逻辑运算的情况下，确定父节点不满足执行条件；在相邻子节点均不满足执行条件的情况下，确定父节点不满足执行条件。
52.然后按照上述的判断逻辑，将父节点作为新的子节点进行判断，在父节点和父节点的相邻节点不满足执行条件的情况下，确定目标任务不满足执行条件，在遍历完数据结构的各个节点，根节点满足执行条件的情况下，确定目标任务满足执行条件。
53.示例性的，在车辆当前状态下，车门控制子系统要控制车辆执行打开车门这个目标任务，需要满足以下条件，条件1(cond1)是车辆处于静止状态，条件2(cond2)是车辆处于有电的状态，以及cond1与cond2同时满足，即在cond1“与”cond2的逻辑运算满足的条件下。
54.从而在状态信息及状态逻辑块的结合下，基于数据结构实现了判断目标任务是否满足执行条件。
55.通过调用各个任务场景对应的soa服务来触发各个can信号，进而通过各个can信号触发各个子系统执行对应的任务，降低了开发复杂度，对执行条件的判断实现了解耦，子系统更关注于调用流程而不是执行条件的判断；减少测试成本，修改执行条件逻辑不需要更改代码重新编译，只需要更改配置文件即可；降低车辆内数据流通复杂度，减少了can信号的定义；对各个原子服务，增加了可定制性，可根据不同的用户需要进行条件的定制；修改执行条件的迭代速度快，可以在前一版的基础上迅速的更新。
56.综上所述，本公开提供的任务识别方法，包括通过面向服务架构soa服务获取车辆各个子系统对应的场景的状态信息，获取各个子系统对应的场景的配置文件中的状态逻辑块，结合状态信息及状态逻辑块判断目标任务是否满足执行条件；通过调用各个任务场景对应的soa服务来触发各个can信号，进而通过各个can信号触发各个子系统执行对应的任务，避免了通过can总线判断多端任务的执行条件，进而避免了定义繁琐且复杂can信号，降
低了负载压力和后期维护压力，便于后期debug以及后期修改需求。
57.图3是根据一示例性实施例示出的一种任务识别装置框图。参照图3，该任务识别装置20包括获取模块201和处理模块203。
58.该获取模块201被配置为通过面向服务架构soa服务获取车辆各个子系统对应的场景的状态信息；
59.该获取模块201，还被配置为获取所述各个子系统对应的场景的配置文件中的状态逻辑块；
60.该处理模块203，被配置为结合所述状态信息及所述状态逻辑块判断目标任务是否满足执行条件。
61.可选的，该处理模块203，还被配置为通过所述soa服务调用组件初始化api，以确定调用的服务；
62.根据所述调用的服务，及文件名生成规则，生成与所述调用的服务匹配的配置文件名称；
63.根据配置文件名称查找到配置文件的位置；
64.基于所述配置文件的位置获取所述配置文件中的所述状态逻辑块。
65.可选的，该处理模块203，还被配置为分析配置文件中的策略标签；
66.将所述策略标签中的条件判断策略语句进行拆分并存入数据结构中；
67.基于所述数据结构判断所述目标任务是否满足所述执行条件。
68.可选的，该处理模块203，还被配置为通过所述数据结构的各个节点，来判断所述目标任务是否满足所述执行条件。
69.可选的，自底层向上遍历所述数据结构的各个节点，根据父节点保存的操作符以及父节点的两个子节点保存的执行条件判断所述父节点是否满足所述执行条件，直至遍历到所述根节点时判断所述根节点是否满足所述执行条件；
70.在所述根节点不满足所述执行条件的情况下，确定所述目标任务不满足所述执行条件；
71.在所述根节点满足所述执行条件的情况下，确定所述目标任务满足所述执行条件。
72.可选的，所述状态信息为车辆的当前状态对应的信息；
73.所述状态逻辑块为所述目标任务的执行逻辑；
74.所述执行条件为在所述车辆的当前状态下，所述目标任务的可执行逻辑。
75.关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。
76.本公开还提供一种计算机可读存储介质，其上存储有计算机程序指令，该程序指令被处理器执行时实现本公开提供的任务识别方法的步骤。
77.上述装置除了可以是独立的电子设备外，也可是独立电子设备的一部分，例如在一种实施例中，该装置可以是集成电路(integrated circuit，ic)或芯片，其中该集成电路可以是一个ic，也可以是多个ic的集合；该芯片可以包括但不限于以下种类：gpu(graphics processing unit，图形处理器)、cpu(central processing unit，中央处理器)、fpga(field programmable gate array，可编程逻辑阵列)、dsp(digital signal processor，
数字信号处理器)、asic(application specific integrated circuit，专用集成电路)、soc(system on chip，soc，片上系统或系统级芯片)等。上述的集成电路或芯片中可以用于执行可执行指令(或代码)，以实现上述的任务识别方法。其中该可执行指令可以存储在该集成电路或芯片中，也可以从其他的装置或设备获取，例如该集成电路或芯片中包括第一处理器、第一存储器，以及用于与其他的装置通信的接口。该可执行指令可以存储于该第一存储器中，当该可执行指令被第一处理器执行时实现上述的任务识别方法；或者，该集成电路或芯片可以通过该接口接收可执行指令并传输给该第一处理器执行，以实现上述的任务识别方法。
78.参阅图4，图4是一示例性实施例示出的一种车辆600的功能框图示意图。车辆600可以被配置为完全或部分自动驾驶模式。例如，车辆600可以通过感知系统620获取其周围的环境信息，并基于对周边环境信息的分析得到自动驾驶策略以实现完全自动驾驶，或者将分析结果呈现给用户以实现部分自动驾驶。
79.车辆600可包括各种子系统，例如，信息娱乐系统610、感知系统620、决策控制系统630、驱动系统640以及计算平台650。可选的，车辆600可包括更多或更少的子系统，并且每个子系统都可包括多个部件。另外，车辆600的每个子系统和部件可以通过有线或者无线的方式实现互连。
80.在一些实施例中，信息娱乐系统610可以包括通信系统611，娱乐系统612以及导航系统613。
81.通信系统611可以包括无线通信系统，无线通信系统可以直接地或者经由通信网络来与一个或多个设备无线通信。例如，无线通信系统可使用3g蜂窝通信，例如cdma、evd0、gsm/gprs，或者4g蜂窝通信，例如lte。或者5g蜂窝通信。无线通信系统可利用wifi与无线局域网(wireless local area network，wlan)通信。在一些实施例中，无线通信系统可利用红外链路、蓝牙或zigbee与设备直接通信。其他无线协议，例如各种车辆通信系统，例如，无线通信系统可包括一个或多个专用短程通信(dedicated short range communications，dsrc)设备，这些设备可包括车辆和/或路边台站之间的公共和/或私有数据通信。
82.娱乐系统612可以包括显示设备，麦克风和音响，用户可以基于娱乐系统在车内收听广播，播放音乐；或者将手机和车辆联通，在显示设备上实现手机的投屏，显示设备可以为触控式，用户可以通过触摸屏幕进行操作。
83.在一些情况下，可以通过麦克风获取用户的语音信号，并依据对用户的语音信号的分析实现用户对车辆600的某些控制，例如调节车内温度等。在另一些情况下，可以通过音响向用户播放音乐。
84.导航系统613可以包括由地图供应商所提供的地图服务，从而为车辆600提供行驶路线的导航，导航系统613可以和车辆的全球定位系统621、惯性测量单元622配合使用。地图供应商所提供的地图服务可以为二维地图，也可以是高精地图。
85.感知系统620可包括感测关于车辆600周边的环境的信息的若干种传感器。例如，感知系统620可包括全球定位系统621(全球定位系统可以是gps系统，也可以是北斗系统或者其他定位系统)、惯性测量单元(inertial measurement unit，imu)622、激光雷达623、毫米波雷达624、超声雷达625以及摄像装置626。感知系统620还可包括被监视车辆600的内部系统的传感器(例如，车内空气质量监测器、燃油量表、机油温度表等)。来自这些传感器中
的一个或多个的传感器数据可用于检测对象及其相应特性(位置、形状、方向、速度等)。这种检测和识别是车辆600的安全操作的关键功能。
86.全球定位系统621用于估计车辆600的地理位置。
87.惯性测量单元622用于基于惯性加速度来感测车辆600的位姿变化。在一些实施例中，惯性测量单元622可以是加速度计和陀螺仪的组合。
88.激光雷达623利用激光来感测车辆600所位于的环境中的物体。在一些实施例中，激光雷达623可包括一个或多个激光源、激光扫描器以及一个或多个检测器，以及其他系统组件。
89.毫米波雷达624利用无线电信号来感测车辆600的周边环境内的物体。在一些实施例中，除了感测物体以外，毫米波雷达624还可用于感测物体的速度和/或前进方向。
90.超声雷达625可以利用超声波信号来感测车辆600周围的物体。
91.摄像装置626用于捕捉车辆600的周边环境的图像信息。摄像装置626可以包括单目相机、双目相机、结构光相机以及全景相机等，摄像装置626获取的图像信息可以包括静态图像，也可以包括视频流信息。
92.决策控制系统630包括基于感知系统620所获取的信息进行分析决策的计算系统631，决策控制系统630还包括对车辆600的动力系统进行控制的整车控制器632，以及用于控制车辆600的转向系统633、油门634和制动系统635。
93.计算系统631可以操作来处理和分析由感知系统620所获取的各种信息以便识别车辆600周边环境中的目标、物体和/或特征。目标可以包括行人或者动物，物体和/或特征可包括交通信号、道路边界和障碍物。计算系统631可使用物体识别算法、运动中恢复结构(structure from motion，sfm)算法、视频跟踪等技术。在一些实施例中，计算系统631可以用于为环境绘制地图、跟踪物体、估计物体的速度等等。计算系统631可以将所获取的各种信息进行分析并得出对车辆的控制策略。
94.整车控制器632可以用于对车辆的动力电池和引擎641进行协调控制，以提升车辆600的动力性能。
95.转向系统633可操作来调整车辆600的前进方向。例如在一个实施例中可以为方向盘系统。
96.油门634用于控制引擎641的操作速度并进而控制车辆600的速度。
97.制动系统635用于控制车辆600减速。制动系统635可使用摩擦力来减慢车轮644。在一些实施例中，制动系统635可将车轮644的动能转换为电流。制动系统635也可采取其他形式来减慢车轮644转速从而控制车辆600的速度。
98.驱动系统640可包括为车辆600提供动力运动的组件。在一个实施例中，驱动系统640可包括引擎641、能量源642、传动系统643和车轮644。引擎641可以是内燃机、电动机、空气压缩引擎或其他类型的引擎组合，例如汽油发动机和电动机组成的混动引擎，内燃引擎和空气压缩引擎组成的混动引擎。引擎641将能量源642转换成机械能量。
99.能量源642的示例包括汽油、柴油、其他基于石油的燃料、丙烷、其他基于压缩气体的燃料、乙醇、太阳能电池板、电池和其他电力来源。能量源642也可以为车辆600的其他系统提供能量。
100.传动系统643可以将来自引擎641的机械动力传送到车轮644。传动系统643可包括
变速箱、差速器和驱动轴。在一个实施例中，传动系统643还可以包括其他器件，比如离合器。其中，驱动轴可包括可耦合到一个或多个车轮644的一个或多个轴。
101.车辆600的部分或所有功能受计算平台650控制。计算平台650可包括至少一个第二处理器651，第二处理器651可以执行存储在例如第二存储器652这样的非暂态计算机可读介质中的指令653。在一些实施例中，计算平台650还可以是采用分布式方式控制车辆600的个体组件或子系统的多个计算设备。
102.第二处理器651可以是任何常规的第二处理器，诸如商业可获得的cpu。可替换地，第二处理器651还可以包括诸如图像处理器(graphic process unit，gpu)，现场可编程门阵列(fieldprogrammable gate array，fpga)、片上系统(sysem on chip，soc)、专用集成芯片(application specific integrated circuit，asic)或它们的组合。尽管图4功能性地图示了第二处理器、第二存储器、和在相同块中的计算机的其它元件，但是本领域的普通技术人员应该理解该第二处理器、计算机、或第二存储器实际上可以包括可以或者可以不存储在相同的物理外壳内的多个第二处理器、计算机、或第二存储器。例如，第二存储器可以是硬盘驱动器或位于不同于计算机的外壳内的其它存储介质。因此，对第二处理器或计算机的引用将被理解为包括对可以或者可以不并行操作的第二处理器或计算机或第二存储器的集合的引用。不同于使用单一的第二处理器来执行此处所描述的步骤，诸如转向组件和减速组件的一些组件每个都可以具有其自己的第二处理器，第二处理器只执行与特定于组件的功能相关的计算。
103.在本公开实施方式中，第二处理器651可以执行上述的任务识别方法。
104.在此处所描述的各个方面中，第二处理器651可以位于远离该车辆并且与该车辆进行无线通信。在其它方面中，此处所描述的过程中的一些在布置于车辆内的第二处理器上执行而其它则由远程第二处理器执行，包括采取执行单一操纵的必要步骤。
105.在一些实施例中，第二存储器652可包含指令653(例如，程序逻辑)，指令653可被第二处理器651执行来执行车辆600的各种功能。第二存储器652也可包含额外的指令，包括向信息娱乐系统610、感知系统620、决策控制系统630、驱动系统640中的一个或多个发送数据、从其接收数据、与其交互和/或对其进行控制的指令。
106.除了指令653以外，第二存储器652还可存储数据，例如道路地图、路线信息，车辆的位置、方向、速度以及其它这样的车辆数据，以及其他信息。这种信息可在车辆600在自主、半自主和/或手动模式中操作期间被车辆600和计算平台650使用。
107.计算平台650可基于从各种子系统(例如，驱动系统640、感知系统620和决策控制系统630)接收的输入来控制车辆600的功能。例如，计算平台650可利用来自决策控制系统630的输入以便控制转向系统633来避免由感知系统620检测到的障碍物。在一些实施例中，计算平台650可操作来对车辆600及其子系统的许多方面提供控制。
108.可选地，上述这些组件中的一个或多个可与车辆600分开安装或关联。例如，第二存储器652可以部分或完全地与车辆600分开存在。上述组件可以按有线和/或无线方式来通信地耦合在一起。
109.可选地，上述组件只是一个示例，实际应用中，上述各个模块中的组件有可能根据实际需要增添或者删除，图4不应理解为对本公开实施例的限制。
110.在道路行进的自动驾驶汽车，如上面的车辆600，可以识别其周围环境内的物体以
确定对当前速度的调整。物体可以是其它车辆、交通控制设备、或者其它类型的物体。在一些示例中，可以独立地考虑每个识别的物体，并且基于物体的各自的特性，诸如它的当前速度、加速度、与车辆的间距等，可以用来确定自动驾驶汽车所要调整的速度。
111.可选地，车辆600或者与车辆600相关联的感知和计算设备(例如计算系统631、计算平台650)可以基于所识别的物体的特性和周围环境的状态(例如，交通、雨、道路上的冰、等等)来预测识别的物体的行为。可选地，每一个所识别的物体都依赖于彼此的行为，因此还可以将所识别的所有物体全部一起考虑来预测单个识别的物体的行为。车辆600能够基于预测的识别的物体的行为来调整它的速度。换句话说，自动驾驶汽车能够基于所预测的物体的行为来确定车辆将需要调整到(例如，加速、减速、或者停止)何种稳定状态。在这个过程中，也可以考虑其它因素来确定车辆600的速度，诸如，车辆600在行驶的道路中的横向位置、道路的曲率、静态和动态物体的接近度等等。
112.除了提供调整自动驾驶汽车的速度的指令之外，计算设备还可以提供修改车辆600的转向角的指令，以使得自动驾驶汽车遵循给定的轨迹和/或维持与自动驾驶汽车附近的物体(例如，道路上的相邻车道中的车辆)的安全横向和纵向距离。
113.上述车辆600可以为各种类型的行驶工具，例如，轿车、卡车、摩托车、公共汽车、船、飞机、直升飞机、娱乐车、火车等等，本公开实施例不做特别的限定。
114.在另一示例性实施例中，还提供一种计算机程序产品，该计算机程序产品包含能够由可编程的装置执行的计算机程序，该计算机程序具有当由该可编程的装置执行时用于执行上述的任务识别方法的代码部分。
115.本领域技术人员在考虑说明书及实践本公开后，将容易想到本公开的其它实施方案。本技术旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。
116.应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。