組態技術在汽車售后維修領域的應用研究

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

（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