一前言

本文主要内容是讨论嵌入式软件的时间分析，供大家探讨，如果有疑问欢迎探讨。
对于汽车软件，往往对执行的时序和代码运行的时间有着严格要求。对于在主循环内执行的任务函数，不论是手写还是Autosar生成,能否节拍执行到，能否在规定的时间内执行完成都非常重要，这中间设计最重要的参数就是WCET（最坏执行时间, Worst-Case Execution Time），一个是抖动时间(JIT，JITter)。最坏执行时间如果过长，将影响到其他任务的执行，甚至造成程序卡死阻塞。而抖动时间会造成程序本该被调用实际却没有，对于需要周期检测功能的函数，这部分周期的紊乱会造成数据采集的失真，对于后续数据的处理造成困难。
脱离硬件的软件代码可以通过理论计算最大执行路径的情况下估算出来，嵌入式平台执行的代码普遍和硬件息息相关，我理解的办法只能通过大量的测试和统计来进行，使用类似劳德巴赫 isystem这种调试器辅助完成。

2 软件时间及代码覆盖率

软件时间参数

软件时间分析包括软件核心执行时间、软件最坏情况执行时间以及周期性抖动。下面将简单介绍一下各个参数的含义及计算方式：
核心执行时间（CET, Core Execution Time）：
它指示CPU实际花费或已经花费了多少时间来执行中断、任务、Runable（接口）、函数或代码片段（如循环体）等，但不包括CPU处理任何被抢占（例如中断或更高优先级的任务抢占）所花费的时间。
最坏情况执行时间(WCET, Worst-Case Execution Time)：它是CET在最坏情况下可能的最大值。对于嵌入式系统软件来说，软件要在一定时间范围内对外部事件做出可靠响应，即每个实时任务应该在截止时间前完成，否则系统会失败。而WCET提供了在最坏的情况下系统的运行时间，我们需要使这个时间小于所规定的最大响应时间，才能够保证程序质量和系统的可靠运行[5]。
周期性抖动(JIT，JITter)：用于描述实际周期时间(DT)与期望周期(PER)之间的偏差。通过该值，可以知道相应事件发生的时间点是否准确。若该值为负，则说明事件过早发生；若该值为正，则说明事件发生过晚。
在这里插入图片描述

代码覆盖率

代码覆盖率，是一种通过计算测试过程中被执行的源代码占全部源代码的比例，进而间接度量软件质量的方法。代码覆盖率的测量有助于我们找到一组测试用例未执行到的程序区域，而这指示一些代码仍然可能包含严重错误。查找永远不会执行的代码，这些代码被称作“死代码”，在分配资源时会产生不必要的开销，并且由于没有经过测试，是一个潜在的危险。此外，代码覆盖率测试还能识别出冗余测试用例。
在根据 ISO26262、DO-178B 或 DO-178C 标准认证产品时，通常需要进行覆盖测量。其中，在ISO26262标准 [6]中，根据不同的安全等级也提出了不同的覆盖率要求。

3 实现过程及结果分析

现以NXP MPC5744P为核心的整车控制器作为硬件平台,通过iSYSTEM的BlueBox ic5700硬件工具及winIDEA软件工具，实现嵌入式软件的时间分析和代码覆盖率分析。

3.1硬件连接

硬件连接主要是将电脑、BlueBox和整车控制器三者连接起来，分为以下几步：
（1）连接电源线
（2）连接PC和BlueBoxUSB
（3）连接接地线
（4）连接BlueBox和控制器
如图1所示。此处应该注意的是上电顺序为先打开BlueBox的电源然后再给控制器上电，关闭的时候应按照相反的顺序。
在这里插入图片描述

图1 硬件连接图

3.2 结果分析

winIDEA中的Analyzer作为一个功能强大的工具，能够记录程序执行跟踪、数据跟踪或其他跟踪消息，然后分析这些记录以生成覆盖率或时序测量。本文主要介绍Profiler Timeline与Coverage Statistics两个窗口，这两个窗口与我们分析嵌入式软件的软件时间和代码覆盖率紧密相关，以上两个窗口如图2所示。
在这里插入图片描述

图2 Analyzer功能分析图

3.2.1软件时间结果分析

Profiler Timeline窗口可以显示收集到的分析数据，在这里，你可以清楚地查看各个事件间是如何相互关联的，如图3所示。

图3 Profiler Timeline窗口

此外，菜单栏中的Properties功能更是分析软件时间的得力助手。其中Net Time表示测量函数处于活动状态的时间；Gross Time表示测量任务处于活动状态或挂起的时间；Call Time表示测量函数进入和退出之间的时间；Period显示连续函数调用之间经过的时间；Inactive表示函数之外花费的时间。如图4所示。
在这里插入图片描述

下面以函数typeFunctionPointer为例来看看Profiler Timeline窗口到底是如何帮助我们进行软件时间分析的。如图5所示，红色块表示该区域处于活动状态，即函数typeFunctionPointer在主体中执行，任务正在运行；浅红色块表示该区域被挂起，任务被函数Mult抢占。因此，函数typeFunctionPointer的核心执行时间CET=CET1+CET2+CET3+CET4。由图6 Properties窗口 Net Time可知核心执行时间为638ns，而最大核心执行时间即为最坏情况执行时间，即WCET为1.575us。
在这里插入图片描述

图5 核心执行时间分析图
设置函数typeFunctionPointer的执行周期为15us，即PER=15us，连续两次开始运行typeFunctionPointer所间隔的时间差为DT，如图7所示。由窗口Properties下的Period可知函数typeFunctionPointer的实际执行周期DT的值，如图8所示。由公式（1）可知，周期性抖动JIT的平均值为0.298us，最大值为0.477us，最小值为0.271us。
在这里插入图片描述

3.2.2代码覆盖率结果分析

如图7所示，iSYSTEM Analyzer提供语句覆盖、函数覆盖、调用覆盖、对象级条件覆盖等覆盖测量。Coverage Statistics窗口显示地址范围以及每个下载文件、模块、函数、源代码行和对象级指令的覆盖率信息。
以函数Adress_TestScopes为例，从图8 可以看出，其源代码行级的语句覆盖率为93%，目标代码级别的语句覆盖率为97%，对象级别条件覆盖率为83%，调用覆盖率为100%。其中几项覆盖率未达到100%的原因是判断语句if (c==1)只有50%的覆盖率。结合代码旁的标志，其中，表示分支从未执行（0% 覆盖率），表示分支条件至少评估为真一次，但从未评估为假（覆盖率为 50%），表示分支条件至少评估为假一次，但从未判定为真（50% 覆盖率），分支条件至少评估为真和假一次（100% 覆盖率），根据以上规定，在可知，第110代码的判断语句只执行过为真，并没有执行过为假条件下的函数语句。

在这里插入图片描述

四计算MCU负载

ISYSTEM本来有计算CPU负载的功能，可能是我的设置问题，测试的结果一致不准确，我现在利用Profiler Timeline功能的两个统计参数。
Net Time：
实际花费在函数自己身上的时间，Net Time减去调用其他函数花费的时间
Gross Time：
就是进入该函数以后所有花费的时间，包括函数自己和函数调用其他函数的时间。

在这里插入图片描述这里将while（1）下面所有调用的函数放在一个测试函数Rte_Call_ScheDispatch以内，调用的函数根据定时器标志位判断是否执行。
深色就代表调用的函数没有达到执行条件，浅红色代表去执行别的函数未返回。那么MCU的负载率就是深红色所占的百分比，即1-Net Time/ Gross Time即1-857/4328 = 82%