用于诊断请求的云管理验证和执行制造技术

本公开提供了“用于诊断请求的云管理验证和执行”。一种系统，包括测试环境和处理器。所述处理器被编程为：在所述测试环境上执行指定多个信息元素的诊断请求；响应于在预定义的超时期限内接收到来自所述测试环境的所述诊断请求的成功结果，批准所述诊断请求由车队车辆执行；以及否则的话，则重新测试作为多个请求的所述诊断请求。

Cloud management validation and execution for diagnostic requests

【技术实现步骤摘要】
用于诊断请求的云管理验证和执行
本公开的各方面总体上涉及用于诊断请求的云管理验证和执行。
技术介绍
诸如诊断故障代码(DTC)的汽车诊断数据形成简洁、具信息性的消息。设计诊断数据以允许车辆控制器指示系统故障和/或需要修理。
技术实现思路
在一个或多个说明性示例中，一种系统包括测试环境和处理器。所述处理器被编程为：在所述测试环境上执行指定多个信息元素的诊断请求；响应于在预定义的超时期限内接收到来自所述测试环境的所述诊断请求的成功结果，批准所述诊断请求由车队车辆执行；以及否则，重新测试作为多个请求的所述诊断请求。在一个或多个说明性示例中，一种方法包括将用于多个诊断代码的接收的诊断请求划分为多个诊断请求，每个诊断请求用于单个诊断代码；在测试环境上执行所述多个诊断请求；以及响应于在预定义的超时期限内接收到来自所述测试环境的所述多个诊断请求的成功结果，批准所述多个诊断请求由车队车辆执行。在一个或多个说明性示例中，一种非暂时性计算机可读介质包括指令，当由处理器执行时，所述指令使得所述处理器将用于多个诊断代码的单个诊断要求划分为多个诊断请求，每个诊断请求用于单个诊断代码；在测试环境上执行所述多个诊断请求；以及响应于在预定义的超时期限内接收到来自所述测试环境的所述多个诊断请求的成功结果，批准所述多个诊断请求由车队车辆执行。附图说明图1示出了实现用于诊断请求的云管理验证和执行的示例系统；图2示出了用于输入诊断要求的请求者装置的用户界面的示例；并且图3示出了实现用于诊断请求的云管理验证和执行的示例系统；并且图4示出了用于实现诊断请求的云管理验证、执行和划分的示例过程。具体实施方式根据需要，本文公开了本专利技术的详细实施例；然而，应理解，所公开的实施例仅仅是可以体现为各种和替代形式的本专利技术的示例。附图不一定按比例绘制；一些特征可能被放大或最小化以示出特定部件的细节。因此，本文中公开的具体结构细节和功能细节不应被解释为是限制性的，而是仅仅作为教导本领域技术人员以不同方式采用本专利技术的代表性基础。车辆可以被配置为经由车辆的嵌入式调制解调器接收和处理对某些诊断的请求。然而，某些车辆控制器的诊断请求的一些组合可能导致控制器功能的暂时丧失。依据控制器和诊断请求发生的时间，控制器功能的丧失可能导致显著的值得客户注意的问题。然而，可能具有挑战性的是：识别或以其他方式预测诊断请求的哪种组合与哪个控制器可能导致这个问题。车辆数据服务器可用于在由车辆执行请求之前自动验证嵌入式调制解调器的诊断请求。车辆数据服务器可以经由请求门户从调查装置接收诊断请求。响应于接收到诊断请求，车辆数据服务器可以经由基于云的管理器来处理请求，所述基于云的管理器在硬件回路(HIL)环境或其他模拟环境中执行请求。云管理器将等待响应，并且一旦可获得，就针对适当结构和内容对其进行评估。如果已经验证响应，则诊断请求将被释放给公共车队以进行执行。如果响应超时或被发现无效，则将取消诊断请求且将通知操作者。车辆数据服务器还可以被配置为将诊断请求分解成部件数据请求，使得每个部件数据请求直到接收和验证了来自前一次请求的响应才执行(而不是一次执行所有数据请求)。如果这个方法对于完整诊断请求有效，则车辆数据服务器可以按这种形式释放请求(在时间上间隔开的一系列单独请求而不是打包的请求)。图1示出了实现用于诊断请求122的云管理验证和执行的示例系统100。如图所示，车辆102包括通过一个或多个车辆总线106进行通信的多个车辆控制器104。系统100还包括车辆数据服务器126，其被配置为维持从各种车辆102接收的诊断数据120。车辆102还包括远程信息处理控制单元(TCU)108，其被配置为将包括诊断信息的诊断数据120发送到车辆数据服务器126。TCU108可以利用安装到TCU108的诊断应用程序130来发送诊断数据120的常规节奏，以及响应于已经满足的触发标准而发送触发的诊断数据120。应注意，系统100仅仅是一个示例，并且可以使用元件的其他布置或组合。车辆102可以包括各种类型的汽车、跨界多功能车(CUV)、运动型多功能车(SUV)、卡车、休闲车(RV)、船、飞机或用于运输人或货物的其他移动机械。在许多情况下，车辆102可以由内燃发动机提供动力。作为另一种可能性，车辆102可以是由内燃发动机和一个或多个电动马达两者提供动力的混合动力电动车辆(HEV)，诸如串联式混合动力电动车辆(SHEV)、并联式混合动力电动车辆(PHEV)、或并联/串联式混合动力电动车辆(PSHEV)。由于车辆102的类型和配置可以变化，因此车辆102的能力可以对应地变化。举一些其他可能性来说，车辆102就乘客容量、牵引能力和容量以及存储容积而言可以具有不同的能力。出于标题、库存和其他目的，车辆102可以与唯一标识符(诸如VIN)相关联。车辆102可以包括多个控制器104，其被配置为在车辆电池和/或传动系的动力下执行和管理各种车辆102的功能。如图所示，示例车辆控制器104被表示为离散控制器104-A至104-G。然而，车辆控制器104可以共享物理硬件、固件和/或软件，使得来自多个控制器104的功能可以集成到单个控制器104中，以及各种这样的控制器104的功能可以分布在多个控制器104上。作为一些非限制性车辆控制器104的示例：动力传动系统控制器104-A可以被配置为提供对发动机操作部件的控制(例如，怠速控制部件、燃料输送部件、排放控制部件等)以及用于监测这种发动机操作部件的状态(例如，发动机代码的状态)；车身控制器104-B可以被配置为管理各种电力控制功能，诸如外部照明、内部照明、无钥匙进入、远程启动和访问点状态验证(例如，车辆102的发动机罩、车门和/或行李厢的关闭状态)；无线电收发器控制器104-C可以被配置为与密钥卡、移动装置或其他本地车辆102装置通信；娱乐控制器104-D可以被配置为支持与驾驶员和驾驶员携带装置的语音命令和蓝牙接口；气候控制管理控制器104-E可以被配置为提供对加热和冷却系统部件的控制(例如，压缩机离合器、鼓风机风扇、温度传感器等)；全球定位系统(GPS)控制器104-F可以被配置为提供车辆位置信息；以及人机界面(HMI)控制器104-G可以被配置为经由各种按钮或其他控件接收用户输入，以及向驾驶员提供车辆状态信息，诸如燃料水平信息、发动机操作温度信息以及车辆102的当前位置。车辆总线106可以包括在车辆电子控制单元(ECU)104之间以及在TCU108和车辆ECU104之间可用的各种通信方法。作为一些非限制性示例，车辆总线106可以包括车辆控制器局域网(CAN)、以太网网络和面向媒体的系统传输(MOST)网络中的一个或多个。车辆总线106的布局和数量的另外的方面将在下面进一步详细讨论。TCU108可以包括网络硬件，其被配置为促进车辆ECU104与系统100的其他装置之间的通信。例如，TCU108可以包括或以其他方式访问被配置为促进与广域网112的通信的蜂窝调制解调器11本文档来自技高网...

【技术保护点】
1.一种系统，其包括：/n测试环境；以及/n处理器，所述处理器被编程为：/n在所述测试环境上执行指定多个信息元素的诊断请求，/n响应于在预定义的超时期限内接收到来自所述测试环境的所述诊断请求的成功结果，批准所述诊断请求由车队车辆执行，以及/n否则的话，则重新测试作为多个请求的所述诊断请求。/n

【技术特征摘要】
20180801 US 16/052,0691.一种系统，其包括：
测试环境；以及
处理器，所述处理器被编程为：
在所述测试环境上执行指定多个信息元素的诊断请求，
响应于在预定义的超时期限内接收到来自所述测试环境的所述诊断请求的成功结果，批准所述诊断请求由车队车辆执行，以及
否则的话，则重新测试作为多个请求的所述诊断请求。


2.如权利要求1所述的系统，其中所述处理器还被编程为：响应于在预定义的超时期限内接收到来自所述测试环境的所述重新测试的诊断请求的成功结果，批准作为多个请求的所述诊断请求由所述车辆执行。


3.如权利要求1所述的系统，其中所述处理器还被编程为：
从请求者装置接收诊断要求；以及
响应于接收到所述重新测试的诊断请求的不成功结果，向所述请求者装置发送指示拒绝所述诊断要求的通知。


4.如权利要求1所述的系统，其中所述诊断要求将所述车辆指定为一组车辆识别号码。


5.如权利要求1所述的系统，其中所述处理器还被编程为针对预期数据格式的数据模式验证所述结果诊断数据，以确定所述诊断请求是否具有成功结果。


6.如权利要求1所述的系统，其中所述处理器还被编程为验证所述结果诊断数据，以确保所述数据值符合所述诊断请求所请求的数据元素的定义。


7.如权利要求1所述的系统，其中所述诊断要求将所述车辆指定为车辆的品牌和型号。

<...

【专利技术属性】
技术研发人员：本杰明·M·洛奇，马克·安东尼·洛克威尔，克里斯汀·克罗扎尔，大卫·伦道夫·罗伯茨，
申请(专利权)人：福特全球技术公司，
类型：发明
国别省市：美国;US