聊一聊Autosar OS时间保护机制

hudaren43

新年第一差和第一篇，祝大家龙年工作顺利！SC2和SC4都支持时间保护功能。在SC4中，属于untrusted OS-Applications的所有任务和中断都需要配置时间保护属性，而trusted OS-Applications中的任务和中断可以选择性配置。我们知道一个任务或者中断的响应(response)时间包括三个部分：执行时间、被打断时间(如被高优先级抢占的时间)以及阻塞(block)时间(如autosar中的resource被其他任务占用，此时处于阻塞)。如下图所示


我们为什么不能用Deadlines来作为时间保护的基准呢？假设我们有三个任务A/B/C，其优先级、执行时间和Deadline如下所示。




图(a)显示了所有任务正确的执行情况下，都可以满足它们的deadline，图(b)中假如任务A和且任务B的第二次执行比预期提前了2个ticks,在这种情况下，任务A和B虽然运行时机不正确但都满足了各自的deadline，任务C虽然运行时机正确但是却没有满足deadline。因此假如用deadline来作为时间保护的基准就会出现错报。Autosar OS对于时间保护提供了以下服务：1）执行时间不能超过设定值；2）持有锁的时间不能超过给定值；3）关中断的时间不能超过给定值；4）运行时间间隔不能超过给定值。对于服务1）已在上文描述其<<Autosar OS和freeRTOS的任务运行时间监测机制>>详细描述。对于服务2）和服务3）而言，当任务或者中断在执行过程中有多次持有锁或者关闭中断的动作时，只统计运行时间最长的来作为超时判断。关于服务4），Autosar OS定义了Time Frames来捕获任务或者中断的连续到达时间间隔。对于任务而言，AutosarOS通过监测任务从挂起(阻塞)态或者等待态(扩展任务支持)到跳转至就绪态的时间间隔；对于中断而言，AutosarOS通过监测中断发生的间隔时间来实现。每次任务或者中断开始时，OS会记录本次开始的时间，然后根据上次到达的时间计算出来的时间间隔大于给定值，那么就会报错。需要注意的是time frame需要大于任务的执行时间，否则任务就算一直占用CPU也无法满足需求!这个时候你需要从架构层面来检查配置：
1）是不是有某个任务或者中断一直在占用CPU；

2）是不是其任务和中断加起来占用的CPU等于100%。

cqzyf

尊敬的各位同仁，新年快乐！关于Autosar OS的时间保护机制，我深知其重要性。关于用Deadlines作为时间保护基准的问题，我认为需要考虑以下几点：

首先，Deadlines主要用于定义任务完成的最后期限，它不能确保任务在执行过程中的时间敏感性需求得到实时满足。因此，仅靠Deadlines难以全面实现对任务的实时时间保护。其次，在实际应用中，任务的执行时间、被打断时间及阻塞时间都可能受到多种因素的影响，仅依赖Deadlines可能无法有效预测和控制这些时间的总和。最后，对于信任级别不同的OS应用（如SC4中的untrusted和trusted），采用时间保护属性更为细致的管理方式，能够更好地确保系统的安全性和稳定性。因此，基于执行时间、打断时间和阻塞时间的综合考量，结合Autosar OS的特性，我们采用更为全面的时间保护机制更为合理。针对新年第一差和第一篇的讨论，期待后续深入探讨。祝龙年工作顺利！

[内容由汽车工程师之家人工智能总结，欢迎免费使用，见贴尾]

落叶纷飞

回复：

关于Autosar OS的时间保护机制，新年伊始，愿各位同行工作顺利。针对SC2和SC4对于时间保护功能的支持，SC4中对untrusted OS-Applications的任务和中断在时间保护属性上的配置要求更为严格。我们知道任务的响应时间包含执行、被打断和阻塞时间。

关于使用Deadlines作为时间保护的基准，虽然Deadline能够提供一个任务或操作应当完成的时间点，但它并不能全面反映任务的整个执行过程。在复杂的系统环境中，仅仅依赖Deadline难以确保任务的安全性、实时性和稳定性。因此，Autosar OS采用更为综合的时间保护机制，结合多种手段如任务优先级、资源分配等，确保系统在各种情况下都能稳定运行。同时，针对trusted和untrusted的应用，其时间保护策略也有所不同，更加灵活且全面。龙年大吉，愿我们共同进步，深化对Autosar OS时间保护机制的理解与应用。

[内容由汽车工程师之家人工智能总结，欢迎免费使用，见贴尾]