《嵌入式软件的时间分析》书友问答接龙 第九集：开发过程中的方法技巧

nmg

《嵌入式软件的时间分析》书友问答接龙 第九集：开发过程中的方法技巧 [复制链接]

这章节，都会有哪些方法和技巧？一起来看看阅读小伙伴在问答能揭晓些什么？

 

《嵌入式软件的时间分析》的书友们（@luyism 、@常见泽1 、@数码小叶 、@hehung 、@qinyunti ）：

需在本周内阅读完书籍的第九章  开发过程中的方法技巧，跟帖参与问答接龙互动：

（1）第一位跟帖发起本章问题，第二位解答第一位发起的问题，第三、四位继续问答接龙；

（2）最后一位是章节总结角色，以文字或者思维导图的形式，对本章进行总结。至此章节互动结束。

 

注意：发起的问题，对解题者理解、学习本章内容有切实意义；发起的问题不可重复。

 

 

 

活动交流群

论坛有开设汽车电子交流群，欢迎感兴趣的小伙伴，微信添加“helloeeworld”为好友，对话：加入汽车电子交流群，入群交流。

扫码，对话：加入汽车电子交流群。

数码小叶

如何更好的确定嵌入式系统的时间需求？

常见泽1

数码小叶 发表于 2024-8-19 20:50 如何更好的确定嵌入式系统的时间需求？

按顺序采访涉及的函数开发人员、网络专家、集成人员。目的是了解受访者的实际需求，即使最初可能不知道需求的存在。可以使用各种时间分析工具来检查时间需求。

luyism

在开发过程中可以利用哪些工具和技术来满足时间需求，又如何在最终产品中持续监控时间性能？

hehung

luyism 发表于 2024-8-20 14:14 在开发过程中可以利用哪些工具和技术来满足时间需求，又如何在最终产品中持续监控时间性能？

在开发过程中可以利用哪些工具和技术来满足时间需求：

可以通过访谈确定时间需求，按顺序采访涉及的函数开发人员、网络专家和集成人员获取时间需求，并给出了时间需求的文档格式（Page 204）。AUTOSAR可以使用TIMEX的形式将时间需求纳入需求规范，非AUTOSAR项目则可以以书面形式记录。

对方法和工具的要求（软件检测在功能安全相关的项目中是必要的）：

可以通过时间测量、追踪、代码仿真和/或静态代码分析来确定和监测 CET。对于调度层级的时间参数(例如响应时间、时间差 DT或 CPU 负载)，可以使用时间测量、追踪、调度模拟和/或静态调度分析。甚至在硬件和软件可用之前，就可以使用基于仿真和模型的方法，可以在较短的评估周期内快速评估不同的配置。通过测量和追踪，可以深入了解不受模型或仿真限制的可能存在的任何错误或缺点影响的真实系统。

如何在最终产品中持续监控时间性能：

一种时间验证方式是看门狗。看门狗需要定期重置计数器，没有重置计数器，则会复位。如果软件由于错误而“挂起”，则计数器不会复位，看门狗也将触发软件重置。软件应具有在初始化过程中确定上次复位原因的能力。

但是看门狗未重置并不意味着系统没有时间问题。看门狗只是最后的一道保障。所以需要常规时间测量作为基础，对时间的监控会更加清晰。用户可以在运行时确定和监测特定的时间参数。最小值和最大值可以有在非易失性存储器(例如NVRAM或EEPROM)中，并在以后访问入式系统时读出。如果非易失性存储器具有足够的空间，则可以在观测到不符合时间需求时永久储存追踪图表。

qinyunti

一点小总结:

本文分享了在嵌入式软件开发的每个阶段如何考虑软件时间，

主要包括时间需求和时间分析需求，时间测试以及检测最终的产品时间。

从个人感受而言，业内尤其是国内能专门去做时间需求分析的微乎其微，

其实更多是在乎开发者个人的考虑于能力，这里提供一个简单点实践策略，

就是根据经验总结checklist而不是专门去做时间需求分析，因为大部分嵌入式软件都是类似的，

比如检查malloc/free的时间消耗，可以封装专门的带时间测试的接口，比如检查中断的执行时间，使用IO翻转示波器查看，这些常见的时间分析写入checklist，并对于通用实现一些封装可供直接调用。