车辆的功能安全监控方法、装置、车辆及存储介质与流程

1.本技术涉及车辆功能安全技术领域，特别涉及一种车辆的功能安全监控方法、装置、车辆及存储介质。


背景技术：

2.随着车辆行业向着新四化的高速发展，整车软件功能迭代更新频率越来越高。为适用软件功能高速更新的需要，整车厂已经逐步将soa(service-oriented architecture，面向服务架构)的思想引入整车功能开发，并通过软件的方式实现，实现各个服务化功能的解耦，提高开发效率。同时，新四化的发展，使得整车内部的机械零件越来越少，电子电器零件急剧增加，这也使得电子电器出现故障的概率增加，影响整车安全。因此，整车厂在开发各个功能时，均会考虑引入功能安全，并且对带有功能安全等级的电子电器提出整车的满足安全目标和安全状态。
3.相关技术中，针对车辆的功能安全策略，一般是将被监控功能模块(无功能安全等级要求)的输入、输出信号接入监控模块(有功能安全等级要求)，实现整个控制软件达到需要的功能安全等级要求。
4.然而，在soa的架构下，是通过服务的方式进行信息的传递，相关技术中的使用信号的方式不一定适用于soa架构，亟待解决。


技术实现要素：

5.本技术提供一种车辆的功能安全监控方法、装置、车辆及存储介质，由此，解决了基于soa架构下开发的软件不能满足功能安全等级要求等问题，使整车能达到安全状态和安全目标。
6.本技术第一方面实施例提供一种车辆的功能安全监控方法，所述车辆包括面向服务的soa架构，所述soa架构包括主功能服务层，功能安全服务层和功能抽象服务层，方法包括以下步骤：通过所述功能安全服务层接收车辆的当前场景信息、用户请求、智驾请求和所述主功能服务层发出的主功能服务请求；基于所述当前场景信息判断当前场景是否为危害场景，并判断所述用户请求或所述智驾请求是否与所述主功能服务请求一致；若所述当前场景为所述危害场景，且所述用户请求或所述智驾请求与所述主功能服务请求不一致，则判断在最大允许故障时间内是否出现所述用户请求或所述智驾请求与所述主功能服务请求一致的情况，并在出现所述用户请求或所述智驾请求与所述主功能服务请求一致的情况时，将所述主功能服务请求透传至所述功能抽象服务层。
7.根据上述技术手段，由此，解决了基于soa架构下开发的软件不能满足功能安全等级要求等问题，使整车能达到安全状态和安全目标。
8.进一步地，上述的车辆的功能安全监控方法，还包括：若所述当前场景不是所述危害场景，和/或，所述用户请求或所述智驾请求与所述主功能服务请求一致，则直接将所述主功能服务请求透传至所述功能抽象服务层。
9.根据上述技术手段，通过直接将主功能服务请求透传至功能抽象服务层，减少了信息传递的时间，提高车辆的安全性。
10.进一步地，在通过所述功能安全服务层接收所述车辆的当前场景信息、所述用户请求、所述智驾请求和所述主功能服务层发出的主功能服务请求之前，还包括：判断所述车辆的驱动设备是否存在异常；若所述车辆的驱动设备不存在异常，则通过所述功能安全服务层接收所述车辆的当前场景信息、所述用户请求、所述智驾请求和所述主功能服务层发出的主功能服务请求。
11.根据上述技术手段，判断车辆的驱动设备是否异常，便于功能安全层接收车辆的信息与请求，提高车辆安全性的检测。
12.进一步地，上述的车辆的功能安全监控方法，还包括：在所述车辆的驱动设备存在异常，或者，在出现所述用户请求或所述智驾请求与所述主功能服务请求一致的情况时，控制所述车辆进入安全状态；判断所述安全状态是否可恢复；若所述安全状态可恢复，则重新判断所述车辆的驱动设备是否存在异常，否则，维持所述车辆处于所述安全状态。
13.根据上述技术手段，通过判断安全状态是否可恢复，提高车辆的安全性。
14.进一步地，所述最大允许故障时间由功能安全服务层通过故障容错时间间隔ftti(fault tolerant time interval，最大允许故障时间)分解所述用户请求或所述智驾请求与所述主功能服务请求获得。
15.根据上述技术手段，最大允许故障时间指不使驾驶员处于危险情况下的更正时间，避免车辆出现故障而驾驶员无法察觉的情况。
16.本技术第二方面实施例提供一种车辆的功能安全监控装置，所述车辆包括面向服务的soa架构，所述soa架构包括主功能服务层，功能安全服务层和功能抽象服务层，其中，所述装置包括：接收模块，用于通过所述功能安全服务层接收车辆的当前场景信息、用户请求、智驾请求和所述主功能服务层发出的主功能服务请求；第一判断模块，用于基于所述当前场景信息判断当前场景是否为危害场景，并判断所述用户请求或所述智驾请求是否与所述主功能服务请求一致；第一传输模块，用于若所述当前场景为所述危害场景，且所述用户请求或所述智驾请求与所述主功能服务请求不一致，则判断在最大允许故障时间内是否出现所述用户请求或所述智驾请求与所述主功能服务请求一致的情况，并在出现所述用户请求或所述智驾请求与所述主功能服务请求一致的情况时，将所述主功能服务请求透传至所述功能抽象服务层。
17.进一步地，上述的车辆的功能安全监控装置，还包括：第二传输模块，用于若所述当前场景不是所述危害场景，和/或，所述用户请求或所述智驾请求与所述主功能服务请求一致，则直接将所述主功能服务请求透传至所述功能抽象服务层。
18.进一步地，在通过所述功能安全服务层接收所述车辆的当前场景信息、所述用户请求、所述智驾请求和所述主功能服务层发出的主功能服务请求之前，所述接收模块，具体用于：判断所述车辆的驱动设备是否存在异常；若所述车辆的驱动设备不存在异常，则通过所述功能安全服务层接收所述车辆的当前场景信息、所述用户请求、所述智驾请求和所述主功能服务层发出的主功能服务请求。
19.进一步地，上述的车辆的功能安全监控装置，还包括：控制模块，用于在所述车辆的驱动设备存在异常，或者，在出现所述用户请求或所述智驾请求与所述主功能服务请求
一致的情况时，控制所述车辆进入安全状态；第二判断模块，用于判断所述安全状态是否可恢复；第三判断模块，用于若所述安全状态可恢复，则重新判断所述车辆的驱动设备是否存在异常，否则，维持所述车辆处于所述安全状态。
20.进一步地，所述最大允许故障时间由功能安全服务层通过故障容错时间间隔ftti分解所述用户请求或所述智驾请求与所述主功能服务请求获得。
21.本技术第三方面实施例提供一种车辆，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序，以实现如上述实施例所述的车辆的功能安全监控方法。
22.本技术第四方面实施例提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行，以用于实现如上述实施例所述的车辆的功能安全监控方法。
23.由此，本技术通过功能安全服务层接收车辆的当前场景信息、用户请求、智驾请求和主功能服务层发出的主功能服务请求，基于当前场景信息判断当前场景是否为危害场景，并判断用户请求或智驾请求是否与主功能服务请求一致，若当前场景为危害场景，且用户请求或智驾请求与主功能服务请求不一致，则判断在最大允许故障时间内是否出现用户请求或智驾请求与主功能服务请求一致的情况，并在出现用户请求或智驾请求与主功能服务请求一致的情况时，将主功能服务请求透传至功能抽象服务层。由此，解决了基于soa架构下开发的软件不能满足功能安全等级要求等问题，使整车能达到安全状态和安全目标。
24.本技术附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本技术的实践了解到。
附图说明
25.本技术上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：
26.图1为根据本技术实施例提供的一种车辆的功能安全监控方法的流程图；
27.图2为根据本技术实施例的基于soa架构功能安全监控方法使用的软件构成元素的示意图；
28.图3为根据本技术实施例的车辆的功能安全监控方法的流程图；
29.图4为根据本技术实施例的车辆的功能安全监控装置的方框示意图；
30.图5为根据本技术实施例的车辆的结构示意图。
31.附图标记说明：10-车辆的功能安全监控装置、100-接收模块、200-第一判断模块、300-第一传输模块、501-存储器、502-处理器、503-通信接口。
具体实施方式
32.下面详细描述本技术的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本技术，而不能理解为对本技术的限制。
33.下面参考附图描述本技术实施例的车辆的功能安全监控方法、装置、车辆及存储介质。针对上述背景技术中提到的基于soa架构下开发的软件不能满足功能安全等级要求的问题，本技术提供了一种车辆的功能安全监控方法，在该方法中，通过功能安全服务层接
收车辆的当前场景信息、用户请求、智驾请求和主功能服务层发出的主功能服务请求，基于当前场景信息判断当前场景是否为危害场景，并判断用户请求或智驾请求是否与主功能服务请求一致，若当前场景为危害场景，且用户请求或智驾请求与主功能服务请求不一致，则判断在最大允许故障时间内是否出现用户请求或智驾请求与主功能服务请求一致的情况，并在出现用户请求或智驾请求与主功能服务请求一致的情况时，将主功能服务请求透传至功能抽象服务层。由此，解决了基于soa架构下开发的软件不能满足功能安全等级要求等问题，使整车能达到安全状态和安全目标。
34.具体而言，图1为本技术实施例所提供的一种车辆的功能安全监控方法的流程示意图。
35.该实施例中，如图2所示，车辆包括soa架构1，soa架构1包括主功能服务层11，功能安全服务层12和功能抽象服务层13。
36.该实施例中，如图2所示，车辆包括soa架构1，soa架构1包括主功能服务层11，功能安全服务层12和功能抽象服务层13。
37.如图2所示，主功能服务层11包含多层服务层，主要用于实现整车的相关功能。功能安全层接收主功能服务层11的服务请求，判定该请求在要求场景下是否与人为请求或智驾请求等相违背。功能抽象服务层13接收功能安全层的服务请求，同时实现硬件的功能抽象。
38.主功能服务层11中包含多层服务层，通过多层服务之间相互排列组合，各个服务接口的相互调用，实现整车相应的功能。同时，主功能服务层11接收外部应用的服务请求和调用外部应用的服务，完成与外部应用的信息交互。除此之外，主功能服务层11调用功能安全服务层12提供的服务接口，驱动相关功能，并且主功能服务层11获取功能安全服务层12反馈的包含但不限于驱动设备的故障信息、电流信息、状态信息等等。主功能服务层11可按照无功能等级要求进行开发。
39.功能抽象服务层13用于实现硬件的功能抽象，通过接收功能安全服务层12的服务请求，驱动相关功能。同时功能抽象服务层13能够获取包含但不限于驱动设备的故障信息、电流信息、状态信息，并将这些信息反馈给功能安全服务层12。功能抽象服务层13位于整个服务的最底层，并且必须按照功能安全要求的等级进行开发。
40.如图1所示，该车辆的功能安全监控方法包括以下步骤：
41.在步骤s101中，通过功能安全服务层接收车辆的当前场景信息、用户请求、智驾请求和主功能服务层发出的主功能服务请求。
42.应当理解的是，功能安全服务层会接收车辆的外部信息，其中，车辆的外部信息包含但不限于场景信息，人为或智驾等请求；场景信息包含但不限于车速信息、横向加速度信息、纵向加速度信息、环境光信息、雨量信息等等，这些信息来自其它软件系统或者传感器；人为或智驾等请求包含但不限于驾驶员或乘员的操作意图，智能控制算法的决策命令等。
43.可选地，在一些实施例中，在通过功能安全服务层接收车辆的当前场景信息、用户请求、智驾请求和主功能服务层发出的主功能服务请求之前，还包括：判断车辆的驱动设备是否存在异常；若车辆的驱动设备不存在异常，则通过功能安全服务层接收车辆的当前场景信息、用户请求、智驾请求和主功能服务层发出的主功能服务请求。
44.在步骤s102中，基于当前场景信息判断当前场景是否为危害场景，并判断用户请
求或智驾请求是否与主功能服务请求一致。
45.可选地，在一些实施例中，上述的车辆的功能安全监控方法，还包括：若当前场景不是危害场景，和/或，用户请求或智驾请求与主功能服务请求一致，则直接将主功能服务请求透传至功能抽象服务层。
46.其中，危害场景可以理解为对驾驶员、乘客或者周围物体造成伤害的场景。具体地，功能安全服务层会根据接收的场景信息，判定整车所处的场景，根据功能安全分析的结果，确认当前整车所处的场景是否是危害场景。若当前场景不是危害场景，且人为请求或智驾请求与主功能服务请求一致，或者人为请求或智驾请求与主功能服务请求一致时，则直接将主功能服务请求透传至功能抽象服务层。
47.在步骤s103中，若当前场景为危害场景，且用户请求或智驾请求与主功能服务请求不一致，则判断在最大允许故障时间内是否出现用户请求或智驾请求与主功能服务请求一致的情况，并在出现用户请求或智驾请求与主功能服务请求一致的情况时，将主功能服务请求透传至功能抽象服务层。
48.其中，在一些实施例中，最大允许故障时间由功能安全服务层通过故障容错时间间隔ftti分解用户请求或智驾请求与主功能服务请求获得。
49.具体地，若当前场景为危害场景，功能安全服务层会根据人为或智驾等请求，确认是否有驾驶员、乘客或智能控制算法的决策命令等使用相关功能的意图，同时功能安全服务层接收主功能服务层的服务请求，并判定接收的主功能服务层的服务请求是否与人为或智驾请求一致。若主功能服务层的服务请求与人为或智驾请求一致，则功能安全服务层会将接收主功能服务层的服务请求直接透传给功能抽象服务层，完成后，重新开始下一帧的判定；若主功能服务层的服务请求与人为或智驾请求不一致，功能安全服务层会通过从ftti分解获得主功能服务层的服务请求与人为或智驾等请求不一致所允许最大故障时间，并判定在该时间范围内主功能服务层的服务请求与人为或智驾等请求是否有出现不一致情况，若出现不一致情况，功能安全服务层会记录功能服务层的服务请求与人为或智驾等请求不一致的情况，将主功能服务层的服务请求透传给功能抽象服务层，完成以上动作后，重新开始下一帧的判定。
50.可选地，在一些实施例中，上述的车辆的功能安全监控方法，还包括：在车辆的驱动设备存在异常，或者，在出现用户请求或智驾请求与主功能服务请求一致的情况时，控制车辆进入安全状态；判断安全状态是否可恢复；若安全状态可恢复，则重新判断车辆的驱动设备是否存在异常，否则，维持车辆处于安全状态。
51.具体地，功能安全服务层会接收功能抽象服务层反馈的驱动设备状态，判定驱动设备是否有异常，若车辆的驱动设备存在异常，则整车进入安全状态，当整车进入安全状态时，或者当人为请求或智驾请求与主功能服务请求一致时，则整车进入安全状态，整车进入安全状态则判定安全状态是否可恢复，若为安全状态可恢复，则重新判定驱动设备是否有异常，开始判定下一帧驱动设备是否已经恢复正常；若为安全状态不可恢复，则结束判定，车辆一致保持安全状态。
52.为便于理解，将在此处结合图3进行详细说明车辆的功能安全监控方法的流程，图3为本技术一个具体实施例的车辆的功能安全监控方法的流程图。
53.在步骤s301中，判断驱动设备是否异常。若驱动设备出现异常，则执行步骤s309，
若驱动设备未出现异常，则执行步骤s302。
54.在步骤s302中，判断场景是否为危害场景。若场景为危害场景，则执行步骤s304，若不是危害场景，则执行步骤s303。
55.在步骤s303中，判断人为或智驾请求是否与主功能服务请求一致。若一致，则执行步骤s304，若不一致，则执行步骤s305。
56.在步骤s304中，对主功能服务层请求透传。
57.在步骤s305中，判断ftti是否出现用户请求或智驾请求与主功能服务请求一致。若出现一致情况，则执行步骤s306，若未出现一致情况，则执行步骤s307。
58.在步骤s306中，记录不一致情况，将最终一致时主功能服务层的服务请求透传。
59.在步骤s307中，维持安全状态。
60.在步骤s308中，判断安全状态是否可恢复。若不可恢复，则结束判定，若可恢复，则执行步骤s301。
61.在步骤s309中，维持安全状态
62.在步骤s310中，判断安全状态是否可以恢复，若不可恢复，则结束判定，若可恢复，则执行步骤s301。
63.根据本技术实施例提出的车辆的功能安全监控方法，通过功能安全服务层接收车辆的当前场景信息、用户请求、智驾请求和主功能服务层发出的主功能服务请求，基于当前场景信息判断当前场景是否为危害场景，并判断用户请求或智驾请求是否与主功能服务请求一致，若当前场景为危害场景，且用户请求或智驾请求与主功能服务请求不一致，则判断在最大允许故障时间内是否出现用户请求或智驾请求与主功能服务请求一致的情况，并在出现用户请求或智驾请求与主功能服务请求一致的情况时，将主功能服务请求透传至功能抽象服务层。由此，解决了基于soa架构下开发的软件不能满足功能安全等级要求等问题，使整车能达到安全状态和安全目标。
64.其次参照附图描述根据本技术实施例提出的车辆的功能安全监控装置。
65.图4是本技术实施例的车辆的功能安全监控装置的方框示意图。
66.其中，车辆包括面向服务的soa架构，soa架构包括主功能服务层，功能安全服务层和功能抽象服务层。
67.如图4所示，该车辆的功能安全监控装置10包括：接收模块100、第一判断模块200和第一传输模块300。
68.其中，接收模块100，用于通过功能安全服务层接收车辆的当前场景信息、用户请求、智驾请求和主功能服务层发出的主功能服务请求；第一判断模块200，用于基于当前场景信息判断当前场景是否为危害场景，并判断用户请求或智驾请求是否与主功能服务请求一致；第一传输模块300，用于若当前场景为危害场景，且用户请求或智驾请求与主功能服务请求不一致，则判断在最大允许故障时间内是否出现用户请求或智驾请求与主功能服务请求一致的情况，并在出现用户请求或智驾请求与主功能服务请求一致的情况时，将主功能服务请求透传至功能抽象服务层。
69.可选地，在一些实施例中，上述的车辆的功能安全监控装置10，还包括：第二传输模块，用于若当前场景不是危害场景，和/或，用户请求或智驾请求与主功能服务请求一致，则直接将主功能服务请求透传至功能抽象服务层。
70.可选地，在一些实施例中，在通过功能安全服务层接收车辆的当前场景信息、用户请求、智驾请求和主功能服务层发出的主功能服务请求之前，接收模块100，具体用于：判断车辆的驱动设备是否存在异常；若车辆的驱动设备不存在异常，则通过功能安全服务层接收车辆的当前场景信息、用户请求、智驾请求和主功能服务层发出的主功能服务请求。
71.可选地，在一些实施例中，上述的车辆的功能安全监控装置10，还包括：控制模块，用于在车辆的驱动设备存在异常，或者，在出现用户请求或智驾请求与主功能服务请求一致的情况时，控制车辆进入安全状态；第二判断模块，用于判断安全状态是否可恢复；第三判断模块，用于若安全状态可恢复，则重新判断车辆的驱动设备是否存在异常，否则，维持车辆处于安全状态。
72.可选地，在一些实施例中，最大允许故障时间由功能安全服务层通过故障容错时间间隔ftti分解用户请求或智驾请求与主功能服务请求获得。
73.需要说明的是，前述对车辆的功能安全监控方法实施例的解释说明也适用于该实施例的车辆的功能安全监控装置，此处不再赘述。
74.根据本技术实施例提出的车辆的功能安全监控装置，通过功能安全服务层接收车辆的当前场景信息、用户请求、智驾请求和主功能服务层发出的主功能服务请求，基于当前场景信息判断当前场景是否为危害场景，并判断用户请求或智驾请求是否与主功能服务请求一致，若当前场景为危害场景，且用户请求或智驾请求与主功能服务请求不一致，则判断在最大允许故障时间内是否出现用户请求或智驾请求与主功能服务请求一致的情况，并在出现用户请求或智驾请求与主功能服务请求一致的情况时，将主功能服务请求透传至功能抽象服务层。由此，解决了基于soa架构下开发的软件不能满足功能安全等级要求等问题，使整车能达到安全状态和安全目标。
75.图5为本技术实施例提供的车辆的结构示意图。该车辆可以包括：
76.存储器501、处理器502及存储在存储器501上并可在处理器502上运行的计算机程序。
77.处理器502执行程序时实现上述实施例中提供的车辆的功能安全监控方法。
78.进一步地，车辆还包括：
79.通信接口503，用于存储器501和处理器502之间的通信。
80.存储器501，用于存放可在处理器502上运行的计算机程序。
81.存储器501可能包含高速ram(random access memory，随机存取存储器)存储器，也可能还包括非易失性存储器，例如至少一个磁盘存储器。
82.如果存储器501、处理器502和通信接口503独立实现，则通信接口503、存储器501和处理器502可以通过总线相互连接并完成相互间的通信。总线可以是isa(industry standard architecture，工业标准体系结构)总线、pci(peripheral component，外部设备互连)总线或eisa(extended industry standard architecture，扩展工业标准体系结构)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图5中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
83.可选的，在具体实现上，如果存储器501、处理器502及通信接口503，集成在一块芯片上实现，则存储器501、处理器502及通信接口503可以通过内部接口完成相互间的通信。
84.处理器502可能是一个cpu(central processing unit，中央处理器)，或者是asic
(application specific integrated circuit，特定集成电路)，或者是被配置成实施本技术实施例的一个或多个集成电路。
85.本技术实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上的车辆的功能安全监控方法。
86.在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本技术的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不是必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或n个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
87.此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本技术的描述中，“n个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。
88.流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更n个用于实现定制逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本技术的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本技术的实施例所属技术领域的技术人员所理解。
89.应当理解，本技术的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，n个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。如，如果用硬件来实现和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列，现场可编程门阵列等。
90.本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。
91.尽管上面已经示出和描述了本技术的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本技术的限制，本领域的普通技术人员在本技术的范围内可以对上述实施例进行变化、修改、替换和变型。