摘 要：針對(duì)嵌入式領(lǐng)域多功能、多任務(wù)，以及復(fù)雜多變環(huán)境下系統(tǒng)的可重構(gòu)性、面向較長(zhǎng)裝備生命周期的可擴(kuò)展性與可維護(hù)性等應(yīng)用需求，為實(shí)現(xiàn)嵌入式系統(tǒng)下計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)等資源的統(tǒng)一管理，設(shè)計(jì)了一種面向嵌入式系統(tǒng)的高可靠資源管理平臺(tái)。平臺(tái)采用XML可擴(kuò)展標(biāo)記語(yǔ)言、Redis數(shù)據(jù)庫(kù)、選舉策略設(shè)計(jì)與故障恢復(fù)機(jī)制等關(guān)鍵技術(shù)，重點(diǎn)實(shí)現(xiàn)了資源管理平臺(tái)與平臺(tái)內(nèi)應(yīng)用軟件的高可靠設(shè)計(jì)，并結(jié)合嵌入式應(yīng)用軟件實(shí)例充分驗(yàn)證了資源管理平臺(tái)的功能、指標(biāo)性能與高可靠特性。

關(guān)鍵詞：嵌入式系統(tǒng)；資源管理平臺(tái)；高可靠設(shè)計(jì)

中圖分類(lèi)號(hào)：TP311 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：2096-4706（2024）17-0115-05

0 引 言

嵌入式系統(tǒng)是以應(yīng)用為中心，以現(xiàn)代計(jì)算機(jī)技術(shù)為基礎(chǔ)，能夠根據(jù)用戶需求（功能、可靠性、成本、體積、功耗、環(huán)境等）靈活裁剪軟硬件模塊的專(zhuān)用計(jì)算機(jī)系統(tǒng)。嵌入式系統(tǒng)的應(yīng)用十分廣泛，涉及工業(yè)生產(chǎn)、日常生活、工業(yè)控制、航空航天等多個(gè)領(lǐng)域[1-2]。

隨著電子技術(shù)、計(jì)算機(jī)軟件技術(shù)、人工智能、大數(shù)據(jù)以及云計(jì)算等信息技術(shù)飛速發(fā)展，嵌入式系統(tǒng)領(lǐng)域逐漸向著需求可定制、硬件可重組、軟件可重構(gòu)等特征發(fā)展，相關(guān)的嵌入式應(yīng)用面臨著巨大的挑戰(zhàn)，針對(duì)嵌入式系統(tǒng)的計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)等資源的管理平臺(tái)設(shè)計(jì)需求也愈來(lái)愈多，如何高效實(shí)現(xiàn)嵌入式資源的統(tǒng)一管理成為領(lǐng)域內(nèi)的熱門(mén)研究方向。

較早期時(shí)，大部分小規(guī)模的嵌入式資源管理平臺(tái)是一種基于中心節(jié)點(diǎn)的中心式管理架構(gòu)，雖然這種中心式架構(gòu)具有資源占用率低、更加輕量、實(shí)時(shí)性較高等優(yōu)勢(shì)，但過(guò)分依賴(lài)中心節(jié)點(diǎn)，壓力集中，使得此類(lèi)架構(gòu)在可靠性、靈活性等方面有所欠缺，因此適用性較低。目前在商用領(lǐng)域資源管理的主流方式大都為使用商用服務(wù)器搭建的一種分布式資源管理系統(tǒng)，具有可靠性高、靈活性高、支持更大集群系統(tǒng)等優(yōu)勢(shì)，但這類(lèi)系統(tǒng)一般為批處理系統(tǒng)，資源占用率較高，需要占用更多的資源來(lái)滿足系統(tǒng)運(yùn)行需求，通常難以滿足嵌入式系統(tǒng)高帶寬、低時(shí)延等實(shí)時(shí)性要求。

現(xiàn)階段，在常見(jiàn)的通用計(jì)算平臺(tái)上已經(jīng)有很多資源管理軟件和框架，像Map Reduce、Hadoop、Spark、Storm等[3-5]。文獻(xiàn)[6]設(shè)計(jì)了一種面向DRE系統(tǒng)的自適應(yīng)資源管理架構(gòu)，實(shí)現(xiàn)動(dòng)態(tài)任務(wù)管理、實(shí)時(shí)資源分配和自適應(yīng)控制；文獻(xiàn)[7]提出一個(gè)面向嵌入式實(shí)時(shí)系統(tǒng)的自適應(yīng)圖形處理器（GPU）資源管理框架。

基于上述研究，本文設(shè)計(jì)了一種面向嵌入式系統(tǒng)的高可靠資源管理平臺(tái)，解決傳統(tǒng)嵌入式應(yīng)用與硬件綁定，資源無(wú)法重用的問(wèn)題，實(shí)現(xiàn)計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)等資源的統(tǒng)一管理與調(diào)度，支持平臺(tái)資源池化管理、統(tǒng)一調(diào)度與按需分配，支持資源的分時(shí)復(fù)用，提升軟件資源利用率。

1 系統(tǒng)架構(gòu)分析

目前主流的系統(tǒng)架構(gòu)主要有中心式與分布式兩種。

1.1 中心式架構(gòu)

中心式架構(gòu)是一種常見(jiàn)的架構(gòu)設(shè)計(jì)模式，如圖1所示，是以一個(gè)中央控制節(jié)點(diǎn)為中心，其他普通節(jié)點(diǎn)圍繞該中心進(jìn)行組織和交互。中央控制節(jié)點(diǎn)和每一個(gè)普通節(jié)點(diǎn)進(jìn)行通信，而普通節(jié)點(diǎn)之間不需要通信，因此中心式架構(gòu)所產(chǎn)生的額外通信開(kāi)銷(xiāo)為N×T（其中N代表普通節(jié)點(diǎn)個(gè)數(shù)，T代表單次通信耗時(shí)）。

中心式的管理方式具有可集中控制與管理、簡(jiǎn)潔和易于理解與維護(hù)、系統(tǒng)具備強(qiáng)一致性和規(guī)范性等優(yōu)點(diǎn)。但是也存在一系列的潛在缺點(diǎn)，一是單點(diǎn)故障風(fēng)險(xiǎn)，即中央控制器的故障會(huì)導(dǎo)致整個(gè)系統(tǒng)的癱瘓；二是性能瓶頸問(wèn)題，即整個(gè)系統(tǒng)的性能優(yōu)劣過(guò)分依賴(lài)于中央控制器的負(fù)載情況；三是靈活性和受限，即整個(gè)系統(tǒng)的擴(kuò)展、調(diào)整、重組等都比較困難。

1.2 分布式架構(gòu)

分布式架構(gòu)是一種無(wú)中央控制節(jié)點(diǎn)的架構(gòu)設(shè)計(jì)模式，如圖2所示，每一個(gè)節(jié)點(diǎn)之間是對(duì)等的關(guān)系，他們之間互相進(jìn)行數(shù)據(jù)的組織和交互。由于每一個(gè)節(jié)點(diǎn)之間均需要進(jìn)行通信，因此分布式架構(gòu)所產(chǎn)生的額外通信開(kāi)銷(xiāo)為N×（N-1）×T（其中N代表普通節(jié)點(diǎn)個(gè)數(shù)，T代表單次通信耗時(shí)）。

、

通過(guò)分布式架構(gòu)搭建的資源管理系統(tǒng)，一般適用于大流量網(wǎng)站（處理高并發(fā)訪問(wèn)）、云服務(wù)平臺(tái)（提供靈活的資源分配）、大數(shù)據(jù)處理（處理海量數(shù)據(jù)）、人工智能系統(tǒng)（支持大規(guī)模模型訓(xùn)練）等，具有可擴(kuò)展性、高可靠性、安全性強(qiáng)等優(yōu)點(diǎn)。

可擴(kuò)展性，能夠方便地增加或減少系統(tǒng)節(jié)點(diǎn)數(shù)量，以滿足系統(tǒng)能力需求的動(dòng)態(tài)變化。

可靠性高，部分節(jié)點(diǎn)發(fā)生故障時(shí)，系統(tǒng)仍然能夠正常運(yùn)行。

安全性強(qiáng)，系統(tǒng)數(shù)據(jù)信息分布在各個(gè)節(jié)點(diǎn)上，進(jìn)一步降低了數(shù)據(jù)丟失的風(fēng)險(xiǎn)。

同時(shí)由于分布式架構(gòu)的復(fù)雜程度，使其也面臨著一系列的挑戰(zhàn)，一是在復(fù)雜的協(xié)調(diào)與同步下，需時(shí)刻確保各節(jié)點(diǎn)的協(xié)同工作，在分布式環(huán)境下保證各節(jié)點(diǎn)的數(shù)據(jù)一致性；二是潛在的網(wǎng)絡(luò)延遲或故障，大量的數(shù)據(jù)交互壓力可能會(huì)影響系統(tǒng)的整體性能與可靠性，反而降低整體的資源利用率；三是龐大的節(jié)點(diǎn)數(shù)量，跨區(qū)域的部署與管理等[8]，需要有效的管理和監(jiān)控眾多節(jié)點(diǎn)。

2 資源管理平臺(tái)設(shè)計(jì)

結(jié)合中心式與分布式架構(gòu)的優(yōu)缺點(diǎn)，針對(duì)嵌入式應(yīng)用軟件的高帶寬、低時(shí)延、強(qiáng)實(shí)時(shí)性等要求，本文設(shè)計(jì)了一種面向嵌入式系統(tǒng)的高可靠資源管理平臺(tái)，其軟件框架示意圖如圖3所示。

資源管理平臺(tái)位于嵌入式應(yīng)用軟件與操作系統(tǒng)之間，由節(jié)點(diǎn)管理器NM（Node Manager）、資源管理器RM（Resource Manager）、從屬資源管理器RM_S（Resource Manager Slave）三部分組成。由于RM與NM、RM與RM_S之間需要進(jìn)行通信交互，因此當(dāng)前架構(gòu)下的額外通信開(kāi)銷(xiāo)是（N+M）×T（其中N代表NM節(jié)點(diǎn)個(gè)數(shù)，M代表RM_S節(jié)點(diǎn)個(gè)數(shù)，T代表單次通信耗時(shí)）。

2.1 節(jié)點(diǎn)管理器NM

節(jié)點(diǎn)管理器NM主要由資源采集與信息上報(bào)組成。資源采集模塊通過(guò)調(diào)用操作系統(tǒng)相關(guān)接口實(shí)時(shí)獲取硬件節(jié)點(diǎn)的計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)等信息，并按照鍵值對(duì)（key-value）的形式統(tǒng)一存儲(chǔ)，形成節(jié)點(diǎn)資源池，采集節(jié)拍可配置，支持對(duì)節(jié)點(diǎn)資源池的增、刪、改、查操作；信息上報(bào)模塊負(fù)責(zé)將實(shí)時(shí)查詢節(jié)點(diǎn)資源池中的資源信息，并通過(guò)TCP形式統(tǒng)一打包發(fā)送給RM。

2.2 資源管理器RM

資源管理器RM主要由信息接收與資源分配組成。信息接收模塊負(fù)責(zé)接收所有NM上報(bào)的資源信息，形成系統(tǒng)資源池，由RM統(tǒng)一管控，支持對(duì)系統(tǒng)資源池的增、刪、改、查操作；資源分配模塊負(fù)責(zé)實(shí)時(shí)響應(yīng)嵌入式應(yīng)用的資源請(qǐng)求（核、內(nèi)存、帶寬等），依據(jù)資源類(lèi)型、資源需求量、資源剩余量、資源負(fù)載、應(yīng)用關(guān)聯(lián)性五個(gè)因素從資源池中分配當(dāng)前應(yīng)用所需資源，支持對(duì)系統(tǒng)資源池的改、查操作，可分時(shí)工作的嵌入式應(yīng)用，分配過(guò)程中資源可復(fù)用。為實(shí)現(xiàn)RM的高可靠設(shè)計(jì)，RM需通過(guò)UDP組播的形式按可配置的節(jié)拍定期發(fā)送心跳信息給各個(gè)RM_S。

2.3 從屬資源管理器RM_S

從屬資源管理器RM_S，NM的一種，同時(shí)還負(fù)責(zé)實(shí)時(shí)接收RM的心跳信息，在RM正常工作時(shí)，RM_S處于未激活狀態(tài)，只執(zhí)行NM的功能，當(dāng)RM的心跳信息連續(xù)丟失三次時(shí)，認(rèn)定RM異常，此時(shí)多個(gè)RM_S之間通過(guò)選舉打分的方式，選擇最優(yōu)的RM_S主動(dòng)激活成為新的RM，當(dāng)原先故障的RM又恢復(fù)正常并成功上線后，該RM只會(huì)發(fā)揮RM_S的功能。

3 關(guān)鍵技術(shù)分析

本文所設(shè)計(jì)的資源管理平臺(tái)，所采用的關(guān)鍵技術(shù)包括XML（Extensible Markup Language）可擴(kuò)展標(biāo)記語(yǔ)言、Redis數(shù)據(jù)庫(kù)、選舉策略設(shè)計(jì)、故障恢復(fù)機(jī)制等。

3.1 XML可擴(kuò)展標(biāo)記語(yǔ)言

XML是一種用于存儲(chǔ)和交換數(shù)據(jù)的標(biāo)記語(yǔ)言，常被選用為應(yīng)用程序的配置文件，以樹(shù)狀結(jié)構(gòu)組織數(shù)據(jù)，具有良好的可讀性與規(guī)范性[9]。

資源管理平臺(tái)采用XML配置文件的方式設(shè)計(jì)系統(tǒng)配置文件，描述了各個(gè)節(jié)點(diǎn)的角色信息（NM、RM、RM_S）以及計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)等資源信息。同時(shí)要求應(yīng)用軟件通過(guò)應(yīng)用XML配置文件來(lái)描述實(shí)際的資源需求。

通常角色信息配置中RM_S的占比情況與系統(tǒng)的節(jié)點(diǎn)規(guī)模有關(guān)，為充分保障資源管理平臺(tái)的高可靠運(yùn)行，當(dāng)系統(tǒng)節(jié)點(diǎn)規(guī)模在10個(gè)以內(nèi)時(shí)，要求RM_S個(gè)數(shù)至少為2個(gè)，系統(tǒng)節(jié)點(diǎn)規(guī)模每增加10個(gè)，至少需要增加一個(gè)RM_S。

3.2 Redis數(shù)據(jù)庫(kù)

Redis是一個(gè)開(kāi)源的、高性能的鍵值對(duì)數(shù)據(jù)庫(kù)，支持多種數(shù)據(jù)類(lèi)型，讀寫(xiě)速度快，設(shè)有哨兵機(jī)制，可以將數(shù)據(jù)存儲(chǔ)到磁盤(pán)，以防止數(shù)據(jù)丟失等優(yōu)點(diǎn)[10]。

NM采集的資源信息、嵌入式應(yīng)用的資源請(qǐng)求、系統(tǒng)的狀態(tài)信息等，通過(guò)鍵值對(duì)的方式存儲(chǔ)在Redis數(shù)據(jù)庫(kù)中，RM_S通過(guò)Redis數(shù)據(jù)庫(kù)實(shí)現(xiàn)與RM的實(shí)時(shí)同步，利用Redis的哨兵機(jī)制，每當(dāng)鍵值對(duì)信息發(fā)送改變時(shí)，RM_S自動(dòng)同步更新該信息，同時(shí)每隔一定周期，RM_S主動(dòng)同步所有的鍵值對(duì)信息，保證RM與RM_S之間的信息強(qiáng)一致性，使得RM_S在RM發(fā)生故障時(shí)，能夠無(wú)縫接手RM功能，保障整個(gè)系統(tǒng)的高可靠運(yùn)行。

3.3 選舉策略設(shè)計(jì)

當(dāng)RM發(fā)生故障時(shí)，系統(tǒng)中多個(gè)RM_S之間通過(guò)選舉的方式，選出一個(gè)最優(yōu)的RM_S來(lái)充當(dāng)RM的功能。采用打分制的選舉策略，對(duì)RM_S節(jié)點(diǎn)的物理鏈路遠(yuǎn)近（有無(wú)跨硬件、跨插箱、跨機(jī)柜等）、資源總量、余量、負(fù)載、網(wǎng)絡(luò)、存儲(chǔ)帶寬等進(jìn)行綜合打分，并設(shè)置權(quán)重占比，打分項(xiàng)與權(quán)重占比情況可通過(guò)系統(tǒng)XML配置文件進(jìn)行具體配置，計(jì)算并選擇分?jǐn)?shù)最高的RM_S節(jié)點(diǎn)激活成為新的RM。

當(dāng)RM_S發(fā)生故障時(shí)，RM會(huì)采用相同的打分策略從所有的NM中選擇分?jǐn)?shù)最高的激活成為新的RM_S。

3.4 故障恢復(fù)機(jī)制

嵌入式應(yīng)用軟件通過(guò)RM的資源分配模塊部署在綜合分?jǐn)?shù)最優(yōu)的NM上。應(yīng)用軟件運(yùn)行起來(lái)后，NM實(shí)時(shí)監(jiān)測(cè)該應(yīng)用軟件的運(yùn)行狀態(tài)，并實(shí)現(xiàn)兩種場(chǎng)景下的故障重構(gòu)設(shè)計(jì)。

場(chǎng)景一，應(yīng)用故障。當(dāng)NM內(nèi)應(yīng)用發(fā)生故障時(shí)，NM會(huì)在當(dāng)前節(jié)點(diǎn)重構(gòu)該應(yīng)用，若多次嘗試后，依然無(wú)法恢復(fù)，NM會(huì)反饋給RM，再重新部署運(yùn)行到其他NM上；

場(chǎng)景二，NM故障。當(dāng)NM自身發(fā)生故障時(shí)，RM會(huì)依據(jù)該NM上的資源占用情況，將NM內(nèi)所有應(yīng)用重新部署運(yùn)行到其他NM上；

場(chǎng)景三，RM故障。當(dāng)RM發(fā)生故障后，多個(gè)RM_S之間會(huì)迅速?zèng)Q策出綜合評(píng)分最高的RM_S，激活RM相關(guān)任務(wù)，迅速接手RM功能；

場(chǎng)景四，RM_S故障。當(dāng)RM_S發(fā)生故障后，RM會(huì)從多個(gè)NM之間選出綜合評(píng)分最高的NM，激活RM_S相關(guān)任務(wù)，迅速接手RM_S功能。

4 使用流程

以某嵌入式應(yīng)用軟件為例，資源管理平臺(tái)的使用步驟如圖4所示。

第一步，資源管理平臺(tái)依據(jù)系統(tǒng)XML配置文件啟動(dòng)RM、NM、RM_S等節(jié)點(diǎn)的相關(guān)任務(wù)，該配置文件中主要描述了各節(jié)點(diǎn)的角色信息、系統(tǒng)資源信息、資源采集節(jié)拍、打分權(quán)重等。

第二步，嵌入式應(yīng)用軟件準(zhǔn)備好可執(zhí)行程序與應(yīng)用XML配置文件，該文件主要描述了當(dāng)前應(yīng)用的資源需求、平臺(tái)與操作系統(tǒng)要求、應(yīng)用交互拓?fù)浣Y(jié)構(gòu)、運(yùn)行時(shí)長(zhǎng)等。

第三步，應(yīng)用軟件向資源管理平臺(tái)RM發(fā)送部署運(yùn)行請(qǐng)求，由RM依據(jù)資源請(qǐng)求和系統(tǒng)資源余量為嵌入式應(yīng)用分配合適的NM或RM_S部署運(yùn)行。

第四步，應(yīng)用部署運(yùn)行起來(lái)后，資源管理平臺(tái)負(fù)責(zé)實(shí)時(shí)監(jiān)測(cè)各節(jié)點(diǎn)與各應(yīng)用的狀態(tài)。

5 測(cè)試驗(yàn)證

基于上述四步具體使用流程，本文搭建了1個(gè)RM、3個(gè)RM_S、10個(gè)NM規(guī)模的資源管理平臺(tái)，并設(shè)計(jì)了Dpc.out/Mti.out/Detect.out三個(gè)應(yīng)用實(shí)例。其中RM的運(yùn)行過(guò)程如圖5所示，IP地址為192.9.200.210，主要負(fù)責(zé)接收應(yīng)用部署任務(wù)、發(fā)送心跳信息給RM_S并實(shí)時(shí)監(jiān)聽(tīng)各RM_S與NM的心跳信息。

RM接收到應(yīng)用部署任務(wù)后，將其分別部署在其中兩個(gè)NM（IP地址為192.9.200.211與192.9.200.212）上，其中一個(gè)NM部署了Dpc與Mti兩個(gè)應(yīng)用，一個(gè)NM部署了Detect一個(gè)應(yīng)用，NM的運(yùn)行過(guò)程如圖6所示，除了負(fù)責(zé)啟動(dòng)并監(jiān)聽(tīng)所部署的應(yīng)用外，還需周期性地發(fā)送心跳信息給RM。

每個(gè)RM_S其實(shí)也屬于一個(gè)NM，只是會(huì)額外監(jiān)聽(tīng)RM的心跳信息，隨時(shí)準(zhǔn)備激活成為新的RM，以某個(gè)RM_S（192.9.200.213）為例，其運(yùn)行過(guò)程如圖7所示。

針對(duì)資源管理平臺(tái)的高可靠特性，本文在測(cè)試驗(yàn)證過(guò)程分別模擬了應(yīng)用故障、NM故障、RM故障、RM_S故障場(chǎng)景下資源管理平臺(tái)的工作情況，測(cè)試故障恢復(fù)時(shí)間，其中故障判斷周期設(shè)置為50 ms，連續(xù)丟失3次則認(rèn)為發(fā)生故障，具體恢復(fù)時(shí)間結(jié)果（測(cè)100次取平均）如表1所示。

結(jié)果顯示四種場(chǎng)景下都能夠?qū)崿F(xiàn)ms級(jí)左右的故障恢復(fù)，基本上不影響整個(gè)系統(tǒng)的正常運(yùn)行。其中NM、RM、RM_S的恢復(fù)時(shí)間包括從診斷故障開(kāi)始到NM、RM、RM_S啟動(dòng)成功后的時(shí)間，應(yīng)用故障的恢復(fù)時(shí)間不包括應(yīng)用自身的啟動(dòng)時(shí)間（與具體應(yīng)用相關(guān)）。

6 結(jié) 論

本文設(shè)計(jì)了一種以RM、NM、RM_S為核心的資源管理平臺(tái)軟件，采用了XML可擴(kuò)展標(biāo)記語(yǔ)言、Redis數(shù)據(jù)庫(kù)、選舉策略設(shè)計(jì)、故障重構(gòu)設(shè)計(jì)等關(guān)鍵技術(shù)，重點(diǎn)描述了該平臺(tái)自身以及平臺(tái)上應(yīng)用的故障后的快速恢復(fù)機(jī)制，進(jìn)一步體現(xiàn)了該資源管理平臺(tái)的高可靠設(shè)計(jì)，并結(jié)合嵌入式應(yīng)用軟件實(shí)例充分驗(yàn)證了資源管理平臺(tái)的功能、指標(biāo)性能指標(biāo)與高可靠特性。

參考文獻(xiàn)：

[1] 張志慧.嵌入式系統(tǒng)的特點(diǎn)與發(fā)展趨勢(shì)分析 [J].電子技術(shù)，2023，52（7）：286-287.

[2] 馬志剛.嵌入式系統(tǒng)的現(xiàn)狀及發(fā)展趨勢(shì) [J].中國(guó)設(shè)備工程，2020（21）：145-147.

[3] 鄭百衡.高實(shí)時(shí)要求的嵌入式智能計(jì)算云平臺(tái)設(shè)計(jì) [J].單片機(jī)與嵌入式系統(tǒng)應(yīng)用，2022，22（1）：48-50.

[4] 邵永杰，王志敏.基于嵌入式云計(jì)算平臺(tái)的分布式實(shí)時(shí)計(jì)算框架研究 [J].通信技術(shù)，2019，52（7）：1708-1712.

[5] 尚葳蕤，黨紀(jì)紅，張錦江.空間站大規(guī)模復(fù)雜控制軟件基于數(shù)據(jù)池的軟件框架設(shè)計(jì) [J].載人航天，2024，30（1）：89-93.

[6] 吳曉，劉文祥，張凱龍.嵌入式分布實(shí)時(shí)系統(tǒng)自適應(yīng)資源管理架構(gòu) [J].計(jì)算機(jī)測(cè)量與控制，2012，20（2）：457-459.

[7] KIM J，RAJKUMAR R，KATO S. Towards Adaptive GPU Resource Management for Embedded Real-Time Systems [J].ACM SIGBED Review，2013，10（1）：14-17.

[8]王姝，溫曉玲.基于資源共享的分布式機(jī)載軟件測(cè)試系統(tǒng)設(shè)計(jì) [J].飛機(jī)設(shè)計(jì)，2024，44（1）：76-80.

[9] 張嵩，許蕾，吳永亮.基于XML的標(biāo)準(zhǔn)結(jié)構(gòu)化架構(gòu)設(shè)計(jì) [J].航天標(biāo)準(zhǔn)化，2023（2）：47-51+33.

[10] 鄧秀輝，李民，方惠.基于分布式集群高可用管理信息系統(tǒng)設(shè)計(jì) [J].制造業(yè)自動(dòng)化，2022，44（7）：43-45+122.

作者簡(jiǎn)介：程杭林（1993—），男，漢族，安徽六安人，工程師，碩士，研究方向：信息處理軟件工程實(shí)現(xiàn)與軟件總體設(shè)計(jì)；李路野（1986—），男，漢族，湖北漢川人，高級(jí)工程師，博士，研究方向：信息處理軟件架構(gòu)設(shè)計(jì)和軟件化雷達(dá)；王鵬（1990—），男，漢族，河北石家莊人，工程師，博士，研究方向：智能化信息處理與軟件總體設(shè)計(jì)。

DOI：10.19850/j.cnki.2096-4706.2024.17.022

收稿日期：2024-04-29

Design of Highly Reliable Resource Management Platform for Embedded System

CHENG Hanglin， LI Luye， WANG Peng

（Nanjing Research Institute of Electronics Technology， Nanjing 210039， China）

Abstract： In view of the application requirements of the multi-function and multi-task of embedded domain， the reconstruction of system in complex and ever-changing environment， and scalability and maintainability for long equipment life cycles and so on， in order to achieve unified management of computing， storage， network and other resources in embedded systems， a highly reliable resource management platform for embedded systems is designed. The platform uses key technologies such as XML， Redis database， election policy design， and fault recovery mechanisms， then it focuses on achieving a highly reliable design for the resource management platform and the application software within the platform.

The functions， metric performance and highly reliable characteristics of the resource management platform are fully verified using examples from embedded application software.

Keywords： embedded system; resource management platform; highly reliable design