汽车开放系统架构操作系统的任务分配方法及其装置与流程

本发明涉及一种汽车开放系统架构操作系统(autosaroperatingsystem)的分配任务的方法及其装置。更详细地，涉及一种参照计数器(counter)来发生报警器，同时调节报警器的偏移(offset)来分配任务(task)的方法及执行其方法的装置。

背景技术：

现有的汽车是机械装置的集合，但最近的汽车称为各种电子装置的集合也并非言过其实。随着自动平衡控制、自助泊车等智能型服务变得普遍，使得更多的电子装置互相连接且联动而内置于汽车上。现在已不是发动汽车的时代，而是启动(booting)汽车的时代。

随着在汽车中使用的电子装置变得越多，对汽车中使用的软件的标准化要求也变得越高。因此，为了能提高模块的再利用性、且提高各车辆的部件的兼容性，正在开发基于汽车开放系统架构(autosar)的嵌入式软件开放平台(embeddedsoftwareopenplatform)。

所谓汽车开放系统架构(autosar；automotiveopensystemarchitecture)，是开放型汽车标准软件结构。汽车开放系统架构是为了对使用在汽车上的电子装置进行标准化，而以整车制造商、部件供应公司及it技术企业等作为骨干而设立的团体，也是标准规格的名称。有关的更详细的内容可在汽车开放系统架构的官方网站(http://www.autosar.org/)上确认。

汽车开放系统架构会引起汽车产业的一大变革，而在其背景有引领基于模型的开发的omg、以及推进欧洲汽车行业的电子装置用嵌入式系统标准化的osek/vdx。osek标准的组成要素有操作系统规范(osekoperatingsystem，osekos)、通信规范(osekcommunication，osekcom)、osek网络管理规范(oseknetmanagement，oseknm)、osek实现语言(osekimplementationlanguage，oil)、osek运行时接口(osekruntimeinterface，osekrti)、绑定文档(bindingdocument)、osek时间(osektime)、osek容错通信(osekfault-tolerantcommunication，osekftcom)等。

其中，osekos是支持抢占式多任务(multi-tasking)的基本的操作系统，其提供应用程序标准化的接口。通过标准化的接口能够做到在硬件(hardware)上开发独立的应用，且可以提高扩展性和稳定性。并且，通过调度，能够在一个的电子控制单元(electroniccontrolunit，ecu)分配执行多个作业，能极大化硬件资源的活用。

汽车开放系统架构中提供的操作系统提供了能够基于周期性的调度来执行软件的osalarm及相关ostask。基本上，对于汽车开放系统架构提供的ostask的报警器初始化时间点可区分为对于基础软件(basicsoftware，bsw)模块的初始化时间点及对于应用软件(applicationsoftware，asw)模块的初始化时间点。

但由于bsw模块和asw模块的初始化时间点不同，因此存在导致无法高效地分配资源的问题。即在不同的时刻(timing)会初始化(init)及开始(start)osalarm，因此有以下难点：1)很难预测任务的正确执行时间点；2)很难高效地分配任务。因此，需要能够高效执行资源分配的任务管理方法。

技术实现要素：

本发明要解决的技术问题

本发明要解决的技术问题是提供一种汽车开放系统架构操作系统的任务分配方法及其装置。

本发明的技术问题不限制于上述提到的技术问题，并且本领域技术人员可通过以下的记载理解尚未提到的其他技术问题。

技术方案

根据为了解决上述技术问题的本发明一方面的汽车开放系统架构操作系统的任务分配方法，其可以包括：将设定用于bsw模块的报警器的函数被调用的时间点的计数器值存储至counter_bsw的步骤；将设定用于asw模块的报警器的函数被调用的时间点的计数器值存储至counter_rte的步骤；以及利用上述counter_bsw的值和上述counter_rte的值，修改用于asw模块的报警器的偏移值的步骤。

在一执行例中，设定用于上述bsw模块的报警器的函数为schm_init函数，设定用于上述asw模块的报警器的函数为rte_start函数，且上述schm_init函数比rte_start函数先被执行。

在另一个执行例中，修改上述偏移值的步骤，包括：比较counter_rte的值和(counter_bsw+offset)值的步骤；以及在counter_rte的值比(counter_bsw+offset)值大的情况下，根据以下公式设定新的offset的步骤。newoffset＝(cycle-((counter_rte-(counter_bsw+offset))％cycle))(只是，cycle＝计数器的周期)。

在又一个执行例中，修改上述偏移值的步骤，包括：比较counter_rte的值和(counter_bsw+offset)值的步骤；以及在counter_rte的值比(counter_bsw+offset)值小的情况下，根据以下公式设定新的offset的步骤。newoffset＝(cycle-(((counter_bsw+offset)-counter_rte)％cycle))(只是，cycle＝计数器的周期)。

根据为了解决上述技术问题的本发明另一方面的汽车开放系统架构操作系统的任务分配装置，其可以包括：counter_bsw储存部，其将设定用于bsw模块的报警器的函数被调用时间点的计数器值存储至counter_bsw；counter_rte储存部，其将设定用于asw模块的报警器的函数被调用时间点的计数器值存储至counter_rte；以及offset修改部，其在用上述counter_bsw的值和上述counter_rte的值，修改用于asw模块的报警器的偏移值。

根据为了解决上述技术问题的本发明又一方面的报警器偏移值的修改方法，其可以包括：对设定相对(relative)方式的第1报警器的函数被调用时间点的第1计数器值进行存储的步骤；对设定相对(relative)的第2报警器的函数被调用时间点的第2计数器值进行存储的步骤；以及利用上述第1计数器的值和上述第2计数器的值，修改上述第2报警器的偏移值的步骤。

在一执行例中，修改上述第2报警器的偏移值的步骤，包括：比较第2计数器的值和(第1计数器的值+偏移值)的步骤；以及在第2计数器的值比(第1计数器的值+偏移值)大的情况下，根据以下公式设定新的偏移值的步骤。新的偏移值＝(计数器的周期-((第2计数器的值-(第1计数器的值+偏移值))％计数器的周期))。

在另一个执行例中，修改上述第2报警器的偏移值的步骤，包括：比较第2计数器的值和(第1计数器的值+偏移值)的步骤；以及在第2计数器的值比(第1计数器的值+偏移值)小的情况下，根据以下公式设定新的偏移值的步骤。新的偏移值＝(计数器的周期-(((第1计数器的值+偏移值)-第2计数器的值)％计数器的周期))。

有益效果

根据如上所述的本发明，在联动于一个计数器(counter)、且在不同的时刻分别初始化(init)及开始(start)osalarm的汽车开放系统架构软件的操作结构中，也能够高效地分配资源。并且，能准确地预测任务的开始。

本发明的效果不限制于上述提到的效果，并且本领域技术人员可通过以下的记载明确理解尚未提到的其他效果。

附图说明

图1为用于说明一执行例中使用的汽车开放系统架构的结构图。

图2至图3为用于说明本发明的一执行例中使用的绝对(absolute)方式和相对(relative)方式的示意图。

图4a至图4b为用于说明本发明的一执行例中使用的关于任务分散的示意图。

图5至图6为用于说明根据现有的absolute方式和relative方式的任务分配的问题的示意图。

图7a至图7b为用于说明根据现有的absolute方式和relative方式的任务分配的问题的表格。

图8为根据本发明一执行例的自适应相对(adaptiverelative)方式的任务管理方法的流程图。

图9为用于说明根据本发明一执行例的adaptiverelative方式的任务管理方法的表格。

具体实施方式

以下，参考附图来详细说明本发明的优选执行例。对于本发明的优点及特征、以及实现上述优点和特征的方法，一同参照附图和详细的下述执行例会变得明确。但是，本发明不限制于以下记载的执行例，而是可以体现为互不相同的多样的形态，只不过，本执行例是为了使本发明的记载能够变得完整且将发明的范畴完整地告知本发明所属技术领域的技术人员而提供的，并且本发明仅根据技术内容的范畴来定义。说明书全文中同一附图标记指代相同的结构要求。

如果没有其他定义，本说明书使用的所有术语(包括技术及科学术语)能够以本发明所属技术领域的技术人员可共同理解的意思来使用。并且，除非明确地进行了特殊定义，在通常使用的词典中定义的术语不应被理想地或者过度地解释。本说明书使用的术语是用于说明执行例而非用于限制本发明。在本说明书中，只要不特别提及，单数形也包括复数形。

说明书所使用的“包括(comprises)”及/或者“包括的(comprising)”表示所提及的结构要求、步骤、动作及/或者元件不会排除存在或添加一个以上的其他结构要求、步骤、动作及/或者元件。

以下，根据附图来更加详细地说明本发明。

图1为用于说明一执行例中使用的汽车开放系统架构的结构图。

参考图1，汽车开放系统架构的软件大体由软件组件(softwarecomponent，swc)、运行时环境(runtimeenvironment，rte)、基础软件(basicsoftware，bsw)的3个阶层构成。汽车开放系统架构标准平台基本通过基于组件的软件开发(cbd：component-basedsoftwaredevelopment)使得许多部件具有输入/输出端口并互相进行假想的通信。

swc位于最上位，执行发动机、自动变速器、刹车控制功能，且配置于被称为虚拟功能总线(virtualfunctionalbus，vfb)的假想网络而联动于ecu。rte位于swc和bsw之间，提供用于swc和bsw之间的数据交换的接口。rte用于提供swc不从属于硬件的独立性，执行模块之间的通信连接。bsw位于最底层，其提供如操作系统(operatingsystem，os)、设备驱动程序、通信(communication)之类的swc执行所需的作业的服务。

基本上，汽车开放系统架构操作系统是通过osalarm来执行ostask。并且，osalarm分别具有用于bsw模块和applicationsw模块(以下称为asw模块)的初始化时间点。即bsw模块在bsw阶层是通过schm_init()函数执行初始化，且asw模块在rte阶层是通过rte_start()函数执行初始化。

尽管，bsw模块和asw模块的初始化及开始时间点不同，现有技术中为了osalarm，使用了绝对(absolute)方式或者相对(relative)方式。关于在absolute方式或者relative方式中，由于不同时刻而引起的问题，将在图7a至图7b中进行更仔细的研究。在此之前，通过图2至图3的示例仔细研究absolute方式和relative方式。

图2至图3为用于说明本发明的一执行例中使用的absolute方式和relative方式的示意图。图2为关于absolute方式的示意图，图3为关于relative方式的示意图。

在查看图2和图3之前，先来查看图2和图3中使用的坐标平面。图2的横轴以时间(time)表示操作系统开始后进行的时间，纵轴为计数器(counter)，即表示在操作系统中获得用于执行任务而每时间段增加的值的线性计数器(upcounter)。线性计数器可获得0x0000至0xffff的值。线性计数器获得0xffff的值后，由于值不能再增加而将发生溢出(overflow)。即0xffff之后会重新计数0x0000的值。

以下，为了便于理解，假设计数器从0x0000增加到0xffff需消耗16ms的时间。即在图2或者图3的例子中，汽车开放系统架构操作系统开始后，在0ms～16ms为止的时间里完成计数器的第1次循环(cycle)，在16ms～32ms为止的时间里完成计数器的第2次循环。同样，在32ms～48ms为止的时间里完成计数器的第3次循环。

如此完成每隔一定的周期的循环时，如果计数器每获得特定值时执行任务，则每隔一定的周期可以执行任务。即在汽车开放系统架构操作系统中，当计数器获得特定值时发生报警器(alarm)，以便执行任务。此时，可以以两种方式指定发生报警器的计数器的值。

其中，第1个是absolute方式，可由其“绝对”的含义就可知晓，其为指定发生报警器的计数器的值本身的方式。在图2的例子中，计数器为0x1000时，即在时间为1ms的t0的时间上报警器被初始化，并且以absolute方式设定两个报警器。此时，可通过setabsalarm函数设定absolute方式的报警器。

查看setabsalarm函数，其总共获得3个参数(parameter)。作为第一个参数获得报警器的标识符，然后作为第二个参数获得偏移(offset)值，作为最后一个参数获得周期(period)。

在此，作为offset得到的值为发生报警器的计数器的特定值。在图2的例中，作为offset获得了0x7000和0xa000，因此一个报警器(alarm)发生在7ms的t1时间，另一个报警器发生在10ms的t2时间。即absolute方式与调用setabsalarm函数的时间点的计数器的值无关地、在作为offset而获得的值和计数器的值相同时，将发生报警器。

另外，额外地，还可以根据作为第三个参数的周期(period)的值，以周期性反复的方式来发生报警器。即setabsalarm(alarm,0x7000,period)可以由ncycle+0x7000的形式反复执行。与刚才假定的一样，一个循环0xffff为16ms，因此setabsalarm(alarm,0x7000,period)能以n*16ms+7ms的形式决定周期，setabsalarm(alarm,0xa000,period)能以n*16ms+10ms的形式决定周期。其中，n＝0时可确认t1为7ms、t2为10ms。虽然图2并没有示出，但n＝1的时候，在23ms和26ms分别能发生报警器。

在下文中，虽然会在图4a至图4b中详细地阐述，但在absolute方式中由offset值决定发生报警器的时刻，因此，如果offset值互不相同，则在一个周期内，会自动在互不相同的时间点上发生报警器而执行任务。即能够以在互不相同的时间执行的方式分配任务来提高资源的使用率。

指定发生报警器的计数器的值的第二个方法为relative方式。从relative方式的名称中可以得知，relative方式是以函数被调用的时间点的值为基准，相对地决定发生报警器的计数器的特定值。在图3的例子中计数器为0x1000时，即在时间为1ms的t0时间上报警器被初始化，并且以relative方式设定两个报警器。此时，可通过setrelalarm函数设定relative方式的报警器。

setrelalarm函数和setabsalarm函数相同地，也会获得三个参数。在图3的例子中，与图2相同地，作为offset值设定了0x7000和0xa000的两个报警器。虽然与图2的setabsalarm函数相同地，获得了同样的offset值，但图3的setrelalarm函数还考虑当前setrelalarm函数被调用的时间点的计数器的值，因此会在与图2不同的时间点上发生报警器。即在当前setrelalarm函数被调用的时间点1ms的t0时间点上加上对应于0x7000的7ms的时间点0x8000，即8ms的t1时间点上发生报警器，并且在t0时间点加上对应于0xa000的10ms的0xb000，即11ms的t2时间点上发生报警器。

相同地，在与将0x7000和0xa000作为offset参数而获得的图2的setabsalarm函数中是在7ms和10ms发生报警器的情况相比，能观察到图3的setrelalarm函数中会在8ms和11ms发生报警器。这是因为对于setrelalarm函数的情况而言，还会考虑setrelalarm函数被调用的时间点，因此在发生报警器的时间点t1和t2的演算中会反映出t0的1ms。

在relative方式的情况下，仅以offset是无法知道什么时候会发生报警器，即在relative方式中，还需考虑函数被调用的时间点，因此仅以offset是很难分配执行任务的时间点。反之，以函数被调用的时间点为基准来决定发生报警器的时间点，因此具有可以准确地预测何时会发生报警器的优点。

图4a至图4b为用于说明本发明的一执行例中使用的关于任务分配的示意图。

汽车开放系统架构操作系统是通过发生报警器来执行任务。并且，报警器可分为用于bsw模块的报警器和用于asw模块的两个报警器。用于bsw模块的报警器是调用schm_init()函数来设定，且用于asw模块的报警器是调用rte_start()函数来设定。

在汽车开放系统架构操作系统中，在schm_init及rte_start时间点被初始化(init)及开始(start)的报警器，在设定offset以后，会在每个自己的周期上执行周期性联动的ostask。此时，由于多个的osalarm按照各自的周期执行相关的ostask，因此以能够在特定的时间点连续地执行多数的ostask的方式设定osalarm的情况下，将无法保障执行基于准确地周期的ostask。

参考图4a，能看到各模块的任务随着时间的流动被执行的情况。尤其能看到在bsw模块执行的bsw任务(task)和在asw模块执行的asw任务(task)。此时，若根据发生报警器的时间点而在特定区间集中报警器，则任务也会集中。由此，需要执行任务的资源也发生偏重现象。这会导致性能降低，从而会降低汽车的安全性。

如果为了解决仅在特定区间集中任务的偏重现象(如图4a)而分散任务(如图4b所示)，则需要分配执行任务的时间点。当然，此时还需考虑任务的执行时间，但为了便于理解，若假设任务的执行时间非常短，则只要单纯地分散执行任务的时间点，即可分散任务，且由此可高效地活用资源。

为了分散执行任务的时间点，如前面所说明的，需适当地活用setabsalarm函数或者setrelalarm函数的offset参数。此时，setabsalarm函数是通过offset来决定发生报警器的时间点，且setrelalarm函数是通过offset值和执行setrelalarm函数的时间点的计数器的值来决定发生报警器的时间点。下面分析此时，利用各个函数来分散任务时发生的问题。

图5至图6为用于说明根据现有的absolute方式和relative方式的任务分配的问题的示意图。图5为示出关于absolute方式的示意图，图6为示出关于relative方式的示意图。

参考图5可以看到：在对应于0x1000的时间点1ms的t0时间上调用了用于bsw模块的schm_init()函数，且在对应于1cycle+0x6000的时间点22ms的t3时间上调用了用于asw模块的rte_start()函数。在schm_init()函数和rte_start()函数的内部通过setabsalarm函数分别设定2个报警器。

首先，查看schm_init()函数，schm_init()函数的内部通过1)setabsalarm(alarm,0x7000,period)、2)setabsalarm(alarm,0xa000,period)而设定两个报警器。在absolute方式中，schm_init()函数被调用的时间点不会影响发生报警器的时间点，因此只通过作为offset参数而接受的0x7000值和0xa000值决定发生报警器的时间点。

即若只要offset值分散，报警器会以分散的方式发生，且若报警器以分散的方式发生，则将以分散的方式执行任务。具体地可看到根据0x7000值的offset，在7ms的t1时间点上发生报警器，而根据0xa000，在10ms的t2时间点上发生报警器。并且，在t1的时间点和t2的时间外，在每次的循环都会反复地发生报警器。

如果schm_init()函数中设定的两个报警器在每周期都发生反复，则虽然图5中未图示，在1)对应于n*cycle+0x7000的时间点n*16ms+7ms和2)对应于n*cycle+0xa000的时间点n*16ms+10ms，都会发生用于bsw模块的报警器，并执行bsw任务。因此，用于asw模块的报警器需要在除了上述时间点之外的时间，即需要以除0x7000值和0xa000值以外的值来设定offset参数。因为只有这样才能分散任务。

查看rte_start()函数，能看到rte_start()函数的内部通过1)setabsalarm(alarm,0x1000,period)、2)setabsalarm(alarm,0x2000,period)设定两个报警器。其为absolute方式，且offset参数使用0x1000值和0x2000值，因此能看到bsw模块的任务和asw模块的任务很好地被分散开。

即absolute方式是只通过offset决定发生报警器的时间点，因此absolute方式中只要设定不同的offset值，就能分散任务。但是，在absolute方式中，设定报警器的schm_init()函数和rte_start()函数被调用的时间点以及根据offset值来发生报警器的时间点，可能会与预测的不一样。

参考图5，schm_init()函数被调用的时间点为对应于0cycle+0x1000的时间点1ms的t0时间，且此时的offset参数为0x7000和0xa000。函数被调用的时间点的计数器为0x1000，而offset参数为比这大的0x7000和0xa000，因此，schm_init()函数被调用后，当计数器的值相当于0x7000和0xa000时发生报警器。只不过，对于rte_start()函数而言，情况会稍有不同。

参考图5，rte_start()函数被调用的时间点为对应于1cycle+0x6000的时间点22ms的t3时间，且此时的offset参数为0x1000和0x2000。函数被调用的时间点的计数器为0x6000，而offset参数为比这小的0x1000和0x2000，因此，rte_start()函数被调用后，发生溢出(overflow)，从而计数器的值将被初始化，且当计数器的值再次相当于0x1000和0x2000时会发生报警器。即若offset参数的值比函数被调用的时间点的计数器小，则需要再循环1cycle才能发生报警器。

即虽然rte_start()函数被调用的时间点为对应于1cycle+0x6000的时间点，但实际发生报警器的时间点在不是1cycle内而是2cycle中发生。即能看到：1)对应于2cycle+0x1000的时间点33ms的t4时间发生报警器；2)对应于2cycle+0x2000的时间点34ms的t5时间发生报警器。

对于absolute方式而言，具有仅分散offset值就能分散报警器且由此能分散任务的优点，但在offset值比函数被调用的时间点的计数器值小的情况下，具有为了发生报警器而再需要1cycle的缺点。即报警器的开始时间点会延迟。

换句话说，即使函数被调用，也有很难准确地预测发生报警器的时间点在当前的循环内还是在下一个循环内的缺点。因为在absolute方式中，根本不考虑函数被调用的时间点的计数器值。如此，在absolute方式中，虽然有可以高效分散任务的优点，但有很难准确管理任务的缺点。

参考图6，与如图5相同地，能看到在对应于0x1000的时间点1ms的t0时间上调用了用于bsw模块的schm_init()函数，且在对应于1cycle+0x6000的时间点22ms的t3时间上调用了用于asw模块的rte_start()函数。但是在图6中，与图5的情况不同地，在schm_init()函数和rte_start()函数中通过setrelalarm函数分别设定两个报警器。

首先，查看schm_init()函数，schm_init()函数的内部通过1)setrelalarm(alarm,0x7000,period)和、2)setrelalarm(alarm,0xa000,period)设定两个报警器。在relative方式中，schm_init()函数被调用的时间点影响发生报警器的时间点，因此以schm_init()函数被调用的时间点的0x1000值及作为offset参数而接受的0x7000值和0xa000值决定发生报警器的时间点。

即在relative方式中，只分配offset值是不够的，还需考虑函数被调用的时间点。具体地，根据在0x1000被调用的0x7000值的offset会在8ms的t1时间点上发生报警器，而根据0xa000，在11ms的t2时间点上发生报警器。并且，除了t1的时间点和t2的时间点以外，在每次的循环也会反复地发生报警器。

如果schm_init()函数中设定的两个报警器在每周期都反复，则虽然图6中未图示，在1)对应于n*cycle+0x8000的时间点n*16ms+8m和2)对应于n*cycle+0xb000的时间点n*16ms+11ms，都会发生用于bsw模块的报警器，并执行bsw任务。因此，用于asw模块的报警器需要在除了上述时间点之外的时间，即需要以除0x8000值和0xb000值以外的值来设定函数被调用的时间点和offset参数。这样才能分散任务。

查看rte_start()函数，能看到rte_start()函数的内部通过1)setrelalarm(alarm,0x1000,period)、2)setrelalarm(alarm,0x2000,period)设定两个报警器。其为relative方式，且作为offset参数，使用0x1000值和0x2000值，因此能看到很好地分散了offset参数其本身。但是，在relative方式中，只分散offset参数是无法分散任务的。

参考图6，rte_start()函数被调用的时间点为对应于1cycle+0x6000的时间点22ms的t3时间，这时的offset参数为0x1000和0x2000。函数被调用的时间点的计数器为0x6000且offset参数为0x1000和0x2000，因此当rte_start()函数被调用后，在对应于1cycle+0x6000+0x1000的时间点，即对应于1cycle+0x7000的时间点23ms的t4时间点上发生报警器，且在对应于1cycle+0x6000+0x2000的时间点，即对应于1cycle+0x8000的时间点24ms的t5时间点上发生报警器。即利用函数被调用的时间点的计数器和offset参数的值来决定发生报警器的时间点，因此，即使分散了offset参数，可能也会由于函数被调用的的时间点而发生报警器并未实现分散的现象。

即在schm_init()函数中是以0x7000和0xa000作为offset参数，在rte_start()函数中是以0x1000和0x2000作为offset参数，从而分散了offset参数。但schm_init()函数被调用的时间点是在0x1000，所以schm_init()函数在0x8000和0xb000发生报警器，而rte_start()函数被调用的时间点是在0x6000，所以在0x7000和0x8000发生报警器，使得报警器在0x8000发生偏重。

对于relative方式而言，函数被调用后，过去相当于offset值的时间后才会发生报警器，因此具有可以准确地预测发生报警器时间的优点。即不必担心报警器开始的时间点会延迟。但是有以下缺点：仅分散offset值无法分散报警器，并且还需考虑设定报警器的函数被调用的时间点才能分配任务。

换句话说，调用设定报警器的函数的同时还要考虑函数被调用的时间点和offset参数才能分散任务。这是因为其用于bsw模块的报警器是通过schm_init()函数来设定的，而用于asw模块的函数是在rte_start()中设定的。即在汽车开放系统架构操作系统中，根据模块设定报警器的时刻会不同，因此利用relative方式会有很难适当地分散任务的缺点。像这样，虽然relative方式具有准确地管理任务的优点，但具有很难高效地分散任务的缺点。

到目前为止，通过图5至图6，分析了联动于一个计数器(counter)且在不同的时刻分别对osalarm进行初始化(init)及开始(start)的汽车开放系统架构软件的动作结构中absolute方式和relative方式所具有的缺点。若用表格整理该内容，则如图7a和图7b所示。

图7a至图7b为用于说明根据现有的absolute方式和relative方式的任务分配的问题的表格。

图7a为整理图5的情况的表格，图7b为整理图6的情况的表格。参考图7a，用于bsw模块的schm_init()函数在计数器为0x1000时会被调用。此时，作为offset参数会接受0x7000和0xa000。为了便于理解以下内容，假定bsw模块在每周期都反复调用bsw任务，而且asw模块只调用一次asw任务。

在absolute方式中，根据offset值决定发生报警器的时间点，因此在offset为0x7000的情况下，在对用于ncycle+0x7000的每个时间点上发生报警器且执行任务，而在offset为0xa000的情况下，在对应于ncycle+0xa000的每个时间点上发生报警器且执行任务。即在0x7000的情况下，每7ms、16ms+7ms＝23ms、2*16ms+7ms＝39ms、……时执行任务，而在0xa000的情况下，每10ms、16ms+10ms＝26ms、2*16ms+10ms＝42ms、……时执行任务。

同样，用于asw模块的rte_start()函数在1cycle+0x6000时被调用。此时，作为offset参数会接受0x1000和0x2000。offset参数比函数被调用的时间的计数器0x6000更小，因此计数器发生一次溢出(overflow)后才会发生报警器。即发生报警器的时间点为对应于2cycle+0x1000的时间点33ms和对应于2cycle+0x2000的时间点34ms。

在absolute方式中，根据offset值决定发生报警器的时间点，因此为了分散用于bsw模块和asw模块的任务，仅不同地设定offset值就可以。在图7a，offset值分别不同地为0x7000、0xa000、0x1000、0x2000，因此执行任务的时间点不会重复。只不过，在asw模块的情况下，offset的值比函数被调用的时间的计数器0x6000小，因此能看到开始报警器被延迟的问题。

即在absolute方式中会发生很难准确地预测执行任务的时间点的问题。absolute方式是虽然易于任务的分散，但在任务的管理上有缺点的方式。实际上，在asw模块函数的调用是在1cycle+0x6000，但是任务的执行是在2cycle里进行，因此直到执行ostask为止会发生延迟，且其无法准确地把握上述延迟。这是因为在absolute方式中几乎不考虑函数被调用的时间。

同样，查看图7b，用于bsw模块的schm_init()函数在计数器为0x1000时会被调用。此时，作为offset参数会接受0x7000和0xa000。在relative方式中决定发生报警器的时间点时，会考虑函数被调用的时间和offset参数，因此在offset为0x7000的情况下，在对应于ncycle+(0x1000+0x7000)的每个时间点上发生报警器且执行任务，而offset为0xa000的情况下，在对应于ncycle+(0x1000+0xa000)的每个时间点上发生报警器且执行任务。即在0x7000的情况下，每1ms+7ms＝8ms、16ms+1ms+7ms＝24ms、2*16ms+1ms+7ms＝40ms、……时执行任务，而在0xa000的情况下，每1ms+10ms＝11ms、16ms+1ms+10ms＝27ms、2*16ms+1ms+10ms＝43ms、……时执行任务。

同样，用于asw模块的rte_start()函数在计数器为1cycle+0x6000时被调用。此时，作为offset参数会接受0x1000和0x2000。从函数被调用的时间点经过offset值后会发生报警器，因此发生报警器的时间点为对应于1cycle+0x6000+0x1000的时间点23ms和对应于1cycle+0x6000+0x2000的时间点24ms。

在relative方式中，从函数被调用的时间点经过offset值后发生报警器，因此不会出现报警器的延迟。即可以准确地预测发生报警器的时间点。但是，因考虑函数被调用的时间点和offset值而发生报警器，所以具有很难分散发生报警器的时间点的缺点。

即在relative方式中，存在很难分散任务的问题。relative方式是虽然利于任务的管理，但在任务的分散上存在缺点的方式。实际上，bsw模块的offset为0x7000、0xa000，而asw模块的offset为0x1000和0x2000，彼此不相同，但由于函数被调用的时间点分别为0x1000和1cycle+0x6000，因此能看到在24ms时，报警器发生偏重的情况。因此会发生无法高效地使用资源的情况。

到目前为止，分析了在通过现有的absolute方式和relative方式管理用于bsw模块和asw模块的任务的情况会发生的问题。这是因设定用于bsw模块的报警器的时间点和设定用于asw模块的报警器的时间互不相同而发生的问题。即汽车开放系统架构操作系统引入适当的offset，以避免ostask间的相互干涉，但即使使用absolute方式和relative方式中的任何一个，也难以在分散任务的同时高效地管理任务。

即使在不同的时刻osalarm被初始化及开始，也需要可以在分散任务的同时可以高效地管理任务的方法。为此，需要整合了absolute方式和relative方式的优点的新的方式。在本发明的一执行例提出了命名为自适应相对(adaptiverelative)osalarm的新方式。

本发明提出的adaptiverelative方式为如下方式：在schm_init()函数的调用时间点存储bsw模块中使用的计数器的值，之后在rte_start()函数的调用时间点将存储的计数器的值与当前的计数器的值进行比较来修改rte_start()函数中设定的报警器的offset。由此，即使bsw模块和asw模块在互不相同的时间点被调用，也可通过共享bsw模块被调用的时间点的计数器的值来将同步的offset引入一个时域(timedomain)。

图8为根据本发明一执行例的adaptiverelative方式的任务管理方法的流程图。

参考图8，设定bsw模块的报警器的时间点，即将schm_init()函数被调用的时间点的计数器值存储至称为counter_bsw的变量(s1000)。对于bsw模块的情况，无需修改offset，根据现有的relative方式设定发生报警器的时间点。

之后，随着时间的经过，将设定asw模块的报警器的时间点，即rte_start()函数的调用时间点的计数器值存储至称为counter_rte的变量(s2000)。对于asw模块的情况，不能直接使用offset，而是考虑bsw模块的报警器被设定的时间而进行修改。

为此，比较counter_rte值与计算后的值(counter_bsw+用于asw模块的rte_start()函数的offset值)(s3000)。如果比较这两个值来修改用于asw模块的rte_start()函数的offset值，则bsw模块和asw模块会在一个时阈中产生报警器。即利用relative方式的同时，也能显示与absolute方式相似的效果。

比较两个值后，如果counter_rte值比(counter_bsw+offset)大，则新的offset值可以使用cycle-((counter_rte-(counter_bsw+offset))％cycle)(s4000)。看公式能得知，其为考虑counter_rte的值和counter_bsw的值来修改offset，从而指定新的偏移的方式。由此，即使在不同的时刻设定用于bsw模块的报警器和用于asw模块的报警器，也能以与absolute相似的方式设定relative方式的报警器。

反之，如果counter_rte值比(counter_bsw+offset)小，则新的offset值可以使用cycle-(((counter_bsw+offset)-counter_rte)％cycle)(s5000)。比较步骤s4000和步骤s5000，则能得知最后是以counter_rte值和(counter_bsw+offset)值之差的绝对值为基准修改offset并算出新的offset。

如果将本发明的一执行例的、根据offset修改方法的adaptiverelative方式的任务分散方法适用于图7b的情况，能更确切地掌握差异点。先对修改的offset导致执行时间点如何变化进行分析，再确认由此实现负荷分散的过程。

图9为用于说明根据本发明一执行例的adaptiverelative方式的任务管理方法的表格。

参考图9，能看出初始的counter值和offset值为止都与图7b相同。只不过，增加了称作修改的offset值的项目，且由此可知，在relative方式下，吸收了absolute方式的优点。具体可参考以下内容。

首先，设定用于bsw模块的报警器的过程与图7b没有太大的区别。发生报警器的时间点也同样为1)ncycle+0x8000，为8ms、24ms、40ms、……；2)ncycle+0xb000，为11ms、27ms、43ms、……。即设定用于bsw模块的报警器的过程是相同的。只不过，在其过程中，将用于设定bsw模块的schm_init()函数被调用的时间点另行存储至变量。在图9的例子，计数器0x1000的值另行存储到名为counter_bsw的变量后，在调用用于asw模块的函数时使用。

查看设定用于asw模块的报警器的过程，rte_start()函数与图7b相同地，在1cycle+0x6000的时间点被调用。此时，参考schm_init()函数被调用的时间点counter_bsw的0x1000值来变更设定在rte_start()函数的报警器的offset。为此，将rte_start()函数被调用的时间点的计数器值0x6000的值存储到counter_rte变量。

接着，比较counter_rte的值和counter_bsw+offset值。首先，在offset为0x1000的情况下，counter_rte为0x6000，且counter_bsw+offset的值为0x1000+0x1000＝0x2000的值。即因counter_rte比counter_bsw+offset大，所以若将这两者之差的0x4000值从一个循环0xffff中去掉，则能获得0xc000的新的offset值。即offset的0x1000值更改为0xc000的值。通过相同的过程，0x2000的offset值会更改为0xd000的值。

利用新修改的offset值计算执行时间点，则如果1cycle+0x6000的rte_start()函数被调用的计数器值加上修改的offset值，分别会在对应于2cycle+0x2000的34ms和在对应于2cycle+0x3000的35ms发生用于asw模块的报警器。

与图7b的情况相比较，能看到用于asw模块的报警器在与用于bsw模块的报警器不同的时间点上发生。即使在不同的时刻执行用于bsw模块的schm_init()函数和用于asw模块的rte_start()函数，能够以与实行用于bsw模块的schm_init()函数时的计数器值0x1000为基准而适用relativie方式一样，能看到0x7000、0xa000、0x1000、0x2000的执行时间点被决定为0x8000、0xb000、0x2000、0x3000。

这样，通过以一个时域、以relative方式设定任务，具有可以准确地预测执行任务的时间点的同时、分散任务的执行时间点来高效地活用资源的效果。如上所述的方式即为在本发明的一执行例提出的adaptiverelative方式的报警器设定。

虽然上文中参照附图说明了本发明的执行例，本发明所属技术领域的技术人员清楚不更改本发明技术思想或者必不可少的特征，可以以其他具体的形态进行执行。因此，应理解为以上所述的执行例在所有的方面是示例性的，而不是限制性的。