延时要求也归结为三种类型，其中第一种类型是我几年前做定义时比较容易忘记的。
　　第一种为观感延时，即用户给出操作后，整个系统的响应时间。例如“用户按下开关后，玻璃应在150ms”内动作，这个需求是对整个系统的要求，在技术上来说它仍要进一步分解成不同部件的需求，如电机的起动时间是多少、控制模块分到的时间是多少。对于只管控制模块的人而言，他只要知道对他的要求是“用户按下开关后，模块的电机控制端输出电压信号的时间不得大于##ms”便够了。但在此基础上进一步，对于做这个模块的团队来说，这仍然不行，因为得去定义软件和硬件的延时，此需求进一分解为“用户按下开关，硬件输入时间是多少、软件debounce的时间是多少、在这个debounce时软件会不会有其他延时（如果是中断口则可以认为没有、如果是非固定周期扫描则要计算；另外需考虑是否有唤醒的需要以把醒来后所需的操作时间也加进来）、应用层所需时间、驱动程序的可能延时”等，将各个时间加一块才是整个模块的延时。对于模块来说纯硬件的延时很多时候都不需精确计算甚至可以不考虑，因为它们都很短，大都可以以uS来计。
　　第二种为总线延时，即某事件触发后要求模块在多少ms内发出总线信息。如开关按下后要求在40ms内发出最新的开关状态。我认为对于整车厂来说只需要定义一个需要的时间便可，而对于模块承接商来说也需像第一条一样从软件和硬件的角度去细分每一个环节的时间，在控制好每一环节后统计总时间看能否达到整车的要求。
　　第三种为延时，这种要求的精度一般都不高，因为它是s级的。比如电压档位由起动档退回ON后，5S内不记录通讯异常的DTC，这种要求均采用定时器实现，有一些误差也是允许的、且整车厂并不会过于计较，因为它只是一个粗略的规定。

　　以上的三种时间要求，整车厂也可以定义一个误差范围，凡事均有误差，当前的软件和系统设计一般是不会精准到1ms的，如果需求的定义方自认为模块提供商做到了十分精准而实际上没有，后面发生了问题会产生争执。另外一点需要提及的是从常规来看，对于某些时间方面的需求整车厂往往会单独提出来，因为他们认为这方面比较重要。例如对于一些开关的采样周期和滤波次数、对于硬件看门狗的最长定时时间等，出于功能安全的需要，某些情况下对功能安全等级要求高的模块会对软件相关的内容提出更多时间方面和软件策略有关的要求。

（2015-1-10 发表于本人QQ空间）