這一篇是延續車用電子漫談(十二) --- 電動助行車漫談的故事內容的。
其實對於許多電子應用系統來說,產品技術開發都只是屬於非常前期的開發工作,
真正困難的階段都是在於後段的產品功能實際測試驗證的。而這一方面都是牽涉到
你產品系統真正的應用在實際的使用情況,這些都是牽涉到產品市場的真正專業知識
領域的。譬如說:以前我待過IC 設計公司,開發過微控器(MCU),這種產品你只要
驗證到可以寫程式開發,所有程式指令都可以正確執行,大概就完成了,至於客人
會用這個MCU 做甚麼產品開發?那就不關你的事了。但後來這麼簡單的工作,大家
也都會做了。所以呢,這些IC 設計公司就會進一步找人或與別人合作,針對一些市場
比較有市場規模的東西,進行所謂的"公版方案"(板卡)設計。最後賣的產品就是搭配
這個MCU 的基礎應用產品,譬如現在大家比較常聽到的有 Arduino 或是樹莓派等
這些產品。甚至有些特殊應用產品也會所謂的標準公版:譬如以前我公司做過的
VCD/DVD 撥放器或是電動自行車用的馬達控制器等...這些也都是可以在市場上
輕易取得,搞類似產品的人或公司,都不一定需要懂複雜的電子控制或程式撰寫,
只要買一片這樣的東西回家自行組裝或維修更換就可以了。這樣子的產品市場對
原始的技術開發者當然就得具備一些基本的系統應用基礎:譬如需要懂得在MCU 上
完善基本的VCD/DVD 的播放功能或是電動自行車的馬達控制理論或方法。
所以現在市場上,只要做到這個階段的話,那幾乎就是模組標準化,量大價美的供需
市場,也是許多電子系統方案提供者所樂見的規模市場。所以只要是有量或普羅
大眾產品,幾乎都是這種產品方式,當然啊,市場的潮流趨勢業務操作方式,也都
慢慢地走向這一種方式,所以啦,像做電腦主機板或筆記型電腦的廠商,也幾乎
都是依循Intel 或顯示卡晶片原廠所提供的"標準參考線路"進行生產成本控管與
品質管理就可以了。因為如果真的所有的終端產品要完全由自己廠商投入系統開發設計
然後再進行產品系統驗證測試,真的不容易,也很辛苦的...而常常搞到最後,
市場沒達到經濟規模,常常就是入不敷出啊。
與其這麼辛苦就乾脆一開始也不用這麼麻煩了。因為這些開發工作都需要集中人力、
財力與資源才有辦法完善的...所以啦,像之前所說的標準"公版方案"(板卡)的開發,
大多集中在人才充沛、財力雄厚的IC 設計產業或供應鏈裡或沒啥營利獲利壓力的
學術單位等單位所釋出。至於那些中小企業,能做的研究開發工作都是非常有限的,
因為這些所謂的標準"公版方案"(板卡),不是開發出來就可以了,後續還牽涉到
生產製造與業務推廣等行銷策略。所以你自認為你的技術了得,你也得要花心思想一下:
"到底我的技術發揮,是該定位在哪一塊市場應用或是著重在哪些業務行銷市場裡?"
因為現在時代不同於過去那一種單打獨鬥的時代了,網路資訊發達所帶來的挑戰也大。
所以我就藉此一題目來簡單的介紹一下關於車用系統中實車測試驗證工作所常碰到或
會用的技術與資源相關議題。也讓你能從各方面的產品開發工作流程中,了解一下
其實許多產品技術開發也都沒有你想像的那麼單純或簡單的啦:不光只是技術好,
耍耍嘴皮子,就想攻占人家主流市場?
---------------------------
CAN( Controller Area Network) Bus 這個名詞其實已經出現超過三十年了,他是德國
汽車應用大廠 BOSCH 所設計的一種在於控制系統之間傳輸的標準。相信很多人早就
聽過或耳聞過,但有實際的設計應用經驗,尤其是在車用的實務經驗上。可能就沒啥
機會使用過,或是也沒有去真正整合過許多Controller Area 的系統,所以一時也搞不
清楚:這個玩意兒,到底他在系統應用上的好處在哪?
我就舉個自己本身的實務經驗來分享一下給各位參考一下。讓大家也透過一個簡單的
實際CAN Bus 的操作環境說明,來解釋一下這個玩意兒。
首先我先用機車ABS (煞車防鎖死系統)來說。系統怎麼設計是一回事,但你要如何進行
系統在實車的在實地測試驗證工作呢?因為這種東西在產品定義上:坦白講沒有所謂的
標準答案,因為每個人對煞車系統的反應能力感受不同,又牽涉到場地環境不同也會有所
不同的測試結果與報告,甚至對於不同車款也未必相同,所以那我們該如何透過許多後段
的實車測試驗證來檢視或完成產品的認證與品管呢?測試是肯定要做的,但要怎麼做?
如何做?你總不能找幾個車手,騎一騎車說可以就可以了吧?
車輛產品開發不是這樣子玩的。
首先我們先來看 BOSCH 這個大廠所做的一張測試報告圖表:
大家可以看到這張圖表下方的文字說明:很明顯的這張圖表是來自於他在日本測試場的數據。
而圖表的橫軸單位是 500msec/一格,所以可見的:ABS 的操控都是以 mSec 為單位的。
所以ABS 系統除了要完成所有的煞車防鎖死控制之外,也得要把所有的測試所需的數據
給傳輸出來的。透過這樣的圖表,讓車輛工程師去分析工程數據的。
所以你認為這樣的系統設計該採用甚麼傳輸介面來完成的呢?當然就是 CAN Bus 。
好:現在就換我Show 一張我們自己做的數據圖表:
橫軸單位也是秒為單位,但每一個座標標示是:0.2 為單位。所以也都是 mSec 為單位的。從圖表紅色圈處:大家可以很明顯地看到後輪的輪速很明顯地偏離車速所以代表後輪鎖死
。所以也可以看到下方ABS 進行煞車卡鉗的收放控制。讓車速穩定的降低至完全停止:
時間過程約四秒左右(從車速原先75 Km/hr 左右)。注意:我沒有說這樣的結果好或不好?
因為這牽涉到每個人、每一款車的特性而定。這當然都需要現場許多工程師一起判讀的:
但這篇文章的重點是如何擷取與紀錄、及如何呈現出分析數據圖表?
你放心好了,國內沒有那麼厲害與偉大的在這方面產品開發的公司與團隊的啦。
因為這些東西在國際上都有很好的資源,我們也都是整合這些資源來完成的啦。
用一張簡單的圖示來說明這個測試驗證系統的架構。
你不要以為甚麼有 CAN bus 的東西,都可以隨隨便便的裝到測試車輛上的。
譬如:左下方那個GPS 測速系統,你怎麼保證你的GPS 測速數據是正確的?
右上方的數據擷取紀錄器是穩定可信的?答案當然就是品牌與口碑啊。
但不好意思:這個東西都不便宜,就以左上方那個 VBOX III 一套是百萬元級的設備。
(這些都是國內外車廠所信任的基本品牌與產品設備的...當然還有更高等級的...)
然後:我們可以看到所有儀器設備、包括ABS 系統本身所傳輸出來的測試數據,都是
經由 CAN Bus 報文(大陸用詞,其實他的原意是:Payload),個別傳出。然後由
數據擷取紀錄器彙整記錄的,然後還要透過一套:數據分析軟體,再把這些資料
統一繪製出來,不好意思:右下方那個數據分析軟體,也不便宜。而這些數據分析軟體
也幾乎都是德國大廠所做的:像圖右下方的 Vector CANanalyzer:
目前最新版好像已經 15 版了。這個數據分析軟體非常重要,因為他就是牽涉到你在車用系統測試驗中的重要的數據判讀。
也包含了一些車用系統的概念。而據我所知:國內南部某機車大廠用的數據分析軟體是用
另一家的:imc FAMOS。
他也是一家德國公司。所以你不能只看到德國搞車子設計生產很厲害,其實他們還有
這方面很厲害的測試驗證軟體工具平台,而這些軟體也都有支援他們自己本身的硬體
設備,不過,如果你要從這些公司把這些儀器設備與軟體一次購足的話,你的口袋
真的要很深...很深。重點還是在於你要在哪裡用?怎麼用?
那你說不搞這些可以嗎?真的很難...因為車輛設計測試驗證真的很重要:
會死人的,不能開玩笑的啦。
所以從上圖與案例說明中:我們就發現其實 CAN Bus 真的非常好用,因為每一套在
測試中的量測儀器或是車用控制系統,都可以自行把自己重要的測試量測數據即時
的傳輸出來,再經由數據擷取記錄器與數據分析軟體,就可以很快的讓我們在圖表上
討論與判讀測試結果,而且有很多量測儀器或控制系統,而不一定得全由你自己本身
投入開發... 也都可以外購,整合完成的。這樣子有沒有真正的反映出 CAN --- Controller
Area Network 這個名詞的精隨啊?
(這塊市場已經回不去了,幾乎都已經被 CAN Bus 規格所延伸出來的儀器設備與
支援的系統工具平台....太多、太多了啦!)
而從這個過程中:你有沒有發現,其實你也不用去研究其他CAN Bus 模組(譬如GPS
對於速度的的計算與校正補償方法)的內容,或是其他控制系統的東西,你就可以很快
的從他們的CAN Bus 內容裡,取得你所需要的東西,這不光只是車用系統應用而已,
所以像後來CAN Bus 也運用在工業自動化的聯網系統中。這就是因為他的基本架構與
方法真的太好用了啦。完全不同於傳統的 RS232 、RS485、SPI 、I2C、USB 或其他
資料傳輸介面。
---
好了,既然如此,我就再用一個電動代步車的測試環境,來延伸說明這樣子的 CAN Bus
系統在電動車輛的開發上的應用實例。我在車用電子漫談(十二) --- 電動助行車漫談的文章
中有提到關於原廠馬達控制器對於電池殘電量的計算準確性的計算量測問題,我該如何
實地測試驗證呢?所以我就比照ABS 測試環境:架出另一套測試環境:
坦白講:我們有技術沒資源,也只好想辦法湊和點用,我們自己的控制系統就自己用一塊
外面標準的 STM32 工業學習版(支援 CAN Bus) 轉換傳輸CAN Bus 報文。
至於其他的量測還是用標準的儀器設備:
至於那個CAN Bus 數據擷取紀錄器,市面上很多,我就真的沒必要幫人家打廣告了。
有興趣者,只要Google 搜尋 "CAN Data Logger" 就有一大堆了。
所以我們把他裝上車上:
從上圖我們可以看到充完一次電池,大概可以跑個 5000 秒左右。大概就是一個多小時。
電池電壓也從約 26V 下降到 22V 左右。
依序的逐步下降至 1 之後,就開始閃燈顯示低電量了。
甚至我們也可以放大分析數據的觀察到:油門開關作動時,瞬間的電池變化情形,
反之,當油門關閉時,電池電壓也會回復一些的情形。像這些非常細膩的工程數據
其實對我們在產品開發上,都有很好的觀察分析價值的。而這樣的即時數據擷取與紀錄
對我們在車用系統開發驗證上,都有非常好的參考價值。
或許,你沒甚麼感覺,但我們這一種車用系統工程師來說:真的很用的。
以下是一段在電池充電時的實際影片展示:
----
好了,故事講完了。
結論:產品開發不只是重視前端的產品設計開發,後段的實際驗證測試也是非常重要的,
如果只有設計開發沒有後段的完整產品測試驗證,那是學術研究而已,稱不上真正的
量產產品,(這代表的意思是說:你辛苦的技術研究開發,只能賺一次設計或技術發表
論文的錢而已,而無法轉換成一個長長久久的 Regular Order 的 Easy Money,也就是:
不能拿來坐在家裡,等著訂單源源不斷所帶來的獲利與成就了啦。)
而後段後段的完整產品測試驗證則是涉及許多測試驗證方法與輔助工具的使用,
尤其是車用系統,因為他是會到處跑的東西,也會遇到許多惡劣環境與氣候條件。
但這些測試的輔助設備與工具,都不太可能都得自己搞,尤其像是測試數據分析軟體,
那更是顯得重要,但國內產業一般也不太重視軟體開發工作,更不用說像這一種涉及
非常專業領域的分析軟體。
而透過車用標準的 CAN Bus 系統也的確可以幫我們省下許多開發資源的不足,因為
這個產業標準規格的目的就是要讓大家在一個標準的平台去分享資源,像是儀器設備,
測試分析軟體等。(但搞這些東西也真的需要預算經費的..又冷門又貴森森的...)
每個行業最難的其實也都不一開始的產品開發設計與切入。譬如寫軟體程式、電路板
開發設計等等...這些其實在市面上都有很好的參考設計或所謂的設計方案公版供每個
設計開發工程師參考,甚至你要逆向工程也不太難了。但其實最難的還是在於:
你真正碰到實際系統應用到實車或現實環境的測驗耐久時,你所遭遇的問題與困難。
而這時候才能真正展現你系統之外,在這些應用領域上的專業判斷與決策能力。
藉由這一篇幾個簡單的實例來說明關於CAN Bus 在車用系統的測試驗證應用,
有興趣者,你也可以透過我上述的一些儀器設備或是相關的分析軟體等關鍵字
去網路上搜尋...其實你可以發現:人家國外在這一塊系統應用市場都有很好的
經驗與產品。或許你下回想搞這方面的產品或對這方面產品研究的話,不妨也試試看。
謝謝你的閱讀與指教。
STM32CubeMX已有第三方公司將CanOpen套件包成套件,但它目前只有slave是free的。所以架CanOpen只要勾進來就架起來了。我是還沒有試,但要進Can Bus也會從STM32開始,找一個STM32標準板子就可以架好軟體實驗看看。
回覆刪除CAN Bus 通訊定義上,是比其他UART/SPI/IIC 嚴謹一點(限制多一點,沒有MCU 內的硬體支援
刪除就沒得玩,不像其他的還可以用軟體模擬...),但也比USB 簡易多了。
不過,這個東西在應用上真的比較冷門一點,在一般消費性電子產品不太可以花這個錢搞
應用,當然要拿來當測試介面平台也是可以的。
所以我就只有簡單交待一下本身的應用經驗,之前我有大學同學搞工控產品,
也有跟我提過 CANOpen 的東西,是他們國外客戶有提過,但說真的~
後來也不了了之,很簡單的,我們國內產業都不是規格制定者,我們都只要配合人家
的規格,照本宣科就可以了,也就沒人想太深入研究。
所以說啦,想也知道:你們一般會用的CAN 的就搞Slave 就好了,量大苦工的產品...
至於那個主控台,還是要包一大堆上層應用的東西,都不是我們這些老中寫程式的料。
就不用了啦。
加油了囉。
PS:雖然CAN Bus 在定義上是沒有 Master/Slave 之分的。但我們在應用上,
都會自動把 ID 定義得比較大一點,就是閃遠一點,乖得像龜孫子一樣,就把自己
當作小媳婦般的 Slave 就好。
在前前公司時還有遇到Power Management Bus (PMBus)因為都用8051做的,我有想換成ARM,因為有些公司有寫好框架。像STM32就有PMBus 1.3的框架,公司還在用1.2。不過原系統已有很多支援工具,我提了也沒有用,產測已經習慣原PC工具。
刪除就像我最近去一家私人超市,看到收銀機還是倚天中文,還可以找到可用硬體還支援熱印表機及QR code,還是有人去升級。作業員的習慣性還是很難改的。
這種有點跟不上時代潮流的想法,對年輕人來說:可能覺得沒長進。
刪除但對我們這一種老人家來說:還蠻不錯的。用我們以前學的東西就可以換錢吃飯過日子也不錯。
至於:公司或市場為什麼還要一直用那一種老掉牙的東西呢?
就像有時候,要不要弄一段8051 組合語言?真的也沒辦法啊。
最近搞了一套產線要的USB 生產工具平台,我已經自認為:寫得夠簡單了吧。
結果:還是被退回來,改了好幾回...很簡單啊:
chamber 啊。你以為大陸工廠的那些小妹哪懂這麼多啊?
那你是要怪小妹呢?還是自己"LP"捏著再改呢?
所以說啦,當我上了年紀,我就比較懂得學甚麼新玩意兒,真的沒那麼重要的啦。
最重要的:還是能不能拿出來換現金過日子,比較重要。
至於那個拼命學新技術,為自己打造一條康莊大道的機會與歲月,我已經試過、幹過了。
然後我發現:這樣子,老闆還比較喜歡現在沉穩的你呢。
我的PMBus也是因為多了USB故事才出來。因為原先要一條PMBus主機轉RS232的線再接PC工具。我的案子就是多了USB,我是寫HID給PC抓資料。都是自己發展出來的。要不是多問人,才知道原先產線已有一套產測。變成我寫的PC USB HID工具要去符合前面的產測習慣,接上後要讀取所有狀況,然後出一個OK/NG,還要寫Log下來。我還弄了二套HID,一個在8051 USB上,一個在STM32的USB上。8051上還看到很多工程師也有在寫USB的碼,但因為不會寫HID測試程式就卡住了。要MCU去PC側寫測試程式,倒了一堆人。所以8051的程式超級複雜的,每個工程師慣用的寫法及系統驅動方法都不同,弄到沒幾個人敢改。
刪除喔~關於 USB 搞產測這檔子的事。講難聽一點:到底是要一個人把韌體與PC軟體一手包呢?
刪除(可能還會牽涉到一點點硬體的東西...) 還是找兩、三人搞呢?
我的經驗就是只要兩個和尚就沒水喝了,根本不用到三個和尚,尤其是那個小貓兩三隻的
小公司。你以為老闆每天發薪水給你們,就像在大公司那樣:只要每周能交出工作報告,
交代一下工作進度,不管成功與否...老闆也不會抓你們來拷問。
但又要工程師扛起責任一手包辦?別傻了啊...要學多久啊?老闆你可以給我多少時間學啊?
況且老闆不認為這是公司應該讓你慢慢學的機會,你來"敝公司"上班就應該是會做這件事的人。
所以啦,每次接到這種案子,我都會笑笑地說:喔~您們公司可以慢慢加油囉。
看到底最後培養出一組超強合作默契的工作小組呢?還是搞得老闆也不知道到底發生甚麼事?
搞技術真的不難啊,但它的先決條件就是:公司能給多少時間?又能給多少資源?
公司上班不比在唸研究所,關起門來...靜心的漫漫鑽研。
看多了,也就習以為常了。隨緣吧...年紀大了,也沒有那麼偉大的情操了。
PS:我之前常用的8051 USB Controller 是 Silicon Labs 的。
它的周邊(外設)就是有支援 SMBus...但我都只是把它當 I2C 在用而已。