基于面向服务架构的软件开发方法研究

基于面向服务架构的软件开发方法研究

郑勇平

浙江上易节能科技股份有限公司 衢州市柯城区 324000

摘要：汽车的电子电气架构逐步由中央网关式分布架构演进为面向服务的域控制架构，这样能够解决整车级功能增多导致的分布式架构接口太过复杂、不便于功能快速迭代的问题，同时有利于实现软硬件松耦合甚至软硬件解耦[2]。为把握开发主导权，整车厂倾向于核心软件模块自主研发，以域控制架构为框架的整车电子电气开发要求整车厂具备较强的软件集成能力。基于SOA（ServiceOrientedArchitecture，面向服务架构）的软件架构及软件开发将是未来汽车电子电气发展方向。基于面向服务架构的软件开发背景以及开发方法，结合此方法给出实际应用案例。本文主要分析基于面向服务架构的软件开发方法。

关键词：面向服务；电子电气架构；软件开发

引言

今后，智能和联网将成为汽车技术发展的主要动力，并将推动汽车领域的重大创新，包括新的节能和减排、自动驾驶和新的运输方式。智能联动汽车的大部分功能特性都是通过软件实现的，但传统的嵌入式汽车软件开发方法难以支持汽车软件的规模和复杂性呈指数增长。汽车工业还引进了先进的信息技术，其面向服务的体系结构(SOA)被认为是支持未来汽车软件开发的基本技术之一。以服务为导向的软件是一种软件设计模式，自1990年代推出以来迅速发展并广泛应用于信息技术领域。SOA具有松散耦合、重用和易于集成等优点，可以支持智能连接汽车软件开发的需求。自适应平台还为汽车中实施SOA软件提供了技术解决方案。在现有文献中，SOA软件开发方法的研究主要集中在it业务领域，而汽车领域的研究则集中在技术实现或个别开发案例上，SOA汽车软件开发方法的研究很少。SOA不仅是一种软件实施技术，更重要的是，它是一种软件设计模式，只有使用适当的开发方法才能有效地利用SOA的优势。本文探讨了SOA汽车软件开发方法，并将其付诸实践:第一部分提出了SOA汽车软件分层模型；第二部分介绍了基于分层模型的SOA汽车软件开发的两种方法；因此，第三部分介绍了基于这两种方法的发展做法；第四节介绍如何在域控制器上部署SOA引擎软件。最后总结一下。

1、SOA汽车软件分层模型

在术语中，将客户的特定需求称之为业务需求，将描述业务需求的一种形式称为业务用例，将业务用例的实现过程称为业务过程，将业务过程中完成特定任务的一部分逻辑称为业务逻辑。在面向服务架构中，“服务”是对业务逻辑的封装，具有明确定义的接口，并被独立的实现；“面向服务”定义了一种方法，这种方法通过连接多个“服务”实现业务需求。“服务”所封装业务逻辑的大小，决定了“服务”在业务过程中涉及的范围，直接决定了“服务”的自治、重用等关键特性，是SOA架构设计的核心问题。在SOA汽车软件设计中，必须有清晰的模型作为依据，才能有效地发挥SOA的优势。参考IT领域良好实践，本文提出一种SOA汽车软件分层模型，包括元服务、基础服务和应用服务三个层级，使不同层级的“服务”分别对应不同层级的汽车业务逻辑。

1.1元服务

元服务是最小单元。从业务角度，元服务是对底层逻辑的封装，不具有再拆分的意义和价值；从架构角度，元服务是高度通用、高度自治和可重用的功能单元，构建了整个SOA架构的底层基础结构。汽车的传感器、执行器等基本接口和车辆基本参数可封装为元服务，例如，将车速、车辆惯性状态等参数封装为“车辆状态”元服务，可以对上层服务架构提供支持。

1.2基础服务

基础服务是分层模型的中间层服务。从业务角度，基础服务封装了更多的业务逻辑，即组合了若干元服务；从架构角度，基础服务可以访问和调用元服务以实现更大范围的业务过程。基础服务应是足够自治和可重用的。在利用元服务的基础上，可重用的汽车业务逻辑可封装为基础服务，例如，在利用自车车辆状态服务、雷达等传感器信息服务以及其他信息的基础上，可构建“环境信息融合”服务，作为基础服务。

1.3应用服务

应用服务是分层模型的最顶层服务。从业务过程角度，应用服务可以包括一个业务过程的全部业务逻辑，封装了与特定业务有关的基础服务；从架构角度，应用服务可以访问和调用基础服务以帮助其解决业务问题。元服务和基础服务更强调架构的灵活性，而应用服务则更强调商业意义，和业务需求有非常紧密的联系。具有客户价值的业务用例可作为应用服务，例如，“能量预测管理”是一个应用服务，它利用车辆状态元服务、环境信息融合基础服务和其他服务，从而实现了通过智能管理降低车辆能耗这一具有商业意义的业务需求。在设计中，上层服务调用下层服务，下层服务不调用上层服务，这一原则有助于构建清晰简单的SOA汽车软件架构。参考以上分层模型，可以有效定义SOA汽车软件的开发方法，从而有效地发挥和获得SOA的优势。

2、SOA软件开发方法

基于SOA的软件开发旨在通过组合和组织多个软件组件来实现功能，这些软件组件是具有多个服务接口的独立可执行单元，其运行方式必须与平台软件通信模块的通信类型相匹配。在软件开发中，首先需要根据硬件配置、可执行单元设计、服务接口设计、网络设计和软件部署设计等来创建automotive open systems architecture extensible mark language(可扩展标记语言)。使用平台软件工具加载XML文件并生成接口代码：最后，将函数逻辑与接口代码集成以生成软件包。

2.1ARXML制作

ARXML制作包括以下七类内容。1)数据类型服务接口的Event(事件)和Method(字段)类型参数必须关联，并且只能与一种数据类型关联。定义数据类型时，必须使用结构或表类型将服务接口数据与服务接口的设计和使用结合起来，或者直接使用基础类型和由基础类型定义的数据类型。2)服务接口不同类型的服务接口操作使用不同的ARXML标记和配置属性。Event类型用于引用将数据发送到Event的数据类型。Method类型用于配置输入和输出参数。带有输出参数的服务接口操作类型为methodr&r，不带输出参数的操作类型为methodf&f . 3)硬件定义硬件定义需要定义网络连接信息，在不同类型的服务发现中配置多个时间参数，如本地IP地址和广播地址4)可执行单元根据体系结构设计将可执行组件与服务接口进行匹配；定义可执行单元的可执行单元进程：可执行单元进程是硬件定义的进程的核心。5)服务部署主要是分配服务接口id(标识、标识号)以满足配置版本的要求。如果服务接口操作使用事件组，则必须定义事件组并为服务接口操作分配一个标识号。Field类型没有ID号，使用EventID。字段具有“通知”操作时。当Field使用Getter或Setter时，会使用MethodID。此外，还必须配置传输协议以运行服务接口，方法是验证传输协议是TCP(transmission control protocol)还是UDP(UserDatagramProtocol)。6)服务实例主要分配给服务接口实例ID、对服务发现(SD)配置参数的引用以及与可执行单元和进程的关联。7)设备映射是服务实例通过分配网络端口号与设备通信链路的映射。

2.2应用代码开发及编译

应用程式码由四个类别组成:主要功能、程式设计类别、服务介面类别及演算法类别。(1)主要功能是可执行单元的主要条目，执行初始化日志类，实例化调度类，调用调度类对象的初始化、执行和关闭功能。(2)编程类用于聚合服务接口类、创建执行线程和控制执行周期。实例化每个服务接口类和算法类，控制每个实例化对象的执行顺序和执行条件，控制每个服务的服务提供，或搜索、停止或停止服务。(3)服务接口类负责模块之间的通信。(4)算法类是结合应用的具体算法，实现方法与传统开发方法相同。生成接口代码和应用程序代码后，编译库文件、接口代码和adaptive auto ar(adapter automotive open system architecture)应用程序代码以生成可执行文件。

结束语

相比传统软件开发方式，采用SOA开发模式，接口代码可通过标准化方式生成，减少写代码的工作量，降低接口代码与功能逻辑代码的耦合度，提升软件开发效率；同时每个可执行单元相互独立，软件迭代过程中，可以通过小范围的更新完成功能升级，无需整体升级。未来，基于SOA的软件开发将是行业重点关注方向。

参考文献：

[1]刘佳熙，丁锋.面向未来汽车电子电气架构的域控制器平台[J].中国集成电路，2019，28（9）:87-92.

[2]宋杰静，马云杰，田鹏飞.基于PREEvision的以太网SOA设计方法[A].中国汽车工程学会.2019中国汽车工程学会年会论文集[C].2019.1275-1278.

[3]刘佳熙，丁锋.面向未来汽车电子电气架构的域控制器平台[J].中国集成电路,2019,9:82-87.

[4]辛园园，钮俊，谢志军，等．微服务体系结构实现框架综述[J]．计算机工程与应用，2018，54（19）：10-17．