一种基于SOA架构的车窗控制系统

技术领域

本发明涉及服务化软件架构技术领域，具体涉及一种基于SOA架构的车窗控制系统。

背景技术

随着汽车行业“新四化”发展的不断深入，汽车电控化、智能化、网联化程度越来越高；对用户需求的关注和理解越来越多；ICT行业、互联网行业技术不断向汽车行业渗透等等，一起推动了汽车电子电器软硬件技术与相关标准的发展，注入了新的发展动力并带来了对传统架构的巨大冲击。

长期以来，车载电子控制单元开发相对独立，功能调整和升级以及车内电子控制单元增加或更新迭代会产生大量开发工作。因此引入面向服务的架构概念，将车内功能进行服务化的设计并以软件实现，以此保障服务化功能的解耦，降低二次开发成本。国内外汽车制造主机厂均在加大汽车研发的软件投入力度。

将整车各个功能定义为服务时，需遵循服务独立化的原则。通过分布在整车各个位置的电子控制单元以及执行器控制是实现整车功能的传统方法，但是当前整车电子电气架构正朝着中央集中运算单元加多个域控制器的方向发展，很多整车功能将由域控制器直接控制执行单元来实现，因此将整车功能进行服务化重新定义带来了可能。然而，现有技术中软硬件之间是绑定在一起的，一旦整车增加新的硬件设备，必然需要对整车的软件进行及时调整，这也使得很多软件的复用率不高，往往一代产品更新之后便无法继续使用，不仅增加了开发时的工作量，也降低了已有软件的使用率。

发明内容

针对现有技术存在的上述不足，本发明的目的在于提供一种基于SOA架构的车窗控制系统，以解决现有技术中软硬件绑定导致更新迭代工作量大、软件复用率低的问题。

为了解决上述技术问题，本发明采用如下技术方案：

一种基于SOA架构的车窗控制系统，包括I/O抽象层、原子服务层、系统服务层、场景服务层和增强服务层；

其中，I/O抽象层用于获取硬件系统或者元器件的物理状态，并对其进行表征，驱动执行器执行控制命令；

原子服务层用于监听I/O抽象层发出的硬件状态变化，经过优先级仲裁以及信号处理后，向系统服务层发出操作请求，驱动执行器执行控制命令；

系统服务层用于接收原子服务层发出的操作请求，并对多个操作请求进行优先级仲裁，然后进行执行条件的判断，向场景服务层发出操作请求；

场景服务层用于向其他系统或域提供服务以及接口，并供其他系统和域调用；

增强服务层用于向系统服务层和场景服务层提供执行器控制接口，并对域内调用和域外调用进行优先级仲裁，向原子服务层发送执行器控制命令。

与现有技术相比，本发明具有如下有益效果：

1、本发明所述系统根据服务化软件架构设计的总体原则，结合电动车窗系统的实际软硬件设计方案和功能/性能需求，定义各层服务应该完成的功能、各层服务之间的接口以及相关的数据类型，将软件组件按照功能进行拆分，并布置到不同服务层上，达到灵活修改、重组、调用的目的。

2、本发明所述系统具有多路输入控制同一个对象的复杂性，对于操作开关的仲裁、聚合进行特殊处理，使开关数量/类型的改变不会对上层服务，即系统服务层、场景服务层和增强服务层造成影响，即使新增开关或者使用其他类型的开关，也不用对系统服务层、场景服务层和增强服务层进行修改。

3、本发明所述系统基于SOA理念，实现软硬件解绑，提高软件复用率，对各层服务功能和接口进行明确定义和规范，互不干扰。

附图说明

图1为本发明所述系统的服务化软件架构图。

具体实施方式

为了使本发明的实施例的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述，所描述的实施例不应视为对本发明的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

本发明提供一种基于SOA架构的车窗控制系统，包括I/O抽象层、原子服务层、系统服务层、场景服务层和增强服务层。本发明根据服务化软件架构设计的总体原则，结合电动车窗系统的实际软硬件设计方案和功能/性能需求，定义各层服务应该完成的功能、各层服务之间的接口以及相关的数据类型。

其中，I/O抽象层用于获取硬件系统或者元器件的物理状态，并对其进行表征，驱动执行器执行控制命令。所述I/O抽象层，用于控制车控域内硬件开关的开闭，以及车门的打开/关闭，并设置多个档位值，通过档位值表示硬件开关以及车门的状态。针对电动车窗系统，I/O抽象层需要处理以下硬件操作：（1）车控域内硬件开关；（2）车门打开/关闭状态。对于硬件开关，I/O抽象层向外发送开关档位值，例如：档位1、档位2、档位3等。这些数据不具备应用语义，反应的是元器件物理状态。对于车门打开/关闭状态，I/O抽象层向外发送状态值，例如：打开状态、关闭状态。该状态值在硬件上已经可以获得应用语义。每个硬件信号，都有操作状态和故障状态，无论该硬件信号故障状态是否置为1，操作状态都必须发送出来。I/O抽象层还要集成复杂驱动、算法等软件SWC。

原子服务层用于监听I/O抽象层发出的硬件状态变化，经过优先级仲裁以及信号处理后，向系统服务层发出操作请求，驱动执行器执行控制命令。所述原子服务层接收I/O抽象层发送的硬件信号后，将其转变为对控制对象的请求，并将该请求发送至系统服务层。

所述原子服务层对I/O抽象层发送的硬件信号进行判定，并根据判定结果生成对应的硬件信号请求。其中，对于某一个硬件信号，首先判断该硬件信号的故障状态，再判断该硬件信号的使能状态，然后才生成该硬件信号的请求。所述原子服务层接收到多个同一类型、来源不同的硬件信号时，对多个硬件信号进行第一级优先级判定，并根据判定结果进行信号处理。其中，对于同一类型但来源不同的硬件信号生成的请求，原子服务要进行第一级优先级判定

系统服务层用于接收原子服务层发出的操作请求，并对多个操作请求进行优先级仲裁，然后进行执行条件的判断，向场景服务层发出操作请求。其中，所述系统服务层接收原子服务层发送的操作请求后，进行前置条件检查。当所述系统服务层接收多个原子服务层发送的操作请求时，对其进行第二级优先级判定，经过前置条件检查和优先级判定后，根据判定结果，调用增强服务层的RR接口执行操作请求。

场景服务层用于向其他系统或域提供服务以及接口，并供其他系统和域调用。场景服务层与系统服务层处于同一层次，但系统服务层是车窗系统域内使用，场景服务层用于对外提供调用接口，在进行场景服务调用时不做前置条件判断。所述场景服务层还用于向上提供对增强服务层参数的设置。所述场景服务层同时向域外发送当前车窗系统软硬件状态信号，以供域外其他系统及时了解当前车窗系统中软硬件的状态。

增强服务层用于向系统服务层和场景服务层提供执行器控制接口，并对域内调用和域外调用进行优先级仲裁，向原子服务层发送执行器控制命令。所述增强服务层为主状态机所在层，用于对控制对象驱动的逻辑控制，并及时从原子服务层获取控制对象的各硬件状态。

如上所述，本发明的提醒系统不限于所述配置，其他可以实现本发明的实施例的系统均可落入本发明所保护的范围内。

最后需要说明的是，以上实施例仅用以说明本发明的技术方案而非限制技术方案，本领域的普通技术人员应当理解，那些对本发明的技术方案进行修改或者等同替换，而不脱离本技术方案的宗旨和范围，均应涵盖在本发明的权利要求范围当中。