组态技术在汽车售后维修领域的应用研究

耿 琦，赵沛时，陈宇鹏，厉健峰，孙 琦，齐光石，葛 亮，洪 宇

（1，中国第一汽车股份有限公司技术中心、汽车电子部，吉林长春，130011；2，启明信息技术股份有限公司，汽车电子，长春，130117）

组态技术在汽车售后维修领域的应用研究

耿 琦1，赵沛时2，陈宇鹏1，厉健峰1，孙 琦1，齐光石2，葛 亮2，洪 宇1

（1，中国第一汽车股份有限公司技术中心、汽车电子部，吉林长春，130011；2，启明信息技术股份有限公司，汽车电子，长春，130117）

本文通过对汽车售后维修领域中诊断程序的传统开发方式与组态化开发方式的对比，论述了传统开发方式的局限性和诊断程序组态化的必要性，并据此设计了诊断程序组态化开发系统，大大降低了新增诊断程序的开发周期和开发成本。使之能够在汽车智能化、信息化发展形势下快速响应用户需求。

组态技术；组件开发；诊断程序；售后维修

图1　组态方式和传统方式的开发流程对比

0　引言

随着汽车电子化和信息化程度越来越高，尤其是自动驾驶、主动安全、智能化控制技术的引入，使得汽车内电子控制单元的数量飞速增长，从原有的几个、十几个，增加到几十个、甚至上百个，功能与结构也愈加复杂。整车电控单元的增加不仅加大了设计开发的难度，更给售后维修带来了巨大的挑战，对售后维修诊断程序从研发、测试、实施到维护各个环节的响应时间都提出了更高的要求。

传统方式下，开发人员是项目资源中最为重要的要素，项目的成败与优劣在很大程度上取决于开发人员的技术能力高低以及责任心强弱。因此，在项目开发过程中，为了降低项目风险往往会增加代码审查、同行评审等管理手段，带来必要的“额外”开销，增加时间成本和人力成本。更重要的是，传统方式要求开发人员必须具备专业的程序设计经验以及相关的行业经验，这无疑将增大人力成本的投入以及由于人才流动而带来的巨大项目风险。组态方式相当于将以往的项目经验以组件的方式固化，可以汇集最优秀的开发人员与测试人员在短期内完成组件的开发，对于使用者而言不需要了解程序设计方法，只要经过简单的培训即可掌握组态开发，能够降低项目的开发难度，减少由于“开发人员”个体差异而导致的项目风险，节省项目成本。

由此可见，传统开发方式已经明显的不再适应当前工业智能化、信息化的发展需要，而组态方式则在快速开发方面表现出旺盛的生命力！因此，本文将结合售后维修领域内诊断程序的业务特点，探讨研究将组态技术在汽车售后维修领域予以应用的具体实施路线。

图2　诊断程序的基础架构

图3　售后组态软件的业务流图

1　诊断程序组态化的必要性

所谓“组态（Configure）”，其含义就是“配置”、“设定”的意思，是指用户通过类似“搭积木”的简单方式来完成自己所需要的软件功能，而不需要编写计算机程序，有时候也称为“二次开发”，组态软件就称为“二次开发平台”。在组态概念出现之前，要实现某一任务，都是通过编写系统软件（如使用DELPHI、C、C#等）来实现的。编写系统软件需要软件开发人员、UI设计人员、业务分析人员等多方向专业人才的协同工作才能实现，不仅涉及大量分析、开发工作，而且对于用户的需求变动往往会导致开发周期过长，容易犯错误，不能保证工期等情况。组态软件的出现，解决了这个问题，它能够弱化系统软件对程序语言的绝对依赖，将用户的“痛点”集中在业务流程的制定与规划上，大大降低了开发难度和开发周期，对于过去需要几个月的工作，通过组态几天就可以完成。

通过图1的对比可见，传统方式的开发流程大致经过需求分析、详细设计、代码开发、功能测试、实施发布几个环节，虽然能够在开发阶段对原有的部分代码进行直接引用，但仍是基于代码层面的复用，一旦用户需求发生变更，需要对底层接口进行更改，那么所有涉及到的复用程序都要重新的编译、测试、发布，对于开发人员而言无异于是“灾难”。而且由于传统方式下迭代开发的环节过长，对各个环节间的协调、管理提出了更高的要求，项目中很可能出现由于沟通问题而导致的业务偏离，无法满足最终用户的真实需要，致使项目开发陷入困境。

组态方式能够将传统方式下的代码开发、测试工作转化为若干相对小的功能组件的开发、测试，使得功能细化、业务单一、接口明确，具有更强的可测试性以及可移植性。尤其在多人合作开发方面能够做到开发人员间互不干扰，大幅度提升项目的开发效率。而且组件代码体量小，易于维护以及交接，增加了项目的可维护性和健壮性。在人员的要求方面，流程设定者不需要具备相关的软件开发能力，只要对业务流程了解即可胜任。因此，能够将业务人员与开发人员的职责更加清晰的分开，便于在不同领域更好的深入研究。项目实施过程中，一旦发生用户的业务变更，只要不涉及组件功能的变更，仅是流程方面的调整，现场人员即可完成修改，实现项目的快速迭代。

图4　图形化节点设计（部分）

2　诊断程序组态化的架构基础

诊断程序的基础架构如图2所示，主要由如下几个部分组成：

●UI表现层

本层主要用于接受用户的输入和执行用户请求，包含窗体、按钮、编辑框、列表框、选择框、树状视图等可视化控件的动作及事件等内容。例如：窗体的创建、销毁事件，编辑框的单击、双击事件，按钮的按下、抬起动作，树状视图的展开、收起动作等。

●业务逻辑层

本层是诊断程序中体现核心价值的部分。它的关注点主要集中在诊断规则的制定、诊断流程的实现等与诊断需求有关的系统设计，处于UI表现层与诊断应用层中间，起到了承上启下的作用。

●诊断应用层

本层是对标准诊断协议（ISO 14229-1/ISO 15765-3 etc.）以及非标准诊断协议（厂家自定义）的函数封装，主要为业务逻辑层提供访问接口，完成汽车售后维修时的故障诊断功能。

●服务驱动层

本层的主要作用是建立诊断设备和ECU间的虚拟链路，隐藏数据传输过程中的拆包、组包等技术细节，实现端与端之间的应用层报文透明传输。在总线采用标准诊断协议时，即为网络层的全部功能（例如：对ISO 15765-2的实现）。

●硬件驱动层

为上层提供统一的访问接口（例如：Open/Close/Send/Recv etc.）。在内部实现过程中，针对不同的硬件开发不同的实现逻辑。

通过上面的分析可见，售后维修诊断程序具有清晰的基础架构，各层间是一种弱耦合结构，层与层之间的依赖是向下的，底层对于上层而言是“无知”的，改变上层的设计对于其调用的底层而言没有任何影响，是一个支持可抽取、可替换的“抽屉”式架构。而且，在层内部的业务定义明确、接口单一，非常适合进行进一步的封装。这些都为组件封装提供了前提保障，是实现组态工具开发的必要条件。

3　诊断程序组态化的关键技术

在设计开发汽车售后领域组态产品时，我们首先根据诊断程序的基础架构对业务功能所涉及的复杂过程进行切分，形成若干个功能独立、接口单一的简单过程。而后按照“高内聚低耦合”的设计原则，采用面向对象方法封装功能组件，并依据组件用途以组件库的形式提供基础组件库（循环/分支/过程/子过程/…）、协议组件库（ISO 15765/SAE J1939/…）、CAN总线组件库、消息组件库、日志组件库、外部接口组件库（MES接口/ERP接口/SAP接口/…）等分组供用户调用。

考虑到虽然单个电控单元诊断程序的业务逻辑复杂，但是不同电控单元间的复用度却很高。因此，我们设计支持用户自定义“过程”的开发，也就是说用户可以将 “序列片段”保存为“过程”，形成 “自定义组件”供程序调用。这样即是实现了序列的嵌套调用，不但能够简化用户使用组态软件开发时诊断序列图的规模，而且能够增加复用度，提高开发效率。例如：可以自定义“安全访问”组件，包含【“请求种子”（27 01）CAN发送CAN接收提取“种子”计算“密钥”“验证密钥”（27 02）…】的子序列。在组态开发过程中，其它序列在编辑的时候可以直接引用此“自定义组件”完成安全访问，而不需要在主序列里重新编辑。

综合考虑诊断程序组态工具的开发过程，项目主要难点在于图形化节点的设计开发，以及宿主语言与脚本语言的融合两方面内容。

3.1图形化节点设计

在设计过程中，我们尽量将图形化节点的逻辑部分与业务部分进行解耦，也就是务求避免在生成逻辑代码时对业务代码进行引用。因此，我们首先实现了程序的基本结构，即顺序、循环、分支。并借鉴C#里的代码组织方式，设计Region节点，实现多节点的收起与展开，设计效果如图5所示。在每个节点的创建与删除时，需要对节点的位置信息进行动态计算，并内置脚本语言的部分代码，同时记录节点的生成次序以及各个节点间的父子、兄弟关系。也就是将逻辑关系通过节点的先后顺序，生成带有有向环的树形结构。在生成代码时，从树形结构的根节点开始遍历，串联所有节点部分预置的脚本语言代码片段，最终生成完整的脚本代码，供解释器识别、执行。（鉴于产品的保密原因，代码部分省略）

3.2宿主语言与脚本语言的融合

考虑到组态软件的执行效率以及用户使用复杂度等因素，我们在设计组态节点时将软件所涉及到的API接口用宿主语言进行部分的功能封装，例如：UI显示时提供标准控件的属性设置、内容设置等接口（向LISTBOX控件中插入、删除行），提供基础控件的事件触发回调接口（按钮、复选框的点击事件、窗体的创建事件等）。在与ECU通信过程中，提供CAN、K总线收发，KWP 2000协议解析，15765协议解析等调用接口。各个不同的功能封装间通过脚本语言调用WINDOWS里的ACTIVE X接口实现宿主语言与脚本语言的信息交互和功能融合。在宿主语言和脚本语言的协调方面，我们摒弃了大脚本（即所有的业务逻辑通过一个或几个体量较大的脚本文件实现）的设计思路，采用以宿主语言作为驱动器，将业务逻辑分散到很多个小的脚本文件中存储、加载、执行，目的在于增强宿主语言与脚本语言的交互频率，缩短单个脚本的运行周期，使得应用程序在执行脚本的过程中也可以快速响应用户的外部动作，增强用户的体验性以及避免出现由于脚本执行时间过长而产生的界面卡顿现象。

本项目在技术方面充分的利用了脚本的“多语言粘合”能力，将传统方式下的软件开发转化为图形组件的可视化序列开发。项目产品提供大量已开发的电控单元诊断模板和标准诊断过程供用户参考、引用。还提供可视化序列的复制、粘贴、存储、导入等功能，使得用户在开发过程中可能仅仅需要对原有序列的部分协议命令、输入输出内容等组件参数进行微调即可完成新电控单元的诊断功能。

4　系统应用现状

从项目开发角度分析，组态方式相较于传统方式最大的优势在于将项目资源的重心从“开发人员”转向为“开发工具”。虽然仅仅是思路上的“改变”，然而在应用过程中体现的则是效率上的巨大“变革”。

以V501项目为例，全车共28个电控单元。按照传统的方式计算，单电控诊断程序的开发大约需要2个人1个月的开发、调试、测试周期，预计开发全车电控诊断程序的总工作量大约为56人月，实际项目周期应该在6个月以上。而实际项目中，我们应用组态方式进行售后维修诊断程序的开发，从需求获取到软件交付使用仅仅占用了4个人2个月的时间（4人均为非专业开发人员）。由此可见，使用组态方式完成项目开发能够大幅度提高开发效率50%以上。

5　总结与展望

在竞争激烈的汽车工业领域，汽车制造业已进入微利时代，更多的获利机会将在售后服务领域。国外汽车制造厂商总利润的30%来源于生产整车的盈利，而在汽车售后服务领域的盈利占总利润的70%。截至2015年底，全国机动车保有量达2.79亿辆，其中汽车1.72亿辆，新能源汽车58.32万辆。随着汽车市场的趋稳，售后服务领域必将成为各方竞相争夺市场份额的主战场，其中售后部门提供服务的品质以及时效性将成为决定战役成败的重要武器。

组态软件是在信息化社会的大背景下，随着工业IT技术的不断发展而诞生、发展起来的。在整个工业自动化软件大家庭中，组态软件属于基础型工具平台。组态软件给工业自动化、信息化、及社会信息化带来的影响是深远的，它带动着整个社会生产、生活方式的变化，这种变化仍在继续发展。因此组态软件作为新生事物尚处于高速发展时期，结合国家十三五规划中所倡导的工业4.0理念，相信将组态软件引入汽车售后维修领域必将带来神奇的化学反应。

［1］ 林伟.浅谈组态软件发展趋势.自动化博览.2003，（S1）.

［2］ 莫晓齐，王耀南.组态软件用户图形界面的设计与开发［J］.计算机工程与设计.2006年01期

［3］ 熊杰，陈忠.设计模式在组态软件图形用户界面中的应用［J］.长江大学学报（自然科学版）理工卷.2008年04期

［4］ 杨焱.汽车后市场服务连锁经营模式研究［D］ .天津大学.2006年

［5］ 《截至2015年底中国机动车保有量达2.79亿辆》.中商情报网.2016年

Research and application on Configuration Technology in the field of automobile after-sales service

Geng Qi1，Zhao Peishi2，Chen Yupeng1，Li Jianfeng1，Sun Qi1，Qi Guangshi2，Ge Liang2，Hong Yu1，
（1.China FAW Co.，Ltd. Research and Development Center；2.QIMING INFORMATION TECHNOLOGY Co.，Ltd.）

This article discussed that the limitations of traditional development mode on diagnosis procedures in the field of automobile service and the necessity of the configuration development mode by contrasting between two modes.Based on the concept of configuration technology，the diagnostic procedure configuration of the development system on configuration mode is designed，which can greatly reduce development time and cost，and give quick response to customers requirement form intelligence and information technology developments.

configuration technology；configuration development；diagnosis procedure；after-sales service