汽車制造商改進系統設計的一種方法是收集實時數據，并將這些數據與系統預期的行為進行比較。

想象一下，為一家大型 OEM 開發汽車零部件。您可能正在制作像自動車道保持系統這樣復雜的東西，或者像輪胎壓力監測器這樣小的東西。但有一個共同點是，您將無法知道車輛的所有排列和您卑微的工程工作的用途。如果您的組件成功，那么它將在多個車輛平臺上進行，每個平臺都有自己的選項包和變體。

使問題更加復雜的是，當您在汽車電子產品領域工作時，您不是在制造單個設備。相反，OEM的多個團隊和各種一級供應商正在制造必須以復雜方式進行交互的組件。現實情況是，如果不組裝組件并監控行為，您將永遠不知道將這些組件放在一起時真正會發生什么。作為工程師，您可能永遠不會與制造其他組件的工程師交談。

JD Powers發現，在過去五年中，美國已經發布了189起與軟件相關的安全召回，其中141起報告增加了崩潰的風險。隨著行業氣喘吁吁地期望將越來越多的駕駛任務交給機器，重要的是要記住這一點 - 我們的機器可以殺死我們。

汽車就像巨大的黑匣子，在路上疾馳而過，數十個微控制器都通過拜占庭迷宮網絡來回發送消息。我們認為我們在控制和駕駛，但實際上，在表面之下，相互依賴的車輛系統正在決定下一步應該發生什么。繼續在路上行駛還是猛踩剎車并吹氣囊？認為這是你的選擇？

當IOactive入侵車輛時，他們通常能夠簡單地利用系統漏洞。軟件設計師總是希望其他模塊能夠很好地發揮作用。例如，普銳斯制動模塊具有安全功能，如果汽車在停車，則無法放氣制動器。如果您還沒有看過記者因為IOactive能夠強制未知狀態而突然失去剎車的視頻，那么您應該觀看。

診斷故障代碼（DTC）可能會告訴您出了什么問題，但它也可能只是一個發出白旗的組件，表示當其他設備脫軌時它不知道該怎么做。軟件相當于吧？

汽車制造商改進系統設計的一種方法是收集實時數據，并將這些數據與系統預期的行為進行比較。不僅適用于少量車輛，而且適用于所有車輛。這些數據可以通過及早發現問題或糾正代碼中的錯誤假設來避免大規模召回。

這就是電子同步的用武之地。eSync 系統旨在收集數據進行分析和管理更新。eSync 是一個整體的端到端系統，從頭開始設計以更新整個車輛。因為如果你要改進系統，真正改進系統，那么你需要能夠更新一切。不要只是戳戳一兩個模塊。

審核編輯：郭婷