上海合兴软件科技有限公司

本系列前两期分别讲了静态分析的"上界"，和仿真的"模型上观测值"。但项目后期总会遇到一类问题：偶发、零星、复现条件不明——这时唯一可靠的信息来源，是目标硬件上正在实际发生什么。获取这类信息有三条技术路径：运行时间测量——从端口引脚配示波器、硬件定时器、性能计数器到 ping，工程上历史最久；它还有一个独有属性：可以一直保留在量产软件里，把关键参数最大值写进非易失存储、超限触发安全状态切换，是...

在 PC 上构建软件模型，让被分析的软件在模型上跑起来，从而在没有真实硬件的前提下观察其时间行为——这就是仿真方法。代码层叫代码仿真，模拟处理器，输入可执行文件，输出函数级的执行特性；调度层叫调度模拟，模拟操作系统的任务和中断调度逻辑，输入系统配置和时间预算，输出任务级响应时间和追踪图表。但有一点容易被混淆：仿真给出的是观测值，不是上界。简单指令集仿真器不模拟流水线、缓存和外设，它给出的指令...

不运行代码就能算出函数最坏情况下的执行时间——这是静态代码分析的核心特点。在硬件还没回来的项目早期，它能给出 WCET 上界；在调度层，类似的思路还能给出每个任务的 WCRT 上界。ISO 26262、DO-178C 等安全相关标准都把它列为推荐方法。但有时实测最大值会超过这个"上界"。不是工具算错了，是它本来就不计这一部分——中断对缓存的扰动、多核共享资源的争用、互斥应用模式带来的高估……...

10ms 周期的报文，总线上实测 8~12ms 跳动。代码没改，配置没动，问题稳定复现。这是很多 AUTOSAR 工程师都遇到过的场景，排查时容易一头扎进驱动、COM 栈或 OS 抢占里反复打转。本期视频用一个真实项目改编的案例，展示了一套从表象到机制的分层下钻排查法：第一步：Overview 看 Task CET——发现 CET 本身在抖动，排除 OS 抢占嫌疑第二步：甘特图下钻到 Run...

一次上电时序观测，上电流程一切正常。但ISDT Overview界面上有个数字不对——OS系统计数器的 DT max，28.9ms。OS Tick周期1ms，28.9ms意味着心跳中间"断"了将近29次。系统在跑，心跳却停过这么久。追下去，Init Task里藏着一段长达28ms的全局关中断代码。不止一处，另一段还有11.2ms。整个初始化阶段，系统心跳被反复阻塞。这个"中断黑洞"会引发什么...

一个关键的周期报文，发送周期时快时慢。代码逻辑查了三遍——没问题。通信配置也查了——没问题。工程师用ISDT工具一看：任务激活周期（PER）稳稳的10ms，但任务实际运行周期（DT）最大飙到19ms。计划准时，执行跑偏——有什么东西在阻碍它。这期视频还原了完整的排查过程：怎么设阈值触发抓现场、甘特图上看到了什么、优先级为什么配错了、以及一个更隐蔽的陷阱——MaxActivation=3如何无...

系统超时了，你拿示波器量了一下—— CET 没问题。那问题出在哪？很多工程师习惯用一种方法做时间分析。但实际上，从静态代码分析到调度模拟，共有七种主要方法，覆盖三个不同层级——代码层级、调度层级、通信层级。选错了层级，结果就答非所问。选错了方法，可能从一开始就走偏了。这期视频帮你理清楚：- 什么阶段该用什么方法？- 哪些方法不需要硬件就能提前验证？- 为什么一个任务 CET 只增加 1%，就...

在嵌入式系统里，CPU负载常被当作性能指标核心。但它本质上是一个统计结果，而不是物理量。决定结果的有三件事：统计对象（算不算idle/后台任务）观测窗口（8ms / 16ms / 2000ms）统计方式（平均值 / 峰值 / 分布）同一套系统，可以同时得到：69%（长期平均）100%（短时窗口）而系统崩溃，往往发生在后者。 平均值最擅长隐藏问题 长窗口最容易掩盖过载这期视频将讲清：C...

AUTOSAR OS任务的10个时间参数

在嵌入式系统开发中，有一类问题经常让工程团队非常头疼：功能逻辑完全正确CPU利用率并不高系统测试阶段表现稳定但在某些特定场景下，系统却会偶发超时问题往往难以复现，定位周期长，甚至需要多轮系统级排查才能找到原因。这类问题通常并不是功能错误，而是时间行为问题（Timing Behavior）。随着系统复杂度不断提高——多任务调度、多核架构、缓存机制、共享资源竞争——系统时间行为已经成为影响系统稳...

合兴软件推出的HXSC-ISDT嵌入式软件时间分析工具正式完成对RISC-V内核的适配，为RISC-V平台的开发者带来了高效、低成本的系统优化能力

从“事后分析”到“实时监控”：用ISDT掌控ECU实时性能在复杂的汽车多核实时系统中，当问题偶发时，开发者常陷入困境：CPU的瞬时高负载由何引起？某个关键任务为何会偶发执行超时？我们上期提到的甘特图分析功能（ISDT-Gantt）为我们提供了强大的“事后”追溯能力，但有的时候，我们需要能够在偶发问题发生的第一时间就能保存现场的手段，从而掌握一手线索。为了弥补这一关键环节，HXSC-ISDT嵌...

在现代汽车电子开发中，ECU内部运行着一个由多核、多任务和多中断组成的复杂实时系统。它们的时序行为是否符合预期，直接决定了软件功能的稳定性和可靠性。然而，这些发生在系统内部的调度行为，对于开发者来说通常是不可见的，当出现问题时，定位根源往往如同大海捞针。为了解决这一难题，HXSC-ISDT嵌入式软件调试和时间分析工具提供了一个核心功能——ISDT-Gantt。它就像一部为ECU软件量身打造的...

在复杂的汽车嵌入式软件世界里，时序问题往往像一个难以捉摸的幽灵，它悄无声息地出现，让系统表现得极其诡异。你是否也曾被一个周期报文不稳定的问题困扰？明明代码逻辑无懈可击，但信号就是无法精准、稳定地发出。我们最近就与一位客户共同经历了一场精彩的“捉鬼”行动。真实案例AUTOSAR报文周期漂移之谜故事的开端，是一个典型的棘手问题：客户发现一个关键的周期报文，其发送周期很不稳定，时快时慢，严重影响了...

“CPU负载计算结果为何总是漂移不定？”“系统响应为何偶发性延迟，复现困难？”“我的系统真的如预期般实时运行吗？”如果您也曾被这些嵌入式开发的“灵魂拷问”所困扰，那么您并不孤单。这背后，往往隐藏着一个难以捉摸的“时序杀手”。真实案例从80%的CPU负载偏差到28ms的中断黑洞近日，我们的一位汽车电子领域客户在使用HXSC-ISDT嵌入式软件调试和时间分析工具时，就解决了一个极其棘手的时序问题...