hehung的个人空间动态-电子工程世界

hehung

动态发布点评好友关于

2024-09-04
回复了主题帖：《嵌入式软件的时间分析》书友问答接龙最后1集：功能安全，ISO 26262 和前景

一般的AUTOSAR嵌入式系统中，软件并不是由一个公司完成，不同的组件软件会由不同公司提供，这种情况下如何保护第三方组件的安全，有几种方式？
2024-08-27
回复了主题帖：《嵌入式软件的时间分析》书友问答接龙第十集：AUTOSAR

AUTOSAR中的时间参数有哪些？
2024-08-26
回复了主题帖：《嵌入式软件的时间分析》书友问答接龙第九集：开发过程中的方法技巧

luyism 发表于 2024-8-20 14:14 在开发过程中可以利用哪些工具和技术来满足时间需求，又如何在最终产品中持续监控时间性能？在开发过程中可以利用哪些工具和技术来满足时间需求：可以通过访谈确定时间需求，按顺序采访涉及的函数开发人员、网络专家和集成人员获取时间需求，并给出了时间需求的文档格式（Page 204）。AUTOSAR可以使用TIMEX的形式将时间需求纳入需求规范，非AUTOSAR项目则可以以书面形式记录。对方法和工具的要求（软件检测在功能安全相关的项目中是必要的）：可以通过时间测量、追踪、代码仿真和/或静态代码分析来确定和监测 CET。对于调度层级的时间参数(例如响应时间、时间差 DT或 CPU 负载)，可以使用时间测量、追踪、调度模拟和/或静态调度分析。甚至在硬件和软件可用之前，就可以使用基于仿真和模型的方法，可以在较短的评估周期内快速评估不同的配置。通过测量和追踪，可以深入了解不受模型或仿真限制的可能存在的任何错误或缺点影响的真实系统。如何在最终产品中持续监控时间性能：一种时间验证方式是看门狗。看门狗需要定期重置计数器，没有重置计数器，则会复位。如果软件由于错误而“挂起”，则计数器不会复位，看门狗也将触发软件重置。软件应具有在初始化过程中确定上次复位原因的能力。但是看门狗未重置并不意味着系统没有时间问题。看门狗只是最后的一道保障。所以需要常规时间测量作为基础，对时间的监控会更加清晰。用户可以在运行时确定和监测特定的时间参数。最小值和最大值可以有在非易失性存储器(例如NVRAM或EEPROM)中，并在以后访问入式系统时读出。如果非易失性存储器具有足够的空间，则可以在观测到不符合时间需求时永久储存追踪图表。
2024-08-12
回复了主题帖：《嵌入式软件的时间分析》书友问答接龙第八集：软件运行时间优化

如何针对存储器的使用做时间上的优化？
2024-08-05
回复了主题帖：《嵌入式软件的时间分析》书友问答接龙第七集：多核及多ECU环境下的软件时间

多核下，如何确保数据一致性，有哪些方法
2024-07-31
发表了主题帖：《嵌入式软件的时间分析》读书活动：12 读后总结

这本书对于嵌入式软件开发人员，尤其是汽车电子嵌入式开发人员而言还是很有帮助的，书中提到了很多时间分析的方案和应用场景，时间优化方法等还需要具体的项目实践才能深入掌握，并且书中提到的一些时间分析工具也很有帮助（但是我搜索了一下，基本上都是付费的）。读完本书，掌握了一些时间分析和优化的方法，对今后的代码开发还是有一定的帮助。同时扩展了一些知识面，比如时间理论，处理器知识等。总的来说，这本书还是偏向于初学者，经验欠缺的从业人员还是很适合读读这本书的。这本书是翻译版，翻译的还算不错，中规中矩，但是有些翻译的描述还是可以优化的。很多时候给人一种机翻的感觉，如果英语水平可以的话，建议读原版。如下为我发现的一些翻译问题，有些语句感觉读起来都不是很通顺，而且难以理解其含义。下面这句话可以修饰一下，读起来很突兀。这句话倒装了，应该是代码仿真器可以在PC上为任何处理器执行机器代码。计算值？这句话描述不清，看不明白。
发表了主题帖：《嵌入式软件的时间分析》读书活动：11 第十一章读书笔记-功能安全，ISO 26262

ISO26262是汽车行业的功能安全标准，本章节简要说明了嵌入式系统的安全。目录如下：第11章功能安全，ISO 26262 235 11.1 基础知识 235 - 11.1.1 风险 235 - 11.1.2 SIL——安全完整性等级 235 - 11.1.3 脱离上下文、在上下文中、经使用验证 236 11.2 安全标准、时间及时间验证 237 11.3 时间安全所需工具 238 11.4 法律方面的考量 239 11.5 总结 240 1. 基础知识风险：风险 = （发生概率 x 损害程度） / 可控性。 SIL-安全完整性等级：嵌入式系统的每一个组成部分(包括硬件和软件)，在经过相应的风险分析后，都会被指定一个特定的安全完整性等级。脱离上下文、在上下文中、经使用验证：大多数情况下，嵌入式系统由多个供应商提供软件，如何保护第三方组件，有三种可能：在上下文中(Icontext)：供应商提供的组件的认证方式与自主开发的代码相同。但是需要供应商提供源代码，一般情况不可能，对于未提供源代码时，这种方式难以实现。脱离上下文(Outofcontext)：组件的认证独立于特定项目或应用程序。供应商组件单独认证，但是还必须确保在其项目中考虑产品和组件认证过程中创建的安全手册。安全手册(SafetyManual)可被视为一种促进安全使用组件的用户手册。因此，用户必须证明他们已经为组件的安全运行建立了所有必要的边界条件，并且已经考虑到组件施加的限制。经运行验证：在验证过程中可能会遇到这样的情况：一个组件已经被使用很多次，并习使用了很长时间，期间并没有出现任何问题。在这种情况下，必须要证明该组件对在当前项目中的边界条件与已经在运行中的项目相比并无不同。 2. 安全标准、时间及时间验证安全标准一般对时间的考虑并不深入。根据安全完整性等级，标准还可能建议使用静态分析方法。最终使用的分析方法必须针对每个项目分别确定。与认证机构专家进行的早期讨论非常有帮助，它确保了所需的保证水平既足够又均衡，因此不会造成不必要的高昂成本。可以通过静态代码分析来确定函数的 WCET，然后将结果以及很多其他函数的 WCET 用作静态调度分析的输入。利用调度模拟，可以模拟数据交换期间的同步；最后，与之前更偏向于理论的步骤相比，追踪将确保真实系统的行为符合预期。 3. 时间安全所需工具专全标推并没有规定使用特定产品，但是要求评估用于验证的各种工具的可靠性。工具的评估需要估计故障发生的可能性并分析该故障可能带来的影啊，结果为工具置信度(TCL)。 4. 总结本章节做了功能安全相关简单的说明，并简单说明了时间分析在功能安全相关项目中的应用。本章主要做了了解。
发表了主题帖：《嵌入式软件的时间分析》读书活动：10 第十章读书笔记-AUTOSAR

该章节讲解了AUTOSAR架构的一些概念，主要是针对AUTOSAR的TIMEX做了介绍，说明了时间分析在AUTOSAR架构中的应用。 TIMEX：AUTOSAR时间扩展，用于对运行时间需求做出详细描述。（目前较少项目使用） ARTI：AUTOSAR运行时间接口，用于提升AUTOSAR模块和AUTOSARECU应用软件的追踪和调试。（目前还不成熟）目录如下：第10章 AUTOSAR 218 10.1 AUTOSAR CP 219 - 10.1.1 功能架构 219 - 10.1.2 软件架构、SW-C 定义和 VFB 219 - 10.1.3 RTE 220 - 10.1.4 实现、系统配置和 Runnable 221 10.2 AUTOSAR AP 221 - 10.2.1 功能架构 221 - 10.2.2 软件架构 AA 221 - 10.2.3 实现与系统配置 223 - 10.2.4 部署 224 - 10.2.5 执行管理和执行客户端 224 - 10.2.6 确定性执行和确定性客户端 224 - 10.2.7 POSIX调度 226 - 10.2.8 AUTOSARAP中的时间 227 10.3 AUTOSAR时间扩展TIMEX 229 - 10.3.1 目标 229 - 10.3.2 事件和事件链 229 - 10.3.3 TIMEX 要求类型 230 - 10.3.4 AUTOSAR/TIMEX 视角 230 10.4 AUTOSAR/ASAM 运行时间接口 ARTI 231 - 10.4.1 AUTOSAR ARTI 232 - 10.4.2 ASAM ARTI 233 10.5 技术报告“时间分析” 233 10.6 总结 234 1. 基础概念 AUTOSAR CP：经典AUTOSAR，其标准侧重于实现实时操作系统的ECU。AUTOSAR OS 标准直接继承了OSEK/VDX标准。 AUTOSAR AP：适用于高性能ECU，例如自动驾驶所需的ECU。 AUTOSAR FO（Soundation）：所有通用要素，例如与方法有关的要素,均已转移到新建立的基础部分。 AUTOSAR的信息通过arxml文件分发，因为项目中使用的arxml文件一般都很庞大，所以都会使用工具进行处理。 2. AUTOSAR CP SW-C通信方式：发送器/接收器：发送器将数据发给一个或多个接收者，这属于单向通信。如果接收器需要响应，则还需要配置额外的通信信道。客户端/服务器：客户端向服务器请求服务，如请求提供数据。软件组件通过单个虚拟总线(虚拟功能总线，VFB)进行通信。 RTE（Rum-Time Environment）：组织通信，RTE的一项基本任务是确保通信过程中的数据一致性。软件组件的实现通过 Runnable（通常是 void-void 函数，即没有参数、没有返回值的函数）执行。Runnable 有特定的需求，比如“必须每 10 ms 执行一次”。作者在本章节中只做了简单的说明，并没有详细介绍，详细的学习可以在网络上搜索，有很多相关的学习资料。 3. AUTOSAR AP 功能将被分发到一个或多个自适应应用程序(Adaptive Applcation，AA)中。反过来说，即可以通过一个AA 来实现多个功能。（读后感：这句话感觉不是很对，前面说过功能被分配到一个或多个AA，后一句话又说一个AA实现多个功能，不对应）自适应应用程序：每个AA都有自己的main函数。运行时POSIX操作系统将AA视为常规进程，一个AA会有一个或者多个线程。实现与系统配置：执行清单（Execution Manifest）：每个 AA 都需要，描述了对于应用程序执行的要求以及与其他AA的依赖关系。服务例程清单(Service Instance Manifest)：描述了 AA 使用的服务。机器清单(Machine Manifest)。所有与不依赖 AA 的执行环境（具体的硬件虚拟机或容器）相关的信息均记录在机器清单中。部署：与AUTOSAR CP的部署不同，AUTOSAR AP将软件分发到ECU可以在运行时实现。软件更新和配置管理负责在运行时将AA纳入系统内。执行管理和执行客户端：调用参数kRunning标志着 AA 执行阶段(“运行”状态)的开始，而调用参数kTerminating 则标志着执行阶段的结束。这两个语句均将通知执行管理组件应用程序的后续状态。确定性执行和确定性客户端：冗余执行：可以再并行执行一次与安全相关的过程，这被称为冗余执行。定期执行：定期执行可能与预期有所不同。首先，确定性客户端要求 AA 符合预期的状态模型。注册服务(Register Services)-kRegisterservices:应用程序注册其通信服务，即告诉系统其将提供哪些通信服务。服务发现(Service Discovery)-kServiceDiscovery:应用程序确定其将可以使用哪些服务。初始化(Init)-kInit:应用程序初始化自身及其数据。运行(Run)-kRun:应用程序执行一次常规代码循环。这是周期性执行的代码所处的唯一状态，所有其他状态均被视为“特殊情况”。终止(Terminate)-kTerminate:应用程序正在准备终止。作者在本章节中只做了简单的说明，并没有详细介绍，详细的学习可以在网络上搜索，有很多相关的学习资料。 3.1. AUTOSAR AP中的时间确定性客户端的时间参数： PER-PERiod，周期：指连续两次激活相同类型循环的时间差。 DT-Deta Time，时间差：指一个实例开始到下一个相同循环类型的实例开始的间隔时间。 JIT-Jitter，抖动：描述了实际周期时间与期望周期时间之间的偏差。 J-Absolute Jitter，绝对抖动：指事件的标准时间与实际时间的关系。 IPT-Initial Pending Time，初始挂起时间：循环等待开始的时间,即从激活到开始执行的时间差，更准确地说，是指从“激活”事件到 DeterministicClient.WaitForNextActivation()的调用返回结果的时间差。 RT-Response Time，响应时间：从“激活”到相应循环体结束(即调用DeterministicClient.WaitForNextActivation())所经过的时间。 DL-DeadLine，截止时间：指允许的最大响应时间。 ST-Slack Time，间隔空闲时间，即剩余时间：指一次循环结束到相同循环类型的下一个循环体“激活”的时间“间隙”。 NST-Net Slack Time，净间隔空闲时间：用间隔空闲时间减去间隔空闲时间内属于其他类型环的所有 GET，即可计算出净间隔空闲时间。 GET-Gross Execution Time，总执行时间，即总运行时间：一次循环的开始时间与结束时间（即从 DeterministicClient.waitForNextActivation()函数返回结果到其再次被调用）的时间差即是总运行时间。 CET-Core Execution Time，核心执行时间，即纯运行时间：由于一个进程可以启动多个线程，并且可以在同一处理器的不同CPU 上同时执行这些线程，因此必须将所有线程的运行时相加。此计算方式的依据是POSIX 提供的 RUNT 时间。 4. AUTOSAR时间扩展TIMEX 在AUTOSAR4.0版本中引入。（目前还没有工具可以实现对TIMEX的arxml的管理）目标：可以为系统的配置提供支持，以便配置决策能够充分地服务于时间需求。可以验证是否时间需求是否得到了满足。事件和事件链：时间需求基本上可应用于事件和事件链。这些事件均为具有唯一标识的AUTOSAR 事件。事件链是指由两个或多个事件构成的链。 TIMEX要求类型： EventTriggeringConstraint 典型用例：监测周期性事件的抖动。 LatencyTimingConstraint 典型用例：避免由于不同步或发送器/接收器同步不良造成重复按收数据或数据丢失。 AgeConstraint 典型用例：确保数据不会太旧。 SynchronizationTimingConstraint 典型用例：同步子系统以避免竞态条件。 OffsetTimingConstraint 典型用例：监测两个事件之间的预期时间偏移。 ExecutionOrderConstraint 典型用例：监测处理Runnable 时的预期序列。 ExccutionTimeConstraint 典型用例:监测允许的最大 CET,例如 Runnable 的允许的最大CET。 AUTOSAR/TIMEX视角： VfbTiming：AUTOSAR软件组件(SW-C)通过虚拟功能总线(VFB)交互树的时间。 SwcTiming：软件组件的内部时间。 SyetemTiming：控制单元的时间。 BswModuleTiming：基础软件模块(BSW)的内部时间(与SwcTiming 类似)。 BswCompositionTiming：多个基础软件模块交互时的时间。 EcuTimmig：配置完整的控制单元的时间。所有软件组件和某础软件模块的交互均在此完整配置中进行了明确定义。 5. AUTOSAR/ASAM 运行时间接口 ARTI 于2016年发布，旨在大幅简化 AUTOSAR 项目的时间分析。 AUTOSAR ARTI 的任务是在V-Model的左侧建立先决条件，便于以后可以进行运行时间测量并在右侧记录追踪图表。 6. 总结本章概述了AUTOSAR中与时间相关的标准和工作组。大多都是概念的讲解，对于初学者肯定不容易理解，更深入的理解需要查找更详细的学习资料。 TIMEX的概念虽然很早就提出来了，但是目前还没有得到广泛使用。AUTOSARARTI与TIMEX相比还不成熟。ASAM ARTI还将大幅简化时间分析工具之间的数据交换过程。
2024-07-30
回复了主题帖：《嵌入式软件的时间分析》书友问答接龙第六集：软件时间问题案例

6.4章节，遗漏及重复的传感器数据中，CAN报文周期设置为了10ms接收一次，为什么还会出现CAN报文时不时丢失的问题，而且不同的ECU报文丢失的时间间隔还不相同？
发表了主题帖：《嵌入式软件的时间分析》读书活动：9 第九章读书笔记-开发过程中的方法技巧

本章节主要讲解开发过程中的一些方法和技巧。目录如下：第9章开发过程中的方法技巧 202 9.1 与时间相关的各种需求 202 - 9.1.1 时间需求 202 - 9.1.2 对于方法和工具的需求 207 - 9.1.3 通用需求模板 208 9.2 开发期间的协作 209 9.3 软件运行时间概念、调度设计和操作系统配置 210 9.4 软件运行时间调试 210 9.5 运行时间优化 211 9.6 时间验证 211 - 9.6.1 测试阶段“分析” 212 - 9.6.2 测试阶段“POI（兴趣点）追踪” 212 - 9.6.3 测试阶段“情况” 212 - 9.6.4 测试阶段“凭经验确定空间” 212 9.7 尽早考虑后期的功能 213 9.8 终产品中的时间监测 214 9.9 一个好例子：Vitesco Technologies出品的CoReMa 215 9.10 总结 216 1. 时间需求启动时间：重启后某些功能达到可用状态所经过的时间。对于大部分嵌入式系统，启动时间通常只有几毫秒。而大部分汽车ECU必须能够在100ms内启动并正常进行总线通信，即启动100ms以内必须能够发送和接收网络管理报文。端到端时间需求：“端”是指事件链的两端。一端可以是传感器(例如刹车踏板)另一端可以是执行器(例如控制刹车灯的电力电子器件)。允许的最大净运行时间(CET)。周期性。大多数嵌入式系统，都包含必须以一定时间间隔定期执行的代码。如果实际时间间隔(时间差(DT))与所需的值相差太大，则控制算法将无法正常运行。控制器可能会变得不稳定并开始振荡，这对连接的任何机械系统都可能造成灾难性后果。执行顺序：系统架构师知道Runnable 之间存在的依赖关系，们可以在核心之间或CPU任之间迁移多核系统的Runnable ，以提高系统利用率。允许的最大响应时间(截止时间)：响应时间描述了从发出执行(启动)需求到执行完成(终止或结束)的时间跨度。允许的最大数据龄期：对数据龄期的要求是与定义的任务和中断的响应时间是正交关系。允许的最大 CPU 负载。书中提到了可以通过访谈确定时间需求，按顺序采访涉及的函数开发人员、网络专家和集成人员获取时间需求，并给出了时间需求的文档格式（Page 204）。AUTOSAR可以使用TIMEX的形式将时间需求纳入需求规范，非AUTOSAR项目则可以以书面形式记录。对方法和工具的要求（软件检测在功能安全相关的项目中是必要的）：可以通过时间测量、追踪、代码仿真和/或静态代码分析来确定和监测 CET。对于调度层级的时间参数(例如响应时间、时间差 DT或 CPU 负载)，可以使用时间测量、追踪、调度模拟和/或静态调度分析。甚至在硬件和软件可用之前，就可以使用基于仿真和模型的方法，可以在较短的评估周期内快速评估不同的配置。通过测量和追踪，可以深入了解不受模型或仿真限制的可能存在的任何错误或缺点影响的真实系统。 2. 开发期间的协作 “项目合作伙伴”是指客户与供应商之间的关系。如果尽早讨论和指定有关合作的其他主题，则可以节省很多时间。信息交换的时候还可以爆出知识产权（IP）。 3. 软件运行时间概念、调度设计和操作系统配置一旦确定了具体的时间需求并选定了处理器，就可以处理软件运行时间概念。从概念出发，确定调度设计，最后得到操作系统配置结果。只有在大致了解哪些软件元素将在哪些处理核心上运行后，才能做出合理的负载估算。但是当前没有任何简单的规则可以用来将软件分发到处理器的不同核心。需要根据具体的需求来分配。 4. 软件运行时间调试在出现明显错误的时间点停止软件，可以检查变量的内容，此外，在单步模式下，还可以追踪软件的流程。深入了解真实系统的调度层级的最好办法是追踪。调度追踪图表可以将所有相关CPU上中断和任务的执行、线程和进程的执行以及相关数据可视化。 5. 时间验证时间验证的成功与否取决于自动化时间测试的可用性。每晚进行一次自动测试，那么突然出现时间问题的可能性非常低。项目在每次提交或推送代码时(即提交更改以实施版本控制时)都会执行时间测试。测试阶段“分析”：分析是指确定时间参数的过程。可以直接使用时间测量来进行，也可以间接使用追踪来进行。测试阶段“POI(兴趣点)追踪”：某一些事件导致系统偏离正常状态运行，通常会或多或少地对调度产生重大影响，从时间分析的角度来看，此类事件为“POI”(兴趣点)，因为还必须确保在偏离正常状态期间，调度和运行时间保持正常。此类事件包括错误处理、执行诊断作业、执行附加功能或变换到另一种运行状态。（可以使用单元测试来检测）测试阶段“极端情况”：对于极端情况的分析，可使用与实际硬件和环境无关的分析方法，例如调度拟和静态调度分析。测试阶段“凭经验确定空间”：目标是我出软件在遇到时间问题之前有多大的空间。也可称"稳键性分析”。将可在运行时扩展的延迟函数内置于要执行分析的代码中。此延迟应可调节，以便消耗定义的CET。在重复执行相关测试时，调节延迟时间使此延迟函数的 CET 缓慢增加，并在此期间检查所有时间需求，尤其是有关 DT、RT和CPU 负载的时间需求。一旦违反时间需求，就会将延迟的当前 CET 记录为受影响代码节和所执行测试的测试结果。 6. 尽早考虑后期的功能提前为后续功能添加占位符，代表功能所需的运行时间。未来功能的占位符将在后续版本实现。这种项目计划用于展望未来，并考虑为下一个版本规划的功能带来的影响。这种方式还可以估计将来总线上的通信量。例如，如果使用了CAN总线，则在早期阶段可以按照预期传输模式发送计划的报文，因而可以暂时确定总线负载。在插入所有占位符之后，可能会发现系统完全无法运行。这说明了如果没有实现时间优化，该软件未来版本将不稳定。如果没有占位符，则可能在未来出现问题的时候才注意到这一点，这个时候再优化将会非常耗时还难以优化。 7. 最终产品中的时间监测一种时间验证方式是看门狗。看门狗需要定期重置计数器，没有重置计数器，则会复位。如果软件由于错误而“挂起”，则计数器不会复位，看门狗也将触发软件重置。软件应具有在初始化过程中确定上次复位原因的能力。但是看门狗未重置并不意味着系统没有时间问题。看门狗只是最后的一道保障。所以需要常规时间测量作为基础，对时间的监控会更加清晰。用户可以在运行时确定和监测特定的时间参数。最小值和最大值可以有在非易失性存储器(例如NVRAM或EEPROM)中，并在以后访问入式系统时读出。如果非易失性存储器具有足够的空间，则可以在观测到不符合时间需求时永久储存追踪图表。 8. 总结本证讲解了一些在开发过程中的方法技巧，但多数都是一些理论的方式，作者并没有给出具体的实现方法，所以具体的方法还需要读者自己去摸索。最后一个章节，讲解了纬湃科技的软件开发方法，该公司有一套相关的工具用来统计每个软件组件在什么条件下使用了多少资源。纬湃科技能够在非常早期的阶段提供对未来调度的可靠估计，这也使得他们的开发人员很少需要处理不可预见的时间问题。
2024-07-24
发表了主题帖：《嵌入式软件的时间分析》读书活动：8 第八章读书笔记-软件运行时间优化

本章主要讲解了软件运行时间的优化相关知识。运行时间优化应严格遵循“自上而下”的原则。首先要在调度层级进行分析和优化，然后才在代码层级进行优化。目录如下：第8章软件运行时间优化 174 8.1 调度层级的运行时间优化 174 - 8.1.1 防止跨核心通信 174 - 8.1.2 避免使用 ECC 任务 174 - 8.1.3 合理使用异构多核处理器 175 - 8.1.4 避免需要确保数据一致性的机制 175 - 8.1.5 通过优化偏移实现周期性任务的负载均衡 175 - 8.1.6 拆分任务 177 - 8.1.7 将功能迁移到执行频率较低的任务 177 8.2 针对存储器使用的运行时间优化 178 - 8.2.1 快速存储器的利用 178 - 8.2.2 数据对齐 180 - 8.2.3 代码对齐和缓存优化 181 8.3 代码层级的运行时间优化 182 - 8.3.1 优化频繁调用的小函数 184 - 8.3.2 优化根函数sqrt 184 - 8.3.3 AURIX的线性内核 ID 187 - 8.3.4 计算至达到饱和 190 - 8.3.5 处理器特定的通用指令 191 - 8.3.6 编译器优化 192 8.4 运行时间优化总结与指南 199 1. 调度层级的时间优化在调度层级进行优化的最重要在于项目特定的参数，包括应用程序在多核处理器不同核心之间的基本分布、操作系统的配置以及任务函数和Runnable的分发等。换言之，整个项目特定的运行时间设计肯定会对调度效率产生最大的影响。防止跨核心通信：在多核处理器的不同核心之间分配功能时，应尽量减少跨越核的通信。应诊将尽可能多的中断(甚至所有中断)交由一个核心集中处理，而将计算密集型代码节部署到另一核心。遐免使用 ECC 任务：只和OSEK/AUTOSAR CP项目相关。合理使用异构多核处理器：在异构多核处理器中，采用前述拆分方式时，应将软件的计算密集型代码节分配给最强大的核心。避免需要确保数据一致性的机制：随着系统变得越来越复杂，确保数据一致性的成本不断提高，因此，最好消除对显式数据一致性机制的需求。数据一致性机制会消耗额外的RAM、闪存和运行时间。避免方式：使用相同的优先级或优先级组来尽可能避免抢占式中断；使用协作式多任务处理来避免抢占式中断；如果无法避免抢占式中断，可以将抢占式任务或(抢占式)中断划分为包含强制性抢占部分的节段和可以以非抢占方式实现且包含所有其他部分的节段。通过优化偏移实现周期性任务的负载均衡：当配置了多个周期性任务时，会带来各任务彼此之间时间关系的问题。可以通过偏移(offsets)来设置，偏移是指与调度开始时的基准或假想的基准之间的时间差。（书中有具体的示例，page 176）目的是让任务切换的中断次数最少。拆分任务：如果后台需要做很多工作，同时任务中也有大量工作，可能导致后台不会执行，所以将任务拆分成两个或者多个，让后台可能有时间执行。但同时更多的任务也意味着更多的资源消耗，需要根据项目具体情况评估。将功能迁移到执行频率较低的任务：这种优化方法比较烦琐;而且它在实践中可能具有很大的针对性。 2. 针对存储器使用的运行时间优化微处理器有多种不同的存储器和寻址模式，有些访问速度快，有些则比较慢。快速存储器的容量一般非常有限，因此没有足够的空间容纳所有符号。因此就有问题：应该将符号放置在何处才能实现软件的最高性能? 下图表示了一个放置规则（经常访问的小符号应该放置在快速存储器中）：符号的大小可以通过编译后生成的map文件查看。确定访问和调用的频率会更加困难。最简单方法就是测量或追踪。数据对齐：一般32位的处理器都会要求数据地址是4的整数倍。所有采用32位对齐的地址都以0、4、8或c结尾，这样的数据访问速度会最快。如果不按照4字节对齐，则处理器会使用其他指令访问数据，速度会慢很多。同样，结构体也需要对齐分配才能获得最优的访问效率。对于代码和数据对齐的运行时间优化是以牺牲存储需求为代价。因此，用户必须“最短运行时”(速度优化)和“最低存储需求”(大小优化)这两个优化目标之间做出选择。 3. 代码层级时间优化一般而言，代码优化的相应候选项(函数)以分为两类: 从很少甚至唯以一一个地方调用但运行时间需求较高的函数（通常为单个大函数中进行的复杂计算）；非常频繁地从很多不同的地方调用的函数（通常包含相对较小的函数或用于适配数据类型的函数）。优化频繁调用的小函数：如果源代码可用，则应对源代码进行分析。最好的办法是同时查看源代码和由编译器生成的汇编代码。同时利用编译器的特性，利用内联函数或者其它特性进行优化。根函数sqrt优化：要得到精确的根则会花费较多的时间。一般对于绝大多数的数学函数，有一些精度低但是速度快很多的替代方案。需要开发人员评估精度的缺失是否会带来负面问题，可以网上搜索替代方案。 AURIX 的线性内核 ID（page187）：英飞凌的第二代AURIX最多有6个CPU，但是内核ID是不连续的，分别为0~4和6，但是一般用户会使用数组，所以需要一个连续的ID，如果为6，则变成5，作者采用的分析方式是通过生成的汇编代码来查看C代码实现的逻辑，并且增加优化等级，查看生成的汇编的变化，然后删除其中不必要的语句，只保留必要的可以实现功能的语句，就可以实现代码效率最高的优化。作者发现内联函数没有真实的被编译器设置为内联函数时，采用了宏的实现方式。计算值达到饱和：很多计算中，都要求结果达到饱和而不溢出。需要查看芯片是否有直接的机器指令支持这种饱和操作，AURIX就有sat.hu指令支持。编译器优化，有如下方式：每个编译器都提供了现成的优化组合，因此用户仅需指定粗略的目标(“针对大小优化”还是“针对速度优化”)或优化程度即可。-O0用于禁用所有优化措施，-O1至-O3用于依次执行更积极的优化。如果未选择何优化选项，则编译器将使用-O0，不进行任何优化。对于编译器提供的每种优化，都有一个单独的编译器开关，当从命令行调用该开关时，可以将其传递给编译器。查看编译器手册。可以直接在函数层级甚至在函数内的源代码中启用或禁用各个优化选项。这可以通过不同的机制来实现。查看编译器手册，一般通过#pragma语法来实现 Page195，作者通过对Memcpy的各种优化说明了优化后的代码的时间消耗，以此说明了优化的方法以及重要性。 4. 总结通过一些流程图来说明了如何解决运行时间问题。本章节的时间优化方案对于嵌入式软件开发人员而言还是很有实际用处的，作者所说的优化方式也在工程中经常用到，但是作者对此进行了系统总结，补充了一些新知识，有助于开发人员对软件做时间优化。
2024-07-23
回复了主题帖：《嵌入式软件的时间分析》书友问答接龙第五集：软件时间分析方法

调度模式的原理和工作方式是什么
回复了主题帖：《嵌入式软件的时间分析》读书活动：7 第七章读书笔记-多核及多ECU环境下的软件时间

Jacktang 发表于 2024-7-23 07:25 所需的电压和时钟频率成正比，所需的功率岁频率的增加而提高三倍为什么是提高三倍这是书中的解释：
2024-07-22
发表了主题帖：《嵌入式软件的时间分析》读书活动：7 第七章读书笔记-多核及多ECU环境下的软件时间

本章节讲解的是多核或者多ECU下软件执行的一些知识和问题。目录如下：第7章多核及多ECU环境下的软件时间 154 7.1 多核基础知识 154 - 7.1.1 Amdahl vs.Gustafson——谁是对的？ 155 - 7.1.2 CPU 核心——同构（Homogeneous）、异构（Heterogeneous）还是锁步（Lock-step）？ 155 - 7.1.3 锁步多核 156 - 7.1.4 英飞凌 AURIX——同类、异类和锁步 157 7.2 并发执行的多种类型 158 - 7.2.1 应用程序的并行执行 158 - 7.2.2 函数的并行执行 159 - 7.2.3 指令的并行执行 164 7.3 数据一致性，Spinlocks 165 - 7.3.1 确保数据一致性的理想解决方案 168 - 7.3.2 确保数据一致性的成本 169 7.4 存储地址克隆 170 7.5 总结 172 1. 基础知识现在处理器通过引入缓存和复杂的流水线提供处理器时钟速度，但是处理器的性能提升不能无限制提高，当处理器以最高速度运行时，所需的电压和时钟频率成正比，所需的功率岁频率的增加而提高三倍。高频率还会带来电磁兼容性（EMC）的挑战，高频率工作就像是无线电一样，会与其他电气信号产生耦合，所以另一种提高高计算能力的方法就是多核。分类：同构多核：具有多个相同架构的核心；异构多核：具有多个不同架构的核心；锁步多核：从软件角度看，软件将在两个相同的核心上并行执行，这样可以检测到暂态错误（非永久存在但偶尔会发生的错误）。锁步多核仍然需要看成是单核处理器。代码将由两个核心同时执行，其结果由硬件执行比较。这里的“同时”不是完全同时，第二个核心的执行将被延迟几个时钟周期。 2. 并发执行的多种类型应用程序的并行执行：嵌入式软件中，开发前会明确知道使用哪种硬件以及在硬件上运行什么软件。嵌入式硬件多核，可以将两种功能放到两个不同的核心中处理。（比如ABS系统和ESP系统，之前单核处理器中需要两个处理器来实现，通过CAN通信来进行数据交互，这两个功能可以使用一个多核处理器实现，通过共享内存交互数据）函数的并行执行：如何将一个单核处理器上运行的函数，变成在多个处理器上并行执行，则逻辑会变得很复杂，除非从项目设计的最初阶段就设计为多核处理器函数。但是这是未来的一种发展趋势，因为很多抽象层级的代码都是由代码自动生成工具生成的，只需要确定处理器类型以及核心，生成的函数就可以是多核并行执行的。文中还介绍了函数并行的两种并行方式：双重并行和流水线并行以及说明了其优点（page 163）。指令的并行执行：这是硬件层面的并行执行。流水线会并行处理多个命令，但是不良的跳转指令可能会影响效率。针对流水线友好的软件的一些建议：避免函数调用（可以使用宏或者inline函数提高流水线效率）；避免不必要的中断，采用轮询。 3. 数据一致性，spinlocks Spinlocks（自旋锁）是为了解决多个核心同时访问同一个共享资源时可能导致的数据不一致的问题。比如核心0和核心1同时访问一个变量并对这个变量做自增操作时，即（读取变量，然后将变量的值+1，然后将新值写回变量）。当当前变量的值为24时，一个核心读取了变量，另一个核心也在此时读取了变量，两个变量读出来的值都是24，此时都分别自增计算，返回给原变量，会导致最终此变量的结果为25，具体现象就是此变量只被增加了一次（实际上增加了2次，只不过数据不一致问题存在导致结果表现为只增加了一次）。使用 spinlock 后，当一个 CPU 占用了某个资源(对所有其他 CPU都可见)，在其占用期间，其他CPU都不能使用该资源。使用spinlock可能会导致多核CPU都被暂停在资源等待处，所以被spinlock保护的部分应该尽可能少。多核代码开发前期就应该考虑多核共享资源访问的问题，应该尽量避免这种资源，每个核心尽可能访问自己核心的资源。 4. 存储地址克隆这种方式是现在多核处理器中地址访问的一种常用方式。通俗来说，就是每个核心有属于自己的RAM区域（比如，CPU0-0x700...，CPU1-0x600...，CPU2-0x500...），同时还提供本地访问地址0xD00...，每个核心都可以通过本地访问地址访问属于自己核心的地址，即CPU0通过0xD00...将访问0x700....，CPU1通过0xD00...将访问0x600....，CPU2通过0xD00...将访问0x500....。这就是地址克隆，0xD00...段就是克隆段。地址克隆的好处，可以在克隆段定义一个变量，这个变量实际上会在每个核心的私有地址上都定义一个，然后不同的核心访问这个变量，都是访问的自己核心私有地址，这样就使用一个变量完成了多个变量的事情。这样的访问当时极大地增加了访问效率。但是也存在一个缺点，就是如果某个核心不会使用这个变量，但是这块地址也会被这个变量占用，导致地址空洞。 5. 总结本章主要讲解了多核架构的类型，多核软件的执行方式，数据一致性的解决方式以及地址克隆等知识，这些知识在多核开发中都会遇到，本章节算是做了一个总结。对使用多核处理器有很大的帮助。其中数据一致性是必须要重点关注分析的点，因为这在多核系统中是一个很常见的问题，处理不好会导致系统运行混乱，发生不可预期的错误。
2024-07-19
发表了主题帖：《嵌入式软件的时间分析》读书活动：6 第六章读书笔记-软件时间问题案例

第六章通过实践来讲解了实践分析的应用，每一节都提供了实际项目中的一个时间问题案例。可以清楚地了解到导致时间问题的各种不同的原因以及问题显现方式的差异。目录如下：第6章软件时间问题案例 139 6.1 中断都是哪来的? 139 6.2 OSEK ECC：并非选择 140 6.3 重置17 min后发生偶发崩溃 143 6.4 遗漏及重复的传感器数据 144 6.5 拉着手刹去比赛 149 6.6 实际测量得到的 WCET 比静态代码分析得到的更大 150 6.7 有时候网络管理报文来得太早了 151 6.8 系列项目中无间断的时间分析 152 6.9 时间分析使得车厂节省了1200万欧元 152 6.10 总结 153 1. 时间分析问题案例总结中断触发次数远高于预期的问题：预期中断10ms一次，但事实际上通过ECU下载后的第一个追踪表中发现7ms内中断就触发了高达200次。经过分析发现是中断的触发方式为引脚状态触发，实际上应该为边沿触发，修改成边沿触发，中断变成了10ms一次。该案例说明调度追踪表的重要性，从中可以发现一些调度异常的问题。 OSEK ECC：并非最优选择：系统出现函数问题和通信不稳定的问题，作者发现是因为任务过载，软件中使用的是ECC任务（Extended Conformance Class：扩展任务），这种任务不会终止。原因为本来该10ms执行完成的任务，可能由于某种原因导致实际执行时间多于10ms，这样就会导致一些任务不能及时处理（每当运行服务发现时，负责通信的任务都具有非常高的CET），造成延时，出现上述问题。重置17分钟后发生有发崩溃：问题现象是操作系统运行一段时间（大约17分钟后，34分钟后又会发生一次）就像“卡死”一样，不再继续执行任务。但是，中断依然继续发生。作者发现定时器的一次跳动需要237ns，位宽为32，表示大约每17分钟就会溢出一次。作者通过减少定时器中断触发周期来快速定位问题，发现在进入中断服务程序后，忘记了保存堆栈上的一个寄存器（这部分为手动编写），正确配置后，问题不再出现。遗漏及重复的传感器数据：系统运行时，CAN报文会时不时的丢失，最初发现几分钟丢失一次，很有规律，但是对于不同的ECU，信号丢失的间隔时间不同。作者发现CAN报文接收周期为10ms，但是存在一定的抖动，不是精确的10ms一次，任务Runnable的执行也存在抖动，这样就会出现任务和接收的CAN报文不匹配导致问题。还存在CAN发送器的晶振工艺的差别，出现发送CAN报文周期为9.9999925ms，而控制器的接收周期为10.000038ms，这些问题的叠加，导致了数据的丢失和重复。作者还详细说明了一种模拟该问题的代码实现，可以看原文Page146。该问题有如下解决方法：同步：由于晶体无法同步，因此必须在软件中实现同步。如果发射器和接收器均使用AUTOSAR,则可以通过“Synchronized Time-Base Maager”进行同步。或者不将计算任务放在周期任务中，而是收到了CAN报文在进行计算，但是这样会存在于其他任务不同步的问题，但是可以通过这种方式检测接收的数据是否正确。也可以将发送器和接收器同步，ECU可以在每次接收的时候显式的发送数据请求。超采样：如果每个测量值发送两次，同时丢弃重复接收的测量值，则不会丢失任何数据。显然，这种方法增加了网络的负载，需要对算法进行相应的修改。拉着手刹去比赛：客户发现控制单元软件不稳定，代码不能正常下载追踪图表，处理器出现了一般性过载导致的该问题，开启了P-Cache之后解决了该问题，开启之后，代码运行速度快了4倍，之前的代码被作者称为“拉着手刹行驶”。实际测量得到的 WCET 比静态代码分析得到的更大：作者在使用基于追踪和测量的时间分析方法，将自己的结果与其他工具的结果进行比较发现净运行时间(CET，核心执行时间)的测量结果大于项目合作伙伴使用静态代码分析计算出的上限。换句话说，测得的值大于数学上可能的WCET(Worst-Case Execution Timo最坏情况执行时间)。原因是静态代码分析工具忘记为执行程序代码的闪存指定等待状态。因此，以前所有静态代码分析的结果都太低、太乐观了。这个故事说明只有通过对真实系统的观测或测量来验证这些方法的关键数据，才能确保模拟以及基于模型的分析可信。验证范围无须太广泛，但必须确模型或模拟环境在其核心方面充分反映现实情况。有时候网络管理报文来得太早了：网络管理报文应每10ms发送一次。允许的偏差在1ms 以内。接收ECU 检查了此时间需求，偶尔发现两个连续消息之间的时间差小于3ms。原因是每当从一种应用模式切换到另一种应用模式时，该报文的周期性发送就变得“失步”。每个应用模式都有其自己的一组任务，上一个应用模式的最后一次调用与下一个应用模式的第一次调用之间的时间差过小，差了7ms。 2. 总结该章节通过几个示例说明了软件时间分析的重要性，就像是看一个个小故事一样，比枯燥乏味的理论知识有意思的多。并且从这些故事中也能了解到一些问题的原因查找方法以及解决方法，还是有很多的收获。该章节的第8,9两个章节主要是说明了时间分析的好处，作者通过实例说明了时间分析的好处，带来了性能上的有效以及CPU负载的有效降低，为公司节省成本。
2024-07-18
发表了主题帖：《嵌入式软件的时间分析》读书活动：5 第五章读书笔记-软件时间分析方法

第五章是本书的重点，也是本书篇幅占比最大的一个章节。主要介绍了在不同的开发阶段使用的各种软件时间分析方法。目录如下：第5章软件时间分析方法 69 5.1 概览及在不同层面上的分类 69 - 5.1.1 通信层级 69 - 5.1.2 调度层级 70 - 5.1.3 代码层级 71 5.2 术语定义 72 - 5.2.1 追踪 72 - 5.2.2 分析、时间测量和（再次）追踪 72 5.3 静态代码分析 73 - 5.3.1 基础功能和工作流 73 - 5.3.2 用例 75 - 5.3.3 静态代码分析的限制 76 - 5.3.4 静态代码分析专家访谈 78 5.4 代码仿真 80 - 5.4.1 功能与工作流 80 - 5.4.2 用例 81 - 5.4.3 静态代码仿真的限制 82 - 5.4.4 与代码仿真领域专家的访谈 83 5.5 运行时间测量 86 - 5.5.1 基本功能和工作流 86 - 5.5.2 用例 95 - 5.5.3 运行时间测量的限制 96 5.6 基于硬件的追踪 97 - 5.6.1 基本功能和工作流 97 - 5.6.2 用例 99 - 5.6.3 基于硬件的追踪的限制 101 - 5.6.4 基于硬件的追踪专家访谈 102 5.7 基于软件方法的追踪 108 - 5.7.1 基本功能和工作流 108 - 5.7.2 用例 115 - 5.7.3 基于测量的追踪的限制 115 - 5.7.4 基于测量的追踪领域专家访谈 116 5.8 调度模拟 121 - 5.8.1 基本功能和工作流 121 - 5.8.2 用例 124 - 5.8.3 调度模拟的限制 124 - 5.8.4 调度模拟专家访谈 125 5.9 静态调度分析 127 - 5.9.1 基本功能和工作流 128 - 5.9.2 用例 129 - 5.9.3 静态调度分析的限制 131 - 5.9.4 静态调度分析专家访谈 131 5.10 使用进化算法进行优化 135 5.11 时间分析方法在 V-Model中的应用 137 1. 概念及分类通信层级：通信层级的时间通常与网络总线上的经过时间有关。关注的重点一般是是通信层级上端到端的时间（例如，从传感器到执行器），或者从软件中的一个事件到服务器上另一个事件的时间差；调度层级：调度层级（RTOS 层级）的时间会影响操作系统所有与时间有关的行为。因此，调度层级也被称为操作系统层级或 RTOS 层级；代码层级：对代码层级的元素执行时间分析时，重点是元素的处理和所需的时间。代码层级的中央时间参数是净运行时间（CET，核心执行时间）。 2. 术语 2.1. 追踪追踪是指在存储器中记录事件并附加时间戳的过程。在以后的某个时间点，此追踪存储内容可用于重现原始事件发生时的情况。 2.2. 分析、时间测量和（再次）追踪分析（Profiling）是指访问运行中嵌入式系统或模拟的时间参数的过程。显示了两种分析方法，其中一种方法是执行运行时间测量，以直接确定所需的时间参数；另一种方法则是通过追踪间接进行。在追踪时，最初仅收集追踪数据，然后便可从中提取时间参数。 3. 静态代码分析本章重点讲解了软件时间的静态代码分析，主要研究如何确定特定代码片段（例如函数）可能的最大内核执行时间。可能的最大CET是指WCET（最坏情况执行时间），实际应表述为 WCCET（最坏情况核心执行时间）。 3.1. 分析流程首先，静态代码分析读取可执行文件并将其反汇编，通过反汇编的代码，可以推导出控制流和函数调用树（函数的调用关系），此分析还能确定最大循环迭代次数。收集的数据合并在一起，可能的最大运行时间将沿着控制流累加。因为可执行文件包含所有机器指令和数据的存储地址，所以此分析甚至可以考虑缓存和流水线对运行时的影响。但是此分析还需要非常精确的处理器模型。由此可见，该分析方式对工程师的能力要求极高，所以一般都是使用工具进行分析。书中提到了一个工具AbsInt，可以用来做静态最大执行时间的分析。我搜索了一下，这个工具有30天的试用，但是没有提供直接的下载链接，而是填写pdf提交申请，下载比较麻烦，所以就没有尝试。 3.2. 静态分析的限制静态代码的分析还是有很多困难的，如下：间接函数调用：在某些情况下，静态分析将无法确定此参数可以取哪些值。在这种情况下，函数调用树并不完整。递归：递归深度不好确定。循环上界：无法确定最大循环迭代次数，计算 WCET 需要此数据。一般使用一个可能过大的值进行分析，从而导致明显的高估。注释：用户必须通过提供其他信息来手动阐明上述三个“绊脚石”。也就是说，必须注释代码（由代码开发者提供）。运行模式和互斥代码：一般一套程序都会有几种不同的工作模式（比如飞机的“在地面上”、“飞行中”），静态分析的时候各个模式的代码会有交叉，导致分析困难高估：即使可以完全完成分析并注释应用程序工作模式，分析结果通常WCET仍会出乎意料的高。造成这种情况的原因之一可能是高估，即报告的 WCET 上界与实际 WCET 之间的差异很大。中断、多核和暂时性错误：静态代码分析是一种代码层级的方法，因此不涉及任何调度方面。存储器接口上的中断或访问冲突（多核设备上经常发生）将不予考虑。为确保完整性，静态代码分析也将忽略暂时性错误。 3.3. 代码仿真代码仿真器可以在 PC(x86 架构)上为任何处理器执行机器代码，PC 模拟了其他处理器。目标处理器的编译器也被称为交叉编译器(Cross-compiler)。代码仿真通常涉及少部分代码的检查，例如单个函数或算法。仿真器由可以模拟目标处理器的软件组成，可以执行为目标处理器生成的可执行文件。为了使单元测试更接近真实目标系统，可以针对目标处理器对其进行编译，然后再使用代码仿真器执行。静态代码仿真的限制：仿真过程如果没有使用“正确的”变量，可能与真实情况出现很大的区别。》》文中通过作者和代码仿真专家的访谈，说明了代码仿真的介绍和一些可能会遇到的问题，受益匪浅。 3.4. 运行时间测量测试方式一：普通IO口来测试传统的时间测量方式是通过IO口的翻转来测量，方法很简单：初始化的时候设置某个IO口为高电平；在需要测试的代码前面将此IO口设置为低电平；然后在测试代码之后将此IO口设置为高电平；然后通过示波器或者逻辑分析仪采集IO口由高变低，然后低电平持续的时间就显示待测代码段执行的时间。个人总结（非本书内容）：这种方式虽然简单，但是这种方式测量的时候需要考虑到IO口翻转的执行执行时间，如果待测试的代码本来就执行很短的时间，则可能会导致测试结果不准确。不使用IO口测试（使用硬件定时器）使用IO口来测试也存在一些弊端，比如不能自动化测试、需要示波器或者逻辑分析仪辅助，相对繁琐。还可以使用硬件定时器来做测试。测试方式：待测试代码之前获取定时器的counter值；待测试代码之后再次捕获定时器的counter值；然后两个值作差，通过定时器的频率就可以算出执行时间。这种方式需要减去定时器值获取本身的开销，即单独调用值获取函数，记录消耗的counter数，然后在总时间中减去2倍此counter。此方式测量还需要考虑定时器是否溢出，一般使用无符号变量可以允许一次溢出，但是如果多次溢出就不适用，需要考虑减小定时器的频率，或者更换位宽更宽的定时器。 OSEK PreTaskHook/PostTaskHook OSEK 引入了一种运行时间测量机制，也可用于 AUTOSAR CP，即PreTaskHook/PostTaskHook 机制。在调用任务的应用程序代码之前，PreTaskHook 运行，任务结束时，PostTaskHook 运行。但是也存在一些缺点，比如，不能知道是哪个任务启动的，而且hook函数会被频繁调用，测试出来结果准确度不行。空循环计数器测量CPU负载吐槽：这个方式看了大半天才看懂，咋说呢？感觉像是机翻，着实有点不好理解，如果换成国人常用的表述则好理解很多。方法如下：这种方式在测量前需要脚本参数，即关闭全局中断、看门狗、各种监控成都等一切可能会打断代码运行的功能；在空闲循环中让计数器值自增，经过一段时间得到的值为Z0（这是一个标准值，也是基准值，也就是在空闲循环中将一个变量自增）；然后开始正产功能运行（中断打开，看门狗打开...）统计空闲函数执行的时间Z（变量自增后的大小） CPU负载率就是1-(Z/Z0)。 “性能计数器”进行测量很多处理器提供的硬件功能都可以在代码执行期间确定与时间密切相关的参数，其中包括缓存未命中的数量和多个核(同时)访问共享存储器时的冲突次数以及流水线推迟次数。这个需要根据特定的处理器来实现。 ping进行测量使用网络诊断工具ping，可以测量简单请求从客户端发送出去、经过网络到达主机再返回的响应时间。 4. 基于硬件的追踪现在的处理器一般都提供调试器可以用于监控指令（）追踪的运行，比如TRACE32，书中只做了相关知识的介绍，具体软件使用还需要参考工具手册。追踪逻辑的确切工作方式取决于使用的处理器，但都有一个共同点：只有少数决定性事件记录在追踪存储器中，而执行的大多数指令都是重构时被插值进来的。基于硬件的追踪提供了一种解决方法：可以在运行期间观测要检查的软件(即无须停止)并记录执行路径。与基于软件的追踪不同，该方法不需要修改软件就能实现这一目的。除了“调试”用例以外，基于硬件的追踪还特别适用于运行时间分析。利用此方法，可以确定追踪期间所执行函数的所有时间参数。通常会有一个视图显示按CPU负载排序的所有已执行函数，这对于运行时间优化特别有用。本章节还描述了作者和硬件追踪专家的访谈记录，看了很受启发。 5. 基于软件方法的追踪下面这张图说明了基于硬件方法的追踪、基于软件方法和外部存储器追踪数据缓存的追踪、单纯基于软件方法的追踪。基于软件追踪（外部追踪数据存储器）：追踪数据的获取基于软件测量。与外部追踪硬件的连接可以通过所有可用的接口来实现（SPI，以太网等）。此方式的时间戳可以由追踪软件本身生成（开销大）并与其他信息一起传输到外部，也可以由外部硬件生成（准确度会有影响）。基于纯软件的追踪：处理器的RAM来存储这些追踪数据，然后通过其他方式传输到外部。追踪测量的细节注意事项还有很多，以及对不同的对象的追踪，书中都有描述，还需细细品味。 6. 调度模拟调度模拟是对操作系统组织任务和中断的执行逻辑进行模拟。调度模拟流程：必须为特定的调度方法配置模拟，即必须选择用于模拟的操作系统；创建任务和中断，并定义与调度相关的参数。最重要的参数是优先级，其他参数涉及任务多次激活或“可抢占”设置。调度模拟工作方式：模拟期间将根据激活模式激活任务并触发中断。对于任务或中断的每次模拟执行，将根据指定的分布以及BCET和WCET随机确定运行时间(CET)。如果存在由另一个任务或中断造成的中断，则也会映射到模拟中，同样使用随机选择的CET。通常会生成与调度相关的所有事件的追踪图表(至少是所有任务的激活、开始和结束，以及所有中断的开始和结束)。追踪数据能够实现可视化，时间参数也可以根据追踪数据计算得出。作者也记录了和调度模拟专家的访谈对话，很有帮助，其中提到了一个工具"TA Tool Suite"，可用于调度模拟。 7. 静态调度分析静态调度分析是在调度层级执行，它是一种按“数学方法”确定最坏情况时间参数的机制，无须借助模拟、测量或追踪。此处所说的时间参数是指调度层级的时间参数，尤其是响应时间。静态调度分析也可以在通信层级进行。比如：可以通过这样的方式验证和优化CAN总线通信，以确保尽管总线负载明显高于广泛使用的40%，但是所有报文仍能在各自的截止时间内完成传输。如下说明了调度分析的工作原理：文中提到了一个工具：INCHRON 的 chronVAL，可以用于静态调度分析。 8. 使用进化算法进行优化进化算法用于解决调度可能非常复杂，至于无法轻松计算时间参数(例如任务的响应时间RT)的问题。过程：首先指定优化目标，例如最小化任务的响应时间；定义自由度，即在优化过程中可能更改的参数。这些参数可能包括周期性务的偏移或某些任务的优先级；最后便是启动实际的优化。简单地说，就是先随机改变形成自由度的参数，然后进分析，并考虑对优化目标的最终影响。追踪参数修改，以确保达到优化目标，然后重新开始整个过程。随机修改参数类似于进化中的突变。成功修改后的“基因组成”将逐渐占上风，经过几代之后，配置将不断完善，并且越来越接近优化目标。如果优化目标得以充实现，或者超过了先前定义的时间，则会停止演化。 9. 总结静态代码分析：静态代码分析需要已编译完成并链接的代码。但是，也可以把要测试的函数链接到测试应用程序(例如，通过单元测试)。对于静态代码分析，分析工具必须支持所用的处理器。代码仿真：代码仿真与静态代码分析的情况类似，只是它还可以在比函数层级更高的层级。运行时间测量：只要具备附带所需处理器和相应编译器工具链的评估版，就可以在PIL(Processor In the Loop，处理器在环)测试中执行运行时间测量。此方法可以在后续开发过程中以及最终产品中使用，以便在常规运行中监视运行时间。基于硬件的追踪：也需要具备处于运行状态的处理器。使用此方法时，会在代码层级和调度层级执行广泛的分析。如果情况允许，还可以将这些分析扩展到 HIL(Hardware In the Loop，硬件在环)环境，甚至扩展到最终的产品环境。基于软件方法的追踪：严格地说，追踪可以与运行时间测量同时开始，但是调度通常是分析的关键方面。因此，这种方法的前提条件是有一个可用的系统并且此系统上已经在运行操作系统。调度模拟：此项分析在很大程度上与处理器、编译器、硬件或软件的可用性无关。只需大致了解系统的情况，就足以在较高的层级进行模拟、分析和优化。可以将后续开发过程中增加的信息添加到模型中，从而使其随着时间的推移越来越详细。静态调度分析：静态调度分析与调度模拟的情况非常类似,只是分析的侧重点有所不同，因为它更明确地考虑了最坏情况。但是，静态调度分析无法提供对系统正常行为的分析。该章节描述了各种事件分析方法，很多方法也是第一次听说，还介绍了一些时间分析的工具，一些章节记录了和相关专家的对话，总的来说，这个章节收益颇丰。
2024-07-15
回复了主题帖：《嵌入式软件的时间分析》书友问答接龙第三集：操作系统

本章首先介绍了不使用操作系统的优势，以及使用操作系统的优势，还介绍了OSEK/VDX和POSIX这两种规则的操作系统，都是汽车行业会使用的。对协作式和抢占式多任务做了利弊分析，最后讲解了POSIX中的进程和线程。本章节介绍的相对简单，因为一个学习一个系统不是一个短短的章节就能说明清楚的，作者只是找出了系统中最重要的部分做了分析说明，相对系统进一步掌握，还需要专门的查看相关文档。
回复了主题帖：《嵌入式软件的时间分析》书友问答接龙第四集：软件时间理论

逻辑执行时间如何解决多核通信的时候存在的数据发送和接收时间不确定的问题？
2024-07-08
回复了主题帖：《嵌入式软件的时间分析》读书活动：4 第四章读书笔记-软件时间理论

秦天qintian0303 发表于 2024-7-7 08:29 如果任何一个嵌入式系统都通过这个理论去分析，能带来什么好处啊这个章节讲解的理论是关于时间的，通过这个理论可以统计出软件中各个环节暂用的时间长短，然后针对长时间的任务或者片段做优化，可以帮助快速定位耗时任务。嵌入式软件一般最关注最大CPU占用率分，析出来可以知道CPU最大占用率是多少，能不能cover住最坏情况的的功能处理，这些都可以帮助定位出时间消耗最大的部分，便于后期做定向优化
2024-07-06
发表了主题帖：《嵌入式软件的时间分析》读书活动：4 第四章读书笔记-软件时间理论

第四章讲解的是软件时间相关的一些定义，理论。章节如下：第4章软件时间理论 53 4.1 时间参数 53 - 4.1.1 RTOS 调度（OSEK、AUTOSAR CP 等）时间参数 53 - 4.1.2 与 POSIX相关的时间参数 58 4.2 统计参数 58 - 4.2.1 小值和值 59 - 4.2.2 平均值 59 - 4.2.3 直方图 60 - 4.2.4 非定期事件的发生模式 60 4.3 CPU负载 61 - 4.3.1 定义 62 - 4.3.2 选择观测范围 64 - 4.3.3 扩增的 CPU 负载 65 - 4.3.4 使用后台任务时的 CPU 负载 66 4.4 总线负载 67 4.5 逻辑执行时间 67 4.6 总结 68 1. 时间相关参数该章节讲解了一些时间分析相关的参数，使用了一些缩写词来标记不同的时间参数，并对这些时间参数做了详细的解释（page 54）： CET：Core Execution Time，即核心执行时间。 DT：Delta Time，指一个(周期)实例开始到下一次开始的间隔时间，即连续两次开始同一个任务所间隔的时间差。（实际周期）。 PER：PERiod，周期。指连续两次激活相同任务的时间差。（期望周期）。 JIT：JITter，抖动(更准确地说是周期性抖动)。描述实际周期时间与期望周期时间之间的偏差。 J：Absolute Jitter，绝对抖动。指事件的标准时间与实际时间的关系。 RT：Response Time，响应时间。调度理论中最重要的时间参数，它指示了从需要执行任务或中断的时间到完成执行任务所经过的时间。 DL：DeadLine，截止时间。指允许的最大响应时间。截至时间是一个规范，无法测量。 GET：Gross Execution Time，总执行时间，即总运行时间。指从任务开始执行到终止执行的时间差，或是从中断、Runnable、函数或代码片段开始执行到结束执行的时间差。 IPT：Initial Pending Time，初始挂起时间，即初始延迟。是任务等待开始的时间，即从激活到开始执行的时间差，或者是从中断进入挂起状态到ISR开始执行的时间差。 ST：Slack Time，间隔空闲时间。指所观测对象的一个实例结束到下一个实例开始所间隔的时间。 NST：Net Slack Time，净间隔空闲时间。用间隔空闲时间减去间隔空闲时间段内属于更高优先级任务或中断的所有CET，即可计算得出净间隔空闲时间。 PRE：PREemption Time，抢占时间，即中断时间。中断时间并不重要，它反映了相应实例执行期间的所有中断和抢占的时间总和。 NPR：Number of PRemptions，抢占次数，即中断次数。中断次数可以针对任务、中断、Runnatle、函数或代码片段的单个实例，也可以指特定时间段内所有中断的总和。 2. 统计参数时间测量的重点在于确定最小值、最大值和平均值。对于特定的数据量，最小值和最大值都比较容易确定，大量多次统计就可以确定最小值和最大值。平均值就是所有时间值的非加权算数平均值。书中也提到了平均值计算虽然简单，但是如果确定计算哪个范围内的平均值就是一个值得讨论的问题了。 3. CPU负载 CPU是会一直处于工作状态的，即使不需要执行代码，CPU也会一直执行机器指令。CPU负载是不计算空闲代码的，空代码是没有功能的代码。单一CPU和观测期t1内的CPU负载可以用时间t2(CPU花在功能代码而非空闲代码士的时间)除以现测期t1的持续时间计算得出，即t2/t1，计算值范围为0~1，通常用百分比表示。 CPU负载的计算虽然很简单，但是如何选取观测期间却是很难回答的。书中列举了监控周期选择不合适会导致的一些问题：使用超周期（各任务周期的最小公倍数）时，系统某一点局部过载，但是总体CPU暂用率还是可能会比较低，不能监控到局部过载的问题；使用最长任务的周期时，也会有上述情况；周期太小则会在过载部分为100%，但是其他部分很小，导致CPU负载率在0~100%来回跳转；所以一般而言，观测周期应该尽可能长吗，但是不能太长。还需要结合实际情况来确定 4. 通信总线负载通信总线的负载计算方式和CPU负载的计算方式是一样的。总线在传输数据的时候则表示总线处于忙状态，没发送报文的时候就是空闲状态。 5. 逻辑执行时间逻辑执行时间(LogicalExecution Time LET)是一种解耦功能与通信概念，目的是使嵌入式软件(尤其是在多核应用中)具有确定性，从而更加稳定、安全且易于分析。多核通信的时候一般都是：任务在开始时会接收数据，然后处理该数据，并在终止之前输出数据。这样的结构会带来一个问题，即数据发送时间很大程度上取决于任务的执行时间，如果任务结束时间早，则数据早发送，结束时间晚，则数据晚发送。下面就是作者提到的逻辑执行的时间范式：使用逻辑执行时间范式，接收和传输时间在一定程度上与任务的执行时间解耦。接收和发送均在任务执行期间的固定时间进行。这种范式下，任务执行的时间长短都不会影响定义好的“通信模式”。但如果执行时间过长到了发送时间还没有执行完成，则可能会发生错误处理。见下图：任务执行完成并不会立刻发送数据，而是等到了设定的时间才会发送。总结本章介绍了很多与时间相关的参数，后面的很多章节都会涉及这些时间参数。还介绍了CPU负载的计算方法以及逻辑执行时间的通信和任务调度解耦的方法等。学了本章的收获还是挺大的，虽然一些知识之前有了解过，但是还没有这么系统的学习过，而且作者还使用具体的示例讲解了可能得问题和解决方法，对后续的时间分析很有帮助。