产品 01 · 行为与时序验证
让汽车软件的
关键行为可验证。
动作是否正确，不只看结果；还要看它是否在正确的时间发生。
KernelSeq 面向汽车 ECU、VCU 等控制软件，帮助研发和测试人员检查运行过程是否符合预先定义的行为规则，定位时序偏差，并保留可追踪、可回放的运行证据。
行为规则验证时序偏差检测运行轨迹记录执行过程回放
Runtime Trace / 04
● TRACE CAPTUREDRule statusVIOLATEDR-014
Event sequence08 events
Trace replayREADY
Illustrative timing deviation+80 ms超过示例时间窗口
THE PROBLEM
故障不总是“没执行”。
有时，是执行得太晚。
在汽车控制软件中，最终动作看起来正确，并不意味着整个执行过程符合预期。真正难查的，是偏差发生的时间、位置与上下文。
动作为什么晚了？
系统最终执行了动作，但动作发生得太晚，可能已经错过规定的控制窗口。
故障为什么复现不了？
相同输入有时正常、有时异常，测试人员难以还原触发故障的执行过程。
怎么证明违反了规则？
只有最终结果或零散日志，很难完整说明事件顺序、状态变化和偏差位置。
工程案例 01 / 时序约束检查
动作最终执行了，
但已经错过时间窗口。
假设控制软件在 105 ms 检测到触发条件，规则要求动作在 20 ms 内完成。实际动作到 205 ms 才发生。问题不在于“有没有动作”，而在于动作是否满足时序约束。
数据状态：模拟案例
时间点和规则仅用于展示分析方法。真实项目需由需求、采集记录及时间基准共同确认。
要回答的问题哪条规则被违反？偏差发生在哪里？
需要的输入触发事件、动作事件、统一时间基准、规则定义
R-014 / 动作时限检查模拟数据 · 非实测
100 ms125 ms 截止205 ms 实际
触发 105 ms截止 125 ms实际 205 ms
允许延迟20 ms125 − 105
实际延迟100 ms205 − 105
超出时限+80 ms100 − 20
! 示例判定：违反 R-014只有在事件时间戳可信、动作定义一致且规则确实适用的前提下，才能作出该判定。运行轨迹用于进一步复核，不自动说明底层根因。
工作流程
从预期规则，到可复核的运行证据。
不是只给出一个“异常”标签，而是帮助团队看清哪条规则被触发、偏差在哪里，以及判断依据是什么。
STEP 01
定义预期行为
设置触发条件、状态约束、时间窗口和违规判定规则。
STEP 02
采集运行过程
接收可获取的事件、状态变化及相关时间信息。
STEP 03
对照规则检查
检查实际执行轨迹是否符合预先定义的行为约束。
STEP 04
输出证据并复核
查看异常位置、相关事件和运行轨迹；条件允许时回放对比。
与现有工具协同
不是替代现有工具，而是补上行为验证这一环。
| 工具类型 | 主要用途 | KernelSeq 的补充价值 |
|---|
| 调试器与跟踪工具 | 查看程序执行、变量和事件 | 按明确的行为规则判断执行过程是否合规 |
| HIL / SIL 测试平台 | 模拟环境、运行测试用例 | 对接可用运行数据，进一步检查行为与时序 |
| 日志分析工具 | 检索、查看和分析记录 | 关注事件之间的行为约束及执行轨迹 |
具体接入能力取决于目标平台、数据接口和当前产品版本。KernelSeq 不代表对整车安全性的自动证明，也不等同于 ISO 26262 认证。
让关键控制行为，
从“看起来正常”变成“有据可验”。
适用于 ECU / VCU 软件验证、时序异常分析、故障复现与回归测试。
产品 02 · 跨层数据有效性
数据还在，
就一定能用吗？
防止已经失效的数据，被当成当前事实继续使用。
GhostGuard 面向汽车服务化软件系统，帮助研发与测试人员分析数据有效性如何跨服务、跨组件传递，并检查下游使用是否符合预先定义的约束。
有效性传播分析跨层使用约束异常路径识别验证证据输出
Data Validity / Graph
● PATH ANALYSISValidity ruleDEFINEDContract
Data lineage03 layers
Risk pathREVIEWPotential
THE PROBLEM
真正危险的，不只是没有数据。
还有失效的数据仍被使用。
数据可能停更、过期、来源异常，或在传递过程中丢失有效性约束。仅检查接口是否连通，并不能回答下游是否应该继续使用它。
数据过期了，谁知道？
上游传感器或服务停止更新，下游仍然保留最后一次数据。
有效性在传递中丢失？
数据经过多个服务或缓存后，原始有效性信息没有被正确传递或检查。
异常时，下游会怎样？
是否拒绝失效数据、切换备用路径或进入保护状态，需要依据规则验证。
工程案例 02 / 跨层数据有效性
数据源停更后，
缓存里的旧值仍被消费。
假设系统约定：数据年龄不得超过 100 ms。最后一次更新时间为 1000 ms，在 1200 ms 时消费端仍读取缓存值。此时数据年龄为 200 ms，超过示例阈值。
数据状态：模拟案例
100 ms 是假设的契约阈值，不是通用汽车标准。是否违规，要以具体接口契约、时间语义和消费行为为准。
要回答的问题有效性在哪一层失守？谁仍在使用旧值？
需要的输入更新时间、消费时刻、数据流路径、有效性契约
数据路径 / Validity propagation模拟路径 · 待验证
01数据源最后更新 1000 ms记录存在
停更 / 未刷新
02缓存层保留旧数据需检查失效标记
仍被读取
03消费组件消费时刻 1200 ms待核查使用行为
数据年龄200 ms
契约阈值 100 ms当前 200 ms
200 ms − 100 ms = 超出 100 ms
可核查事实更新时间、消费时刻、配置阈值，以及数据是否被读取。
尚需验证消费端是否执行有效性检查，真实契约是否禁止继续使用，以及保护逻辑是否触发。
工作流程
沿着数据的路径，检查它是否仍然可信。
GhostGuard 的重点不是简单标记“数据异常”，而是分析有效性条件如何传递，以及下游使用是否符合契约。
STEP 01
声明有效性规则
描述有效条件、失效条件、传播要求及下游消费约束。
STEP 02
梳理数据传递路径
分析服务、组件和数据依赖，识别有效性信息如何传递。
STEP 03
检查使用路径
查找数据失效后仍被使用的潜在路径及保护逻辑问题。
STEP 04
生成可复核结果
提供相关路径、规则依据、触发条件和证据缺口。
补充现有工具，而非简单替代
在接口与通信检查之外，再问一步：数据还能用吗？
| 工具类型 | 主要用途 | GhostGuard 的补充价值 |
|---|
| 静态代码分析工具 | 查找代码缺陷及特定规则违规 | 关注数据有效性从产生到消费的跨层传播 |
| SOA / 通信测试工具 | 检查接口、通信和服务交互 | 进一步检查数据是否有效、下游是否合规使用 |
| 系统测试与 HIL | 验证系统在特定场景下的行为 | 补充跨组件的数据依赖分析和失效路径检查 |
以上描述的是产品关注重点，不代表其他工具无法实现类似功能。具体差异需按产品版本、配置方式和场景逐项验证。分析结果不自动构成安全认证。
不要只确认数据存在。
还要确认它仍然有效。
适用于汽车 SOA、跨服务数据流、缓存与状态管理及失效保护逻辑检查。
产品 03 · 故障调查与证据分析
故障发生之后，
快速找到调查线索。
把分散的日志和记录，组织成可核查的故障证据链。
TracePilot 是面向汽车软件研发、测试和故障分析人员的离线故障调查工具，帮助工程师从多源日志中发现线索、还原事件过程，并形成可验证的候选根因。
多源日志解析时间线对齐异常线索发现证据关联
Fault Investigation / Case 021
● OFFLINE ANALYSISSources03 files
Key events05 events
ConclusionNEEDS REVIEW
Investigation statusEvidence-linked根因尚待验证
THE PROBLEM
故障有很多记录，
但记录不等于答案。
问题可能分散在 ECU / VCU 日志、CAN 记录和测试数据中。工程师要做的，是把这些信息放到同一条可核查的调查线上。
日志太多，查不完
一次故障涉及多份记录，工程师需要反复搜索、筛选和比对。
不同来源的时间不一致
设备、软件和采集工具的时间戳可能存在偏差，事件先后关系难以确认。
发现异常，不等于找到根因
告警可能只是结果。真正的触发原因需要跨来源证据和进一步测试。
工程案例 03 / 多源故障调查
车辆出现扭矩限制，
先建立证据，再讨论根因。
把 BMS 日志、CAN 记录与 VCU 日志放到同一条时间线上，确认记录中实际出现了什么，再判断哪些关联值得进一步调查。
数据状态：模拟时间线
以下时间与事件为示例。时间上的先后关系只能形成线索，不能单独证明因果关系。
调查目标找出通信超时与扭矩限制之间是否存在可证实的关系
关键限制时间戳、信号标识和原始日志必须可追溯
故障调查单 / Case 021模拟数据 · 根因未确认
BMS.logCAN.csvVCU.log
1000 msBMS发送记录需确认信号 ID、周期及原始报文
记录 1020 msBMS再次发送记录与上一条记录间隔 20 ms
记录 1122 msVCU通信超时记录检查超时对象、计时起点与阈值
线索 1200 msBMS再次发送记录需确认是否为同一信号与通信链路
记录 1210 msVCU扭矩限制记录需核查限制请求、状态机及触发条件
线索 ✓ 已知事实（以原始记录为准）示例记录包含 BMS 发送、VCU 超时与随后出现的扭矩限制事件。
? 候选关联（尚未证实）通信超时可能与扭矩限制有关；需要核对报文接收情况、信号映射、超时策略与状态机日志。
＋ 仍需补充的证据CAN 原始帧、接收端计数器、超时配置、扭矩限制原因码及可重复测试结果。
! 当前结论：根因未确认TracePilot 应帮助缩小调查范围并关联原始证据，而不是仅凭时间接近自动宣告根因。
工作流程
把调查过程拆成四步，结论每一步都有依据。
TracePilot 面向故障发生后的离线分析：先整合数据，再建立事件关系，最后输出可核查的调查结果。
STEP 01
导入已有记录
加载支持格式的 ECU / VCU 日志、CAN 数据及测试记录。
STEP 02
解析并对齐时间
提取事件、识别时间戳差异，并记录校正依据与不确定性。
STEP 03
建立故障时间线
把相关事件放到统一视图，发现异常及待调查位置。
STEP 04
输出证据与结论
为关键判断关联原始记录，区分事实、候选解释与证据缺口。
围绕故障调查设计
不是又一个日志搜索框，而是故障调查工作流。
| 工具类型 | 主要用途 | TracePilot 的补充价值 |
|---|
| CAN 分析与诊断工具 | 查看报文、信号及通信问题 | 把通信记录与其他来源的故障事件关联起来 |
| ECU 调试与测量工具 | 观察变量、执行状态和控制器行为 | 利用已有离线记录辅助还原故障前后过程 |
| 日志搜索与通用分析工具 | 检索文本、筛选记录、绘制统计图 | 面向汽车故障调查组织时间线、证据链和候选根因 |
TracePilot 不以替代 CANoe、INCA 或所有现有诊断工具为目标。商业价值需通过具体案例验证，例如人工整理时间、线索发现效率与证据可追溯性的改善。
从“我觉得可能是这里”，
走向“证据支持继续查这里”。
适用于 ECU / VCU 故障调查、道路测试问题分析、台架异常定位与软件回归问题排查。