組態(tài)技術在汽車售后維修領域的應用研究

耿 琦，趙沛時，陳宇鵬，厲健峰，孫 琦，齊光石，葛 亮，洪 宇

（1，中國第一汽車股份有限公司技術中心、汽車電子部，吉林長春，130011；2，啟明信息技術股份有限公司，汽車電子，長春，130117）

組態(tài)技術在汽車售后維修領域的應用研究

耿 琦1，趙沛時2，陳宇鵬1，厲健峰1，孫 琦1，齊光石2，葛 亮2，洪 宇1

（1，中國第一汽車股份有限公司技術中心、汽車電子部，吉林長春，130011；2，啟明信息技術股份有限公司，汽車電子，長春，130117）

本文通過對汽車售后維修領域中診斷程序的傳統(tǒng)開發(fā)方式與組態(tài)化開發(fā)方式的對比，論述了傳統(tǒng)開發(fā)方式的局限性和診斷程序組態(tài)化的必要性，并據(jù)此設計了診斷程序組態(tài)化開發(fā)系統(tǒng)，大大降低了新增診斷程序的開發(fā)周期和開發(fā)成本。使之能夠在汽車智能化、信息化發(fā)展形勢下快速響應用戶需求。

組態(tài)技術；組件開發(fā)；診斷程序；售后維修

圖1　組態(tài)方式和傳統(tǒng)方式的開發(fā)流程對比

0　引言

隨著汽車電子化和信息化程度越來越高，尤其是自動駕駛、主動安全、智能化控制技術的引入，使得汽車內(nèi)電子控制單元的數(shù)量飛速增長，從原有的幾個、十幾個，增加到幾十個、甚至上百個，功能與結構也愈加復雜。整車電控單元的增加不僅加大了設計開發(fā)的難度，更給售后維修帶來了巨大的挑戰(zhàn)，對售后維修診斷程序從研發(fā)、測試、實施到維護各個環(huán)節(jié)的響應時間都提出了更高的要求。

傳統(tǒng)方式下，開發(fā)人員是項目資源中最為重要的要素，項目的成敗與優(yōu)劣在很大程度上取決于開發(fā)人員的技術能力高低以及責任心強弱。因此，在項目開發(fā)過程中，為了降低項目風險往往會增加代碼審查、同行評審等管理手段，帶來必要的“額外”開銷，增加時間成本和人力成本。更重要的是，傳統(tǒng)方式要求開發(fā)人員必須具備專業(yè)的程序設計經(jīng)驗以及相關的行業(yè)經(jīng)驗，這無疑將增大人力成本的投入以及由于人才流動而帶來的巨大項目風險。組態(tài)方式相當于將以往的項目經(jīng)驗以組件的方式固化，可以匯集最優(yōu)秀的開發(fā)人員與測試人員在短期內(nèi)完成組件的開發(fā)，對于使用者而言不需要了解程序設計方法，只要經(jīng)過簡單的培訓即可掌握組態(tài)開發(fā)，能夠降低項目的開發(fā)難度，減少由于“開發(fā)人員”個體差異而導致的項目風險，節(jié)省項目成本。

由此可見，傳統(tǒng)開發(fā)方式已經(jīng)明顯的不再適應當前工業(yè)智能化、信息化的發(fā)展需要，而組態(tài)方式則在快速開發(fā)方面表現(xiàn)出旺盛的生命力！因此，本文將結合售后維修領域內(nèi)診斷程序的業(yè)務特點，探討研究將組態(tài)技術在汽車售后維修領域予以應用的具體實施路線。

圖2　診斷程序的基礎架構

圖3　售后組態(tài)軟件的業(yè)務流圖

1　診斷程序組態(tài)化的必要性

所謂“組態(tài)（Configure）”，其含義就是“配置”、“設定”的意思，是指用戶通過類似“搭積木”的簡單方式來完成自己所需要的軟件功能，而不需要編寫計算機程序，有時候也稱為“二次開發(fā)”，組態(tài)軟件就稱為“二次開發(fā)平臺”。在組態(tài)概念出現(xiàn)之前，要實現(xiàn)某一任務，都是通過編寫系統(tǒng)軟件（如使用DELPHI、C、C#等）來實現(xiàn)的。編寫系統(tǒng)軟件需要軟件開發(fā)人員、UI設計人員、業(yè)務分析人員等多方向專業(yè)人才的協(xié)同工作才能實現(xiàn)，不僅涉及大量分析、開發(fā)工作，而且對于用戶的需求變動往往會導致開發(fā)周期過長，容易犯錯誤，不能保證工期等情況。組態(tài)軟件的出現(xiàn)，解決了這個問題，它能夠弱化系統(tǒng)軟件對程序語言的絕對依賴，將用戶的“痛點”集中在業(yè)務流程的制定與規(guī)劃上，大大降低了開發(fā)難度和開發(fā)周期，對于過去需要幾個月的工作，通過組態(tài)幾天就可以完成。

通過圖1的對比可見，傳統(tǒng)方式的開發(fā)流程大致經(jīng)過需求分析、詳細設計、代碼開發(fā)、功能測試、實施發(fā)布幾個環(huán)節(jié)，雖然能夠在開發(fā)階段對原有的部分代碼進行直接引用，但仍是基于代碼層面的復用，一旦用戶需求發(fā)生變更，需要對底層接口進行更改，那么所有涉及到的復用程序都要重新的編譯、測試、發(fā)布，對于開發(fā)人員而言無異于是“災難”。而且由于傳統(tǒng)方式下迭代開發(fā)的環(huán)節(jié)過長，對各個環(huán)節(jié)間的協(xié)調(diào)、管理提出了更高的要求，項目中很可能出現(xiàn)由于溝通問題而導致的業(yè)務偏離，無法滿足最終用戶的真實需要，致使項目開發(fā)陷入困境。

組態(tài)方式能夠將傳統(tǒng)方式下的代碼開發(fā)、測試工作轉化為若干相對小的功能組件的開發(fā)、測試，使得功能細化、業(yè)務單一、接口明確，具有更強的可測試性以及可移植性。尤其在多人合作開發(fā)方面能夠做到開發(fā)人員間互不干擾，大幅度提升項目的開發(fā)效率。而且組件代碼體量小，易于維護以及交接，增加了項目的可維護性和健壯性。在人員的要求方面，流程設定者不需要具備相關的軟件開發(fā)能力，只要對業(yè)務流程了解即可勝任。因此，能夠將業(yè)務人員與開發(fā)人員的職責更加清晰的分開，便于在不同領域更好的深入研究。項目實施過程中，一旦發(fā)生用戶的業(yè)務變更，只要不涉及組件功能的變更，僅是流程方面的調(diào)整，現(xiàn)場人員即可完成修改，實現(xiàn)項目的快速迭代。

圖4　圖形化節(jié)點設計（部分）

2　診斷程序組態(tài)化的架構基礎

診斷程序的基礎架構如圖2所示，主要由如下幾個部分組成：

●UI表現(xiàn)層

本層主要用于接受用戶的輸入和執(zhí)行用戶請求，包含窗體、按鈕、編輯框、列表框、選擇框、樹狀視圖等可視化控件的動作及事件等內(nèi)容。例如：窗體的創(chuàng)建、銷毀事件，編輯框的單擊、雙擊事件，按鈕的按下、抬起動作，樹狀視圖的展開、收起動作等。

●業(yè)務邏輯層

本層是診斷程序中體現(xiàn)核心價值的部分。它的關注點主要集中在診斷規(guī)則的制定、診斷流程的實現(xiàn)等與診斷需求有關的系統(tǒng)設計，處于UI表現(xiàn)層與診斷應用層中間，起到了承上啟下的作用。

●診斷應用層

本層是對標準診斷協(xié)議（ISO 14229-1/ISO 15765-3 etc.）以及非標準診斷協(xié)議（廠家自定義）的函數(shù)封裝，主要為業(yè)務邏輯層提供訪問接口，完成汽車售后維修時的故障診斷功能。

●服務驅動層

本層的主要作用是建立診斷設備和ECU間的虛擬鏈路，隱藏數(shù)據(jù)傳輸過程中的拆包、組包等技術細節(jié)，實現(xiàn)端與端之間的應用層報文透明傳輸。在總線采用標準診斷協(xié)議時，即為網(wǎng)絡層的全部功能（例如：對ISO 15765-2的實現(xiàn)）。

●硬件驅動層

為上層提供統(tǒng)一的訪問接口（例如：Open/Close/Send/Recv etc.）。在內(nèi)部實現(xiàn)過程中，針對不同的硬件開發(fā)不同的實現(xiàn)邏輯。

通過上面的分析可見，售后維修診斷程序具有清晰的基礎架構，各層間是一種弱耦合結構，層與層之間的依賴是向下的，底層對于上層而言是“無知”的，改變上層的設計對于其調(diào)用的底層而言沒有任何影響，是一個支持可抽取、可替換的“抽屜”式架構。而且，在層內(nèi)部的業(yè)務定義明確、接口單一，非常適合進行進一步的封裝。這些都為組件封裝提供了前提保障，是實現(xiàn)組態(tài)工具開發(fā)的必要條件。

3　診斷程序組態(tài)化的關鍵技術

在設計開發(fā)汽車售后領域組態(tài)產(chǎn)品時，我們首先根據(jù)診斷程序的基礎架構對業(yè)務功能所涉及的復雜過程進行切分，形成若干個功能獨立、接口單一的簡單過程。而后按照“高內(nèi)聚低耦合”的設計原則，采用面向對象方法封裝功能組件，并依據(jù)組件用途以組件庫的形式提供基礎組件庫（循環(huán)/分支/過程/子過程/…）、協(xié)議組件庫（ISO 15765/SAE J1939/…）、CAN總線組件庫、消息組件庫、日志組件庫、外部接口組件庫（MES接口/ERP接口/SAP接口/…）等分組供用戶調(diào)用。

考慮到雖然單個電控單元診斷程序的業(yè)務邏輯復雜，但是不同電控單元間的復用度卻很高。因此，我們設計支持用戶自定義“過程”的開發(fā)，也就是說用戶可以將 “序列片段”保存為“過程”，形成 “自定義組件”供程序調(diào)用。這樣即是實現(xiàn)了序列的嵌套調(diào)用，不但能夠簡化用戶使用組態(tài)軟件開發(fā)時診斷序列圖的規(guī)模，而且能夠增加復用度，提高開發(fā)效率。例如：可以自定義“安全訪問”組件，包含【“請求種子”（27 01）CAN發(fā)送CAN接收提取“種子”計算“密鑰”“驗證密鑰”（27 02）…】的子序列。在組態(tài)開發(fā)過程中，其它序列在編輯的時候可以直接引用此“自定義組件”完成安全訪問，而不需要在主序列里重新編輯。

綜合考慮診斷程序組態(tài)工具的開發(fā)過程，項目主要難點在于圖形化節(jié)點的設計開發(fā)，以及宿主語言與腳本語言的融合兩方面內(nèi)容。

3.1圖形化節(jié)點設計

在設計過程中，我們盡量將圖形化節(jié)點的邏輯部分與業(yè)務部分進行解耦，也就是務求避免在生成邏輯代碼時對業(yè)務代碼進行引用。因此，我們首先實現(xiàn)了程序的基本結構，即順序、循環(huán)、分支。并借鑒C#里的代碼組織方式，設計Region節(jié)點，實現(xiàn)多節(jié)點的收起與展開，設計效果如圖5所示。在每個節(jié)點的創(chuàng)建與刪除時，需要對節(jié)點的位置信息進行動態(tài)計算，并內(nèi)置腳本語言的部分代碼，同時記錄節(jié)點的生成次序以及各個節(jié)點間的父子、兄弟關系。也就是將邏輯關系通過節(jié)點的先后順序，生成帶有有向環(huán)的樹形結構。在生成代碼時，從樹形結構的根節(jié)點開始遍歷，串聯(lián)所有節(jié)點部分預置的腳本語言代碼片段，最終生成完整的腳本代碼，供解釋器識別、執(zhí)行。（鑒于產(chǎn)品的保密原因，代碼部分省略）

3.2宿主語言與腳本語言的融合

考慮到組態(tài)軟件的執(zhí)行效率以及用戶使用復雜度等因素，我們在設計組態(tài)節(jié)點時將軟件所涉及到的API接口用宿主語言進行部分的功能封裝，例如：UI顯示時提供標準控件的屬性設置、內(nèi)容設置等接口（向LISTBOX控件中插入、刪除行），提供基礎控件的事件觸發(fā)回調(diào)接口（按鈕、復選框的點擊事件、窗體的創(chuàng)建事件等）。在與ECU通信過程中，提供CAN、K總線收發(fā)，KWP 2000協(xié)議解析，15765協(xié)議解析等調(diào)用接口。各個不同的功能封裝間通過腳本語言調(diào)用WINDOWS里的ACTIVE X接口實現(xiàn)宿主語言與腳本語言的信息交互和功能融合。在宿主語言和腳本語言的協(xié)調(diào)方面，我們摒棄了大腳本（即所有的業(yè)務邏輯通過一個或幾個體量較大的腳本文件實現(xiàn)）的設計思路，采用以宿主語言作為驅動器，將業(yè)務邏輯分散到很多個小的腳本文件中存儲、加載、執(zhí)行，目的在于增強宿主語言與腳本語言的交互頻率，縮短單個腳本的運行周期，使得應用程序在執(zhí)行腳本的過程中也可以快速響應用戶的外部動作，增強用戶的體驗性以及避免出現(xiàn)由于腳本執(zhí)行時間過長而產(chǎn)生的界面卡頓現(xiàn)象。

本項目在技術方面充分的利用了腳本的“多語言粘合”能力，將傳統(tǒng)方式下的軟件開發(fā)轉化為圖形組件的可視化序列開發(fā)。項目產(chǎn)品提供大量已開發(fā)的電控單元診斷模板和標準診斷過程供用戶參考、引用。還提供可視化序列的復制、粘貼、存儲、導入等功能，使得用戶在開發(fā)過程中可能僅僅需要對原有序列的部分協(xié)議命令、輸入輸出內(nèi)容等組件參數(shù)進行微調(diào)即可完成新電控單元的診斷功能。

4　系統(tǒng)應用現(xiàn)狀

從項目開發(fā)角度分析，組態(tài)方式相較于傳統(tǒng)方式最大的優(yōu)勢在于將項目資源的重心從“開發(fā)人員”轉向為“開發(fā)工具”。雖然僅僅是思路上的“改變”，然而在應用過程中體現(xiàn)的則是效率上的巨大“變革”。

以V501項目為例，全車共28個電控單元。按照傳統(tǒng)的方式計算，單電控診斷程序的開發(fā)大約需要2個人1個月的開發(fā)、調(diào)試、測試周期，預計開發(fā)全車電控診斷程序的總工作量大約為56人月，實際項目周期應該在6個月以上。而實際項目中，我們應用組態(tài)方式進行售后維修診斷程序的開發(fā)，從需求獲取到軟件交付使用僅僅占用了4個人2個月的時間（4人均為非專業(yè)開發(fā)人員）。由此可見，使用組態(tài)方式完成項目開發(fā)能夠大幅度提高開發(fā)效率50%以上。

5　總結與展望

在競爭激烈的汽車工業(yè)領域，汽車制造業(yè)已進入微利時代，更多的獲利機會將在售后服務領域。國外汽車制造廠商總利潤的30%來源于生產(chǎn)整車的盈利，而在汽車售后服務領域的盈利占總利潤的70%。截至2015年底，全國機動車保有量達2.79億輛，其中汽車1.72億輛，新能源汽車58.32萬輛。隨著汽車市場的趨穩(wěn)，售后服務領域必將成為各方競相爭奪市場份額的主戰(zhàn)場，其中售后部門提供服務的品質(zhì)以及時效性將成為決定戰(zhàn)役成敗的重要武器。

組態(tài)軟件是在信息化社會的大背景下，隨著工業(yè)IT技術的不斷發(fā)展而誕生、發(fā)展起來的。在整個工業(yè)自動化軟件大家庭中，組態(tài)軟件屬于基礎型工具平臺。組態(tài)軟件給工業(yè)自動化、信息化、及社會信息化帶來的影響是深遠的，它帶動著整個社會生產(chǎn)、生活方式的變化，這種變化仍在繼續(xù)發(fā)展。因此組態(tài)軟件作為新生事物尚處于高速發(fā)展時期，結合國家十三五規(guī)劃中所倡導的工業(yè)4.0理念，相信將組態(tài)軟件引入汽車售后維修領域必將帶來神奇的化學反應。

［1］ 林偉.淺談組態(tài)軟件發(fā)展趨勢.自動化博覽.2003，（S1）.

［2］ 莫曉齊，王耀南.組態(tài)軟件用戶圖形界面的設計與開發(fā)［J］.計算機工程與設計.2006年01期

［3］ 熊杰，陳忠.設計模式在組態(tài)軟件圖形用戶界面中的應用［J］.長江大學學報（自然科學版）理工卷.2008年04期

［4］ 楊焱.汽車后市場服務連鎖經(jīng)營模式研究［D］ .天津大學.2006年

［5］ 《截至2015年底中國機動車保有量達2.79億輛》.中商情報網(wǎng).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