车辆控制装置的制作方法

本发明涉及汽车、列车、升降机等运输机器等的所需功能多种多样的系统、组合了多种硬件、多种软件的大规模系统中的使用多核心处理器来控制系统的车辆控制装置。

背景技术：

在汽车、升降机、建筑机械等中使用了由所谓嵌入式软件来对控制对象进行控制的嵌入式控制装置。关于嵌入式软件，作为其优点，与现有的由机械机构和电路实现的方式相比，例如能够实现更灵活且先进的控制。

这样的嵌入式控制装置，例如在车辆的控制装置中，以减少车载空间和降低制造成本为目的，正在进行将以往搭载在不同的ecu(electroniccontrolunit：电子控制单元)中的功能集中至1个ecu的ecu统合。另外，在进行ecu统合时，考虑到需要在同一ecu中处理多个功能，因此开始对车辆控制装置应用多核心处理器。

多核心处理器不仅能够使用多个核心并行地实施不同的处理，而且在一部分核心故障的情况下，能够用其他核心代替处理对该核心分配的应用软件。由此，已知能够实现系统的冗余化，例如在专利文献1中有记载。

另外，在多核心处理器的一部分核心中检测出故障的情况下，通过仅使被检测出故障的核心重新起动，能够不使系统整体的功能停止就使故障的核心恢复。作为实现这一点的技术，已知按多核心处理器的每个核心动态变更运转/非运转的技术，例如在专利文献2中有记载。

但是，因为多核心处理器整体的处理能力存在上限，所以在一部分核心重新起动时，难以执行最初的所有应用软件。因此，要求被检测出故障的核心尽快地重新起动，执行原本的应用软件。

现有技术文献

专利文献

专利文献1：日本特开2007-154050号公报

专利文献2：日本特开2006-260568号公报

技术实现要素：

发明要解决的问题

图2是按多核心微型计算机的每个核心分配车载功能的例子。图2的核心1中运行adas(advanceddriverassistancesystems：高级驾驶辅助系统)功能，核心2中运行电动制动系统，核心n中运行通信功能。这样，通过用多核心处理器进行ecu的统合，能够用一个ecu来处理以往用不同的ecu处理的功能。

图3示出了在多核心微型计算机的核心1中检测出故障的情况下的核心重新起动的流程。图3(a)是在核心1中检测出异常的图。图3(b)是根据专利文献1，用核心2代替处理核心1中实施的adas功能的图。图3(c)是根据专利文献2，仅使核心1重新起动的图。

这样，通过使用多核心处理器，例如在一部分核心中检测出异常的情况下，也能够不使系统整体的功能停止而是继续工作，并恢复为原本的状态。

图3(a)、(b)、(c)中，因为用核心2运行核心1的adas功能，所以核心2的处理量大幅增加。因此，在核心中检测出异常的情况下，要求核心1尽可能快速地重新起动，恢复为原本的状态。但是，上述现有技术中没有进行关于核心的重新起动处理的研究。

根据以上所述，本发明的目的在于提供一种车辆控制装置，其在多核心处理器中的一部分核心中检测出异常的情况下，能够缩短被检测出异常的核心重新起动、再次执行应用软件所需的时间。

用于解决问题的技术手段

为了达成上述目的，本发明根据起动全部处理器核心的情况和重新起动全部处理器核心中的一部分的情况，具有不同的诊断处理的执行方法，在仅使一部分处理器核心重新起动的情况下，执行重新起动一部分处理器核心的情况下的诊断处理方法，由此缩短了一部分处理器核心重新起动所需的时间。特别是，在一部分处理器核心重新起动时的诊断处理中，其他处理器核心在重新起动的处理器核心执行软件诊断之前执行软件诊断，由此缩短了重新起动所需的时间。

发明效果

根据本发明，在仅使多核心处理器的一部分核心重新起动的情况下，能够缩短核心重新起动并执行应用软件所需的时间。

附图说明

图1是本发明的一个实施方式中的车辆控制装置的系统结构图。

图2是表示使用了多核心微型计算机的功能的并行处理的具体例的图。

图3是表示使用现有技术的情况下的、从在多核心微型计算机中检测出异常到核心重新起动的具体处理流程的图。

图4是表示从微型计算机起动到应用软件开始的一般例的流程图。

图5是表示提案方法中的从处理器核心起动到应用程序开始的具体例的流程图。

图6是表示提案方法中的一部分核心重新起动时软件诊断的具体例的图。

图7是表示提案方法中的存储区域的软件诊断进度的具体例的图。

图8是表示提案方法中的多个核心协作的情况下的、存储区域的软件诊断进度的具体例的图。

具体实施方式

以下参考附图说明本发明的一个实施方式。

图1是表示本发明的一个实施方式的车辆控制装置的系统结构的系统结构图。车辆控制装置1具有诊断单元101、诊断处理方法变更部102、电源ic103、多核心处理器104、存储区域105、诊断处理日志106。

此处，多核心处理器104具有多个核心10401、10402、10403。

此处，诊断单元101具有全部核心起动时使用的诊断单元即全部核心起动时用诊断单元10101、和一部分核心重新起动时使用的诊断单元即部分核心重新起动时用诊断单元10102。诊断处理方法变更部102在处理器核心起动时，在全部核心起动的情况下选择全部核心起动时用诊断单元10101，在一部分核心重新起动的情况下选择部分核心重新起动时用诊断单元10102。由此，缩短一部分核心重新起动并执行应用软件所需的时间。

图4是表示从微型计算机起动到应用程序开始的一般例的流程图。在步骤s1020101中处理开始。在步骤s1020102中微型计算机起动。在步骤s1020103中执行bist(built-inself-test：内建自测试)。在步骤s1020104中执行使用软件的诊断。在步骤s1020105中开始应用程序，在步骤s1020106中结束处理。

如图4所示，一般而言在微型计算机起动的情况下，首先执行电路(硬件)中嵌入的bist，之后执行使用软件的诊断。

此处，步骤s1020104中记载的软件诊断，例如指的是使用软件的以存储区域105为对象的ram诊断。具体而言，对存储区域105写入固定值，判断写入后读取的结果是否等于最初的固定值。由此，能够诊断存储区域105是否正常工作。此外，软件诊断也有使用校验的rom诊断和用故障注入进行的ecc(errorcheckandcorrect：错误检查和纠正)功能的诊断等。

图5是表示提案方法中的从处理器核心起动到应用程序开始的具体例的流程图。在步骤s1020201中处理开始。在步骤s1020202中核心起动。在步骤s1020203中，判断是否仅起动一部分处理器核心。“是”的情况即仅起动一部分处理器核心的情况下，前进至步骤s1020204，执行部分核心重新起动时用诊断单元10101。在步骤s1020204中执行部分核心起动时用的bist。在步骤s1020205中执行部分核心重新起动时用的软件诊断。在步骤s1020206中开始应用软件，在步骤s1020207中结束处理。另一方面，步骤s1020203中为“否”的情况即全部处理器核心起动的情况下，前进至步骤s1020208，执行全部核心起动时用诊断单元10102。在步骤s1020208中执行全部核心起动时用bist。在步骤s1020209中执行全部核心起动时用的软件诊断。在步骤s1020206中开始应用软件，在步骤s1020207中结束处理。

图6示出了使用提出技术的情况下的一部分核心重新起动时的软件诊断的具体例。图6中，示出了在核心1中检测出异常且运行部分核心重新起动时用诊断单元10101的状态。提案技术中，在检测出异常的核心1执行bist时，核心n先执行软件诊断，对诊断对象范围即核心1用存储区域进行诊断，由此能够缩短核心1开始应用软件前的时间。

图7示出了对存储区域10502进行软件诊断的情况下的进度管理。如图7所示，作为软件诊断的进度的管理方法，对诊断结束的范围的地址值进行记录管理，由此在诊断途中变更作业的情况下，也能够从之前的场所起继续软件诊断。

图8示出了多个核心协作的情况下的存储区域10503的软件诊断进度。如图8所示，例如用2个核心进行诊断的情况下，一个核心从低地址值起开始诊断，另一个核心从高地址值起开始诊断，由此能够进一步缩短诊断所需的时间。

符号说明

1：车辆控制装置，101：诊断单元，10101：全部核心起动时用诊断单元，10102：部分核心重新起动时用诊断单元，102：诊断处理方法变更部，103：电源ic，104：多核心处理器，10401、10402、10403：处理器核心，105、10501、10502、10503：存储区域，106：诊断处理日志。