AUTOSAROS规范（⼀部分）
1.AUTOSAR OS构架概述
2.AUTOSAR OS在AUTOSAR构架中的位置
3.AUTOSAR OS 概念
3.1.1任务类别
任务分为两个类别：
·基础任务：只有running，suspended，ready三个状态。
基础任务在三种情况下释放处理器资源：任务结束；操作系统切换到⾼优先级任务；中断发⽣导致处理器切换到⼀个中断服务程序ISR。 ·拓展任务：较之基础任务，多了⼀个waiting状态。拓展任务被允许调⽤系统服务WaitEvent。
3.1.2任务状态及转换
任务状态
running 在任何时间点只有⼀个任务能处于running状态，CPU将会被分配到该任务，该任务的指令将被执⾏。
单元测试流程
ready 所有的任务要转换为running状态都必须先处于ready状态，处于ready状态的任务只需等待分配处理器就能转换为running状态。调度器决定哪⼀个ready状态的任务将是下⼀个执⾏的任务。 suspended 处于suspended的任务是被动的，可以被激活。
waiting 处于waiting状态的任务将不能继续执⾏，它将等待⾄少⼀个事件发⽣。 任务转换
activate：⼀个新的任务被设置成ready状态通过⼀个系统服务。AUTOSAR操作系统将确保任务从第⼀条指令开始执⾏。
（在多重激活情况下，任务激活不会⽴即改变任务状态。如果任务不是suspended状态，激活只会被记录，晚些时候被执⾏。）
start：⼀个ready任务被调度器选择去执⾏。
preempt：调度器决定去执⾏另⼀个任务，使得running任务进⼊ready状态。
terminate： running任务通过调⽤系统服务导致它的状态转换为suspended状态。
（注：任务只⾃⼰结束⾃⼰）
以下两个状态转换为拓展任务特有
wait：通过⼀个系统服务引起状态转换到waiting状态，waiting任务等待⼀个事件，以能够继续操作。
release：⾄少⼀个任务等待的事件发⽣。
3.1.3激活⼀个任务
使⽤操作系统服务ActivateTask或ChainTask激活任务。
AUTOSAR OS不⽀持类C参数传递当启动⼀个任务时。
任务激活的多重请求
依据⼀致性类别，⼀个基础任务可以被激活⼀次或多次。“任务激活的多重请求”意味着AUTOSAR OS接收和记录已经被激活任务的平⾏激活。
并⾏的多重请求的数⽬被定义在基础任务的⼀个特定的属性⾥在系统⽣产阶段。如果没有达到多重请求的最⼤数⽬，那么请求是排队的。基础任务激活的请求按照激活顺序⾥的优先级排序。
3.1.4任务切换机制
调度器：决定哪⼀个任务应该开始运⾏和触发所有必须的AUTOSAR OS内部的活动的实体被称作调度器。
在AUTOSAR OS ⾥调度器是⼀个资源。依据实现的调度策略，每当要进⾏⼀次任务切换时，调度器会被激活。任务可以保留调度器来避免任务切换直到调度器被该任务释放。
3.1.5任务优先级
0是最低优先级，数值越⼤优先级越⾼。
任务的优先级是静态定义的，在运⾏时不可以改变。但是在特殊情况下，操作系统可以给⼀个任务⼀个定义的更⾼的优先级（详见优先级上限协议）。
BCC2和ECC2⽀持相同优先级有多个任务。
在相同优先级的任务的开始顺序依据激活的顺序，通过拓展的任务进⼊waiting状态不会阻塞相同优先级⾥后⾯的任务的开始。被抢占的任务被认为是在它当前优先级的ready清单⾥第⼀个任务（最⽼的任务）。 从waiting状态⾥释放的任务被当作它的优先级的ready序列⾥的最后的任务（最新的）。
决定下⼀个要执⾏的任务的基本的步骤：
·调度器搜索所有的处于ready/running状态的任务
·从处于ready/running状态中的任务集合，调度器判定拥有最⾼优先级的任务集合
·在拥有最⾼优先级处于ready/running状态的任务集内，调度器到最⽼的任务。
3.1.6调度策略
3.1.6.1全抢占调度
全抢占调度意思是⼀个⽬前处于running状态的任务可能在任何的指令处被重调度，通过操作系统预置的触发条件的发⽣。全抢占调度会使得running任务转化为ready状态，只要⼀个更⾼的优先级的任务处于ready状态。任务环境被保存以便被抢占的任务可以在被中断的位置继续。
对于全抢占调度延迟时间与低优先级任务的运⾏时间⽆关。⼀些限制关于为了保
存环境要求增加的RAM内存和为了同步任务⽽必须的特征的增强的复杂性。由于理论上⼀个任务可以在任何位置被重调度，对于与其它任务共享的数据的访问应该被同步。
如果⼀个任务的代码段不能被抢占，那么它应该调⽤系统服务GetResource给调
度器上锁。
总之，重调度将在下⾯情况发⽣：
·⼀个任务成功结束（TerminateTask、ChainTask）
·
激活⼀个任务在任务层
太阳影子定位技术
·显式wait调⽤如果⼀个到waiting状态的调⽤发⽣（WaitEvent）
·setting⼀个事件到⼀个waiting任务在任务层
·释放资源在任务层上（ReleaseResource）
·从中断层返回到任务层
在中断服务程序运⾏期间，不执⾏重调度。
3.1.6.2⾮抢占调度
如果任务切换只通过⼀个选择的显式的定义的系统服务执⾏（显式的重调度点），这样的调度策略被描述为⾮抢占调度。
⾮抢占调度强加特殊的约束在可能的任务的时间要求上。特别是⼀个低优先级的running任务的⾮抢占区域，延迟⼀个⾼优先级任务的开始到下⼀个重调度点。
在⾮抢占任务情况下，重调度将在下⾯情况发⽣：
·⼀个任务成功结束（TerminateTask、ChainTask）
·显式的调⽤调度器（Schedule）
·发⽣到waiting状态的转换（WaitEvent）
⾮抢占调度系统的实现可能规定（导致重调度的）操作系统服务可能只能在最⾼
任务程序层被调⽤（不是在⼦函数⾥）
3.1.6.3任务组
操作系统允许任务去结合抢占和⾮抢占调度⽅⾯通过定义任务组。对于有着同任
务组内最⾼优先级⼀样或者更低优先级的那些任务，在这个任务组内的任务表现得像
⾮可抢占任务：重调度将会发⽣在重调度点（理解：任务组内的低优先级任务不会被
那些⽐他⾼的任务组外的任务抢占，因为它的优先级被调整到任务组内最⾼的优先级，任务组内外就表现的像⾮可抢占任务调度⼀样，因为没有任务会被抢占）。对于有着
⽐任务组内最⾼优先级更⾼的优先级的那些任务，在任务组内的任务表现得像可抢占
调度。
通过使⽤内部的资源来定义组合。
⾮可抢占任务是⾮常普遍使⽤的内部资源的概念：它们是拥有⼀个特别的分配了
最⾼优先级的内部的资源的任务。
⾮可抢占任务是⼀个特别的组合拥有⼀个资源有着相同的RES_SCHEDULER分配
的优先级。
3.1.6.4混合的抢占调度
如果可抢占调度和⾮可抢占调度被混合在相同的系统⾥，产⽣的调度策略被称为“混合的抢占”调度。在这个情况⾥调度策略依据running任务的抢占属性值。如果running 任务是⾮可抢占的，那么⾮可抢占调度被执⾏。如果running任务是可抢占的，那么抢占调度被执⾏。
⼀个⾮可抢占任务的定义在⼀个全抢占操作系统⾥有意义
·如果任务的执⾏时间同任务切换的时间处于相同量级
·如果RAM被⽤来提供空间去保存任务环境⽐较经济，或者
·如果任务不能被抢占。
3.1.6.5选择调度策略
软件开发者或系统集成者决定任务的执⾏顺序通过配置任务优先级和分配可抢占
性作为⼀个任务属性。
任务的类型（基础的或拓展的）独⽴于任务的调度类型（可抢占或⾮可抢占）。
如果⼀个操作系统服务在运⾏，抢占和环境切换可能会被延迟直到服务完成。
3.1.7任务的结束
在AUTOSAR操作系统⾥，⼀个任务只可以⾃我结束。
每个任务应该结束⾃⼰在它的代码的最后。不调⽤TerminateTask或ChainTask 结束任务被严格禁⽌且这会导致未定义的⾏为。
3.2事件
事件是由操作系统管理的对象。事件机制只提供给拓展的任务，它开始任务从waiting到ready和running到waiting状态的转换，是⼀种同步的⽅法。
每个任务有⼀个确切数量的事件集。这个任务被称作那些事件的所有者。⼀个个别的事件被识别通过它的所有者和它的名称（或掩码）。事件可以被⽤来传达⼆进制信息到（事件分配到的）拓展的任务。
有多种可⽤的选项去操作事件，要看特有的任务是事件所有者任务还是另⼀个任务（每必要⼀定是拓展的任务）。任何任务可以设置任何⾮suspended任务的任何事件，但是只能事件的所有者可以清除事件和等待事件的接收。
任何的任务或者第⼆类中断可以设置⼀个事件给⼀个⾮suspended任务，这样通过这个事件通知这个拓展的任务关于任何状态的改变。
硅胶加热膜任何情况下⼀个事件的接收者是⼀个拓展的任务。因此，不可能⼀个中断服务程序或⼀个基础的任务等待⼀个事件。⼀个事件只能被该事件的所有者任务清除。
如果⾄少⼀个任务正等待的事件已经发⽣，该处于waiting状态的拓展的任务被释放到ready状态。如果⼀个拓展的任务试图等待⼀个事件，⽽这个事件已经发⽣，该任务继续在running状态。
3.3资源
资源管理被⽤来协调有着不同优先级的⼏个任务对共享资源的并发访问。
资源管理对于所有的⼀致性类别是强制的。易切削不锈钢
资源管理可以视情况的被拓展到协调任务和中断服务程序并发的访问。
资源管理确保
·两个任务不可以占据相同的资源在相同的时间
·优先级反转不会发⽣
·通过使⽤资源不会发⽣死锁
·访问资源不会导致⼀个waiting状态。
如果资源管理被拓展到中断层，它额外的要确保
·两个任务或中断服务程序不能占据相同资源在相同的时刻。
资源管理的功能在下⾯情况⾥是有⽤的：
·可抢占任务
·⾮可抢占任务，如果⽤户打算让代码在其它调度策略下也能执⾏。
·任务和中断服务程序之间共享资源
·中断服务程序之间共享资源
3.3.1访问被占据的资源期间的⾏为
AUTOSAR OS规定AUTOSAR优先级上限协议，因此在任务或⼀个中断服务试图
去访问⼀个被占据的资源时没有情况发⽣。
如果资源概念被⽤于协调任务和中断，AUTOSAR操作系统还要确保⼀个中断服务程序只有在在它执⾏期间可能要占据的资源都被释放后，该中断服务程序才能被处理。
AUTOSAR严格禁⽌嵌套的访问相同的资源。在⼀些罕见的需要嵌套访问的情况⾥，推荐使⽤⼀个同第⼀个资源有着完全⼀样⾏为的第⼆个资源。实现语⾔⽀持有着完全相同⾏为的资源的定义（所谓的‘
链接的资源’）。
3.3.2使⽤资源的限制
当⼀个资源被占据的时候TerminateTask，ChainTask，Schedule，WaitEvent不
应该被调⽤。中断服务程序不能被完成因为⼀个资源被占据。
如果发⽣在⼀个任务内多重的请求资源，⽤户必须依据LIFO原则（像堆栈⼀样）请求和释放资源。
3.3.3Scheduler作为⼀个资源
调度器作为⼀个资源预定义的名称是RES_SCHEDULER。任务可以通过占据调度
器这个资源来给调度器上锁，以保护⾃⼰免被其它任务抢占。该资源不是⾃动被配置的，但是为了兼容OSEK应⽤软件，应该配置该资源，并分配最⾼的优先级。
中断的接收和处理独⽴于资源RES_SHCEDULER的状态。不管怎样，它阻⽌任务
的调度。
3.3.4对于同步机制的⼀般的问题
优先级反转
死锁
3.3.5AUTOSAR优先级上限协议
为了避免优先级反转和死锁AUTOSAR操作系统要求下⾯的⾏为：
·在系统⽣成时，对于每个资源它的所属的上限优先级被静态分配。上限优先级应该被设置访问⼀个资源或任何链接到这个资源的资源的所有的任务的最⾼优
先级。上限优先级应该低于所有不访问该资源的，以及有着⽐访问该资源的所
有任务的最⾼优先级更⾼优先级的任务的最低优先级。
·如果⼀个任务请求⼀个资源，且它的当前的优先级低于该资源的上限优先级，那么该任务的优先级会被提供到资源的上限优先级。
·如果任务释放资源，该任务的优先级复位到在请求资源之前动态分配的优先级。
优先级上限导致⼀个可能的事件延迟对于有着⽐资源优先级低或相等优先级的任务。这个延迟被任何
更低优先级任务占据资源的最⼤时间限制。
3.3.6AUTOSAR优先级上限协议拓展到中断层
资源管理到中断层的拓展是可选的。
对于决定被使⽤在中断⾥的资源的上限优先级，⾼于所有任务的优先级虚拟的优
先级被分配到中断。软件优先级和硬件中断层的处理取决于实现。
·在系统⽣成时，对于每个资源它拥有的上限优先级被静态分配。上限优先级⾄少被设置成所有任务和（访问⼀个资源或链接到这个资源的资源的）中断程序
的最⾼优先级。上限优先级应该低于所有不访问该资源任务或中断程序的最低
优先级，且同时这些任务、中断程序的最低优先级⾼于访问该资源的所有任务
和中断程序的最⾼优先级。
·如果⼀个任务或中断程序请求⼀个资源，且它的当前的优先级⽐这个资源的上限优先级低，任务或中断程序的优先级被提⾼到资源的上限优先级
·如果任务或中断程序释放资源，这个任务或中断的优先级被复位到它请求该资源前动态分配的优先级。
3.3.7内部的资源
内部的资源是对⽤户不可见的资源，因此不能通过系统功能GetResource和ReleaseResource处理。作为替代，他们在⼀个清楚定义的系统功能集内被严格的管理。除此以外内部的资源的⾏为跟标准的资源恰好⼀样。
内部的资源仅限于任务。顶多⼀个内部的资源可以被分配到⼀个任务在系统⽣成时。如果⼀个内部的资源被分配到⼀个任务，内部的资源按下⾯的⽅式被管理：
·资源被⾃动的获取当任务进⼊running状态，当它已经获取该资源时除外。作为⼀个结果，任务的优先级被⾃动的改变到该资源的上限优先级。
石墨冷铁·在重调度点，资源被⾃动的释放。实现可能优化，例如如果有需要重调度，只在系统服务Schedule内释放/获取资源。
内部的资源可以被使⽤在所有的情况⾥当需要在⼀组任务内去避免不希望的重调
度时。多余⼀个组合可以被定义在⼀个系统⾥（也就是多余⼀个内部资源可以被定义）。
在⼀些系统调⽤上的⼀般限制（拥有被占⽤的资源的系统调⽤不能被调⽤）不适
预测地震的方法
⽤于内部的资源，因为内部的资源在那些调⽤内被处理。不管怎样，所有标准的资源
必须被释放在内部的资源可以被被释放前。
分配相同的内部资源的任务覆盖⼀定范围的优先级。很有可能在相同的优先级范
围内有不使⽤这个内部的资源的任务。应⽤需要考虑这样是否有意义。
3.4调度表
通过使⽤⼀个AUTOSAR计数器和⼀系列⾃动启动的报警器可以实现⼀个静态定义的任务激活机制。最简单的情况是，通过规定“⼀旦启动就不可更改的报警器”获得静态定义的任务激活机制。⽽想要在运⾏时修改，只能在报警器之间相关的同步能够得到保证时完成。这通常意味着在相关联的计数器tick中断被禁⽌期间修改报警器。
调度表被⽤来处理上述的同步问题，通过提供⼀个封装好的静态定义的溢出点集。每个溢出点定义了：
·当处理⼀个溢出点时必须发⽣的⼀个或多个活动。⼀个活动可以是⼀个任务的激活或设置⼀个事件。
·从调度表开始的tick偏移。
每个调度表都有⼀个以tick为单位的持续时间。这个持续时间从0开始测量，它定义了调度表的模数。
在运⾏时，操作系统模块会在调度表上迭代，循环的处理每个溢出点。循环迭代由⼀个AUTOSAR计数器驱动。
3.4.1调度表结构
⼀个调度表⾄少有⼀个溢出点。
⼀个溢出点应该包含⼀个要被激活的任务的集合（可能是空的）。
⼀个溢出点应该包含⼀个要被设置的事件的集合（可能是空的）。
⼀个溢出点应该包含从调度表开始tick偏移。
调度表解析3.4.2在调度表上的约束
在调度表上⽤不到空的溢出点，所以每⼀个溢出点必须定义⾄少⼀个活动。
SWS_OS_00407：每个溢出点应该⾄少激活⼀个任务或者设置⼀个事件
操作系统需要知道处理溢出点的顺序。因此有必要确保在⼀个调度表上的溢出点总是有序的。这通过强制在调度表上的每⼀个溢出点上有⼀个统⼀的偏移得到保证。SWS_OS_00442：在调度表上的每个溢出点应该有⼀个统⼀的偏移。
在调度表上溢出点的循环迭代通过AUTOSAR计数器驱动。计数器的特征OsCounterMinCycle和OsCounterMaxAllowedValue对溢出点偏移形成约束。
SWS_OS_00443：初始的偏移应该是0或者在作为基础的计数器的OsCounterMinCycle … OsCounterMaxAllowedValue范围内。
同样的，约束也适⽤于临近的溢出点之间的延迟以及溢出点到调度表逻辑末端的延迟。
SWS_OS_00408：临近的溢出点之间的延迟应该在作为基础的计数器的OsCounterMinCycle … OsCounterMaxAllowedValue范围内。
3.4.3处理调度表
SWS_OS_00002：操作系统模块应该处理在⼀个调度表上每个溢出点从初始的溢出点到最后的溢出点按增加的偏移顺序。
SWS_OS_00007：操作系统模块应该允许多重调度表同时被处理。
SWS_OS_00409：操作系统模块的⼀个调度表应该恰好被⼀个计数器驱动。
SWS_OS_00410：操作系统模块应该能够⾄少⼀个调度表对于每个计数器在任何给定的时间上。
SWS_OS_00411：操作系统模块应该使⽤tick，以便在计数器上的⼀个tick对应与在调度表上的⼀个tick。
在相同的溢出点可以激活⼀个任务和设置（⼀个或多个独特的）事件给这个相同的任务。⽽激活任务和设置事件的顺序不同会导致不同的结果。
SWS_OS_00412：操作系统模块在⼀个溢出点上应该先处理所有的任务激活，然后在设置事件。
⼀个调度表应该有⼀个定义的状态，下图阐明了不同的状态（对于⾮同步的调度表）和它们之间的转换。
3.4.4重复的调度表处理
⼀个调度表在最后的溢出点被处理后可能会也可能不会重复。这允许两种⾏为：
1、单次的——调度表顺序的处理每个溢出点，然后在调度表末端结束。这对
于应答⼀些触发器触发⼀个阶段性的顺序活动是有⽤的。
2、重复的——调度表循环的处理每个溢出点，在处理最后⼀个溢出点后，循
环到最初的溢出点。这很有⽤对于构建执⾏重复处理的应⽤或需要同步处
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议