2020年3月3日 星期二

車用電子漫談(一) --- 產品與核心技術概述

講車用電子,對於不同專業領域的人來說:有著不同角度的解讀。

對業務或產品企劃來說:它是一塊很有價值的產品市場,產品毛利有一定的維持

能力,產品生命周期較長。而對老闆來說:它是一塊很有說服力的產品市場,

是一個很有題材性,而且代表著高度專業的公司品牌。而對於搞技術的工程師來說:

覺得它是一塊很容易令人熱血賁張的激情產品市場。

姑且無論如何:無庸置疑的~它卻是一塊"難啃"的市場。對於以上各個領域的人來說。

譬如:業務:搞了老半天,客人怎麼還不下單呢?到底問題出在哪?老闆整天盯著

要交出成績?搞越久就覺得越沒成就感。老闆呢?怎麼還沒出貨?創造績效呢?

每天一開門不管人事或相關管銷費用不斷的攀升。連損益平衡時間點在哪都無法掌握?

工程師呢?激情總是會慢慢地回歸平淡,眼見老闆業務都快沒耐心了,沒績效代表著

未來前途堪慮,轉身看看同學們或朋友,那我是否還需要堅持嗎?....
---
我想這些故事都是很現實的問題,那到底問題是出在哪呢?那就讓我們從各種角度來

解讀看看吧:

首先我們先來定義車用電子產品吧。一般來說,車用電子只分兩大類:

電子產品車用化。

車用產品電子化。

夠簡單的分法。這是不管是從核心技術、財務投資或是產品市場銷售等多方面的來說。

這也是我多年的感觸心得。因為我曾經都有從這兩方面切入的經驗。

先談電子產品車用化,這是一般公司,尤其是有錢的IT 產業公司的想法。

也最常見。這個我就是身處台灣高科技城:新竹科學園區待過,一些公司老闆或

高階主管的心態我見多了,我也曾經從這些"老闆們"拿錢辦過事...

我們會軟硬體核心技術,我們有優秀的台清交電子電機工程師,我們在IT 產業也有不錯

經營績效,我們也有完整的產業供應鏈,產品行銷全世界。對於切入車用應用市場,

最重要的是:在財務上也有健全的投資理財之道。且車用市場,有甚麼困難之處呢?

所以這類公司或新聞屢見不鮮。但這樣的產品與公司也秉持著 IT 產業"一代拳王"慣例。

總是不斷的上演著世代交替:我就直接點名說了。像搞倒車雷達的同X,搞車載多媒體

的X利、搞行車紀錄器,甚至最近興起的X創。

沒錯,只要我公司找到好的IT 產業出身的工程師,只要順著產品市場潮流,

我只要把IT 產業中很成熟的產品,導入車用市場就好了。

對啊~只要測試驗證走完,就可以大聲地對外宣稱,我們是車用電子題材公司了。

這類產品,結果有時發現,搞到最後改裝或後裝市場好像比前裝市場好賺...

很簡單:因為有時發現搞了老半天沒量,也沒想像中的高毛利啊。而且也沒有像傳說

中的車用電子產品壽命長的特色啊?超音波倒車雷達被倒車影像取代了,車載多媒體

已經被行動裝置給取代了,行車紀錄器搞了老半天,原來還要跟導航或雲端圖資系統

相結合。技術搞了老半天,還是要不斷的更新,驗證都還沒走完,人家市場已經又在

炒作新的產品技術了。就算有了一點小小成績之後,所謂有題材是老闆或手上有

大量公司股票的人爽,工程師呢?搞了幾年,技術沒多大長進?薪水待遇分紅

也沒多多少,眼見一年一年過,就開始有了中年危機了。
---
第二種車用電子呢?就是所謂的車用產品電子化

這個對於一般IT 產業的人來說,就真的比較不熟悉的產品了,這一部分我就舉一些

例子來解說,因為這些所謂的車用電子是真的利用電子科技技術來解決原來車用

零組件所遭遇的一些難以克服的問題。最早最明顯的故事,也是現今最大車用電子

公司:BOSCH 或 DENSO 所走過的故事。七零年代因為石油危機與環保問題,

造就了電子噴油技術的出現,它就是要解決傳統機械引擎中化油器供油問題。

其實在真正電子噴油系統出現之前,還有一段電子化油器的年代,所以很明顯的

它就是車用產品電子化的實例。這一部分我以前網頁有說明過,但因為 Hinet 網頁

已經不見了,我在稍微補充一下:下圖是PORSCH 944 的ECU (電子噴油控制單元)



這個東西後來有人(後裝改裝市場)複製重新設計製造:


這張圖放大一點看:


你是搞電子技術的,寫單晶片的,有沒有很熟悉啊?對。沒錯,就是8051 。

不要懷疑:



這是 BOSCH 自己在SAE 雜誌所發表的技術文獻。

那系統架構早在 8039 時代就奠定了:



這種晶片技術放到今日,不要說檯面上的園區公司啊,隨隨便便路上一堆DIY 的朋友

肯定就會打趴你了。

是啊~現在誰還在用外掛EPROM 的啊,直接MCU 帶 FLASH ,容量隨你隨便寫程式

都不怕啊。還只有 8 KBytes ? 現在 8 KBytes 8 Bits MCU ,一顆只要台幣十塊以內了。

當然以IT 產業來講這個純硬體成本是一點意義都沒有的,因為這一類產品是要講

它成長的故事,尤其就是甚麼是車用產品電子化。如果你真的沒有走過這一類產品的

開發經驗,你真的無法真正掌握車用電子系統驗證測試的核心技術。


這是我去法國接受汽車電子噴油系統導入機車應用的訓練課程講義。

有一份很重要的調教系統課程,這一部分就真的需要機械原理背景的知識。

這樣子你真的才能搞懂甚麼是車用產品電子化。


這些內容就是交錯著機械原理與程式語言的關係。

而以下則是另一家美國公司的訓練課程講義:


如果你沒有車輛機械背景,這些內容再延伸到電子系統就很難搞得懂軟硬體內容了。


這些都是機械用詞,但它所帶出的是:控制演算法及程式時序安排。


然後才有了:流程圖與程式碼:


當然啊,既然要講到韌體程式,如果沒有輔以硬體電路設計分配,只要是碰到

周邊硬體控制,你還是搞不懂程式的邏輯順序:


是的~從這些內容,如果是以你本身的專業領域角度,你覺得該如何看待這樣子的產品開發?

或是核心技術投入?當然啊,這些也不光只是時間與金錢而已,這些不管是團隊或公司

之所以能有機會成長有很多是來自於市場潮流與機會:

以我自己的例子而言:我是學機械的,從不懂電子電機與單晶片程式語言架構,一路的

給全面的訓練出來的。~沒有後來的園區高科技產業的歷練,也不可能的。

我說過:沒有人天生就懂得這些,【我們家的狗,很可愛,我要把他養大"成人"】,

那是不可能的,因為我們有了那個時空背景,有那個機會,才能從國際一流公司

一窺車用系統產品開發的核心技術。是真正的車用產品如何電子化。

當然啊~這已經是三十年前的技術了,現在這種核心技術已經更進化演繹到更高層次了。

不管是軟硬體,連帶的整合周邊測試驗證環境,那都已經一日千里了,

要不然你以為人家能搞無人自駕車,就只是簡單的電子產品車用化而已嗎?
---

最後先再以另一個車用電子產品的故事先告一段落:

這是 BOSCH 電子煞車制動系統的演進圖表。記住:這是車用機械產品電子化。


走了超過 25 年,這裡面也充滿著電子科技進步的軌跡。你說這裏面的說明:是機械還是

電子術語?但它明明就是車用機械零組件。


你說這還是截至 2003 年的。沒關係,我也看過BOSCH 給機車用的第十代ABS:

這IC 方案好像是 TI 的。



----
結語:這些電子產品從產品外觀,其實從網路搜尋,努力地找,都不難找得到。

但有許多產品開發與核心內容整合,都不是光從這些圖表照片就可以體會得到的。

因為這是一個漫長的產品開發路程。它背後也代表著產品與技術的時代演進。

包括著許多規格與最新技術引進。

最後還是再一次強調:當你看到國內在搞車用電子產品時,你在認真想一想:

他們是用哪一種心態在看這一塊產品市場:

電子產品車用化?還是車用產品電子化?

下回我會再討論一些技術相關問題,也包括一部分的電動機車。

當然後續也會從產品研究開發管理與一些產品市場投資風險評估來聊聊。

謝謝。

待續。

12 則留言:

  1. 學歷好真是不錯,有這麼好的學習機會,跟我這個私立大學學士完全沒關係的事,
    也真是感嘆,回不來的青春歲月...離題了

    回到主題說到的訓練課程,教人從來就是一門學問,甚至可說是一門藝術;一個人
    專業領域可以很強很強,但他一天也只有24小時一個人力,再怎麼提昇效率也有極
    限,所以最終也是要請人來教,這也是很多企業的共同難題:到底要怎麼教?

    之前看過一篇文章,在講這個問題
    大麥克對原味主廚 https://www.csie.ntu.edu.tw/~p92005/Joel/fog0000000024.html

    對企業來說,照著程序不見得真的教出能用的人,但不是每間公司都有正規的教育
    訓練,我自己是覺得這些教育訓練是會有下面這些好處:

    1. 將公司的知識結晶給系統化,不再將這些片斷資料留在腦海與隨手記錄上
    2. 降低學習門檻,降低有心想學習員工的時間成本
    3. 知識系統化後便於驗證與調整

    想到大學時,學校接受xx部門的評鑑,連系主任也不禁抱怨,做一堆資料,弄一堆
    活動,結果上面只是把學校當成產線,畢業後還是看個人造化。

    教育很多時候是長久的投資,學校如此,企業更是如此。但能了解的有多少,
    自學有能者從來都不佔多數,但教育可以有更多的有能者投入,不用再能者過勞了

    回覆刪除
    回覆
    1. 上面所提供的連結網頁內容講得不錯,非常感謝你的分享。

      以前雖然我是在大的財團法人機構裡上班,但因為我們分工很細,我們計劃成員

      也就那小貓兩三隻,我又是最菜的,所以我才有那個機會去受教育訓練與成長。

      後來我離開之後,所到的第一家科技公司也是小公司,所以學習成長機會還是有。

      那時我就有點開始羨慕人家上市櫃的大公司了...後來我也如願的~因公司合併才有

      機會進入大型公司,結果一到這一種公司之後,甚麼教育訓練都沒了~有啦,就教你

      一大堆企業組織管理課程啦,但我們又是很基層的人員,上這些企業組織管理真的也沒啥

      感覺與體會。上課時,心裡還在想:待會兒下課後,還得回公司繼續趕程式...

      後來要開始有機會帶人了,但是呢?

      哪來那麼多時間可以整理那些要教人的文案與簡報內容呢?

      這篇文章中,你看人家國外會在產品開發後,會請你花一點時間把這些東西,

      有系統的把它們編寫成教案。請問:你在國內哪家公司上班時,老闆會請你幹這種事?

      而中國人也會願意幹這種事?若請你做時,你腦袋裡的第一個想法會不會是:

      "老闆打算把我腦袋裡的東西挖出來了,會不會等挖完東西之後,就一腳把我踢開啊?"

      這些跟所謂的學經歷無關,而是跟企業文化與老闆的心態有關。

      所以啦,有時候,真的要想一響:年輕人當你畢業之後,到底是到大公司比較好呢?

      還是小企業比較好?這真的很難說得準。

      不過,你所整理歸納的幾項好處,的確是說到重點了。老中的科技發展要跟上西方

      國家,就一定要做到這幾點,否則:在老中的技術發展過程中,往往就是最有價值的

      核心技術不是在公司的資料文檔裡,而是長在某些人的腦袋裡。

      當這些人離開會或退休之後,也就只能在慢慢等有沒有新一代的天才工程師

      可以橫空再蹦出來一兩個,來創造一家新公司的奇蹟。不都是如此嗎?

      大家加油了囉。

      刪除
  2. https://wallace7914032.blogspot.com/2020/03/pc.html
    這局是現在進行式。就看後面的現象是不是符合我猜的。

    回覆刪除
    回覆
    1. 微軟在手機市場本來就是弱勢,所以若能再從手機市場再拉回一些客戶市場,

      那當然肯定要努力的啦。只是局勢是否還有那個機會?還很難說啦。

      就像我最近有點想研究一下如何在 Web Browser 中 Access USB Device。

      有人建議我用IE 的 OCX 方式,但我網路一查:人家Google 這一兩年也推了

      WebUSB API 了,也蠻多人推薦,那你說:微軟怎麼辦?

      很簡單啊。還是市場機制,我們這些小老百姓?喔~不是,小小工程師,

      就只能依自己的判斷賭賭看了囉。

      刪除
    2. 當然用手機有支援的,沒得好選就是webUSB。
      IE全系列已經無救。新的edge從2版急升到80版,因為內核改成chrome核。這樣也不用再去想要用那一個瀏覽器了。微軟早了一步想好如何應付,也調整好了。
      反倒我想問是那個人建議用OCX,他沒有看到市場的變化?

      刪除
    3. 喔~那個建議用OCX 的人,不幸的是:他今年中風了。

      才四十幾歲,他不只技術職場已經提早結束了,連帶人生也瞬間成黑白了。

      因為沒有結婚,已經被家人送去安養中心,努力的復健,看看能拾回多少人生吧。

      所以工程師們要注意健康...有時候這些產業大消息或訊息,其實是離我們很遠的。

      不是嗎?

      刪除
  3. https://www.segger.com/products/connectivity/emusb-device/technology/webusb/
    ARM的除錯器已經用webUSB做好了。只要開網頁就可以連上。手機也可以開,但未試能不能連上裝置。

    回覆刪除
    回覆
    1. 謝謝你提供的資訊。

      但因為 WebUSB 是由JAVAScript 寫的,我真的不知道我還真的要不要還要學這個東西。

      唉~年紀大了,這也只能閒暇之餘,加減看看了囉。

      刪除
    2. 我一開始也是這樣想,後來找到emscriptem,是C轉javascript,所以可以寫C做主體,API才接回javascript。所以用C可以做開發。

      刪除
    3. 我以為以您們這麼專業的軟體工程師,對轉換甚麼程式語言應該都不困難的。

      所以也不需要繞這麼遠路來學這些程式語言。

      而我呢?年紀也算是要做"人生變現"了,一直追著當紅技術也不是長久之計。

      所以現在對於學新玩意兒,就真的比較謹慎一點了。

      或許當你搞這些東西時,有一些值得分享給大家的,也期待能看到更多的分享文。

      加油了囉。

      刪除
    4. 不完全是語言的問題,一個語言也許數月就可以學會,但函式庫的使用及套用又要重來。不如找轉換器,將已經很熟的函式庫再套入。效率不會好,但一定可以動。要有效率,還是找專職的。
      但專職不一定會硬體,只要可以證明程序可以通並除錯才是重點。

      刪除
    5. 的確是,現在有很多平台在網路上都有很多現成的函式庫供人使用,

      但問題最大的還是在於如何整合 Debug,尤其是牽涉到硬體周邊的東西。

      至於效率不好的問題?反正現在硬體資源都很多,沒差這個,只要能迅速交差的,

      沒有人會多在意這個的啦。沒辦法,時代進步了...

      刪除