DCT自動變速器拓展應(yīng)用開發(fā)探討

Discussion on Application Development of Automatic Transmission DCT

錢向陽李育

上海汽車變速器有限公司

QianXianyanLiYu

ShanghaiAutomobileGearWorks

[摘要]基于DCT變速器首個(gè)整車項(xiàng)目的成功上市，本文介紹了DCT變速器拓展應(yīng)用開發(fā)內(nèi)容，并提出了相應(yīng)的解決方案，從而保證了DCT變速器的成功應(yīng)用。

Abstract[]Based on DCT transmission first vehicle listed on the success of the project, this paper introduces the DCT transmission develops the content of application development, and puts forward the corresponding solutions, so as to ensure the success of the DCT transmission applications.

關(guān)鍵詞：DCTCAN應(yīng)用開發(fā)

文章編號：1006-8244(2015)03-025-03

中圖分類號：U463.212

Key words: DCTCANApplication

1　概述

DCT是一種高效節(jié)能的濕式雙離合器自動變速器。首個(gè)搭載該變速器的整車成功上市后得到市場認(rèn)可，為此作為變速器專業(yè)生產(chǎn)公司必須考慮DCT的拓展應(yīng)用。拓展應(yīng)用關(guān)鍵技術(shù)是需要針對不同發(fā)動機(jī)以及整車特性進(jìn)行匹配開發(fā)。本文就CAN通訊開發(fā)、診斷開發(fā)、駕駛性能提升、項(xiàng)目流程管理等方面對拓展應(yīng)用項(xiàng)目開發(fā)進(jìn)行全方位的闡述。

2　CAN通訊開發(fā)

在DCT基本軟件的開發(fā)過程中，因TCU對發(fā)送接收信號需求不斷更新，其通訊CAN Matrix也需隨之更新。然而由于受底層軟件平臺的CAN sharing 模式限制，CAN Matrix的更新需要底層軟件供應(yīng)商來完成。無論CAN Matrix修改內(nèi)容多少，底層軟件都需要進(jìn)行重新集成、測試，因此每版軟件都需要較長的開發(fā)周期。

針對這一問題，為了提高CAN matrix的靈活性，減少底層軟件的開發(fā)工作量，在DCT拓展應(yīng)用匹配項(xiàng)目中，TCU通訊方面采用了全標(biāo)定CAN的開發(fā)模式。即實(shí)現(xiàn)CAN模塊的一次性開發(fā)，底層軟件供應(yīng)商將CAN matrix的配置，集成工作開放給應(yīng)用層來完成，以減少軟件開發(fā)周期。

所謂全標(biāo)定CAN，就是CAN通訊功能中底層軟件只負(fù)責(zé)接收和發(fā)送報(bào)文，而報(bào)文信號的打包及解包由應(yīng)用層軟件負(fù)責(zé)。在此基礎(chǔ)上，應(yīng)用層擁有配置權(quán)限。即底層將所涉及配置的參數(shù)以標(biāo)定量的形式開放給應(yīng)用層，使得在更新CAN matrix時(shí)，只需應(yīng)用程序編寫接口函數(shù)，重新標(biāo)定參數(shù)，而無需重新對底層軟件進(jìn)行更新。

全標(biāo)定CAN通訊功能主要通過三個(gè)方面來開發(fā)實(shí)現(xiàn)：接口函數(shù)，報(bào)文解包打包，通訊參數(shù)配置。如圖1所示

首先，開發(fā)報(bào)文接收發(fā)送接口函數(shù)。其中包括，報(bào)文接收，報(bào)文狀態(tài)接收以及報(bào)文發(fā)送。所有報(bào)文均以byte為單位被接收或發(fā)送。其次，通過Matlab建模實(shí)現(xiàn)報(bào)文解包打包。一幀報(bào)文有8個(gè)byte，根據(jù)解讀dbc文件得知信號與byte的關(guān)系，從而把一個(gè)CAN信號從報(bào)文中解析出來。而報(bào)文打包，可理解為報(bào)文解包的逆過程。最后，離線配置CAN通訊參數(shù)。包括報(bào)文通訊方向、中斷使能、報(bào)文ID、報(bào)文模式、報(bào)文掩碼、報(bào)文DLC位數(shù)、報(bào)文周期，報(bào)文接收超時(shí)、報(bào)文監(jiān)測使能。如圖2所示：

圖1　全標(biāo)定CAN實(shí)現(xiàn) Fig.1　The calibration CAN realize

圖2　CAN通訊參數(shù)配置 Fig.2　The CAN communication parameter configuration

3　駕駛性能提升

對于專業(yè)變速器制造公司而言，十分關(guān)注變速器在整車上的駕駛性能，只要有細(xì)微的潛力可挖掘就必須尋找解決方案以進(jìn)行優(yōu)化提升。

提升駕駛意圖變化下的操控性：在車輛行駛過程中，換檔需要一定的時(shí)間來完成，在這段時(shí)間中，不可避免地駕駛員會基于周圍的環(huán)境和實(shí)時(shí)的路況更改意向。如駕駛員在滑行升檔過程中踩油門、降檔過程中減小油門或松油門、小油門降檔過程中踩更大油門等。

以滑行升檔過程中駕駛員踩油門工況為例，如圖3所示，如果TCU軟件中沒有change mind策略，若踩下100%的油門，變速箱還是要繼續(xù)把發(fā)動機(jī)轉(zhuǎn)速往下調(diào)節(jié)，先完成本次降檔，然后才可以執(zhí)行大油門降檔。實(shí)車測試過程中感覺到明顯的不平順感，而且汽車動力響應(yīng)較慢。如果TCU軟件中有change mind策略，如圖4所示，駕駛員踩下大油門的時(shí)候，變速箱會立刻響應(yīng)駕駛需求轉(zhuǎn)為大油門降檔，快速調(diào)節(jié)發(fā)動機(jī)轉(zhuǎn)速到達(dá)目標(biāo)轉(zhuǎn)速，然后目標(biāo)離合器快速實(shí)現(xiàn)扭矩接合，汽車動力響應(yīng)也會加快。

圖3　升檔過程中踩油門繼續(xù)升檔

Fig.3In the process of the shift up continue to shift up on the accelerator

小油門降檔過程中駕駛員加大油門的工況，如圖5所示，如果TCU軟件中沒有change mind策略，則只能先完成本次降檔，才可以開始下一次降檔，發(fā)動機(jī)轉(zhuǎn)速的調(diào)節(jié)不連續(xù)，并且兩次降檔過程中有動力中斷的感覺。如果TCU軟件中有change mind策略，如圖6所示，變速箱會立刻響應(yīng)駕駛員的駕駛需求，快速執(zhí)行多級降檔到需求的檔位，發(fā)動機(jī)的轉(zhuǎn)速的上升比較連續(xù)，加速感也比較連續(xù)。

圖4　升檔過程中踩油門轉(zhuǎn)降檔

Fig.4In the process of shift up turned down on the accelerator

圖5　降檔過程中加大油門繼續(xù)降檔

Fig.5Step on the gas in the process of change down to continue down

圖6　降檔過中加大油門轉(zhuǎn)更多級降檔

Fig.6Down a step on the gas to turn the more multistage downshifts

“2003年時(shí)，湖區(qū)的養(yǎng)殖面積一度達(dá)到36萬畝。2010年國家加強(qiáng)養(yǎng)殖權(quán)制度建設(shè)以來，高寶邵伯湖按照省政府批準(zhǔn)的養(yǎng)殖規(guī)劃實(shí)行嚴(yán)格的限制措施，盡管如此，2016年初湖區(qū)仍有養(yǎng)殖面積30.5萬畝，占湖泊總面積的21.2%。其中，養(yǎng)殖發(fā)證面積23.4萬畝，持證養(yǎng)殖漁民2244戶；無證養(yǎng)殖面積7.1萬畝，無證養(yǎng)殖漁民約600戶。”江蘇省高寶邵伯湖漁管辦副主任索維國介紹道。

這些策略能夠快速、準(zhǔn)確地響應(yīng)駕駛員的操作意圖，在不同的工況下能夠使車輛更具有動力性并兼顧經(jīng)濟(jì)性，車輛的加速度也相對比較平順，并能有效改善車輛在行駛過程中的駕駛性能。

4　診斷開發(fā)

在DCT系列拓展項(xiàng)目中診斷功能需做如下開發(fā)：

按客戶需求進(jìn)行診斷服務(wù)開發(fā)：目前TCU基礎(chǔ)軟件的診斷服務(wù)都是完全按照ISO 14229、ISO 15031等國際標(biāo)準(zhǔn)進(jìn)行開發(fā)，而各整車廠都會對診斷服務(wù)有不同的需求，為此對UDS/OBD服務(wù)需要做相應(yīng)的變更來滿足不同整車廠的企業(yè)標(biāo)準(zhǔn)。

故障警告機(jī)制開發(fā)：每款車型儀表以及整車對故障警告的理念都不盡相同，因此TCU需根據(jù)實(shí)際情況為客戶訂制service、MIL、多級過溫提醒燈、緊急停車燈、無法換擋等警告機(jī)制。

CAN網(wǎng)絡(luò)信號監(jiān)控策略開發(fā)：需針對不同車型的網(wǎng)絡(luò)架構(gòu)定義，對通信中斷、校驗(yàn)錯(cuò)誤、信號有效性失效等故障進(jìn)行監(jiān)控，并對失效幀的信號做失效后處理策略，增強(qiáng)系統(tǒng)的魯棒性。

新功能的保護(hù)策略開發(fā)：需針對客戶所提出的如：坡上輔助、自動啟停、陡坡緩降等整車新功能，進(jìn)行故障診斷機(jī)制、故障后處理策略開發(fā)，消除因新功能工作或失效所帶來的一切風(fēng)險(xiǎn)。

5　項(xiàng)目流程管理

軟件產(chǎn)品的特殊之處在于其質(zhì)量完全由過程決定，這就意味著軟件開發(fā)過程管理至關(guān)重要。項(xiàng)目時(shí)間節(jié)點(diǎn)把控、人力物力資源分配、軟件缺陷解決能力、變更審核能力、全工作過程追溯等，涉及的核心都是軟件開發(fā)過程管理。

項(xiàng)目開發(fā)過程管理：通過TCU開發(fā)過程管理平臺對項(xiàng)目生命周期進(jìn)行管理，以計(jì)劃為管理的主線，將需要完成的工作任務(wù)按照完成時(shí)間和客戶需求歸納到不同計(jì)劃的迭代中去。將每個(gè)工作任務(wù)之間設(shè)置先后及因果關(guān)系形成一個(gè)基于時(shí)間的工作任務(wù)“網(wǎng)”，通過這個(gè)“網(wǎng)”，我們可以評估整個(gè)項(xiàng)目的工作量，對項(xiàng)目是否能在節(jié)點(diǎn)前交付工程產(chǎn)品有一個(gè)明確的預(yù)期。

風(fēng)險(xiǎn)管理：以V型開發(fā)為模型，將用戶需求分解為系統(tǒng)需求，軟件需求和模塊需求。根據(jù)層級關(guān)

系設(shè)置鏈接，當(dāng)某一條需求變更時(shí)就能清晰得知該變更會對哪些模塊的哪些需求產(chǎn)生影響，這有利于更加全面、快速的進(jìn)行風(fēng)險(xiǎn)分析。所有需求還必須與其相關(guān)的工作任務(wù)及測試用例相關(guān)聯(lián)，這就可以明確是否所有的需求都被測試。在測試過程中發(fā)現(xiàn)了缺陷，通過測試用例與需求的對應(yīng)關(guān)系可以更加方便知道缺陷是來源于哪個(gè)層面的哪些需求。

配置管理：利用RTC工具管理開發(fā)過程工作流，即整個(gè)開發(fā)過程是動態(tài)流轉(zhuǎn)的，工作任務(wù)及工作產(chǎn)品像流水線一樣從一個(gè)工程師流轉(zhuǎn)到下一個(gè)工程師，每個(gè)工程師在不同的工作狀態(tài)需要交付不同的工作產(chǎn)品到開發(fā)流中，開發(fā)流中的所有工作產(chǎn)品允許被修改，但到達(dá)項(xiàng)目節(jié)點(diǎn)時(shí)會對所有工作產(chǎn)品進(jìn)行評審，并對評審后無疑義的工作產(chǎn)品建立基線，基線可以為開發(fā)流中配置項(xiàng)的持續(xù)變更和工作產(chǎn)品的發(fā)布提供穩(wěn)定的保證。在開發(fā)流中，僅建立基線的產(chǎn)品才有被允許發(fā)布的可能。這樣就可以通過配置管理來保證所有被發(fā)布的軟件質(zhì)量，并在發(fā)現(xiàn)問題的時(shí)第一時(shí)間找到問題的來源。

6　結(jié)束語

通過本文所探討的拓展項(xiàng)目開發(fā)內(nèi)容，DCT的控制器軟件可以靈活滿足客戶的CAN通訊需求；并可以提供匹配不同發(fā)動機(jī)特性來實(shí)現(xiàn)優(yōu)越的駕駛性能；還可以滿足客戶的診斷需求，最后在軟件開發(fā)流程的管理下確保整個(gè)項(xiàng)目的開發(fā)質(zhì)量。