第一次扫描我的车辆，以检查检查引擎灯的代码。我对这些错误代码是否在抛出时带有某种日期和时间戳的地方记录下来感到好奇。我正在想象一些类似于计算机操作系统中使用的事件日志的设计，但是我可能完全误认为这一点。
就如何记录这些故障代码而言，确切的设计是什么。设计的一个明显方面是使用特定于某些特定问题的唯一代码。那是一个带有故障的完整故事吗，是否可以查找故障实例周围的其他元数据？故障历史记录在车辆中如何工作？历史记录甚至是故障，无论是当前的还是当前的，都是故障，无论它们是否在车辆寿命的任何时刻都存在。我知道您可以使用扫描仪工具清除代码，这是否意味着在您手动清除错误之前，故障将永久保留在系统上。这使我相信，即使在修复了故障的根本原因之后，检查引擎的灯仍将保持点亮状态。这个准确吗？
Answers:
这实际上取决于OBD2的实现。与2015年雪佛兰Cruise相比，我1997年的Subaru日志（几乎没有记录）完全不同。
但是，在大多数情况下，使用冻结帧记录诊断故障代码（DTC），该帧是所有参数ID（PIDS）的完整存储。这些参数涵盖了RPM，车速，O2传感器数据，空气质量流量数据，长期和短期燃油调整，点火提前，进气和冷却液温度等各种信息。这些可以通过OBD2模式2访问。简单的“ Pxxxx” DTC故障可以通过OBD2模式3访问，这通常是简单的消费者扫描工具能够显示的程度。
在更复杂的扫描工具上，可以显示模式2“冻结帧”数据，这是非常宝贵的数据，因为它可以在设置DTC代码的那一刻显示确切的运行条件。
此类代码的历史再次随着OBD2的实施而变化，并且很可能会随着车辆的更新而变化。在我的1997斯巴鲁（Subaru）上，数据有限-鉴于OBD2直到1996车型年才成为强制性产品。
但是，所有车辆都具有DTC的两类：“待定”，这是一种已检测到的故障，但是直到再次检测到该条件一定次数之前，才设置检查引擎指示灯（CEL，SES）。（这可以通过OBD2模式7进行访问。）促使CEL处于“挂起”状态所需的“行驶周期”数量取决于故障，实现方式和车辆。
DTC的另一个类别是“存储”或“记录”。这些是真正的故障代码，已从“待处理”状态提升为实际故障代码，并且必须通过OBD2定义来设置CEL。
另外，某些发动机控制单元/模块（ECU / ECM）能够记录几个或几十个“历史性”故障代码，无论它们是否已维修和/或清除。即使没有当前挂起或记录的 DTC故障，这也为精明的技术人员提供了背景。
DTC代码不必“手动”清除。如果导致故障的条件得到修复，或者根本不再发生（典型的例子是P0420催化剂效率），则代码将“清除自身”，可以说是在一定数量的驱动周期后，而不会再次发生故障。清除活动的CEL DTC所需的驱动周期数取决于故障和软件实现。但是，在大多数情况下，技术人员在进行有效维修后会清除这些代码，以确保客户维修已完成。但是我们没有；这是礼貌。ECU / ECM不断监视PID和排放状况，并在足够的“干净”驱动周期后最终将退出。
顺便说一句，有一种DTC会导致FLELING CEL。这些与“固定” CEL显着不同，如果它持续存在，则表明存在问题，驾驶员应在方便的机会寻求服务。但是，FLASHING CEL表示严重错误，有可能导致车辆损坏。通常，这表示状态过浓，通常是由严重的点火故障或燃油喷射引起的，如果任其单独使用可能会损坏昂贵的催化转化器。这些“闪烁的”检查引擎灯应立即解决-一些原始设备制造商建议将车辆停下来拖走。
为了使此过程进一步复杂化，清除CEL消除了“活动”类别中的故障代码，但就像您的计算机类似，它是ALT_CTRL-DEL。它会完全重置ECU / ECM，并清除所谓的“监视器”。
监控程序是大量测试的一部分，这些测试可以连续运行，或者在大多数情况下满足某些PID（温度，发动机负荷，燃料水平，行驶周期）的条件时进行。（这使得通过蒸发排放系统监控器特别困难；该标准是精确的，甚至取决于油箱中的燃料量。）
遵循所有必需的条件，需要一定数量的成功驾驶周期，才能“通过”这些监视器测试。此时，所有监控器都通过后，车辆即可通过OBD2排放检查。（在纽约，在2001年之前生产的车辆可能有两项不完整的监控测试，允许2001年及以后的车辆进行一项不完整的监控测试，并且可能最近的车辆没有不完整的监控。这只是琐碎的事。）
结果是，尽管车辆可能已经进行了适当的维修并且故障代码已清除，但这并不意味着它将通过OBD2排放检查。这样可以避免使用遮蔽树技术来断开电池并立即进行检查。车辆必须完成所有（或大多数）标准所要求的行驶次数，才能获得及格分数。虽然所谓的“没有准备好”车辆没有失败的排放测试，它也不会通过。在对ALT-CTRL-DEL ECU / ECM进行了放气手术之后，车辆停驻了下来，直到它自己证明所有监视器都在运行并且车辆运行清洁后，才准备进行检查。
故障代码有两种：单程和两次旅行。
单跳故障代码通常是重大故障，例如严重失火。一旦检测到，这将立即点亮检查引擎灯。
必须在两次跳闸中验证两次跳闸故障代码。第一次行程将设置未决代码而不会照亮灯。如果再次检测到故障，指示灯将点亮。
从理论上讲，当硬故障（指示灯点亮）连续两次通过测试时，指示灯将熄灭。然后将代码从硬故障降级为挂起。如果测试仍然在硬故障下运行，则对此进行了规定。在某些情况下，由于硬故障导致测试被暂停，然后使用扫描工具清除灯是唯一关闭灯的方法。如果测试通过了60个连续的驾驶周期，则待处理代码将消失（启动和关闭汽车60次不构成驾驶周期）。
每当存储代码时，冻结帧数据都会随之存储。冻结帧数据（FFD）是检测到故障时最常见数据的快照。问题在于，存储的值因制造商和车辆年份而异。这些值可以包括但不限于；冷却液温度，rpm，空气温度，短期燃油调整，长期燃油跳闸，回路状态，故障被设置到驱动循环中的时间，自故障被排除以来经过了多少个驱动循环....继续。
较旧的车辆只能存储FFD的单个帧，而较严重的故障代码优先。较新的车辆可以存储多个FFD框架。尽管您可以找出代码按什么顺序出现，但没有像事件记录器那样众所周知的时间戳记。