【導讀】費者可以親眼目睹并親身體驗的汽車工業(yè)創(chuàng)新往往出現(xiàn)在信息娛樂領(lǐng)域，其中的核心組成部 分便是顯示系統(tǒng)。對此消費者可以直接體驗新功能帶來的便利性和創(chuàng)新性。然而在這些新功能實現(xiàn)之前往往有許多工作要做。從創(chuàng)意出現(xiàn)開始，問題便接踵而來，因為這些創(chuàng)意在實現(xiàn)之前還要面臨在顯示和操作方面的挑戰(zhàn)。　　消費者可以親眼目睹并親身體驗的汽車工業(yè)創(chuàng)新往往出現(xiàn)在信息娛樂領(lǐng)域，其中的核心組成部 分便是顯示系統(tǒng)。對此消費者可以直接體驗新功能帶來的便利性和創(chuàng)新性。然而在這些新功能實現(xiàn)之前往往有許多工作要做。從創(chuàng)意出現(xiàn)開始，問題便接踵而來，因為這些創(chuàng)意在實現(xiàn)之前還要面臨在顯示和操作方面的挑戰(zhàn)?！　∈紫?，人們需要對這些創(chuàng)意進行詳細的闡述，讓決策者完全了解后做出決定。在初期階段通過草圖、PowerPoint幻燈片和Flash動畫這些方式基本可以達到概念呈現(xiàn)的目的，當然通過這些方式還無法獲取布線系統(tǒng)的相關(guān)數(shù)據(jù)。接下來，根據(jù)這些手工雛形來評估該創(chuàng)意能否真正得到用戶的青睞，另外也要看目前的技術(shù)水平是否能夠?qū)崿F(xiàn)。這些步驟都只是實現(xiàn)創(chuàng)新的一部分工作而已，要想評估用戶操作界面是否簡單且易于操作，即可實現(xiàn)性，則更加困難。為了成功跨越這一障礙，便不得不開始一個耗時費力的建模過程。這些模型的制作往往由專業(yè)研發(fā)人員完成。在制定周密詳盡的計劃前，一個繁瑣的討論過程便開始了，首先是研發(fā)團隊召開項目啟動會議，緊接著便是無數(shù)的電話會議。該決策過程說明這樣一個事實，即建模必須由研發(fā)人員來編程，這就是上面所提到的耗時費力的建模過程?！　∮纱说贸鼋Y(jié)論：為了借助模型來測試新功能往往需要很多精通HMI編程和汽車布線系統(tǒng)的專家提供他們的專業(yè)知識并且投入相當多的時間和精力，這將是一條漫長且復雜的過程。 以下是對新解決方案的要求：　　◆ 借助現(xiàn)有HMI的Look And Feel功能無需掌握不同研發(fā)領(lǐng)域?qū)I(yè)知識也可以進行建模 　　◆ 通過現(xiàn)有功能的標準化接口便可簡單地使用真實數(shù)據(jù)（真實的ECU或PC模擬）　　任務(wù)拆分 　　可靠且實用的工具是任務(wù)得以順利進行的關(guān)鍵。多功能工具雖然能夠為多種任務(wù)領(lǐng)域提供支持，但這種支持效果并沒有那些專門為之開發(fā)的工具明顯。在HMI開發(fā)領(lǐng)域需要進行界面設(shè)計并且對動態(tài)行為進行定義。當人們決定實現(xiàn)任務(wù)拆分這一基本想法時還有些問題需要解決：“對操作者來說，什么才是最理想的工具”尤其是專門為某一任務(wù)新開發(fā)的工具并不能滿足開發(fā)人員需求的時候。此外，項目經(jīng)費也是有限的，況且軟件供應(yīng)商和互聯(lián)網(wǎng)上已經(jīng)提供很多辦法可供使用。為了實現(xiàn)寶馬集團該項目的要求我們采取了兩種工具：用于界面構(gòu)建的Microsoft Expression Blend和用于HMI動態(tài)行為建模的Telelogic Rhapsody。 標準的使用 　　伴隨著工具的選擇又產(chǎn)生了新的問題，標準的使用能否帶來一定的好處。除了顯而易見的功用性外，即在可能的情況下將所使用的工具市場化，另一個決定性的優(yōu)勢也才會變得明顯：用戶的接受性。一種工具的成功與否主要是取決于，使用者是否能在特定的時間內(nèi)借助所給的工具來完成任務(wù)，具體說就是：“我可以用到所學到的知識嗎？或者這僅能使我成為某一任務(wù)的專家嗎？”本文所介紹的解決方案便是考慮到了這一不可或略的問題，并且采用了以下兩個標準： 　　◆ UML（統(tǒng)一建模語言）：UML狀態(tài)圖可用于HMI系統(tǒng)動態(tài)行為的建模。 　　◆ XAML（可擴展應(yīng)用程序標記語言）：XAML使得用戶界面中的聲明性設(shè)計成為可能。對此目前還沒有一個行業(yè)標準，而是微軟專有技術(shù)，專門為本文所介紹的任務(wù)拆分目的而開發(fā)的。XUL（XML使用者界面標記語言）是一種可比較的界面描述語言，來自于開源社區(qū)。 　　UML的使用，特別是UML狀態(tài)圖的使用為此提供了許多優(yōu)勢：UML狀態(tài)圖是一個動態(tài)的基于條件的系統(tǒng)圖形描述。相對于程序代碼或腳本語言，這種描述方式對于該領(lǐng)域的使用者來說更容易理解和改編。編程員可以通過功能強大卻簡單的命令來獲得支持，因為這些命令包含了復雜的功能。例如列表上的一個新的復雜菜單項通過一個命令即可進行改編。于是這種狀態(tài)圖更容易理解，同時他們也具有更長的使用周期?！　∠到y(tǒng)概覽：GUI工具箱的使用在很多領(lǐng)域減輕了任務(wù)的繁重性。界面構(gòu)建 　　預(yù)制組件如工具箱或者是Lego原則的使用在很多方面減輕了任務(wù)的繁重性。在具體的項目中GUI工具箱使界面構(gòu)建成為可能。可以將GUI元素拖放到一個界面上，然后進行設(shè)置。在此，可設(shè)置性很重要，因為它們從根本上決定了工具箱的靈活性?！　⒖继峁┻@些元素的GUI庫API，人們可以找到更多的屬性，它們規(guī)定了元素的命令。我們這個情況也一樣，因此我們把屬性分成了兩組： 　　◆ 靜態(tài)屬性 　　◆ 動態(tài)屬性 　　靜態(tài)屬性在界面構(gòu)建時是固定的且在運行過程中不可改變。人們可以采用他們在工作中所掌握的工具進行界面的構(gòu)建。動態(tài)性能剛好相反,在運行過程中根據(jù)行為邏輯可以改變。對此，行為邏輯編程員可以使用已經(jīng)提到過的命令，例如：LABEL_SETTEXT（“TitleLabel標題標簽”，“Hauptmenu主菜單”）。 可執(zhí)行性和“可體驗性” 　　為了可以對創(chuàng)意進行評估，新構(gòu)建的界面需要具有可體驗性。在這種情況下可體驗性即意味著可執(zhí)行性。但是要想對體驗進行清晰的描述，僅僅這些還是不夠的。車輛上配置有相關(guān)操作元素的HMI構(gòu)建，只要有就應(yīng)該是可以操作的。用真實的數(shù)據(jù)來代替模擬數(shù)據(jù)更具意義。這些數(shù)據(jù)除了可以實現(xiàn)體驗性，還可以讓開發(fā)人員對建立的界面進行測試，通過真實的數(shù)據(jù)來經(jīng)受住首次質(zhì)量檢驗。 應(yīng)用與經(jīng)驗 　　寶馬的項目便采取了本文所介紹的解決方案。由此達到了兩個目的： 　　◆ HMI環(huán)境的建立，用于檢測地圖數(shù)據(jù)（同樣適用于國外） 　　◆ 用于檢測用戶相關(guān)的新功能 　　除了前面所介紹的解決辦法外還需要適當?shù)膱D形，這些圖形對于對話的構(gòu)建非常必要。對此每個單獨的圖形需要作為一個單獨的文件，該要求已經(jīng)在項目開始時便執(zhí)行了。然后會建立一個專業(yè)概念形式的Storyboard，便可以開始真正的建模。首先，單獨的對話可以用微軟Expression Blend來構(gòu)建。對此在不同的面板上界面元素通過拖放進行定位，接著進行設(shè)置。每個面板會構(gòu)建一個Panel-State-Chart，它會控制該面板上所包含的界面元素。最后連接到MOST-Bus，實現(xiàn)MOST信號的接收和發(fā)送功能。最后還有一種系統(tǒng)可以使用，即通過目標系統(tǒng)的實時控制描述可以在PC平臺上運行的系統(tǒng)。 結(jié)論 　　不需要編程就可以建立對話框的這個構(gòu)思，經(jīng)驗證明是可實現(xiàn)的。一開始所設(shè)定的目標也是可以實現(xiàn)的，雖然工作流程的細化還有待優(yōu)化，以減少時間的消耗。在第一次測試成功后，至今仍然有懸而未決的問題：“該理念以怎樣的形式來支持普遍的流程鏈？”或者更具體的問題：“針對新目標系統(tǒng)的研發(fā)，可以向系統(tǒng)供應(yīng)商提交怎樣的說明規(guī)格？”這里可運行的對話框作為 “可執(zhí)行技術(shù)規(guī)范說明書”，UML狀態(tài)圖的圖形作為“可運行白盒規(guī)范”，兩者結(jié)合起來一起使用——這種方法在未來還需要得到進一步驗證。