一种平台化汽车门锁控制方法与流程

一种平台化汽车门锁控制方法、系统、设备及介质
技术领域
1.本发明涉及智能化汽车控制技术领域，具体涉及一种平台化汽车门锁控制方法
、
系统
、
设备及介质
。


背景技术：

2.汽车智能化的发展成为趋势，软件定义汽车成为行业关注的重点，这样的变革表现为软件和硬件解耦，软件平台化，延长了汽车的生命周期和价值周期
。
在车辆控制领域，应用层软件的开发使用基于
soa
架构
(
面向服务架构
)
方式实现，旨在实现构建可扩展
、
灵活和可维护的系统
。
每个服务通过松耦合的方式进行通信和交互，服务可被多个模块调用，每个服务可以独立开发升级而不对别的服务产生影响，同时可以实现平台化，一套软件适配多种车型，节省开发经历和周期，极大地提升软件开发效率，同时便于维护和升级
。
3.在智能化汽车控制领域，由于自身控制器的功能复杂繁冗，同时与较多的硬件强相关，在日益增加的智能化功能需求下，控制器软件的迭代升级需要面临速度的挑战
。
传统控制器软件间
、
软硬件间耦合十分严重，可移植性和复用性低，致使开发效率低下，迭代成本高，迭代周期长，因此，进行软件架构解耦涉及是必然趋势
。
现有的汽车门锁控制软件架构更强调功能实现和功能独立，软件架构不够清晰，功能模块间耦合度高，后期维护及迭代难度较大
。
4.为解决上述问题，现有研究，如公开号为
cn115774438a
的专利申请文件公开一种汽车中央门锁控制软件架构及构建方法，软件架构包括应用软件层
、
基础软件层
、
位于应用软件层和基础软件层之间的运行环境层以及硬件层，应用软件层位于最顶层，包括中央门锁逻辑判断模块和中央门锁执行模块，用于根据中央门锁开关操作完成中央门锁控制功能逻辑
。
该申请将中央门锁的各部分功能模块
、
硬软件资源的占用及其交互关系与
autosar
分层架构标准体系结合，并提出
autosar
在汽车中央门锁控制软件架构应用的分层原则，将中央门锁控制的输入采集
、
功能控制
、
故障诊断和输出控制等功能按照标准架构分层级执行，从而提升上层应用软件的可移植性
、
底层硬件与软件的高度解耦性
、
整体架构的高稳定性
。
但是该申请实现门锁硬件与软件的解耦的方式为中央门锁按照标准架构分层级执行，为单一门锁配置多种门锁功能，即，当门锁类型更改时，仍需要改性上层应用软件进行适配
。
因此，上述汽车门锁软硬件解耦应用，仍具有一定的局限性
。
5.对于汽车而言，车辆门锁的控制也由传统的机械拉手升级为电控门锁，例如，公开号为
cn114445937a
的专利申请文件公开一种基于
soa
架构的汽车门锁控制系统及方法，所述系统基于
soa
构架，将汽车门锁控制系统封装成标准的服务组件，包括由上至下相互连接并相互通讯的用户场景定制层
、
场景服务层
、
增强服务层
、
原子服务层和
i/o
抽象层；用户场景服务层用于向增强服务层发出解锁或闭锁命令请求；增强服务层用于根据指令设定相应的门锁控制逻辑；原子服务层用于接收来自增强服务层的解锁或闭锁指令；
i/o
抽象层与硬件绑定，屏蔽硬件设计的具体实现方式，并供原子服务层直接调用，接收原子服务层的解锁或闭锁指令对门锁电机进行控制；在
i/o
抽象层对门锁电机进行解闭锁控制后，若在一定时
间内，门锁电机的实际状态与解闭锁控制指令不符，则跳转到重试状态
。
通过上述方法以实现用户个性化定制解锁
、
闭锁场景，且达到解锁
、
闭锁成功率高的效果
。
但是，上述方法虽然基于
soa
架构，但是却未提出平台化控制汽车门锁的方法，当使用不同门锁硬件的时候，仍需要改动软件进行适配
。
当前车辆的门锁硬件分类多为电控锁
、
释放吸合锁，上述门锁控制方法只能用于普通门锁，更换不同门锁硬件组合方案时都需要重新设计软件，未能达到平台化使用，需要新的较长时间的迭代周期
。
6.因此，如果能提供一种平台化汽车门锁控制方法，能够基于
soa
架构，实现多类型门锁硬件与软件的高度解耦，门锁控制方法能够适配于市面大多数门锁硬件方案，能够解决更换不同门锁硬件组合方案时都需要重新设计软件的问题，以缩短迭代周期，适配多种车型和多种应用场景，则更有利于汽车智能化的发展，缩短软件开发维护周期，提高经济效益
。


技术实现要素：

7.本发明的目的之一在于提供一种平台化汽车门锁控制方法，以解决现有技术中更换不同门锁硬件组合方案时都需要重新设计软件
、
现有汽车门锁控制方法对不同车型和不同应用场景的适配性低
、
现有汽车门锁控制方法软硬件耦合高等问题；目的之二在于提供一种平台化汽车门锁控制系统；目的之三在于提供一种电子设备；目的之四在于提供一种计算机可读存储介质
。
8.为了实现上述目的及相关目的，本发明采用的技术方案如下：
9.本发明第一方面提供一种平台化汽车门锁控制方法，该方法包括以下步骤：
10.响应于接收到的门锁功能请求，读取门锁硬件配置类型，并将门锁硬件配置类型通知至增强服务层；
11.确定车辆的当前增强服务状态；
12.若当前增强服务状态满足预设门锁控制前置条件，则将门锁功能请求对应的控制参数传递给增强服务层；
13.增强服务层基于控制参数确定与门锁硬件配置类型相对应的驱动策略，以及与驱动策略对应的目标增强服务，以对门锁进行控制
。
14.于本技术一实施例中，门锁功能请求包括用户在预设的场景服务编排界面中添加的一种或多种编排解闭锁场景，所添加的每种解闭锁场景均设置有对应的控制参数；门锁硬件配置类型包括独立式门锁硬件或组合式门锁硬件
。
15.于本技术一实施例中，预设门锁控制前置条件包括为执行解闭锁场景对应的锁功能时，车辆需达到的预设运行状态
。
16.于本技术一实施例中，基于控制参数确定目标增强服务的方法包括：增强服务层的增强服务被调用，并对控制参数进行校验，若控制参数校验通过，则判断控制参数为有效数据，基于控制参数确定与门锁硬件配置类型对应的驱动策略，以及与驱动策略对应的目标增强服务
。
17.于本技术一实施例中，驱动策略包括实时检测门锁的当前微开状态，增强服务层调用原子服务层传递与门锁硬件配置类型对应的控制指令至输入输出抽象层，输入输出抽象层切换门锁的当前微开状态至门锁硬件配置类型对应的中间微开状态，并执行控制指
令，执行结束后，退出中间微开状态，进入解锁或闭锁状态
。
18.于本技术一实施例中，方法还包括存储门锁硬件类型，以及与门锁硬件配置类型相对应的驱动策略
。
19.本发明第二方面提供一种平台化汽车门锁控制系统，该系统包括：
20.获取模块，用于响应于接收到的门锁功能请求，读取门锁硬件配置类型，并将门锁硬件配置类型通知至增强服务层；
21.确定模块，用于确定车辆的当前增强服务状态；
22.传递模块，用于在当前增强服务状态满足预设门锁控制前置条件时，将门锁功能请求对应的控制参数传递给增强服务层；
23.控制模块，用于增强服务层基于控制参数确定与门锁硬件配置类型相对应的驱动策略，以及与驱动策略对应的目标增强服务，以对门锁进行控制
。
24.于本技术一实施例中，系统还包括存储模块，用于存储门锁硬件类型，以及与门锁硬件配置类型相对应的驱动策略
。
25.本发明第三方面提供一种电子设备，电子设备包括：
26.一个或多个处理器；
27.存储装置，用于存储一个或多个程序，当一个或多个程序被一个或多个处理器执行时，使得电子设备实现如上所述的平台化汽车门锁控制方法
。
28.本发明第四方面提供一种计算机可读存储介质，其上存储有计算机程序，当计算机程序被计算机的处理器执行时，使计算机执行如上所述的平台化汽车门锁控制方法
。
29.本发明的有益技术效果在于：
30.(1)
本发明基于
soa
架构，提供平台化汽车门锁控制方法，以适配市面大多数门锁硬件，包括电控锁
、
释放锁
、
吸合锁的单独使用或组合使用，实现门锁硬件与软件的高度解耦，解决更换不同门锁硬件组合方案时都需要重新设计软件的问题，从而达到缩短迭代周期
、
适配多种车型
、
提高软件质量的目的；
31.(2)
本发明平台化汽车门锁控制方法，提升门锁应用层控制软件模块的质量，涵盖多种车型与应用场景，缩短开发维护周期，实现软件平台化；
32.(3)
本发明将汽车门锁控制平台化，做到软硬件解耦，几乎适用所有门锁控制的功能场景，普适性高，平台化汽车门锁控制方法对于多类车型应用层软件的复用和功能迭代均具有可靠性
、
稳定性和便捷性
。
附图说明
33.为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关附图
。
34.图1为本技术一示例性实施例示出的平台化汽车门锁控制方法流程图；
35.图2为本技术一示例性实施例示出的平台化汽车门锁软件架构示意图；
36.图3为本技术一示例性实施例示出的门锁驱动过程示意图；
37.图4为本技术一示例性实施例示出的平台化汽车门锁控制系统结构框图；
38.图5示出了适用于实现本技术实施例的电子设备的计算机系统的结构示意图
。
具体实施方式
39.以下将参照附图和优选实施例来说明本发明的实施方式，本领域技术人员可由本说明书中所揭露的内容轻易地了解本发明的其他优点与功效
。
本发明还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本发明的精神下进行各种修饰或改变
。
应当理解，优选实施例仅为了说明本发明，而不是为了限制本发明的保护范围
。
40.需要说明的是，以下实施例中所提供的图示仅以示意方式说明本发明的基本构想，遂图式中仅显示与本发明中有关的组件而非按照实际实施时的组件数目
、
形状及尺寸绘制，其实际实施时各组件的型态
、
数量及比例可为一种随意的改变，且其组件布局型态也可能更为复杂
。
41.首先需要说明的是，
soa(service-oriented architecture)
即面向服务的架构，是面向
soa
的汽车旨在打通车内上万个零部件和应用软件之间的协同合作
。
在
soa
架构中，服务是整个系统的抽象手段，是系统最基础的单元
。
每个服务具有独立的功能，各个域将自己的能力全部服务化，提供给第三方使用，服务之间通过统一的接口相互访问，并支持组合扩展
。
基于
soa
架构的服务化，具有松耦合
、
可复用
、
高内聚的特点，是汽车智能化发展的底层支撑
。
服务编排是以
soa
架构为基础，将汽车各个域提供的服务能力进行整合
、
编排，快速生成一个组合服务或是一个应用场景，以动态
、
快速
、
自动化地满足用户定制化需求
。
42.简单的理解，面向服务的体系结构是一个组件模型，它将应用程序的不同功能单元
(
服务
)
通过这些服务之间定义良好的接口和契约联系起来
。
接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台
、
操作系统和编程语言
。
这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互
。
43.ntf(notifier)
接口：属于服务调用方法中的
notifier
，其实就是通知事件
。
对应
event
接口类型
(
当某种事情发生后，服务端向客户端发送的报文
)
，类似
can
报文，在特定的事件触发下，服务端会发给客户端一个
notification
报文主要包括
cyclic
事件，数据
changed
等
。
44.图1为本技术一示例性实施例示出的平台化汽车门锁控制方法流程图，如图1所示，本发明提供一种平台化汽车门锁控制方法，包括步骤
s110
至步骤
s140
，详细介绍如下：
45.步骤
s110
，响应于接收到的门锁功能请求，读取门锁硬件配置类型，并将门锁硬件配置类型通知至增强服务层
。
46.本步骤中，本技术提供的平台化汽车门锁控制方法适用于多种车型，例如轿车
、suv、mpv、
跑车
、
货车
、
越野汽车
、
自卸汽车
、
牵引汽车等；同时也普适于多类门锁硬件，包括电控锁
、
释放书
、
吸合锁等
。
47.本步骤中，门锁功能请求包括用户在预设的场景服务编排界面中添加的一种或多种编排解闭锁场景，以及所添加的每种解闭锁场景均设置有对应的控制参数
。
进一步的优选，预设的场景服务编排界面包括但不限于运行有汽车门锁控制
app
的汽车中控屏
、
手机
、
笔记本
、
平板等具有编排界面的电子设备
。
用户通过汽车门锁控制
app
自定义编排一种或多种解闭锁场景，包括但不限于迎宾解闭锁场景
、
中控解闭锁场景
、
遥控解闭锁场景
。
控制参
数包括用户能够根据所选择的解闭锁场景，以及车门锁的实际开闭状态，选择所要解闭锁的具体车门，例如，左前门锁
、
左后门锁
、
右前门锁
、
右后门锁
。
48.本步骤中，门锁硬件配置类型包括独立式门锁硬件或组合式门锁硬件
。
进一步的优选，本实施例门锁包括普适性硬件电控锁，吸合锁，释放锁的单独使用或组合使用
。
49.本步骤中，响应于用户发出的门锁功能请求，读取门锁硬件配置类型，并通过
ntf
接口通知至增强服务层，通知内容包括该门锁硬件属于电控锁，吸合锁，释放锁的单独使用或组合使用
。
50.步骤
s120
，确定车辆的当前增强服务状态
。
51.本步骤中，当车辆系统上电后，车辆软件服务首先会进入到初始化状态，随后判断是否接收到用户的门锁功能请求，判断接收到后，检测并确定车辆的当前增强服务状态
。
当前增强服务状态包括但不限于驻车档位
、
行车速度
、
发动机状态
、
电源档位
。
52.步骤
s130
，若当前增强服务状态满足预设门锁控制前置条件，则将门锁功能请求对应的控制参数传递给增强服务层
。
53.本步骤中，预设门锁控制前置条件包括为执行解闭锁场景对应的锁功能时，车辆需达到的预设运行状态
。
进一步的优选，解闭锁场景对应的锁功能包括但不限于，迎宾解闭锁场景对应的迎宾自动解锁
、
送宾自动闭锁模式；行车自动落锁；落锁速度；驻车解锁；热保护
。
用户可根据需求定制锁功能
。
本技术实施例可以从多个不同的车门锁控制的应用场景进行说明，分别为中控解闭锁的功能场景以及行车自动落锁与驻车解闭锁的功能场景
。
当用户选定的解闭锁场景为行车自动落锁时，车辆的四个车门进行行车自动落锁功能，此时，车辆需达到的预设运行状态为车辆速度从0达到指定速度，例如
20km/h
时，对车门进行自动锁定；或者当车辆速度达到指定速度并保持设定时长，例如5秒后，车门进行自动落锁并锁止
。
当用户选定的解闭锁场景为驻车解锁时，车辆驻车档位需满足
p
档，车辆静止
。
当用户选定的解闭锁场景为中控解闭锁时，车辆所有车门及后备箱处于完全关闭状态
。
54.本步骤中，若车辆的当前服务状态不满足预设门锁控制前置条件，则向用户发送提示信息，例如，当需要中控解闭锁时，提示用户具体某车门未完全关闭等
。
55.步骤
s140
，增强服务层基于控制参数确定与门锁硬件配置类型相对应的驱动策略，以及与驱动策略对应的目标增强服务，以对门锁进行控制
。
56.本步骤中，基于控制参数确定目标增强服务的方法包括：增强服务层的增强服务被调用，并对控制参数进行校验，若控制参数校验通过，则判断控制参数为有效数据，基于控制参数确定与门锁硬件配置类型相对应的驱动策略，以及与驱动策略对应的目标增强服务
。
对控制参数的校验包括输入范围校验
、
有效性校验，主要是对门锁功能请求的门锁解锁
、
门锁闭锁的校验，确定所发出的门锁功能请求是对具体车门的解锁指令或闭锁指令
。
当控制参数为有效数据时，目标增强服务发出的调用指令才为有效指令
。
若判断控制参数为无效数据，则维持车辆的当前增强服务状态
。
57.本步骤中，驱动策略包括实时检测门锁的当前微开状态，增强服务层调用原子服务层传递与门锁硬件配置类型对应的控制指令至输入输出抽象层，输入输出抽象层切换门锁的当前微开状态至门锁硬件配置类型对应的中间微开状态，并执行控制指令，执行结束后，退出中间微开状态，进入解锁或闭锁状态
。
进一步的优选，目标增强服务完成控制对象的控制，门锁的具体控制逻辑由目标增强服务实现，一个目标增强服务可以被多个解闭锁
场景调用
。
原子服务层接收来自目标增强服务的控制指令，此处的控制指令为有效调用指令，并屏蔽输入输出抽象层的变动对目标增强服务的影响，实现软硬件解耦
。
门锁硬件配置类型对应的中间微开状态包括但不限于，吸合锁对应的吸合状态，释放锁对应的释放状态
。
输入输出抽象层执行控制指令，控制门锁电机动作，进行解闭锁行程
。
58.本步骤中，平台化汽车控制方法还存储门锁硬件类型，以及与门锁硬件配置类型相对应的驱动策略
。
59.图2为本技术一示例性实施例示出的平台化汽车门锁软件架构示意图，如图2所示，本技术平台化汽车门锁控制方法基于
soa
架构，将软件应用层分为基础服务层
、
场景服务层
、
系统服务层
、
增强服务层和原子服务层
。
其中，场景服务层与基础服务层可以用于域间通信，供域外调用，实现软开关设置
。
场景服务层用于提供接口给用户自定义编排解闭锁场景调用，并根据用户设定的解闭锁场景向增强服务层发出门锁功能请求，增强服务层对门锁功能请求对应的控制参数进行入参校验，判断其有效性
。
增条服务层基于控制参数调用原子服务层，原子服务层接收来自目标增强服务的控制指令，并屏蔽
i/o
抽象层的变动对目标增强服务的影响，实现软硬件解耦
。
原子服务层调用
i/o
抽象层发送控制指令控制门锁电机动作，实现解闭锁
。
60.在一些实施例中，由场景服务层进行域外调用，以允许用户编排解闭锁场景，并向基础服务层发送解闭锁场景对应的门锁功能请求
。
基础服务层
(basc)
包括允许用户设置锁功能设置服务，以及用户不可设置的锁硬件设置服务
。
锁硬件设置服务为用户不可设置的服务，根据不同的车型与配置设置好锁类型，儿童锁类型，锁状态硬线反馈配置
。
锁功能设置服务中提供对外接口供域外调用，可设置与门锁功能请求对应的控制参数，设置热保护
、
行车自动落锁
、
落锁速度
、
解锁模式
、
驻车解锁等功能，用户可根据需求定制功能
。
基础服务层受到域外调用传参处理后将控制参数通过
ntf
接口通知出去给域内服务使用，从而读取并通知门锁硬件配置类型，包括中控锁
、
吸合锁
、
释放锁的单独使用或组合使用
。
用户可以通过车辆中控屏的软开关设置选择是否开启多种解闭锁功能，车辆的解闭锁功能包括中控解闭锁
、
门内外开关解闭锁
、
碰撞解锁
、
动力电池失控解锁
、
行车自动落锁
、
驻车自动解锁
、
双拉门内把手解锁等
。
系统服务层
(sys)
提供中控解闭锁
、
门内外开关解闭锁
、
动力电池热失控解锁
、
驻车解锁
、
行车自动落锁等解闭锁情况的条件判断，判断条件为确定车辆的当前增强服务状态，若当前增强服务状态满足预设门锁控制前置条件，则调用增强服务，传递控制解闭锁的控制参数
。
其中，驻车解闭锁和行车自动落锁的功能通过基础服务层
ntf
接口通知的参数确定预设门锁控制前置条件满足时，是否调用增强服务驱动门锁电机执行控制指令
。
进一步的优选，用户的软开关动作调用基础服务层设置的解闭锁功能对应的不同的控制参数，并通知出去，系统服务层收到控制参数后，可以判断是否在预设门锁控制前置条件满足时，调用增强服务驱动门锁电机执行控制指令
。
61.在一些实施例中，不同的门锁硬件配置可以共用一套系统服务，例如，不同的门锁硬件配置需要不同的功能，以读取门锁硬件配置类型，基础服务层通知的信息适配不同的解闭锁功能，如，双拉门内把手功能读取硬件信息为普通中控锁时，满足预设门锁控制前置条件时，调用目标增强服务，为其他门锁硬件配置时则不触发上述功能，不调用目标增强服务
。
不同的门锁硬件配置类型，目标增强服务对应的驱动策略有差异
。
基础服务层会将门锁硬件配置类型
ntf
通知出来，分为中控锁
、
吸合锁
、
释放锁，它们可以单独使用，也可以自由
组合
。
基础服务层通知读取到的不同门锁硬件配置类型，增强服务层根据对应的门锁硬件配置类型执行不同的驱动策略
。
中控锁驱动策略包括的控制指令可以为解锁
、
闭锁；释放锁驱动策略包括的控制指令可以为释放；吸合锁驱动策略包括的控制指令可以为吸合；吸合释放锁驱动策略包括的控制指令可以为释放
、
吸合
。
驱动策略还包括基于控制指令，调用原子服务层发送控制指令，使
i/o
抽象层控制电机动作
。
62.图3为本技术一示例性实施例示出的门锁驱动过程示意图，如图3所示，本技术提供不同门锁硬件配置类型的驱动过程
。
63.实施例164.当门锁硬件配置类型为电释放锁时，响应于接收到的门锁功能请求，例如，中控解闭锁
、
行车自动落锁
、
驻车自动解锁时，增强服务层收到的控制指令为解闭锁指令，不会有电机驱动过程的控制逻辑，因为没有实体中控锁，所以收到的控制指令为有效调用指令时，目标增强服务会调用锁标志基础服务，解锁时将标志位置为1，表示中控解锁，此时，车外乘客可以触发外开关打开车门；闭锁时中控指示灯亮起，表示中控闭锁，此时，车外乘客触发外开关无法打开车门
。
当门外开关释放服务或门开解锁服务触发调用目标增强服务时，传递有效控制指令释放，原子服务层收到有效释放指令后会调用
i/o
抽象层进行门锁电机驱动过程的控制
。
进一步的优选，车辆系统上电后，车辆进入
init
初始化状态，读取并通知门锁硬件配置类型为释放锁，检测门锁的当前微开状态为门开或门关，并根据当前微开状态进入
lock
闭锁状态，或
unlock
解锁状态，收到有效释放指令后，触发目标增强服务调用原子服务层向
i/o
抽象层传递有效释放指令，切换门锁的当前微开状态至门锁硬件配置类型对应的中间微开状态，即，释放状态
(releasing)
并执行控制指令，执行结束后，退出释放状态，当检测到当前门锁微开状态为门开时，跳转到
unlock
状态
。
当检测到当前门锁微开状态为门关时，跳转到
lock
状态
。
65.在一些实施例中，当电力电池热失控或碰撞发生时，不能直接驱动释放弹开门，发送解锁指令，目标增强服务通过
id(
身份识别
)
识别到为电力电池热失控或碰撞时进入
unlocking
状态，触发目标增强服务调用原子服务层发送有效解锁指令，驱动电机进行解锁行程，不弹开门，当行程结束后，用户可以通过机械拉手打开门，进入
unlock
状态
。
在上述过程中，驱动电机使门锁为
releasing
状态
、unlocking
状态的中间微开状态时，同时也会调用基础服务将解闭锁标志位置为
1。
66.实施例267.当门锁硬件配置类型为普通中控锁时，基础服务层通知门锁硬件配置类型为中控锁，系统服务层判断满足预设门锁控制前置条件时，发送有效解锁指令或有效闭锁指令，有效解锁指令和有效闭锁指令都会执行电机驱动过程
。
车辆系统上电后，进入初始化状态，根据锁状态硬线反馈进入
unlock
状态或
lock
状态，收到有效解锁指令或有效闭锁指令时，进入
unlocking
状态或
locking
状态，触发目标增强服务调用原子服务层传递有效解锁指令或有效闭锁指令驱动电机执行，接收到锁状态硬线反馈为闭锁或解锁时，退出当前中间微开状态，进入
unlock
状态或
lock
状态
。
中控锁关闭时，乘客无法在门外拉动门把手开门
。
68.实施例369.当门锁硬件配置类型为吸合锁时，基础服务层通知门锁硬件配置类型为吸合锁，系统服务层判断满足预设门锁控制前置条件时，发送有效吸合指令
。
车辆系统上电后，进入
初始化状态，目标增强服务收到有效吸合指令后，调用原子服务层传递有效吸合指令使门锁进入中间微开状态，即
pulling
状态
(
吸合状态
)
，并通过原子服务层调用
i/o
抽象层驱动电机进行吸合行程，关闭车门，当检测到当前门锁微开状态为门关时，退出吸合行程，跳转至
lock
状态
。
70.在一些实施例中，本技术平台化汽车门锁控制方法基于
soa
架构，在软件应用层中还设置配置字存储服务，为每个软件模块分别配置字存储块，以存储门锁硬件配置类型，以及门锁硬件配置类型对应的驱动策略
。
71.在一些实施例中，不同的门锁硬件配置类型可以进行不同的组合，也可以单独使用，解闭锁功能的设置通过设置基础服务进行配置，不同的门锁硬件读取，以配置字存储块进行区分，执行与门锁硬件配置类型对应的驱动策略
。
本技术提供的平台化汽车门锁控制方法将门锁控制平台化，做到软硬件解耦，适配不同车型，缩短开发周期，减小维护难度，提高软件质量，几乎使用所有门锁控制的功能场景
。
72.图4为本技术一示例性实施例示出的平台化汽车门锁控制系统结构框图，如图4所示，本技术还提供一种平台化汽车门锁控制系统，该系统包括：
73.获取模块
410
，用于响应于接收到的门锁功能请求，读取门锁硬件配置类型，并将门锁硬件配置类型通知至增强服务层；
74.确定模块
420
，用于确定车辆的当前增强服务状态；
75.传递模块
430
，用于在当前增强服务状态满足预设门锁控制前置条件时，则将门锁功能请求对应的控制参数传递给增强服务层；
76.控制模块
440
，增强服务层用于基于控制参数确定与门锁硬件配置类型相对应的驱动策略，以及与驱动策略对应的目标增强服务，以对门锁进行控制
。
77.在一些实施例中，系统还包括存储模块
450
，用于存储门锁硬件类型，以及与门锁硬件配置类型相对应的驱动策略
。
78.需要说明的是，上述实施例所提供的平台化汽车门锁控制系统与上述实施例所提供的平台化汽车门锁控制方法属于同一构思，其中各个模块和单元执行操作的具体方式已经在方法实施例中进行了详细描述，此处不再赘述
。
上述实施例所提供的平台化汽车门锁控制系统在实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将系统的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能，本处也不对此进行限制
。
79.本技术的实施例还提供了一种电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述电子设备实现上述各个实施例中提供的平台化汽车门锁控制方法
。
80.图5示出了适于用来实现本技术实施例的电子设备的计算机系统的结构示意图
。
需要说明的是，图5示出的电子设备的计算机系统
500
仅是一个示例，不应对本技术实施例的功能和使用范围带来任何限制
。
81.如图5所示，计算机系统
500
包括中央处理单元
(central processing unit
，
cpu)501
，其可以根据存储在只读存储器
(read-only memory
，
rom)502
中的程序或者从储存部分
508
加载到随机访问存储器
(random access memory
，
ram)503
中的程序而执行各种适当的动作和处理，例如执行上述实施例中所述的方法
。
在
ram 503
中，还存储有系统操作所需的
各种程序和数据
。cpu 501、rom502
以及
ram 503
通过总线
504
彼此相连
。
输入
/
输出
(input/output
，
i/o)
接口
505
也连接至总线
505。
82.以下部件连接至
i/o
接口
505
：包括键盘
、
鼠标等的输入部分
506
；包括诸如阴极射线管
(cathode ray tube
，
crt)、
液晶显示器
(liquid crystal display
，
lcd)
等以及扬声器等的输出部分
507
；包括硬盘等的储存部分
508
；以及包括诸如
lan(local area network
，局域网
)
卡
、
调制解调器等的网络接口卡的通信部分
509。
通信部分
509
经由诸如因特网的网络执行通信处理
。
驱动器
510
也根据需要连接至
i/o
接口
505。
可拆卸介质
511
，诸如磁盘
、
光盘
、
磁光盘
、
半导体存储器等等，根据需要安装在驱动器
510
上，以便于从其上读出的计算机程序根据需要被安装入储存部分
508。
83.特别地，根据本技术的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序
。
例如，本技术的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的计算机程序
。
在这样的实施例中，该计算机程序可以通过通信部分
509
从网络上被下载和安装，和
/
或从可拆卸介质
511
被安装
。
在该计算机程序被中央处理单元
(cpu)501
执行时，执行本技术的系统中限定的各种功能
。
84.需要说明的是，本技术实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合
。
计算机可读存储介质例如可以是电
、
磁
、
光
、
电磁
、
红外线
、
或半导体的系统
、
装置或器件，或者任意以上的组合
。
计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接
、
便携式计算机磁盘
、
硬盘
、
随机访问存储器
(ram)、
只读存储器
(rom)、
可擦式可编程只读存储器
(erasable programmable read only memory
，
eprom)、
闪存
、
光纤
、
便携式紧凑磁盘只读存储器
(compact disc read-only memory
，
cd-rom)、
光存储器件
、
磁存储器件
、
或者上述的任意合适的组合
。
在本技术中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的计算机程序
。
这种传播的数据信号可以采用多种形式，包括但不限于电磁信号
、
光信号或上述的任意合适的组合
。
计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送
、
传播或者传输用于由指令执行系统
、
装置或者器件使用或者与其结合使用的程序
。
计算机可读介质上包含的计算机程序可以用任何适当的介质传输，包括但不限于：无线
、
有线等等，或者上述的任意合适的组合
。
85.附图中的流程图和框图，图示了按照本技术各种实施例的系统
、
方法和计算机程序产品的可能实现的体系架构
、
功能和操作
。
其中，流程图或框图中的每个方框可以代表一个模块
、
程序段
、
或代码的一部分，上述模块
、
程序段
、
或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令
。
也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生
。
例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定
。
也要注意的是，框图或流程图中的每个方框
、
以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现
。
86.描述于本技术实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬
件的方式来实现，所描述的单元也可以设置在处理器中
。
其中，这些单元的名称在某种情况下并不构成对该单元本身的限定
。
87.本技术的另一方面还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被计算机的处理器执行时，使计算机执行如前所述的平台化汽车门锁控制方法
。
该计算机可读存储介质可以是上述实施例中描述的电子设备中所包含的，也可以是单独存在，而未装配入该电子设备中
。
88.本技术的另一方面还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中
。
计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各个实施例中提供的平台化汽车门锁控制方法
。
89.上述实施例仅例示性说明本发明的原理及其功效，而非用于限制本发明
。
任何熟悉此技术的人士皆可在不违背本发明的精神及范畴下，对上述实施例进行修饰或改变
。
因此，举凡所属技术领域中具有通常知识者在未脱离本发明所揭示的精神与技术思想下所完成的一切等效修饰或改变，仍应由本发明的权利要求所涵盖
。