一种驾驶舱平台

IPRDB

API 数据接口

专利申请

使用指引 chat嘟嘟

会员体验

联系我们

交流群

现在联系顾问~

一种驾驶舱平台
申请号	CN202210368109.5	申请日	2022-04-08	公开(公告)号	CN116932129A	公开(公告)日	2023-10-24
申请人	北京科软驰创科技中心(有限合伙);			发明人	王宏安; 冷昶; 王忠平; 章程; 彭华;
摘要	本申请提供一种具有通用性、可扩展性强、可靠性高的驾驶舱平台，平台包括至少一个第一处理器和至少一个第二处理器；每个第一处理器用于运行第一操作系统；第一操作系统为实时操作系统；第一操作系统上运行有用于按照预先设计生成硬实时任务的应用；每个第二处理器用于运行第二操作系统；第二操作系统为实时操作系统或通用操作系统；第二操作系统上运行有能够动态生成硬实时任务的应用、用于按照预先设计生成或动态生成软实时任务的应用和用于按照预先设计生成或动态生成非实时任务的应用；每个第一操作系统用于执行在本操作系统上运行的应用生成的硬实时任务；每个第二操作系统，用于执行在本操作系统上运行的应用生成的软实时任务和非实时任务。
权利要求	1.一种驾驶舱平台，其特征在于，所述驾驶舱平台包括多个处理器，所述多个处理器包括至少一个第一处理器和至少一个第二处理器；每个所述第一处理器，用于运行第一操作系统；所述第一操作系统为实时操作系统；所述第一操作系统上运行有用于按照预先设计生成硬实时任务的应用；每个所述第二处理器，用于运行第二操作系统；所述第二操作系统为实时操作系统或通用操作系统；所述第二操作系统上运行有用于按照预先设计生成或动态生成软实时任务的应用和按照预先设计生成或动态生成非实时任务的应用；每个所述第一处理器运行的第一操作系统，用于执行在本操作系统上运行的应用生成的硬实时任务；每个所述第二处理器运行的第二操作系统，用于执行在本操作系统上运行的应用生成的软实时任务和非实时任务。 2.如权利要求1所述的驾驶舱平台，其特征在于，所述至少一个第一处理器包括至少一个第一部分处理器和至少零个第二部分处理器；其中，每个所述第一部分处理器用于通过实时虚拟机监视器运行第一操作系统；每个所述第二部分处理器用于直接运行第一操作系统；每个所述第二处理器，用于通过实时虚拟机监视器运行第二操作系统。 3.如权利要求1所述的驾驶舱平台，其特征在于，所述第二操作系统上还运行有能够动态生成硬实时任务的应用；每个所述第二处理器运行的第二操作系统，还用于当检测到在本操作系统上运行的应用动态生成硬实时任务时，触发动态硬实时任务处理机制，以将当前生成的硬实时任务，按照预先设计发送至指定或任一所述第一处理器运行的第一操作系统中执行。 4.如权利要求3所述的驾驶舱平台，其特征在于，每个所述第一处理器运行的第一操作系统，还用于当接收到任一所述第二处理器上运行的第二操作系统发送的硬实时任务时，对接收到的硬实时任务进行准入控制，在确定接收到的硬实时任务能够被准入时，将接收到的硬实时任务插入任务队列中等待执行。 5.如权利要求3所述的驾驶舱平台，其特征在于，每个所述第一处理器运行的第一操作系统中，预先部署有本操作系统需要运行的硬实时任务的算法及其程序实现；每个所述第二处理器运行的第二操作系统中，预先部署有本操作系统需要运行的软实时任务的算法及其程序实现，非实时任务的算法及其程序实现，以及硬实时任务的算法及其程序实现。 6.如权利要求3所述的驾驶舱平台，其特征在于，所述第二操作系统上运行的用于动态生成硬实时任务的应用，是第三方应用。 7.如权利要求1‑6任一项所述的驾驶舱平台，其特征在于，每个所述第一处理器运行的第一操作系统，还用于当通过准入控制确定当前系统资源不足时，触发迁移硬实时任务处理机制，以将本操作系统中的部分待执行的硬实时任务，按照预先设计发送至指定或任一所述第二处理器运行的第二操作系统中执行。 8.如权利要求7所述的驾驶舱平台，其特征在于，每个所述第二处理器运行的第二操作系统，还用于当接收到任一所述第一处理器上运行的第一操作系统发送的硬实时任务时，挂起本操作系统内的非硬实时任务，并调度执行接收到的硬实时任务，在所述接收到的硬实时任务执行完毕后恢复执行所述非硬实时任务。 9.如权利要求1‑6任一项所述的驾驶舱平台，其特征在于，每个所述第一处理器运行的第一操作系统，还用于当通过准入控制确定本操作系统资源不足时，检查其他第一处理器运行的第一操作系统的负载，将本操作系统中的部分待执行的硬实时任务，按照预先设计发送至目标第一处理器运行的第一操作系统中执行，所述目标第一处理器是指当前资源足够且预先部署有所述待执行的硬实时任务的算法及其程序实现的其他第一处理器。 10.如权利要求1所述的驾驶舱平台，其特征在于，每个所述第一处理器运行的第一操作系统中安装有实时的基础软件；每个所述第二处理器运行的第二操作系统中安装有实时或通用的基础软件；所述基础软件包括数据库和数据协同管理服务。
说明书全文	一种驾驶舱平台技术领域 [0001] 本申请涉及实时任务调度与控制技术领域，特别是涉及一种驾驶舱平台。背景技术 [0002] 为解决各类工业生产、企业管理、驾驶控制中存在的装配计划不合理、动态调度困难、过程监控和信息管理手段缺乏等问题，有效获取现场实时运行信息，提高管理控制的透明化程度，许多领域基于自身行业特点进行了驾驶舱技术的研究。设置驾驶舱能够实现由一个集中控制平台将整个大系统的信息有序化，为驾驶员提供集中监控和操作的平台，实现更科学、准确地决策与控制。 [0003] 近些年，在生产车间、电力系统等领域中都开展了单领域、面向应用的运行驾驶舱研究。针对数据异构、海量信息、单功能系统整合和指标系统标准化等问题进行了技术研究和方案设计。在纯驾驶控制领域，无人驾驶、智能驾驶等离生活越来越近。智能化驾驶舱技术进一步提高了驾驶的可靠性，呈现给驾驶员更清晰、准确的数据和方案，实现简便、快捷、科学的驾驶控制。 [0004] 实时调度与控制方法是智能驾驶舱的关键基础技术，对于实现数据信息实时分析、系统精确控制十分重要。一个大系统中的资源任务调度分配也需要实时调度与控制方法的支持。 [0005] 实时系统要求保证任务执行的逻辑正确和时间正确。即为每个任务设置截止期，使用有限的资源，尽可能保证每个任务在截止期内完成。根据任务的重要性，可以将实时任务分为硬实时任务和软实时任务。硬实时任务需要确保其在截止期内被完成，否则可能会导致灾难性结果，超时的硬实时任务即使完成也失去意义；软实时任务允许一定的超时行为，在尽可能满足截止期的前提下，即使超时完成也有一定的意义。 [0006] 为满足实时任务的截止期约束，需要在执行实时任务的系统中设置准入控制机制，其关键是：当新任务到达系统时，对系统的可调度性进行判定，如果新任务不会导致系统出现截止期错失现象，则准入新任务，否则拒绝新任务。 [0007] 现有的驾驶舱技术多针对某一领域提出各种面向具体应用的设计方案。使得现有工作更关注满足上层应用需求，一定程度上忽略了底层基础设计及系统可靠性。总体而言，现有驾驶舱缺乏通用性强的平台方案，难以实现实用性强的硬/软实时任务混合调度。此外，定制化研发驾驶舱的传统思路大大增加了研发成本，限制了驾驶舱的广泛应用。发明内容 [0008] 本申请实施例针对上述不足或缺点，提供了一种具有通用性、可扩展性强、可靠性高的驾驶舱平台，通过该驾驶舱平台可以更好地满足驾驶舱的硬/软实时任务混合调度需求，适应各类驾驶舱的研发需要，从而在提高驾驶舱实时智能能力的同时降低其研发成本。 [0009] 本申请提供了一种驾驶舱平台，在一个实施例中，该驾驶舱平台包括多个处理器，该多个处理器包括至少一个第一处理器和至少一个第二处理器； [0010] 每个第一处理器，用于运行第一操作系统；第一操作系统为实时操作系统；第一操作系统上运行有用于按照预先设计生成硬实时任务的应用； [0011] 每个第二处理器，用于运行第二操作系统；第二操作系统为实时操作系统或通用操作系统；第二操作系统上运行有用于按照预先设计生成或动态生成软实时任务的应用和按照预先设计生成或动态生成非实时任务的应用； [0012] 每个第一处理器运行的第一操作系统，用于执行在本操作系统上运行的应用生成的硬实时任务； [0013] 每个第二处理器运行的第二操作系统，用于执行在本操作系统上运行的应用生成的软实时任务和非实时任务。 [0014] 在一个实施例中，该至少一个第一处理器包括至少一个第一部分处理器和至少零个第二部分处理器；其中，每个第一部分处理器用于通过实时虚拟机监视器运行第一操作系统；每个第二部分处理器用于直接运行第一操作系统； [0015] 每个第二处理器，用于通过实时虚拟机监视器运行第二操作系统。 [0016] 在一个实施例中，第二操作系统上还运行有能够动态生成硬实时任务的应用； [0017] 每个第二处理器运行的第二操作系统，还用于当检测到在本操作系统上运行的应用动态生成硬实时任务时，触发动态硬实时任务处理机制，以将当前生成的硬实时任务，按照预先设计发送至指定或任一第一处理器运行的第一操作系统中执行。 [0018] 在一个实施例中，每个第一处理器运行的第一操作系统，还用于当接收到任一第二处理器上运行的第二操作系统发送的硬实时任务时，对接收到的硬实时任务进行准入控制，在确定接收到的硬实时任务能够被准入时，将接收到的硬实时任务插入任务队列中等待执行。 [0019] 在一个实施例中，每个第一处理器运行的第一操作系统中，预先部署有本操作系统需要运行的硬实时任务的算法及其程序实现； [0020] 每个第二处理器运行的第二操作系统中，预先部署有本操作系统需要运行的软实时任务的算法及其程序实现，非实时任务的算法及其程序实现，以及硬实时任务的算法及其程序实现。 [0021] 在一个实施例中，第二操作系统上运行的能够动态生成硬实时任务的应用，是第三方应用。 [0022] 在一个实施例中，每个第一处理器运行的第一操作系统，还用于当通过准入控制确定当前系统资源不足时，触发迁移硬实时任务处理机制，以将本操作系统中的部分待执行的硬实时任务，按照预先设计发送至指定或任一第二处理器运行的第二操作系统中执行。 [0023] 在一个实施例中，每个第二处理器运行的第二操作系统，还用于当接收到任一第一处理器上运行的第一操作系统发送的硬实时任务时，挂起本操作系统内的非硬实时任务，并调度执行接收到的硬实时任务，在接收到的硬实时任务执行完毕后恢复执行非硬实时任务。 [0024] 在一个实施例中，每个第一处理器运行的第一操作系统，还用于当通过准入控制确定本操作系统资源不足时，检查其他第一处理器运行的第一操作系统的负载，将本操作系统中的部分待执行的硬实时任务，按照预先设计发送至目标第一处理器运行的第一操作系统中执行，目标第一处理器是指当前资源足够且预先部署有上述待执行的硬实时任务的算法及其程序实现的其他第一处理器。 [0025] 在一个实施例中，每个第一处理器运行的第一操作系统中安装有实时的基础软件； [0026] 每个第二处理器运行的第二操作系统中安装有实时或通用的基础软件； [0027] 基础软件包括数据库和数据协同管理服务。 [0028] 本申请在上述实施例中，提供了一种具有通用性、可扩展性强、可靠性高的驾驶舱平台(以下简称平台)。 [0029] 首先，本申请实施例将平台分为负责处理硬实时任务的硬实时组和主要负责软实时任务和非实时任务的非硬实时组部分。通过以上划分，可以将硬实时任务的运行与其他任务的运行分离，有利于保证系统安全。具体地，本申请实施例将平台中的处理器分为硬实时组的处理器(以下称为第一处理器)和非硬实时组的处理器(以下称为第二处理器)，第一处理器用于运行第一操作系统，第一操作系统为实时操作系统，并且第一操作系统上运行的应用需要按照预先设计生成硬实时任务，生成的硬实时任务会由本操作系统执行；第二处理器用于运行第二操作系统，第二操作系统既可以是实时操作系统，也可以是通用操作系统，第二操作系统上运行的应用既可以按照预先设计生成软实时任务或非实时任务，也可以动态生成软实时任务或非实时任务，生成的软实时任务和非实时任务会由本操作系统执行。 [0030] 其次，本申请实施例还提供了基于准入控制的用于调度、控制硬实时任务的机制，通过该机制能够保障硬实时任务在硬实时组和非硬实时组之间安全地跨越，从而实现合理利用全平台资源，保障硬实时任务运行的目的。其中，该机制具体包括动态硬实时任务处理机制和迁移硬实时任务处理机制。通过动态硬实时任务处理机制，可以允许非硬实时组的应用(具体是第二操作系统中的应用)动态生成硬实时任务，并将动态生成的硬实时任务安全地从非硬实时组跨越到硬实时组(具体是将硬实时任务从第二操作系统发送到第一操作系统中执行)。通过迁移硬实时任务处理机制，可以允许硬实时组的第一操作系统在资源不足时将硬实时任务发送到非硬实时组的第二操作系统，以利用非硬实时组资源执行硬实时任务。 [0031] 再次，本申请实施例提供的驾驶舱平台对于硬件平台的参数等不敏感，可以容易地扩展到大规模分布式系统。 [0032] 综上所述，本申请实施例提供的驾驶舱平台，能够适应各类需要运行硬实时任务、软实时任务和非实时任务的驾驶舱的研发需要，利用本驾驶舱平台能够实现可靠的实时调度与控制，有效提高驾驶舱的实时性、可靠性，并且，利用本驾驶舱平台研发驾驶舱时，无需从底层重新设计，进而能够在提高驾驶舱实时智能能力的同时，降低驾驶舱的研发成本。附图说明 [0033] 图1为一个实施例中的动态硬实时任务处理机制示意图； [0034] 图2为一个实施例中的迁移硬实时任务处理机制示意图； [0035] 图3为一个实施例中驾驶舱平台的架构示意图； [0036] 图4为一个实施例中驾驶舱平台中进行实时调度与控制的示意图。具体实施方式 [0037] 为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅用以解释本申请，并不用于限定本申请。 [0038] 本申请提供了一种驾驶舱平台(也可称为一种驾驶舱架构)。在一个实施例中，该驾驶舱平台包括多个处理器(核)，该多个处理器包括至少一个第一处理器和至少一个第二处理器； [0039] 每个第一处理器，用于运行第一操作系统；第一操作系统为实时操作系统；第一操作系统上运行有用于按照预先设计生成硬实时任务的应用； [0040] 每个第二处理器，用于运行第二操作系统；第二操作系统为实时操作系统或通用操作系统；第二操作系统上运行有用于按照预先设计生成或动态生成软实时任务的应用和按照预先设计生成或动态生成非实时任务的应用； [0041] 每个第一处理器运行的第一操作系统，用于执行在本操作系统上运行的应用生成的硬实时任务； [0042] 每个第二处理器运行的第二操作系统，用于执行在本操作系统上运行的应用生成的软实时任务和非实时任务。 [0043] 在本实施例中，将驾驶舱平台(以下简称平台)中包括的处理器分为硬实时组的处理器(以下称为第一处理器)和非硬实时组的处理器(以下称为第二处理器)。其中，平台包括至少一个第一处理器和至少一个第二处理器。 [0044] 上述的第一处理器用于运行第一操作系统，第一操作系统是指通过第一处理器运行的操作系统。在本实施例中，第一操作系统必须为实时操作系统，比如是VxWorks(指美国公司Wind River System推出的一个实时操作系统)，并且第一操作系统上运行的应用需要按照预先设计生成硬实时任务，生成的硬实时任务会由本操作系统执行。 [0045] 上述的第二处理器用于运行第二操作系统，第二操作系统是指通过第二处理器运行的操作系统。在本实施例中，第二操作系统既可以是实时操作系统，也可以是通用操作系统，比如Linux操作系统、Windows操作系统等，第二操作系统上运行的应用既可以按照预先设计生成软实时任务或非实时任务，也可以动态生成软实时任务或非实时任务，生成的软实时任务和非实时任务会由本操作系统执行。 [0046] 还需要说明的是，每个第一处理器运行的第一操作系统中，预先部署有本操作系统需要运行的硬实时任务的算法及其程序实现；每个第二处理器运行的第二操作系统中，预先部署有本操作系统需要运行的软实时任务的算法及其程序实现，非实时任务的算法及其程序实现，以及硬实时任务的算法及其程序实现。 [0047] 本实施例将平台分为负责处理硬实时任务的硬实时组和主要负责软实时任务和非实时任务的非硬实时组部分。通过以上划分，可以将硬实时任务的运行与其他任务的运行分离，有利于保证系统安全。 [0048] 进一步地，硬实时组和非硬实时组的操作系统中均需安装基础软件，需要说明的是，操作系统也是基础软件，因而这里的基础软件是指操作系统之外的基础软件，这里的基础软件可以包括但不限于数据库、数据协同管理服务(或是通信服务)等软件，其中，硬实时组的第一操作系统上必须安装实时的基础软件，如实时数据库、实时数据协同管理服务等；非硬实时组的第二操作系统上即可以安装实时的基础软件，也可以安装非实时的基础软件，如通用数据库、通用数据协同管理服务等。 [0049] 在一个实施例中，上述的第一处理器用于通过实时虚拟机监视器运行第一操作系统。上述的第二处理器用于通过实时虚拟机监视器运行第二操作系统。其中，实时虚拟机监视器(real‑time hypervisor)，用于对硬件资源进行分配、管理和虚拟化等处理，可以使用RT‑XEN、XtratuM、ACRN等产品来实现实时虚拟机监视器。让非硬实时组中的全部处理器通过实时虚拟机监视器运行操作系统的优势在于，实时虚拟机监视器可以从底层统一分配和管理硬件资源，从而实现硬件资源的高效利用，它既可以用于支持第一处理器中的硬实时任务，尤其是动态生成的硬实时任务，也可以用于支持第二处理器上运行的软实时任务和非实时任务。 [0050] 在另一个实施例中，可以将平台中的第一处理器分为两部分，其中一部分第一处理器(本实施例将这一部分称为第一部分处理器)用于通过实时虚拟机监视器运行第一操作系统，另一部分第一处理器(本实施例将这一部分称为第二部分处理器)用于直接运行第一操作系统，其中，第二部分处理器的数量可以为零，此时表示平台中的第一处理器均用于通过实时虚拟机监视器运行第一操作系统。让硬实时组中的部分处理器直接运行操作系统有以下优势：(1)对于至关重要(如关系生命、财产安全)的任务，由处理器直接运行操作系统及应用，更加有利于在系统设计阶段完成安全性的验证分析；(2)它们与实时虚拟机监视器管理的资源相互隔离，可相对独立地设计和运行；(3)许多现有系统采用处理器直接运行操作系统的模式，这样设计可以兼容现有的应用模式。 [0051] 在一个实施例中，上述的第二操作系统上还运行有能够动态生成硬实时任务的应用。其中，第二操作系统上运行的能够动态生成硬实时任务的应用，是第三方应用。相应地，每个第二处理器运行的第二操作系统，还用于当检测到在本操作系统上运行的应用动态生成硬实时任务时，触发动态硬实时任务处理机制，以将当前生成的硬实时任务，按照预先设计发送至指定或任一第一处理器运行的第一操作系统中执行。其中，指定的第一处理器运行的第一操作系统可以根据实际需要灵活调整，在一个可能的实施方式中，指定的第一处理器运行的第一操作系统可以是指当前负载最小的第一处理器运行的第一操作系统。 [0052] 相应地，每个第一处理器运行的第一操作系统，还用于当接收到任一第二处理器上运行的第二操作系统发送的硬实时任务时，对接收到的硬实时任务进行准入控制，在确定接收到的硬实时任务能够被准入时，将接收到的硬实时任务插入任务队列中等待执行。 [0053] 本实施例在驾驶舱平台中设置了动态硬实时任务处理机制。通过动态硬实时任务处理机制，可以允许非硬实时组的应用(具体是第二操作系统中的应用)动态生成硬实时任务，并将动态生成的硬实时任务安全地从非硬实时组跨越到硬实时组(具体是将硬实时任务从第二操作系统发送到第一操作系统中执行)。 [0054] 示例性地，在一个示例中，本示例允许在非硬实时组动态生成硬实时任务。为保证硬实时任务能够安全地从非硬实时组跨越到硬实时组，设立动态硬实时任务处理机制，请参见图1，该机制包括以下步骤： [0055] 1)非硬实时组中的第二操作系统os_a，运行有应用app_1，应用app_1动态生成硬实时任务task_a。 [0056] 2)第二操作系统os_a在检测到应用app_1生成硬实时任务task_a之后，产生相应的硬实时任务请求request_a，并将硬实时任务task_a的指令、参数等信息封装为硬实时任务请求消息message_a，之后其发送给硬实时组中的第一操作系统os_b。 [0057] 3)第一操作系统os_b对接收到的硬实时任务请求消息message_a进行消息解析，以还原硬实时任务请求request_a。 [0058] 4)第一操作系统os_b响应于硬实时任务请求request_a对硬实时任务task_a进行准入控制，如果确定系统资源足够，则通知调度器进行处理，利用本地已部署的硬实时任务task_a的算法algo_a，将硬实时任务task_a激活并插入任务队列中等待执行。 [0059] 在一个实施例中，每个第一处理器运行的第一操作系统，还用于当通过准入控制确定当前系统资源不足时，检查其他第一处理器运行的第一操作系统的负载，将本操作系统中的部分待执行的硬实时任务，按照预先设计发送至目标第一处理器运行的第一操作系统中执行。其中，目标第一处理器是指当前资源足够且预先部署有上述待执行的硬实时任务的算法及其程序实现的其他第一处理器，目标第一处理器可以根据实际需要灵活调整，在一个可能的实施方式中，可以根据需迁移的待执行硬实时任务，遍历所有迁移方案并从中选择一个可行的迁移方案。 [0060] 在另一个实施例中，每个第一处理器运行的第一操作系统，还用于当通过准入控制确定当前系统资源不足时，触发迁移硬实时任务处理机制，以将本操作系统中的部分待执行的硬实时任务，按照预先设计发送至指定或任一第二处理器运行的第二操作系统中执行。其中，指定的第二处理器运行的第二操作系统可以根据实际需要灵活调整，在一个可能的实施方式中，指定的第二处理器运行的第二操作系统可以是指当前负载最小的第二处理器运行的第二操作系统。还需要说明的是，上述的当前系统可以是指本操作系统，还可以是指所有第一处理器运行的第一操作系统，也就是说，在一种可能的情况下，每个第一处理器运行的第一操作系统在通过准入控制确定本操作系统资源不足时，即通过迁移硬实时任务处理机制将本操作系统中的部分待执行的硬实时任务迁移到非硬实时组中进行处理，而在另一种可能的情况下，每个第一处理器运行的第一操作系统在预先设计无法给出可行的迁移方案时，才通过迁移硬实时任务处理机制将部分待执行的硬实时任务迁移到非硬实时组中进行处理，在这种情况下，第一处理器运行的第一操作系统，通过准入控制确定本操作系统资源不足，此时先按照预先设计确定是否存在可行的迁移方案。其中，上述可行的迁移方案是指当前系统中是否存在用于处理上述部分待执行的硬实时任务的目标第一处理器。 [0061] 如果存在的话，则将本操作系统中的部分待执行的硬实时任务，发送至目标第一处理器运行的第一操作系统中执行，其中，上述目标第一处理器中包含的其他第一处理器的数量可以一个，也可以是多个，上述部分待执行的硬实时任务的数量可以大于或等于目标第一处理器包含的其他第一处理器的数量，还应理解的是，上述部分待执行的硬实时任务中的任一个硬实时任务，只会被发送至一个其他第一处理器中执行，不会存在两个甚至更多的其他第一处理器同时处理一个硬实时任务的情况。 [0062] 目标第一处理器满足以下两个条件，即(1)预先部署有上述部分待执行的硬实时任务的算法及其程序实现，(2)资源足够处理上述部分待执行的硬实时任务。 [0063] 当目标第一处理器包含的其他第一处理器的数量为一个时，目标第一处理器包含的这一个其他第一处理器预先部署有上述部分待执行的硬实时任务的算法及其程序实现，并且资源足够处理上述部分待执行的硬实时任务。 [0064] 当目标第一处理器包含的其他第一处理器的数量为多个时，这些其他第一处理器作为一个整体满足上面两个条件。具体地，此时相当于将上述部分待执行的硬实时任务分配给目标第一处理器包含的各其他第一处理器，应理解此时，各其他第一处理器满足以下条件，即(a)资源足够处理分配到的硬实时任务，(b)已部署了分配到的硬实时任务的算法及其程序实现。 [0065] 以上述部分待执行的硬实时任务的数量等于目标第一处理器包含的其他第一处理器的数量为例，假设该数量为2，如果需要将硬实时任务T1、T2分别分配给其他第一处理器P1、P2，那么P1应已部署了用于处理T1的算法及其程序实现，以及当前资源足够处理T1，同理，P2应已部署了用于处理T2的算法及其程序实现，以及当前资源足够处理T2。 [0066] 以上述部分待执行的硬实时任务的数量大于目标第一处理器包含的其他第一处理器的数量为例，假设硬实时任务的数量为3，其他第一处理器的数量为2，如果需要将硬实时任务T1、T2分配给其他第一处理器P1，将硬实时任务T3分配给其他第一处理器P2，那么P1应已部署了用于处理T1和T2的算法及其程序实现，以及当前资源足够处理T1和T2，同理，P2应已部署了用于处理T3的算法及其程序实现，以及当前资源足够处理T3。 [0067] 如果不存在的话，则判定当前系统资源不足，此时即触发迁移硬实时任务处理机制。 [0068] 相应地，每个第二处理器运行的第二操作系统，还用于当接收到任一第一处理器上运行的第一操作系统发送的硬实时任务时，挂起本操作系统内的非硬实时任务，并调度执行接收到的硬实时任务，在接收到的硬实时任务执行完毕后恢复执行非硬实时任务。 [0069] 本实施例在驾驶舱平台中设置了迁移硬实时任务处理机制，通过迁移硬实时任务处理机制，可以允许硬实时组的第一操作系统在资源不足时将硬实时任务发送到非硬实时组的第二操作系统，以利用非硬实时组资源执行硬实时任务，并且能保障硬实时组的第一操作系统将生成的硬实时任务安全地从硬实时组跨越到非硬实时组。 [0070] 示例性地，在一个示例中，本示例允许在硬实时组中的第一操作系统在发现系统资源不足时，迁移部分硬实时任务至非硬实时组以避免安全风险。为保证硬实时任务能够安全地从硬实时组跨越到非硬实时组，设立迁移硬实时任务处理机制，请参见图2，该机制包括以下步骤： [0071] 1)硬实时组中的第一操作系统os_c通过准入控制发现系统资源不足。 [0072] 2)第一操作系统os_c从待执行的硬实时任务中选择需要迁移的硬实时任务，假设选择了硬实时任务task_b，可理解的，被迁移任务task_b的算法algo_b应已在非硬实时组中部署。 [0073] 3)第一操作系统os_c生成硬实时任务task_b相应的硬实时任务请求request_b，并将硬实时任务task_b的指令、参数等信息封装为迁移硬实时任务请求消息message_b，之后将其发送给非硬实时组中的第二操作系统os_d。 [0074] 4)第二操作系统os_d对接收到的迁移硬实时任务请求消息message_b进行消息解析以还原硬实时任务请求request_b。 [0075] 5)第二操作系统os_d挂起本操作系统当前的非硬实时任务(包括软实时任务和非实时任务)，并调度执行硬实时任务task_b。 [0076] 6)当硬实时任务task_b执行完毕后，第二操作系统os_d恢复执行之前挂起的非硬实时任务。为了更方便理解上述实施例，本申请还提供了一个具体应用的实施例(以下简称为应用例)。 [0077] 本应用例结合驾驶舱使用场景，提供了一种驾驶舱平台(下面简称为平台)，如图3所示，该平台分为硬件层、实时虚拟监视层、基础软件层和应用层四层。下面对上述各层进行介绍。 [0078] 硬件层，配有多个处理器(核)的硬件，包括但不限于各种嵌入式计算机。硬件层中的全部处理器中，一部分用于支持平台中硬实时组的运行，另一部分用于支持平台非硬实时组的运行。 [0079] 实时虚拟监视层，是连接硬件层和基础软件层的桥梁。除部分硬实时组的处理器直接运行操作系统等基础软件和应用外，平台其他处理器均通过实时虚拟监视层为上层软件管理分配处理器资源。 [0080] 基础软件层，包含支持应用运行的基础软件，如操作系统、数据库、数据协同管理服务等。 [0081] 应用层，包含根据应用场景需要而设置的应用，应用会生成相应的任务，如硬实时任务、软实时任务和非实时任务。 [0082] 具体地，请参见图4，本应用例提供的平台共拥有4个处理器核P1、P2、P3和P4；P1和P2属于硬实时组，P3和P4属于非硬实时组。P1直接运行硬实时组的实时操作系统VxWorks。P2、P3和P4通过实时虚拟监视层为上层软件管理分配处理器资源，其中P2用于支持运行硬实时组的实时操作系统FreeRTOS，P3和P4用于支持运行非硬实时组的非实时操作系统Linux和Windows。实时操作系统VxWorks上安装了实时数据库及实时数据协同管理服务，运行应用APP1。实时操作系统FreeRTOS上安装了实时数据库及实时数据协同管理服务，运行应用APP2。非实时操作系统Linux上安装了实时数据库及通用数据协同管理服务，运行应用APPa。非实时操作系统Windows上安装了通用数据库及通用数据协同管理服务，运行应用APPb。 [0083] APP1、APP2和APPa对应的任务按照平台预先的设计产生。APPb会动态生成硬实时任务，且这些硬实时任务的算法已部署在硬实时组的实时操作系统FreeRTOS内。可能被迁移的硬实时任务的算法已部署在非硬实时组的非实时操作系统Linux内。 [0084] 在系统运行期间，APPb持续动态生成硬实时任务。每个动态生成的硬实时任务都需要通过动态硬实时任务处理机制进行控制，请参见图1，动态硬实时任务处理机制的执行过程可以如下所示： [0085] 1)APPb动态生成硬实时任务。 [0086] 2)APPb对应的操作系统Windows产生硬实时任务请求，并将该硬实时任务的指令、参数等信息封装为硬实时任务请求消息，之后发送给FreeRTOS操作系统。 [0087] 3)FreeRTOS接收到硬实时任务请求消息，进行消息解析还原硬实时任务请求。 [0088] 4)FreeRTOS响应于该硬实时任务请求，进行准入控制，如果系统资源足够则通知调度器进行处理，利用本地已部署的算法将硬实时任务激活并插入任务队列中。 [0089] 当FreeRTOS发现资源不足时，将激活迁移硬实时任务处理机制，请参见图2，迁移硬实时任务处理机制的执行过程可以如下所示： [0090] 1)FreeRTOS通过准入控制发现系统资源不足。 [0091] 2)FreeRTOS选择需要迁移的任务，被迁移任务的算法应已在Linux上部署。 [0092] 3)生成硬实时任务请求，将需迁移的硬实时任务的指令、参数等信息封装为迁移硬实时任务请求消息并发送给Linux操作系统。 [0093] 4)Linux操作系统收到迁移硬实时任务请求消息，进行消息解析还原硬实时任务请求。 [0094] 5)Linux操作系统响应于该硬实时任务请求，挂起非硬实时任务，调度执行硬实时任务。 [0095] 6)当硬实时任务执行完毕后，Linux操作系统恢复执行非硬实时任务。 [0096] 本领域普通技术人员可以理解实现上述方法实施例中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)、直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。 [0097] 以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。 [0098] 以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。