CN115384400A - 车辆的氛围灯控制方法/装置、车辆及存储介质 - Google Patents

Abstract

本申请涉及一种车辆的氛围灯控制方法、装置、车辆及存储介质，车辆包括面向服务架构SOA架构，其包括增强服务层、原子服务层和IO抽象服务层，其中，方法包括：通过接收氛围灯的控制指令，并通过增强服务层和原子服务层分别确定氛围灯的当前场景服务和获取车辆的车型配置，进而识别氛围灯的类型，在氛围灯类型为氛围灯光导类型或灯组类型时，则分别通过IO抽象服务层调整氛围灯通讯类型为第一通讯类型和第二通讯类型，并根据当前场景服务控制氛围灯的亮度、颜色以及点亮模式。本申请实施例基于SOA架构，可以将氛围灯的功能架构拆解为多个服务，每个服务均制定了开放的控制参数，以适用不同类型的调用及用户定制化的适配性。

Description

车辆的氛围灯控制方法/装置、车辆及存储介质

技术领域

本申请涉及车身电子技术领域，特别涉及一种车辆的氛围灯控制方法/装置、车辆及存储介质。

背景技术

随着汽车智能化的程度越来越高，用户对于汽车的服务需求也愈来愈高，比如汽车的舒适性、安全性、可定制性等功能，是用户普遍关注的。其中，可定制性的需求度日益增加，用户追求汽车功能的个性定制化，甚至希望像手机消费电子一样，让用户与车辆建立情感，保持使用粘性，而车辆氛围灯作为表达用户情感、车辆状态、外围环境的媒介，则需要自定义修改，以适配多样的场景表达。

相关技术中，车辆氛围灯通过采集外界的温度、光度和天气等数据，通过LED(Light Emitting Diode，发光二极管)芯片驱动车辆氛围灯的变化。

然而，该方法只能使氛围灯适应既有功能，而无法适配多样的场景表达以及用户定制化的需求。

发明内容

本申请提供一种车辆的氛围灯控制方法、装置、车辆及存储介质，以解决相关技术中的氛围灯无法适配多样的场景表达以及用户定制化的需求等问题。

本申请第一方面实施例提供一种车辆的氛围灯控制方法，所述车辆包括面向服务架构SOA(service-oriented architecture，面向服务的体系结构)架构，所述SOA架构包括增强服务层、原子服务层和IO(Input/Output，输入输出端口)抽象服务层，所述方法包括以下步骤：接收氛围灯的控制指令，并基于所述控制指令，通过所述增强服务层确定所述氛围灯的当前场景服务，并通过所述原子服务层获取车辆的车型配置；根据所述车型配置识别所述氛围灯的类型；以及在所述氛围灯类型为氛围灯光导类型时，通过所述IO抽象服务层调整所述氛围灯通讯类型为第一通讯类型，并根据所述当前场景服务控制所述氛围灯的亮度和颜色；在所述氛围灯类型为氛围灯组类型时，通过所述IO抽象服务层调整所述氛围灯通讯类型为第二通讯类型，并根据所述当前场景服务控制所述氛围灯的点亮模式。

根据上述技术手段，通过对SOA架构进行分层拆解，并分别制定开放参数，以适用不同场景的用户需求。

进一步地，在本申请的一个实施例中，所述SOA架构还包括场景应用服务层，所述方法还包括：通过所述场景应用服务层检测所述车辆的氛围灯亮度和颜色是否满足同步调节，并在所述车辆的氛围灯亮度和颜色满足同步调节时，生成所述氛围灯的点亮场景服务；通过所述场景应用服务层检测所述车辆的氛围灯是否满足单节点控制，并在所述车辆的氛围灯满足单节点控制时，生成所述氛围灯的效果场景服务；通过所述场景应用服务层检测所述车辆的氛围灯是否满足单节点和单LED控制，并在所述车辆的氛围灯满足单节点和单LED控制时，生成所述氛围灯的交互场景服务。

根据上述技术手段，通过应用场景服务层将氛围灯功能划分为多种使用场景，增强了用户的多样化交互体验感。

进一步地，在本申请的一个实施例中，上述的车辆的氛围灯控制方法，还包括：通过所述IO抽象服务层发送所述氛围灯的当前驱动状态；通过所述原子服务层接收所述IO抽象服务层发送的所述氛围灯的当前驱动状态和服务运行状态，并在所述当前驱动状态为故障状态时，发送所述故障状态至预设移动终端。

根据上述技术手段，使用户能够实时的了解氛围灯当前的驱动状态，以便进行相应报警提示。

进一步地，在本申请的一个实施例中，上述的车辆的氛围灯控制方法，还包括：通过所述增强服务层接收所述原子服务层发送的所述当前驱动状态和所述服务运行状态，通过所述增强服务层将所述当前驱动状态和所述服务运行状态发送至所述场景应用服务层和/或所述上层应用服务。

根据上述技术手段，通过增强服务层的应用，可以实现各种氛围灯场景的服务请求仲裁。

进一步地，在本申请的一个实施例中，所述第一通讯类型为LIN(LocalInterconnectNetwork，串行通讯网络)通讯，所述第二通讯类型为CAN(ControllerArea Network，控制器局域网络)/CANFD通讯。

根据上述技术手段，通过不同发光源提供不同的通讯类型，可以对氛围灯节点分别进行控制，以满足不同场景使用氛围灯的需求。

本申请第二方面实施例提供一种车辆的氛围灯控制装置，所述车辆包括面向服务架构SOA架构，所述SOA架构包括增强服务层、原子服务层和IO抽象服务层，所述装置包括：获取模块，用于接收氛围灯的控制指令，并基于所述控制指令，通过所述增强服务层确定所述氛围灯的当前场景服务，并通过所述原子服务层获取车辆的车型配置；识别模块，用于根据所述车型配置识别所述氛围灯的类型；以及控制模块，用于在所述氛围灯类型为氛围灯光导类型时，通过所述IO抽象服务层调整所述氛围灯通讯类型为第一通讯类型，并根据所述当前场景服务控制所述氛围灯的亮度和颜色；在所述氛围灯类型为氛围灯组类型时，通过所述IO抽象服务层调整所述氛围灯通讯类型为第二通讯类型，并根据所述当前场景服务控制所述氛围灯的点亮模式。

进一步地，在本申请的一个实施例中，所述SOA架构还包括场景应用服务层，所述装置还包括：第一检测模块，用于通过所述场景应用服务层检测所述车辆的氛围灯亮度和颜色是否满足同步调节，并在所述车辆的氛围灯亮度和颜色满足同步调节时，生成所述氛围灯的点亮场景服务；第二检测模块，用于通过所述场景应用服务层检测所述车辆的氛围灯是否满足单节点控制，并在所述车辆的氛围灯满足单节点控制时，生成所述氛围灯的效果场景服务；第三检测模块，用于通过所述场景应用服务层检测所述车辆的氛围灯是否满足单节点和单LED控制，并在所述车辆的氛围灯满足单节点和单LED控制时，生成所述氛围灯的交互场景服务。

进一步地，在本申请的一个实施例中，上述的车辆的氛围灯控制装置，还包括：发送模块，用于通过所述IO抽象服务层发送所述氛围灯的当前驱动状态；接收模块，用于通过所述原子服务层接收所述IO抽象服务层发送的所述氛围灯的当前驱动状态和服务运行状态，并在所述当前驱动状态为故障状态时，发送所述故障状态至预设移动终端。

进一步地，在本申请的一个实施例中，上述的车辆的氛围灯控制装置，还包括：第二接收模块，用于通过所述增强服务层接收所述原子服务层发送的所述当前驱动状态和所述服务运行状态；第二发送模块，用于通过所述增强服务层将所述当前驱动状态和所述服务运行状态发送至所述场景应用服务层和/或所述上层应用服务。

进一步地，在本申请的一个实施例中，所述第一通讯类型为LIN通讯，所述第二通讯类型为CAN/CANFD通讯。

本申请第三方面实施例提供一种车辆，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序，以实现如上述实施例所述的车辆的氛围灯控制方法。

本申请第四方面实施例提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行，以用于实现如上述实施例所述的车辆的氛围灯控制方法。

本申请实施例通过接收氛围灯的控制指令，并通过增强服务层和原子服务层分别确定氛围灯的当前场景服务和获取车辆的车型配置，进而识别氛围灯的类型，在氛围灯类型为氛围灯光导类型或灯组类型时，则分别通过IO抽象服务层调整氛围灯通讯类型为第一通讯类型和第二通讯类型，并根据当前场景服务控制氛围灯的亮度、颜色以及点亮模式。由此，解决了相关技术中的氛围灯无法适配多样的场景表达以及用户定制化的需求等问题。

本申请附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

本申请上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1为根据本申请实施例提供的一种车辆的氛围灯控制方法的流程图；

图2为根据本申请一个实施例的氛围灯SOA服务架构系统方框示意图；

图3为根据本申请实施例的车辆的氛围灯控制装置的示例图；

图4为根据本申请实施例的车辆的结构示意图。

附图标记说明：10-车辆后视镜的控制装置；100-获取模块、200-识别模块、300-控制模块。

具体实施方式

下面详细描述本申请的实施例，实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本申请，而不能理解为对本申请的限制。

下面参考附图描述本申请实施例的车辆的氛围灯控制方法、装置、车辆及存储介质。针对上述背景技术中提到的相关技术中的氛围灯无法适配多样的场景表达以及用户定制化的需求的问题，本申请提供了一种车辆的氛围灯控制方法，在该方法中，通过接收氛围灯的控制指令，并通过增强服务层和原子服务层分别确定氛围灯的当前场景服务和获取车辆的车型配置，进而识别氛围灯的类型，在氛围灯类型为氛围灯光导类型或灯组类型时，则分别通过IO抽象服务层调整氛围灯通讯类型为第一通讯类型和第二通讯类型，并根据当前场景服务控制氛围灯的亮度、颜色以及点亮模式，从而基于SOA架构，可以将氛围灯的功能架构拆解为多个服务，每个服务均制定了开放的控制参数，以适用不同类型的调用及用户定制化的适配性。由此，解决了相关技术中的氛围灯无法适配多样的场景表达以及用户定制化的需求等问题。

在介绍本申请实施例之前，首先介绍一下本申请实施例基于SOA服务架构所涉及的四个层级，自下而上分别为氛围灯IO抽象层、氛围灯原子服务层、氛围灯增强服务层以及氛围灯场景应用服务层。

其中，氛围灯IO抽象服务层与硬件强相关。针对氛围灯光导类型的发光源，通过LIN通讯，直接进行氛围灯节点控制；针对氛围灯组类型的发光源，通过CAN/CANFD通讯，直接进行氛围灯节点控制，控制颗粒度均可到每颗LED。

氛围灯原子服务层介于氛围灯增强服务层和IO抽象层之间，是实现软件和硬件隔离的关键，对下可以直接调用IO抽象层实现输出控制，对上可以把IO抽象层的数据进行整合提供标准服务接口给到增强服务层。由于原子服务层是上层软件和硬件的分离点，所以只与增强服务层和场景应用服务层发生订阅关系，不对外部应用提供服务接口。

氛围灯增强服务层位于原子服务上层，其主功能是实现各种氛围灯场景服务请求的仲裁、不同调用需求整合，以提供标准化的接口到上层应用或场景服务。

氛围灯场景应用服务是本申请实施例的最顶层，可以将氛围灯功能划分为各种使用场景，并对外部应用提供相应的服务接口，既实现了常规氛围灯功能的使用，也为提示报警、多样化的体验交互功能提供了相应的基础服务。

通过将氛围灯功能划分为4层服务，并涉及到关于氛围灯的常规点亮功能、报警提示功能以及交互体验功能，下面根据具体实施例进行详细论述。

具体而言，图1为本申请实施例所提供的一种车辆的氛围灯控制方法的流程示意图。

如图1所示，该车辆的氛围灯控制方法包括以下步骤：

在步骤S101中，接收氛围灯的控制指令，并基于控制指令，通过增强服务层确定氛围灯的当前场景服务，并通过原子服务层获取车辆的车型配置。

具体地，如图1所示，本申请实施例首先通过原子服务层获取车辆的实际车型配置，通过实际车型配置，进而确定需要对哪些氛围灯IO层进行控制；其次，通过增强服务层接收原子服务层发送的氛围灯当前驱动状态和服务运行状态，进而调用对应的氛围灯IO抽象层，并执行氛围灯的输出控制指令；最后，接收氛围灯IO抽象通知，并通过增强服务层将当前驱动状态和服务运行状态发送至场景应用服务层和/或上层应用服务，以确定氛围灯的当前场景服务。

在步骤S102中，根据车型配置识别氛围灯的类型。

应当理解的是，本申请实施例可以根据不同的车型设置不同的氛围灯类型，因此，本申请实施例可以在通过原子服务层获取车辆的车型配置后，根据车型配置识别氛围灯的类型，其中，氛围灯类型就可以包括氛围灯光导类型和氛围灯组类型。

需要说明的是，氛围灯光导类型为单LED的发光源，氛围灯组类型为多LED的发光源。

在步骤S103中，在氛围灯类型为氛围灯光导类型时，通过IO抽象服务层调整氛围灯通讯类型为第一通讯类型，并根据当前场景服务控制氛围灯的亮度和颜色；在氛围灯类型为氛围灯组类型时，通过IO抽象服务层调整氛围灯通讯类型为第二通讯类型，并根据当前场景服务控制氛围灯的点亮模式。

进一步地，在本申请的一个实施例中，上述的车辆的氛围灯控制方法，还包括：通过IO抽象服务层发送氛围灯的当前驱动状态；通过原子服务层接收IO抽象服务层发送的氛围灯的当前驱动状态和服务运行状态，并在当前驱动状态为故障状态时，发送故障状态至预设移动终端。

其中，第一通讯类型和第二通讯类型可以由用户自行设定，也可以为本领技术人员根据实际应用情况进行设定，优选地，本申请实施例的第一通讯类型可以为LIN通讯，第二通讯类型可以为CAN/CANFD通讯，预设移动终端可以为车载电脑、蓝牙手机等。

具体地，本申请实施例为了实现软件和硬件分离，IO抽象层需与硬件强绑定，由原子服务层去适配IO抽象层，对上提供标准统一服务接口，其中，氛围灯增强服务提供的接口包括执行的优先级和控制模式，即针对不同类型的场景应用，提供不同的服务接口和参数。

具体而言，若氛围灯类型为单LED硬件类型，即氛围灯光导类型时，此时，通过IO抽象服务层调整氛围灯通讯类型为LIN通讯，并根据当前场景服务控制氛围灯的亮度和颜色的调节以及氛围灯的开闭状态，且通过原子服务层接收IO抽象服务层发送的氛围灯的当前驱动状态和服务运行状态，并在当前驱动状态为故障状态时，发送故障状态至车载电脑，以提示用户当前氛围灯运行存在故障。

可选地，若氛围灯类型为多LED硬件类型，即氛围灯组类型时，此时，通过IO抽象服务层调整氛围灯通讯类型为CAN/CANFD通讯，并根据当前场景服务控制氛围灯亮度和颜色的调节以及氛围灯的开闭状态，并控制氛围灯的点亮模式，如呼吸、闪烁、流水、跑马等，且通过原子服务层接收IO抽象服务层发送的氛围灯的当前驱动状态和服务运行状态，并在当前驱动状态为故障状态时，发送故障状态至车载电脑，以提示用户当前氛围灯运行存在故障。

进一步地，在本申请的一个实施例中，SOA架构还包括场景应用服务层，方法还包括：通过场景应用服务层检测车辆的氛围灯亮度和颜色是否满足同步调节，并在车辆的氛围灯亮度和颜色满足同步调节时，生成氛围灯的点亮场景服务；通过场景应用服务层检测车辆的氛围灯是否满足单节点控制，并在车辆的氛围灯满足单节点控制时，生成氛围灯的效果场景服务；通过场景应用服务层检测车辆的氛围灯是否满足单节点控制，并在车辆的氛围灯满足单节点控制时，生成氛围灯的效果场景服务；通过场景应用服务层检测车辆的氛围灯是否满足单节点和单LED控制，并在车辆的氛围灯满足单节点和单LED控制时，生成氛围灯的交互场景服务。

进一步地，在本申请的一个实施例中，上述的车辆的氛围灯控制方法，还包括：通过增强服务层接收原子服务层发送的当前驱动状态和服务运行状态，通过增强服务层将当前驱动状态和服务运行状态发送至场景应用服务层和/或上层应用服务。

具体地，通过上述获取的氛围灯类型，在场景应用服务层中，可以实现三种不同的氛围灯场景服务。首先，通过场景应用服务层检测车辆的氛围灯亮度和颜色是否满足同步调节，并在车辆的氛围灯亮度和颜色满足同步调节时，向氛围灯增强服务层发出控制请求，从而生成氛围灯的点亮场景服务；其次，通过场景应用服务层检测车辆的氛围灯是否满足单个氛围灯节点的控制，若车辆的氛围灯满足单节点控制，则可以实现单节点的颜色、亮度、闪烁、呼吸、流水、跑马等固定效果的控制，从而向氛围灯增强服务层发出控制请求，生成氛围灯的效果场景服务；最后，通过场景应用服务层检测车辆的氛围灯是否满足单节点和单LED控制，若车辆的氛围灯满足单节点和单LED控制，则可以实现自定义可变效果，如音乐律动、情绪感知、环境切换，车辆主题、用户自定义等场景，从而向氛围灯增强服务层发出控制请求，生成氛围灯的交互场景服务。

根据本申请实施例提出的车辆的氛围灯控制方法，通过接收氛围灯的控制指令，并通过增强服务层和原子服务层分别确定氛围灯的当前场景服务和获取车辆的车型配置，进而识别氛围灯的类型，在氛围灯类型为氛围灯光导类型或灯组类型时，则分别通过IO抽象服务层调整氛围灯通讯类型为第一通讯类型和第二通讯类型，并根据当前场景服务控制氛围灯的亮度、颜色以及点亮模式，从而基于SOA架构，可以将氛围灯的功能架构拆解为多个服务，每个服务均制定了开放的控制参数，以适用不同类型的调用及用户定制化的适配性。由此，解决了相关技术中的氛围灯无法适配多样的场景表达以及用户定制化的需求等问题。

其次参照附图描述根据本申请实施例提出的车辆的氛围灯控制装置。

图3是本申请实施例的车辆的氛围灯控制装置的方框示意图。

如图3所示，该车辆的氛围灯控制装置10包括：获取模块100、识别模块200和控制模块300。

其中，获取模块100，用于接收氛围灯的控制指令，并基于控制指令，通过增强服务层确定氛围灯的当前场景服务，并通过原子服务层获取车辆的车型配置；

识别模块200，用于根据车型配置识别氛围灯的类型；以及

控制模块300，用于在氛围灯类型为氛围灯光导类型时，通过IO抽象服务层调整氛围灯通讯类型为第一通讯类型，并根据当前场景服务控制氛围灯的亮度和颜色；在氛围灯类型为氛围灯组类型时，通过IO抽象服务层调整氛围灯通讯类型为第二通讯类型，并根据当前场景服务控制氛围灯的点亮模式。

进一步地，在本申请的一个实施例中，SOA架构还包括场景应用服务层，装置还包括：第一检测模块、第二检测模块和第三检测模块。

其中，第一检测模块，用于通过场景应用服务层检测车辆的氛围灯亮度和颜色是否满足同步调节，并在车辆的氛围灯亮度和颜色满足同步调节时，生成氛围灯的点亮场景服务；

第二检测模块，用于通过场景应用服务层检测车辆的氛围灯是否满足单节点控制，并在车辆的氛围灯满足单节点控制时，生成氛围灯的效果场景服务；

第三检测模块，用于通过场景应用服务层检测车辆的氛围灯是否满足单节点和单LED控制，并在车辆的氛围灯满足单节点和单LED控制时，生成氛围灯的交互场景服务。

进一步地，在本申请的一个实施例中，上述的车辆的氛围灯控制装置，还包括：发送模块和接收模块。

其中，发送模块，用于通过IO抽象服务层发送氛围灯的当前驱动状态；

接收模块，用于通过原子服务层接收IO抽象服务层发送的氛围灯的当前驱动状态和服务运行状态，并在当前驱动状态为故障状态时，发送故障状态至预设移动终端。

进一步地，在本申请的一个实施例中，上述的车辆的氛围灯控制装置，还包括：第二接收模块和第二发送模块。

其中，第二接收模块，用于通过增强服务层接收原子服务层发送的当前驱动状态和服务运行状态；

第二发送模块，用于通过增强服务层将当前驱动状态和服务运行状态发送至场景应用服务层和/或上层应用服务。

进一步地，在本申请的一个实施例中，第一通讯类型为LIN通讯，第二通讯类型为CAN/CANFD通讯。

根据本申请实施例提出的车辆的氛围灯控制装置，通过接收氛围灯的控制指令，并通过增强服务层和原子服务层分别确定氛围灯的当前场景服务和获取车辆的车型配置，进而识别氛围灯的类型，在氛围灯类型为氛围灯光导类型或灯组类型时，则分别通过IO抽象服务层调整氛围灯通讯类型为第一通讯类型和第二通讯类型，并根据当前场景服务控制氛围灯的亮度、颜色以及点亮模式，从而基于SOA架构，可以将氛围灯的功能架构拆解为多个服务，每个服务均制定了开放的控制参数，以适用不同类型的调用及用户定制化的适配性。由此，解决了相关技术中的氛围灯无法适配多样的场景表达以及用户定制化的需求等问题。

图4为本申请实施例提供的车辆的结构示意图。该车辆可以包括：

存储器401、处理器402及存储在存储器401上并可在处理器402上运行的计算机程序。

处理器402执行程序时实现上述实施例中提供的车辆的氛围灯控制方法。

进一步地，车辆还包括：

通信接口403，用于存储器401和处理器402之间的通信。

存储器401，用于存放可在处理器402上运行的计算机程序。

存储器401可能包含高速RAM(Random Access Memory，随机存取存储器)存储器，也可能还包括非易失性存储器，例如至少一个磁盘存储器。

如果存储器401、处理器402和通信接口403独立实现，则通信接口403、存储器401和处理器402可以通过总线相互连接并完成相互间的通信。总线可以是ISA(IndustryStandard Architecture，工业标准体系结构)总线、PCI(Peripheral Component，外部设备互连)总线或EISA(Extended Industry Standard Architecture，扩展工业标准体系结构)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图4中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

可选的，在具体实现上，如果存储器401、处理器402及通信接口403，集成在一块芯片上实现，则存储器401、处理器402及通信接口403可以通过内部接口完成相互间的通信。

处理器402可能是一个CPU(Central Processing Unit，中央处理器)，或者是ASIC(Application Specific Integrated Circuit，特定集成电路)，或者是被配置成实施本申请实施例的一个或多个集成电路。

本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上的车辆的氛围灯控制方法。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不是必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或N个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本申请的描述中，“N个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更N个用于实现定制逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。

应当理解，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，N个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。如，如果用硬件来实现和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列，现场可编程门阵列等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (10)

1.一种车辆的氛围灯控制方法，其特征在于，所述车辆包括面向服务架构SOA架构，所述SOA架构包括增强服务层、原子服务层和IO抽象服务层，所述方法包括以下步骤：

接收氛围灯的控制指令，并基于所述控制指令，通过所述增强服务层确定所述氛围灯的当前场景服务，并通过所述原子服务层获取车辆的车型配置；

根据所述车型配置识别所述氛围灯的类型；以及

在所述氛围灯类型为氛围灯光导类型时，通过所述IO抽象服务层调整所述氛围灯通讯类型为第一通讯类型，并根据所述当前场景服务控制所述氛围灯的亮度和颜色；在所述氛围灯类型为氛围灯组类型时，通过所述IO抽象服务层调整所述氛围灯通讯类型为第二通讯类型，并根据所述当前场景服务控制所述氛围灯的点亮模式。

2.根据权利要求1所述的方法，其特征在于，所述SOA架构还包括场景应用服务层，所述方法还包括：

通过所述场景应用服务层检测所述车辆的氛围灯亮度和颜色是否满足同步调节，并在所述车辆的氛围灯亮度和颜色满足同步调节时，生成所述氛围灯的点亮场景服务；

通过所述场景应用服务层检测所述车辆的氛围灯是否满足单节点控制，并在所述车辆的氛围灯满足单节点控制时，生成所述氛围灯的效果场景服务；

通过所述场景应用服务层检测所述车辆的氛围灯是否满足单节点和单LED控制，并在所述车辆的氛围灯满足单节点和单LED控制时，生成所述氛围灯的交互场景服务。

3.根据权利要求2所述的方法，其特征在于，还包括：

通过所述IO抽象服务层发送所述氛围灯的当前驱动状态；

通过所述原子服务层接收所述IO抽象服务层发送的所述氛围灯的当前驱动状态和服务运行状态，并在所述当前驱动状态为故障状态时，发送所述故障状态至预设移动终端。

4.根据权利要求3所述的方法，其特征在于，还包括：

通过所述增强服务层接收所述原子服务层发送的所述当前驱动状态和所述服务运行状态；

通过所述增强服务层将所述当前驱动状态和所述服务运行状态发送至所述场景应用服务层和/或所述上层应用服务。

5.根据权利要求1-4任一项所述的方法，其特征在于，所述第一通讯类型为LIN通讯，所述第二通讯类型为CAN/CANFD通讯。

6.一种车辆的氛围灯控制装置，其特征在于，所述车辆包括面向服务架构SOA架构，所述SOA架构包括增强服务层、原子服务层和IO抽象服务层，所述装置包括：

获取模块，用于接收氛围灯的控制指令，并基于所述控制指令，通过所述增强服务层确定所述氛围灯的当前场景服务，并通过所述原子服务层获取车辆的车型配置；

识别模块，用于根据所述车型配置识别所述氛围灯的类型；以及

控制模块，用于在所述氛围灯类型为氛围灯光导类型时，通过所述IO抽象服务层调整所述氛围灯通讯类型为第一通讯类型，并根据所述当前场景服务控制所述氛围灯的亮度和颜色；在所述氛围灯类型为氛围灯组类型时，通过所述IO抽象服务层调整所述氛围灯通讯类型为第二通讯类型，并根据所述当前场景服务控制所述氛围灯的点亮模式。

7.根据权利要求6所述的装置，其特征在于，所述SOA架构还包括场景应用服务层，所述装置还包括：

第一检测模块，用于通过所述场景应用服务层检测所述车辆的氛围灯亮度和颜色是否满足同步调节，并在所述车辆的氛围灯亮度和颜色满足同步调节时，生成所述氛围灯的点亮场景服务；

第二检测模块，用于通过所述场景应用服务层检测所述车辆的氛围灯是否满足单节点控制，并在所述车辆的氛围灯满足单节点控制时，生成所述氛围灯的效果场景服务；

第三检测模块，用于通过所述场景应用服务层检测所述车辆的氛围灯是否满足单节点和单LED控制，并在所述车辆的氛围灯满足单节点和单LED控制时，生成所述氛围灯的交互场景服务。

8.根据权利要求7所述的装置，其特征在于，还包括：

第一发送模块，用于通过所述IO抽象服务层发送所述氛围灯的当前驱动状态；

第一接收模块，用于通过所述原子服务层接收所述IO抽象服务层发送的所述氛围灯的当前驱动状态和服务运行状态，并在所述当前驱动状态为故障状态时，发送所述故障状态至预设移动终端。

9.一种车辆，其特征在于，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序，以实现如权利要求1-5任一项所述的车辆的氛围灯控制方法。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行，以用于实现如权利要求1-5任一项所述的车辆的氛围灯控制方法。

Images