嵌入式系統一直被認為是現代技術的支柱，為從智能手機到汽車到家用電器的一切提供動力。盡管嵌入式系統在我們的日常生活中扮演著至關重要的角色，但在代碼開發方面，它仍然需要趕上其他技術領域。在本文中，我們將探討為什么會出現這種情況，并討論微服務理念如何幫助加速嵌入式開發。
MCU上的資源有限，可能性有限?
微控制器(MCU)具有有限的資源，這可能會限制開發和應用的可能性。
由于它們經常需要更多的內存和計算能力，因此實現繁重的算法和功能具有挑戰性。你不要在42MHz，2kRAM的MCU上運行Windows11!開發人員需要優化他們的應用程序，通過專門為其目標開發來消耗更少的資源。這使得代碼不靈活或不適應。同樣，你不能運行Docker或任何虛擬化系統，因為它很重，你需要訪問真實的硬件，而不是虛擬的硬件。
因此，嵌入式系統可能需要特定的工具來跟上技術進步并滿足用戶不斷增長的需求和期望，這可能是一個很大的缺點。例如，隨著物聯網的發展和擴大，對具有尖端連接和計算能力的嵌入式設備的需求肯定會更大。提高他們能力的一種方法是考慮制作在互聯網上運行的功能，但這變得很困難，因為連接并不總是有保證的——你可能會失去連接，或者在某些困難的情況下被禁止。
這種系統臨界性使得嵌入式開發人員更喜歡使用舊的但經過驗證的技術，以避免可靠性意外。
隨著時間的推移，MCU上有限的資源也可能使維護和更新嵌入式系統變得更加困難。正因為如此，我們正在創建我們的開源產品，以盡可能使用最少的系統資源。許多其他操作系統選項，如ROS，需要更多的資源，對于目前可用的最小設備來說是不夠的。
由超定制需求驅動的整體理念
事實上，嵌入式系統經常被創建為針對特定目的或任務集合進行非常專業和優化的，這是開發如此落后的主要原因之一。這種超定制的理念導致一切從頭開始重新制作，并導致單片代碼，因為你的優先事項是使某些東西工作，而不是開發一個適應的、可靠的、優化的和可伸縮的代碼架構。
我們經?？吹焦I版模塊化架構的夢想，但沒有時間這樣做——特別是因為它可能會損害大量工作代碼。所以最終，模塊化架構的想法沒有實現。
這使得在不實質性改變當前系統的情況下整合新技術或新功能變得非常困難。這種設計方法導致缺乏模塊化和可重用性，最終減慢了開發過程，并增加了對原始設計進行更改時出現錯誤和缺陷的可能性。加劇這一問題的是，許多嵌入式系統使用專有的硬件和軟件，這可能會限制嵌入式開發開發人員對底層代碼的訪問和控制。因此，嵌入式系統傾向于更慢地采用新技術。它們可能不如利用更模塊化和更靈活的方法創建的系統靈活。
組件的多樣性使整個系統變得復雜
這些系統種類繁多是嵌入式系統發展緩慢的另一個原因。嵌入式系統有大量的硬件和軟件組件，所有這些組件在使用前都需要仔細集成和測試。復雜設備意味著多個電路板使用專用或定制的網絡交換信息，有時甚至在同一產品中使用多種不同的網絡技術。同樣，所有這些都需要進行大規模測試。
這可能是一個勞動密集型且容易出錯的過程，會減慢開發周期，并使快速實現新功能或新技術變得非常困難。由于其復雜性，創建和管理系統可能具有挑戰性，因為可能需要特定的知識和經驗來理解每個組件如何作為一個整體進行交互和運行。
對實時應用的需求給嵌入式領域增加了另一層重要的復雜性。最重要的是，你不能像在正常的軟件調試過程中那樣容易地從運行的嵌入式代碼中提取信息。事實上，同樣的人機界面在嵌入式(屏幕、鍵盤、互聯網)中是不存在的。結果，調試和測試變得更加困難。我們看不到正在發生的事情。
像Luos這樣的方法旨在為用戶提供將系統活動實時視為數字孿生的能力。你可以使用Luos創建實際系統的數字復制品，以測試和觀察任何潛在的問題。
讓我們將微服務的愿景應用于這些問題
如今，嵌入式系統依賴于連接的子系統。我們稱之為網絡物理系統(CPS)。但獨立的子系統并不意味著你不是單片的，你可能有不可能維護的單片子組件，也不直接與其他組件兼容。此外，為了連接整個系統的所有部分，嵌入式開發人員需要創建一個經過調整的通信系統，這可能需要花費大量時間才能使其可靠。你可能無法將其用于其他產品。
由于設計更改、產品可用性或任何其他外部變量，這種靈活性的缺乏導致許多與我們互動的開發人員重做他們的整個系統(數月的工作)。半導體危機是眾多僵化舉措的一個典型例子，這些舉措僅僅因為兼容性問題而被迫戛然而止。
網絡物理系統可以利用許多緊湊、自主的服務來創建，這些服務由于微服務而易于組合和修改。我們必須把嵌入式系統看作一種產品，而不是一塊板。
近年來，微服務哲學在軟件行業越來越受歡迎，這為解決這些同樣的問題提供了補救措施。微服務將軟件應用程序分離為可管理的、自包含的部分，這些部分可以獨立創建、部署和擴展。因此，開發人員可以輕松地添加新功能或技術，而無需對當前系統進行大的調整。微服務的模塊化設計也使測試和實現新功能變得更簡單，這有助于縮短開發周期。但正如本文開頭所提到的，我們不能在嵌入式世界中使用相同的工具。像Luos項目這樣的開源努力正在創造未來所需的工具。
延遲問題
在嵌入式系統中使用微服務可能存在一定的延遲問題。在考慮微服務時，開發人員可能會想到管理各種服務之間通信的延遲?；谖⒎盏南到y將需要在服務之間進行一種板間IPC(進程間通信)，這可能會導致延遲。嵌入式開發人員可以通過測量延遲并使其對實時應用程序具有確定性來管理延遲。通過使用時間戳，它將允許你以數學方式計算延遲。我們可以使用排隊和調度等策略來確保請求得到一致處理，并使延遲具有確定性。
市場需求
嵌入式系統的設計和構建通常是為了滿足短期需求，但需要長期維護。因此，解決某些標準可能優先于添加可能需要一些時間才能變得必要或重要的新技術或功能。嵌入式系統適應不斷變化的環境或不斷發展的需求的能力可能會受到這種對實現精確目標的強調的阻礙。
在研發程序經常受到限制的情況下，從長遠來看，考慮一個嵌入式項目需要更多的時間，從而需要更多的資金。因此，嵌入式系統可能難以跟上技術進步。考慮使事物具有適應性總是比在給定時間產生滿足需求的系統更復雜。
此外，市場需求可能會迫使嵌入式系統開發采用同樣久經考驗的方法，這最終可能會使靈活性和互操作性面臨挑戰。
到目前為止，已有一些項目試圖建立一個“開發標準”，但很少有項目能在受嵌入式系統影響的各個領域真正獲益。開源哲學可以成為一種解決方案。開源的使用保證了無論發生任何意外事件(公司崩潰或出售)，你都可以長期維護你的系統。它由嵌入式開發人員社區維護，可以更好地適應你的需求，更新最新功能，并在開發方面具有靈活性。
以更可持續的方式發展
通過使用更可持續的方法，嵌入式系統的開發可以變得更加靈活和適應性，以及更加有效和資源高效。這種方法意味著開發可根據你的需求重復使用的代碼，而不僅僅是當前的特定項目。這種可重用性可以應用于系統中的代碼或組件，并且應該從可重用性的角度進行長期考慮，而不僅僅是針對當前的特定項目。
通過將你的全局系統劃分為小代碼塊來開發你的項目，也將允許隨著時間的推移進行更好的維護。這種維護將針對系統的單個元件，這樣就不會改變整個系統的其他功能。
總結
總之，由于其復雜性、專業性以及對專有硬件和軟件的依賴，嵌入式系統在發展方面落后于其他技術領域。然而，通過使用微服務或數字孿生等方法來思考一種新的系統開發方式，可以幫助開發人員在日常生活中發揮作用。
利用這種微服務的理念，我們正在創建一個開源項目，以增加嵌入式系統的靈活性。我們創建的許多工具可以幫助嵌入式開發人員更快、更輕松地編寫代碼。
京公網安備 11010802030320號