用于机器系统中实时诊断和故障监视的方法、设备和系统
技术领域
本申请涉及实时诊断和故障监视领域，尤其涉及一种用于机器系统中实时诊断和故障监视的方法、设备和系统。
背景技术
出于安全目的，自动驾驶车辆系统(AVS)必须收集和分析有关其自身状态和性能的数据，以便它可以实时检测和报告故障，并在检测到故障时可以对故障做出适当的反应。它也有助于自动驾驶车辆车队的操作员从整个车队的各个车辆收集性能指标，以便有效地搜集有关车辆的操作的数据。
出于这些目的和其他目的，AVS必须从各种传感器以及以不同的速率测量数千种不同的操作参数。为了进行安全监视，必须以非常低的延迟实时收集并分析这些参数，以便识别故障并对故障做出反应。另外，故障检测通常需要整体考虑多个参数。仅一个参数可能不足以确定已发生故障。相反，在大多数情况下，必须在一个或多个公式或等式中一起考虑多个参数以识别故障。
当AVS确定发生了故障时，系统(AVS本身或离线系统)可能需要确定故障的根本原因。鉴于成千上万的参数可能会对故障有贡献，因此识别哪些参数和子系统实际上导致了故障的任务并非微不足道的计算任务，并且可能需要大量的处理能力、数据保持和时间。
本文描述了针对解决上述问题和/或其他问题的方法和系统。
发明内容
在各种实施例中，诸如自动驾驶车辆之类的机器设备包含各种硬件组件和各种计算过程，它们中的每一个可操作以进行一个或多个任务。机器设备包含诊断服务，该诊断服务包含处理器和编程指令，编程指令可操作以使诊断服务监视任务的操作。例如，在自动驾驶车辆中，诊断服务可以是车载车辆诊断系统。诊断服务将从任务中接收主信号。主信号中的至少一个将是与具有多个价的键相关联的有键信号。对于主信号中的每一个，诊断服务将对主信号执行函数的第一实例，以针对主信号创建第一派生信号，并且将函数的第一实例保存到存储器中。对于作为有键信号的主信号中的每一个，诊断服务将函数的第一实例识别为与键的第一价相关联。对于该键的每个附加价，诊断服务将创建所述函数的附加实例以针对每个附加价创建附加派生信号，并且其可以将每个附加实例保存到存储器中。诊断服务将使用函数的第一实例和函数的每个附加实例创建聚合信号。诊断服务还将使用聚合信号同时监视在机器系统上操作的硬件组件和计算处理中的每一个。
可选地，当创建聚合信号时，诊断服务可以为主信号中的一个或多个识别到期时间，确定所识别的主信号的到期时间中的哪一个是最小值；以及将该最小值指派为聚合信号的到期时间。
可选地，在机器系统的运行时间期间，所述诊断服务可以接收有键信号中的一个或多个的更新值，并使用每个更新值实时生成更新的聚合信号。
可选地，当对主信号中的至少一个执行函数的第一实例以创建第一派生信号时，诊断服务可以访问配置文件，从配置文件中提取用于主信号的键的第一实例；以及在函数的第一实例中使用用于主信号的键的第一实例。另外，对于作为有键信号的主信号中的至少一个，诊断服务可以对键的附加价中的每一个进行以下操作：(i)访问配置文件；(ii)为作为有键信号的主信号提取键的附加实例；以及(iii)使用键的附加实例并对主信号执行函数的附加实例，以利用键的附加实例创建附加派生信号。
可选地，在运行时间之前诊断服务可以将用于函数的算法存储在机器设备的存储器中作为可执行代码的一部分。然后，在运行时间，诊断服务可以加载配置文件以接收要与函数一起使用的配置变量。
可选地，在检测到机器设备中的故障时，诊断服务可以使用聚合信号来确定故障的原因，并使机器设备响应于故障采取安全相关动作。
在其他实施例中，在一种确定机器系统中的故障的原因的方法中，机器系统的诊断服务将从在机器系统上运行的各个处理中接收主信号。诊断服务将访问存储在存储器中的函数的图形表示，并且其将对主信号中的一个或多个执行函数以产生一个或多个派生信号。然后，机器系统的槽将订阅原因轨迹。原因轨迹包括用于所述派生信号中指定的派生信号的值以及从中派生出指定的派生信号的每个信号的标识。在运行时间期间，当用于指定的派生信号的值改变时槽将接收对原因轨迹的更新。在检测到机器系统中的故障时，诊断服务将使用原因轨迹来识别导致故障的处理。
可选地，在该实施例中，当诊断服务使用原因轨迹来识别导致故障的处理时，诊断服务可以：(a)确定原因轨迹中的处理延迟是否超过阈值时间值；和/或(b)确定原因轨迹中的不确定性是否超过阈值。
可选地，原因轨迹可以包括触发器，并且仅当(a)用于指定的派生信号的值改变；且(b)触发器激活时，槽才接收对原因轨迹的更新。
可选地，在运行时间之前诊断服务可以将用于函数的算法存储为可执行代码的一部分，并且诊断服务可以加载配置文件，以接收要在运行时间与函数一起使用的配置变量。
可选地，当诊断服务检测到机器系统中的故障时，它可以使用聚合信号来确定故障的原因，并使机器系统响应于故障采取安全相关动作。例如，如果机器系统是车辆，则安全相关动作可以包括：(a)如果在检测到故障时车辆未在自动驾驶模式下操作，则阻止车辆进入自动驾驶模式；或者(b)如果在检测到故障时车辆正在自动驾驶模式下操作，则使车辆退出自动驾驶模式。
附图说明
图1示出了机器设备监视系统的示例组件。
图2示出了诸如自动驾驶车辆的机器设备的示例组件。
图3示出了机器设备监视系统中的主信号和派生信号的各种元素和用途。
图4示出了系统可以如何从主信号的集合中生成派生信号。
图5示出了当派生信号的一个或多个分量是多价信号时系统可以如何生成派生信号。
图6示出了监视在机器系统上运行的处理并识别在处理中发生的故障的原因的过程。
图7示出了诊断系统可以实现的示例功能。
图8A示出了遵循图7的规则定义的原因轨迹的示例，其中仅示出了原因的主信号。
图8B示出了图8A的原因轨迹，但是还示出了非原因的主信号。
图9是可以在其上实现本文中的各种系统和方法的计算设备的元件的框图。
具体实施方式
如在本文中使用的，单数形式的“一”、“一个”和“所述”包括复数引用，除非上下文另外明确指出。除非另有定义，否则这里使用的所有技术和科学术语具有与本领域普通技术人员通常理解的相同含义。如本文中所使用的，术语“包括”意为“包含但不限于”。与本文相关的其他术语的定义被包含在本“具体实施方式”的末尾处。
图1示出了根据实施例的用于机器设备的一个或多个系统的示例监视系统。如图1所示，监视系统可以包含负责执行一种或多种类型的任务或功能的一个或多个子系统。例如，图1示出了监视系统100，其具有传感器子系统102、检测子系统104、跟踪子系统106、定位子系统108、运动规划子系统110、路径跟随器子系统112和诊断服务子系统114。
如图1所示，子系统可以与本地监视器116、118、120通信。本地监视器116、118、120可以使用硬件、软件或硬件的组合来实现。例如，本地监视器116、118、120可以被实现为微控制器的一部分。本地监视器116、118、120可以包含用于临时存储数据的寄存器或数据存储、用于比较数据的比较器、用于执行一个或多个密码运算的编程电路等中的一个或多个。本地监视器116、118、120可以接收与子系统执行的一个或多个功能相关的数据，并且可以使用该信息来验证与该(一个或多个)功能相关的执行流的至少一部分，如下面更详细地解释的。
图1还示出了示例性非易失性存储器(NVM)122、124、126，其可用于存储信息，如贯穿本公开更详细地讨论的那样。在各个实施例中，每个NVM122、124、126可以包含主哈希(hash)表。主哈希表是指存储与一个或多个函数关联的加密和/或编码信息的数据结构，如下面更详细地讨论的。
如图1所示，监视系统100可以包含全局监视器128。可以使用硬件、软件或硬件的组合来实现全局监视器128。例如，全局监视器128可以被实现为微控制器的一部分。全局监视器128可以包含用于临时存储数据的寄存器和/或数据存储、用于比较数据的比较器、用于执行一个或多个密码运算的编程电路和/或其他组件。全局监视器128可以与本地监视器116、118、120中的一个或多个通信。如下面更详细地解释的，本地监视器116、118、120可以向全局监视器128发送关于由它们相关联的一个或多个子系统执行的功能或任务的信息。全局监视器128可以使用该信息在更高的系统级别监视、检测或跟踪模式。换句话说，本地监控器116、118、120可以在本地级别检测故障或异常，而全局监控器128可以在一段时间内检测系统级别的故障。在各种实施例中，全局监视器128可以与诊断系统(未示出)通信。
应当理解的是，附加的或替代的子系统、以及附加的或更少的本地监视器、每个NVM和/或配置可以在本公开的范围内使用。
图2示出了诸如自动驾驶车辆之类的机器设备的示例性系统组件。以车辆为例，车辆的操作系统(本文可将其称为自动驾驶车辆系统或AVS)将从诸如相机201和激光雷达(LiDAR)系统202的各种传感器以及车辆的其他组件接收感测到的数据。还可以从车辆的操作部件203收集数据，例如从车辆的电池、动力传动系统、转向信号、加速器或任何其他车辆组件，其中此类数据可以包含传递给组件的命令、所测量的参数(例如电流、电压、压力、转矩等)或操作中使用的参数(例如每分钟旋转数、施加的电流等)。还可以从在车辆上操作的一个或多个处理接收数据，例如使用来自多个传感器的数据来检测车辆附近行人的存在的处理。
系统将在数据日志中记录感测和/或处理的数据，该数据日志还将包含时间戳，在该时间戳处与传感器相关联的数据被收集和/或经过检查点。系统将使用收集的数据来进行执行流211，执行流211包含对数据的一个或多个处理(例如，211A-211C)。系统将在执行流期间更新数据日志，以包含一个或多个附加检查点的标识符和时间戳。
系统将执行对来自每个执行流的结果进行融合从而产生融合数据的数据融合处理221。然后，系统将融合数据用作决策处理231的输入。系统将使机器设备的组件(例如241A或241B)响应于决策处理的输出而选择性地采取动作。系统将在存储器中记录每个传感器和/或处理的动作、动作时间戳和数据日志。
本文将使用术语“信号”来描述从机器设备的一个或多个传感器或子系统收集的数据。“主信号”是由源或任务直接提供的信号。主信号将由在机器设备上运行的某些处理直接测量或产生。例如，在自动驾驶车辆中，主信号可以包含子系统组件的电流或电压电平、诸如激光雷达系统的传感器收集的数据、传感器数据到达消耗其的任务需要多久的测量值、或者AVS可以直接从组件接收的成千上万个其他参数中的任何一种。“派生信号”是系统将使用作为一个或多个主信号和/或一个或多个其他派生信号的输入来计算的信号。每个处理将以规则的频率生成主信号，并且每个处理发出的每个主信号应在每个时间点都有值。如果某个处理未能按照其预期的时间安排来发出信号值，则系统可以为其分配值——该值对于与错过的计划时间相关联的时间戳无效。这样，如果某个处理没有通过按照规则的时间安排发出信号来定期通知诊断服务一切正常，则诊断服务可以假定该处理并非一切正常，并且其可能是故障的原因。
参照图3，可以从诸如在机器系统上运行的处理之类的任务301接收主信号302。来自任务301的主信号302可以包含诸如值和有效时间(Time of Validity,ToV)的元素。ToV是表示信号的值被测量的时间或生成信号的时间的测量值。ToV通常用系统时间表示——例如，在自动驾驶车辆中，系统时间可以是车辆时间，从启动车辆或首次移动车辆时的T＝0开始测量。系统可以使用ToV来确定信号的到期时间。
每个信号也将具有定义的数据类型。示例数据类型包含当前的有符号整数、无符号整数、布尔值、浮点数、枚举、持续时间(时间)、字符串、特殊(唯一定义的)类型或其他类型。
还可以从诸如操作员的命令、全球定位系统(GPS)、诊断系统或其他输入之类的源303接收主信号304。信号的源不仅限于硬件，还可以包含在机器系统上运行的软件模块或子系统。来自任务301的主信号304可以包含诸如值和ToV、以及源TX时间之类的元素。源TX时间将是源在收到对信号的调用时为信号分配的时间(通常为当前车辆时间)。系统可以使用源TX时间来通过负责故障检测的槽(sink)将陈旧值阈值化。例如，如果当前时间与更新的源TX时间的比较大于预期，则可以表明诊断服务或某些其他处理未正确执行。如果诊断任务在单个批次中一起处理来自多个源的信号，则它可以在输出上使用所有信号的源TX时间的函数(例如，来自各个信号的最小源TX时间作为该批次的源TX时间)。
另外，每当诊断服务305生成对主信号或派生信号的更新时，它将给信号附上当前车辆时间，这将表示“生成时间”，如在信号306中那样。生成时间可以提供表示诊断任务看到信号值的一致且单调的时间，由于传输时间不同，该时间可能与任务发送主信号的顺序不同。
也可以向每个信号分配寿命(lifetime)，该寿命是在没有进一步更新的情况下该信号被认为是有效的持续时间。另外，可以将信号的“到期时间(expiration time)”设置为在故障检测中有效使用其值的截止日期，如在信号308中那样。对于主信号，可以将到期时间设置为：expiration_time＝time_of_validity+lifetime，尽管可以使用其他公式。对于派生信号而言，可以从任何有贡献的原因信号的到期的最早时间推断出到期时间。下面描述的故障检测函数可以对到期时间进行原因推断，并产生示出哪些主信号确定了派生信号的到期时间的原因轨迹。
除了表示各种类型的数据，信号也可以被认为是“有键(keyed)”或“无键(keyless)”。“有键”信号是可以从系统内的多个源或任务中收集的信号类型，而“无键”信号将仅具有单个可能值，因为它仅与单个源或任务相关联。例如，被称为CpuTemperature的信号可以表示系统中的中央处理单元(CPU)芯片的温度。然而，系统可以包含许多CPU，并且系统可以分别测量每个CPU的温度。因此，取决于哪个CPU提供该信号，CpuTemperature信号具有多个可能的值。本文将信号值及其源的关联称为“价(valence)”，因此CpuTemperature信号可以被认为是多价的(multivalent)。该信号的键将是从中派生出信号的值的源或任务的标识符(例如CPU0、CPU1、CPU2等)。作为另一示例，被称为VehicleRotationVariance的信号可以表示在参考地图中关于车辆的旋转(即定向轴承)的AVS的所计算的不确定性。AVS可以将该信号派生为随时间从多个传感器收集的数据的函数，并且VehicleRotationVariance信号可以具有不同的价，这取决于使用哪种算法和/或传感器数据的哪个集合来确定信号的值。其他示例包含表示在车辆附近检测到多少行人的NumDetectedPedestrians信号、或表示在车辆附近但无法归类为诸如“行人”、“自行车”或“车辆”之类的特定动作者的移动对象的数量的NumPredictionUnknownActorClassifications信号。
通过允许信号是多价的，该系统就能够定义可以使用的派生信号，而不管信号的价如何。例如，如果CpuTemperature信号是多价信号，则系统将知道含有多价信号的派生信号(诸如CpuOverheating＝CpuTemperature>CpuTemperatureThreshold)也必须是多价的。系统将推断多价的派生信号CpuOverheating具有与其多价的CpuTemperature分量相同的键。因此，系统将为派生信号创建多个键，在此示例中这些键还将为CPU0、CPU1、CPU2等。
槽307是消耗或订阅信号的处理。槽307可以选择它们将订阅的信号，并且当它们接收到对信号的更新时，它们可以通知诊断系统。该过程将在下面的图6的讨论中更详细地描述。
图4和图5以图形表示示出了系统如何使用信号价利用单个定义的函数来同时监视车辆上运行的多个处理(而不是针对每个处理利用多个函数)。图4示出了系统可以对各个接收到的信号执行的示例函数。这种函数在AVS中的一个示例可以是对是否可能发生可能延迟车辆实施停止命令的故障进行确定的处理。AVS可以从各种系统组件接收任意数量的主信号。主信号中的某些主信号可以是无键信号401、402，而其他主信号可以是具有多个价的有键信号403。系统将对主信号执行一个或多个函数，以生成任意数量的派生信号405、407，这些派生信号中的每一个都是有键信号，因为它们是部分地从有键输入信号派生而来的。(在图4中，函数由节点之间的箭头表示，并且每个函数生成的信号由方形框表示。)派生信号可以馈送到键聚合器409，该键聚合器使用如求和(Sum)、最小值(Min)、最大值(Max)或求平均(Mean)的组函数将一组键折叠(collapse)为单个函数。
系统然后可以使用来自聚合器409的输出来指示主信号是否指示发生了由馈送到聚合器409的信号中的一个或多个引起的或与之有关的故障。例如，如果聚合器发出的值与预期值匹配，并且如果馈送到聚合器的信号的时间戳是有效的，则系统可以假定发出了产生聚合信号的信号的处理工作正常并且不是故障的原因。然而，如果聚合器发出的值与预期值不匹配，或者信号的时间戳无效，则系统可以假定导致信号派生改变的处理之一就是故障源。然后，可以使用原因轨迹来识别该处理，如下面将更详细描述的。
如上面提到的，每个信号将具有数据类型。每个主信号的数据类型将在系统的代码中指定。可以从已从中派生出派生信号的主信号的数据类型来推断派生信号的数据类型。例如，如果主信号A和B具有带符号的整数数据类型，并且信号C被派生为A+B，则可以将信号C的数据类型推断为带符号的整数数据类型。相比之下，如果将信号D定义为“A>B”，则D将具有布尔类型(真或假)而不是带符号的整数类型。各种其他规则可以用于执行类型推断。
图5示出了当主信号中的任何一个是具有多个价的有键信号时，系统可以在聚合键并确定结果之前执行函数的多个实例。例如，如图5所示，如果有键信号403具有三个价，则系统可以创建使用非有键(无键)信号401、402和有键信号的第一价403a来生成派生信号405a、407a的函数的第一实例。该系统可以创建使用有键信号的第二价403b来生成派生信号405b、407b的函数的第二实例。系统可以创建使用有键信号的第三价403c来生成派生信号405c、407c的函数的第三实例。如果有键信号具有附加的价，则将针对每个附加的价来创建函数的附加实例。每个实例都将例如以图形格式或规则集合保存到存储器中。
在复制函数的每个实例之后(例如通过生成图形的多个实例)，系统可以指定公共聚合节点409以接收来自函数的每个实例的输出。在运行时间(runtime)期间，系统然后将来自函数的每个实例的派生信号传递到键聚合器409，以生成合并了有键主信号的所有价403a…403c的单个聚合的派生信号。然后，系统可以使用输出来确定主信号是否指示发生了由派生出主信号的系统元件中的一个或多个引起的或与之有关的故障。
在机器设备的运行时间期间，监视系统可以接收有键信号中的一个或多个的更新值。如果是这样，它将使用每个更新值来实时生成更新的聚合信号。每当函数的任何实例中的任何主信号的值改变时，聚合信号的值都会改变。
可以在运行时间之前由诊断服务将函数作为其可执行代码的一部分进行存储。然后，系统可以使用通常在单独的配置文件中接收或存储的配置变量集合，以允许在不重新编译可执行代码的情况下改变配置参数。与信号一样，配置变量可以具有定义的类型，也可以具有通过推断确定的类型。配置变量也可以是单价或多价的。配置变量可以用于为多价信号指定有效键的集合。以示例的方式，在上面使用的表达式之一中，CpuTemperatureThreshold变量可以是配置变量。因此，当诊断服务(例如，图1中的114)监视在机器设备上运行的处理时(如图3中的步骤309)，机器设备可以加载配置变量集合并在运行时间使用配置变量，以将一个或多个键插入到一个或多个主信号中，以派生与机器设备的子系统的操作有关的一个或多个主信号。如果信号是多价信号，则系统可以识别与键的第一价相关联的函数的第一实例，并且它可以从配置文件中检索键的第一价。然后，可以使用每个函数实例的键的附加价，对函数的每个附加实例执行相同的操作。
机器设备的操作系统可以使用诊断活动的结果来确定是否存在需要机器设备实现与安全有关的校正动作的故障或其他状况。例如，在自动驾驶车辆中，与安全有关的动作可以包含防止车辆进入自动驾驶模式，或者如果已经处于自动驾驶模式，则确定退出自动驾驶模式的动作。例如，如果诊断系统确定CpuOverheating派生信号的值为“真”，则它可以推断出存在故障或其他与安全有关的状况，并且车辆的操作系统可以阻止车辆进入自动驾驶模式，而是需要手动操作。如果车辆已经处于自动驾驶模式，则为了退出自动驾驶模式，操作系统可以指引车辆切换到手动操作(如果有驾驶员可用)或者在最近的安全泊车位置停车。
当诊断系统确定存在感兴趣的状况(例如故障或另一与安全有关的状况)时，以上讨论的主信号和派生信号的使用可以帮助诊断系统确定故障的原因。(为简单起见，以下讨论将触发与安全有关的响应动作的任何状况称为“故障”，尽管这些状况不仅限于实际故障，还可能包含被视为故障的临时失常和其他状况。)诊断系统实质上将通过计算网络反向工作，以确定哪个输入或哪些输入创建了导致故障的输出。系统将通过识别导致故障的(一个或多个)主信号以及(一个或多个)信号导致此故障所通过的中间计算路径来做到这点。
图6示出了监视在机器系统上运行的处理并识别在处理中发生的故障的原因的过程。如上所述，在启动时，机器设备系统可以加载配置文件(步骤601)。然后，在运行时间期间，机器系统的诊断系统将从在机器系统上运行的各种处理接收主信号(步骤602)。诊断系统将访问存储在存储器中的各种函数的图形表示(步骤603)，并且它将通过对主信号中的一个或多个执行函数来生成一个或多个派生信号(步骤604)。
机器系统的槽(即任务处理)将订阅原因轨迹(步骤604)。例如，AVS的运动规划服务可以是订阅原因轨迹的槽，因为运动规划服务将被编程为在检测到某些故障时采取与安全有关的动作。当诊断服务重新计算信号时，它还会跟踪哪些其订阅的信号已改变，并为每个订阅槽组装输出集合。当已完成执行规划并且重新计算了所有受影响的信号时，诊断服务将把任何更新发送到订阅槽(步骤607)。可选地，仅在以下情况下才提供更新：(a)信号值发生变化，以及(b)原因轨迹包含激活的触发器并且对应的原因信号集合已改变(步骤606)。这可以帮助提高可扩展性，使得除非或直到必要，否则不需要发生传输。
原因轨迹包含用于派生信号中指定的一个派生信号的值，以及从中派生出指定的派生信号的每个信号的标识。在检测到机器设备的子系统中的故障时，诊断服务610可以使用原因轨迹来识别引起故障的源。而且，如上所述，在检测到机器设备的故障时，设备的操作系统可以使机器设备采取与安全有关的动作(步骤609)。
原因轨迹是作为特定的被跟踪信号的原因的信号的子图。原因轨迹与一个或多个触发器相关联，并且当触发器激活时，原因轨迹跟踪原因轨迹的变化。原因轨迹将是上面讨论的整个操作图形的子图(如图4和图5所示)，但只有在给定时间实际对输出有贡献的节点。一组处理的原因轨迹将随着值和时间戳的变化而不断变化。系统可以跟踪原因轨迹的变化，并且仅在信号发生变化时才将原因轨迹传输到诊断服务。
上面提到的触发器将是充当触发器的信号，以指示哪个信号将具有关联的原因轨迹。作为示例，系统可以使用被称为“AllowedAutonomyLevel”的派生信号，该信号根据系统的当前状态来确定当前允许实施哪种自动驾驶操作模式。该信号可以具有指示何时系统中出现问题并且禁止自动驾驶、应当生成原因轨迹的触发器。在这种情况下，可以使用诸如AutonomyIsDisabled的标记来标记触发器。然后，无论何时当AutonomyIsDisabled触发器信号的值为“真”，订阅该信号的槽就会接收到更新。但是，当AutonomyIsDisabled的值等于“假”时，由于不需要任何更新，因此不会生成更新，从而节省了处理资源。
如上面提到的，在接收到原因轨迹时，诊断服务可以使用原因轨迹来识别引起故障的处理。为此，诊断服务可以确定原因轨迹中的处理延迟是否超过阈值时间值，或者可以确定原因轨迹中的不确定性是否超过阈值。
以示例的方式，图7示出了可以用作诊断服务可以用来分析原因轨迹的函数(即，规则的逻辑定义)的示例性算法，而图8A和图8B示出了可以应用该函数的原因轨迹的示例。参考图7，一组主信号(由圆圈表示)包含CPUTemp 701和703、CPUTempWarnThreshold 702、CPUTempCriticalThreshold 704和MaxCpuTempWarnings 705信号。主信号用作产生派生信号(由菱形表示)711、712、713的函数的输入。六边形是键聚合器721、722，而方形CPUOverheat是输出730，它也是派生信号。这实现了以下逻辑：如果任何CPU的温度超过临界阈值，或者如果多于MaxCpuTempWarnings超过警告阈值，则CPUOverheat派生信号＝真(或激活)。机器系统可以在运行时间之前(即，在机器设备在环境中移动之前)在存储器中存储诸如图7所示的函数，而无需诸如CPUTemp、CPUOverheat等的特定变量。
图8A示出了遵循图7的逻辑的示例原因轨迹。在该原因轨迹中，主信号CPUTemp701、703指示两个中央处理单元(CPU)的温度值。CPUTempWarnThreshold 703、CPUTempCriticalThreshold 704和MaxCpuTempWarnings 705信号。每个CPU的CPUTempWarnThreshold 702为75华氏度。在这种情况下，每个CPUTemp 701、703信号的值(分别为76.7和78.2华氏度)高于CPUTempWarnThreshold 702，因此派生信号711、712的值均为“真”。因此，CPUOverheat 730的值也为真。在当车辆或其他机器系统启动时、或者在开始机器系统的移动时的运行时间处，系统可以将配置变量(CPUTemp、CPUOverheat等)加载到函数中。
注意，实际上，多于两个的CPU可能为系统的一部分。然而，在该图形中，仅示出了作为CPUOverheat输出为真的原因的CPU。另外，省略了图7的“临界”路径，因为没有CPU呈现出处于临界过热温度范围内的温度值，而只处于警告温度范围。因此，在该原因轨迹中仅示出了作为输出为真的原因的节点。在替代实施例中，不是输出原因的节点可以是轨迹的一部分，但是它们以与原因节点不同的格式出现。例如，在图8B中，图8A的原因轨迹在图8B中重复，其中用虚线代替实线示出非原因信号705、706。非原因信号705、706是非原因的，因为它们的值小于CPUTempWarnThreshold。
该处理可以考虑“值原因”和“时间原因”两者，因为每个信号将具有与之相关联的值和时间戳两者。时间戳很有用，因为如果数据陈旧，则操作系统可能会使机器设备采取动作。(例如，如果数据没有按预期尽快更新，则自动驾驶车辆可以退出自动驾驶模式。)信号的时间戳允许操作系统确定哪个信号(从而哪个信号源)更新的晚，并且该源可以是问题的原因。如果所有信号都是最新的，则系统可以使用信号的值来确定问题的原因。
图9描绘了可以被包含在系统的诸如内部处理系统、外部监视和报告系统或远程服务器的电子组件中的任何一个中的内部硬件的示例。电气总线900用作互连硬件的其他所示组件的信息高速公路(highway)。处理器905是系统的中央处理设备，被配置为进行执行编程指令所需的计算和逻辑运算。如本文和权利要求书中所使用的，术语“处理器”和“处理设备”可以指单个处理器或集体进行操作的集合的、处理器的集合中的任何数量的处理器，例如中央处理单元(CPU)、图形处理单元(GPU)、远程服务器或它们的组合。只读存储器(ROM)、随机存取存储器(RAM)、闪存、硬盘驱动器和能够存储电子数据的其他设备构成了存储器设备925的示例。存储器设备可以包含在其上存储数据和/或指令的单个设备或设备的集合。本发明的各种实施例可以包含含有程序指令的计算机可读介质，该程序指令被配置为使一个或多个处理器、打印设备和/或扫描设备执行在先前附图的上下文中描述的功能。
可选的显示接口930可以允许来自总线900的信息以视觉、图形或字母数字格式显示在显示设备935上。也可以提供音频接口和音频输出(例如扬声器)。可以使用各种通信设备940与外部设备发生通信，通信设备940诸如无线天线、RFID标签和/或短距离或近场通信收发器，它们中的每一个可以经由一个或多个通信系统与设备的其他组件可选地通信连接。(一个或多个)通信设备940可以被配置为通信地连接到诸如因特网、局域网或蜂窝电话数据网络的通信网络。
硬件还可以包含允许从诸如键盘、鼠标、操纵杆、触摸屏、触摸板、遥控器、指点设备和/或麦克风的输入设备950接收数据的用户接口传感器945。也可以从能捕获视频和/或静止图像的照相机920接收数字图像帧。
以上公开的特征和功能以及替代物可以被组合到许多其他不同的系统或应用中。可以以硬件或软件或嵌入式软件来实现各种组件。本领域技术人员可以做出各种目前无法预见或无法预料的替代、修改、变型或改进，所公开的实施例也意图包含其中的每一种。
与以上提供的公开有关的术语包含：
“自动化设备”或“机器设备”是指电子设备，其包含处理器、编程指令以及可以基于来自处理器的命令以最少或无人为干预执行至少一些操作或任务的一个或多个组件。例如，自动化设备可以执行一个或多个自动化功能或功能集。这样的操作、功能或任务的示例可以包含但不限于导航、运输、驾驶、递送、装载、卸载、医疗有关过程、建筑有关过程等。示例性自动化设备可以包含但不限于自动驾驶车辆、无人机和其他自动驾驶机器设备。
“电子设备”或“计算设备”是指包含处理器和存储器的设备。每个设备可以具有其自己的处理器和/或存储器，或者该处理器和/或存储器可以如在虚拟机或容器布置中那样与其他设备共享。存储器将含有或接收编程指令，该编程指令在由处理器运行时使电子设备根据该编程指令执行一个或多个操作。
术语“存储器”、“存储器设备”、“数据存储”、“数据存储设施”等均指其上存储有计算机可读数据、编程指令或两者的非暂时性设备。除非另有特别说明，否则术语“存储器”、“存储器设备”、“数据存储”、“数据存储设施”等旨在包含单个设备实施例、其中多个存储器设备一起或共同存储数据或指令的集合的实施例、以及此类设备内的各个扇区。
术语“处理器”和“处理设备”是指被配置为运行编程指令的电子设备的硬件组件。除非另有特别说明，否则单数术语“处理器”或“处理设备”旨在包含单处理设备实施例和其中多个处理设备一起或共同执行处理的实施例。
术语“车辆”是指能够运载一个或多个人类乘员和/或货物并且由任何形式的能量提供动力的任何移动形式的运载工具。术语“车辆”包含但不限于汽车、卡车、货车、火车、自动驾驶车辆、飞机、空中无人机等。“自动驾驶车辆”是具有处理器、编程指令和可由处理器控制而无需人类操作员的传动系统组件的车辆。自动驾驶车辆可以是完全自动驾驶的，因为它不需要人类操作员来进行大部分或所有驾驶状况和功能；或者它可以是半自动驾驶的，因为在某些状况下或某些操作中可以需要人类操作员；或者人类操作员可以越权车辆的自动驾驶系统并可以控制车辆。
术语“执行流”是指要以特定顺序执行的一系列功能。功能是指使系统执行一个或多个动作的一个或多个操作指令。在各种实施例中，执行流可以与自动化设备的操作相关。例如，对于自动驾驶车辆，特定的执行流可以由车辆在某些情况下执行，例如当车辆在刚刚变成绿色的红色停车灯处停止时。例如，该执行流可以包含以下功能：确定灯为绿色、确定在车辆前方或附近是否有任何障碍物、以及仅当灯为绿色且不存在障碍物时才加速。当自动化设备的子系统无法在执行流中执行功能时，或者当其依次乱序执行功能时，该错误可以表示发生了故障或关于执行流存在另一问题。
“自动化设备监视系统”是通信地和/或电连接到自动化设备的各种组件(例如传感器)的硬件的集合，以从那些组件收集状态或操作参数值。自动化设备监视系统可以包含或连接到数据记录设备，该数据记录设备包含被配置为从设备的组件直接或间接地接收设备操作数据的数据输入(例如无线接收器)。监视系统还可以包含带有编程指令的处理器、发送器和存储器。监视系统可以包含用于将命令和/或数据发送到外部电子设备和/或远程服务器的发送器。在各种实施例中，监视系统可以被嵌入或集成到自动化设备的其他计算系统组件中，或者它可以是与一个或多个其他本地系统通信的单独设备，例如，在自动驾驶车辆的上下文中的车载诊断系统。
