色哟哟视频在线观看-色哟哟视频在线-色哟哟欧美15最新在线-色哟哟免费在线观看-国产l精品国产亚洲区在线观看-国产l精品国产亚洲区久久

0
  • 聊天消息
  • 系統消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發帖/加入社區
會員中心
創作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內不再提示

嵌入式軟件可靠性設計的編程要點

工程師進階筆記 ? 來源:csdn ? 2023-05-16 09:39 ? 次閱讀

設備的可靠性涉及多個方面:穩定的硬件、優秀的軟件架構、嚴格的測試以及市場和時間的檢驗等等。這里著重談一下作者自己對嵌入式軟件可靠性設計的一些理解,通過一定的技巧和方法提高軟件可靠性。

1、判錯

工欲善其事必先利其器。判錯的最終目的是用來暴露設計中的Bug并加以改正,所以將錯誤信息提供給編程者是必要的。

有時候需要將故障信息儲存于非易失性存儲器中,便于查看。這里以使用串口打印錯誤信息到PC顯示屏為例,來說明一般需要顯示什么信息。

編寫或移植一個類似C標準庫中的printf函數,可以格式化打印字符、字符串、十進制整數、十六進制整數。這里稱為UARTprintf()。

unsignedintWriteData(unsignedintaddr)
{
if((addr>=BASE_ADDR)&&(addr<=END_ADDR))?
????{
????????…/*地址合法,進行處理*/
?}?
????else?
????{?/*地址錯誤,打印錯誤信息*/
??UARTprintf?("文件%s的第?%d?行寫數據時發生地址錯誤,錯誤地址為:0x%x
",__FILE__,__LINE__,addr);
??…/*錯誤處理代碼*/
?}

假設UARTprintf()函數位于main.c模塊的第256行,并且WriteData()函數在讀數據時傳遞了錯誤地址0x00000011,則會執行UARTprintf()函數,打印如下所示的信息:

文件main.c的第256行寫數據時發生地址錯誤,錯誤地址為:0x00000011。類似這樣的信息會有助于程序員定位分析錯誤產生的根源,更快的消除Bug。

2、判斷實參是否合法

程序員可能無意識的傳遞了錯誤參數;外界的強干擾可能將傳遞的參數修改掉,或者使用隨機參數意外的調用函數,因此在執行函數主體前,需要先確定實參是否合法。

intexam_fun(unsignedchar*str)
{
if(str!=NULL)
{//檢查“假設指針不為空”這個條件

...//正常處理代碼
}
else
{
UARTprintf(…);//打印錯誤信息
…//處理錯誤代碼
}
}

3、仔細檢查函數的返回值

對函數返回的錯誤碼,要進行全面仔細處理,必要時做錯誤記錄。

char*DoSomething(…)
{
char*p;
p=malloc(1024);
if(p==NULL)
{/*對函數返回值作出判斷*/
UARTprintf(…);/*打印錯誤信息*/
returnNULL;
}
retuenp;
}

4、防止指針越界

如果動態計算一個地址時,要保證被計算的地址是合理的并指向某個有意義的地方。特別對于指向一個結構或數組的內部的指針,當指針增加或者改變后仍然指向同一個結構或數組。

5、防止數組越界

數組越界的問題前文已經講述的很多了,由于C不會對數組進行有效的檢測,因此必須在應用中顯式的檢測數組越界問題。下面的例子可用于中斷接收通訊數據。

#defineREC_BUF_LEN100
unsignedcharRecBuf[REC_BUF_LEN];
…//其它代碼
voidUart_IRQHandler(void)
{
staticRecCount=0;//接收數據長度計數器
…//其它代碼
if(RecCount

在使用一些庫函數時,同樣需要對邊界進行檢查:

#defineREC_BUF_LEN100
unsignedcharRecBuf[REC_BUF_LEN];

if(len

6、數學算數運算

檢測除數是否為零

檢測運算溢出情況

「有符號整數除法,僅檢測除數為零就夠了嗎?」

兩個整數相除,除了要檢測除數是否為零外,還要檢測除法是否溢出。對于一個signed long類型變量,它能表示的數值范圍為:-2147483648 ~ +2147483647,如果讓-2147483648 / -1,那么結果應該是+ 2147483648,但是這個結果已經超出了signed long所能表示的范圍了。

#include
signedlongsl1,sl2,result;
/*初始化sl1和sl2*/
if((sl2==0)||((sl1==LONG_MIN)&&(sl2==-1)))
{
//處理錯誤
}
else
{
result=sl1/sl2;
}

「加法溢出檢測:」

a)無符號加法

#include
unsignedinta,b,result;
/*初始化a,b*/
if(UINT_MAX-a

b)有符號加法

#include
signedinta,b,result;
/*初始化a,b*/
if((a>0&&INT_MAX-ab))
{
//處理溢出
}
else
{
result=a+b;
}

「乘法溢出檢測:」

a)無符號乘法

#include
unsignedinta,b,result;
/*初始化a,b*/
if((a!=0)&&(UINT_MAX/a

b)有符號乘法

#include
signedinta,b,tmp,result;
/*初始化a,b*/
tmp=a*b;
if(a!=0&&tmp/a!=b)
{
//
}
else
{
result=tmp;
}

7、其它可能出現運行時錯誤的地方

運行時錯誤檢查是C 程序員需要加以特別的注意的,這是因為C語言在提供任何運行時檢測方面能力較弱。對于要求可靠性較高的軟件來說,動態檢測是必需的。

因此C 程序員需要謹慎考慮的問題是,在任何可能出現運行時錯誤的地方增加代碼的動態檢測。大多數的動態檢測與應用緊密相關,在程序設計過程中要根據系統需求設置動態代碼檢測。

8、編譯器語義檢查

為了更簡單的設計編譯器,目前幾乎所有編譯器的語義檢查都比較弱小,加之為了獲得更快的執行效率,C語言被設計的足夠靈活且幾乎不進行任何運行時檢查,比如數組越界、指針是否合法、運算結果是否溢出等等。

C語言足夠靈活,對于一個數組a[30],它允許使用像a[-1]這樣的形式來快速獲取數組首元素所在地址前面的數據;允許將一個常數強制轉換為函數指針,使用代碼( * ((void( * )())0))()來調用位于0地址的函數。

C語言給了程序員足夠的自由,但也由程序員承擔濫用自由帶來的責任。下面的兩個例子都是死循環,如果在不常用分支中出現類似代碼,將會造成看似莫名其妙的死機或者重啟。

a.unsignedchari;
for(i=0;i<256;i++)??{…?}??????????????
b.?unsigned?chari;
???for(i=10;i>=0;i--){…}

對于無符號char類型,表示的范圍為0~255,所以無符號char類型變量i永遠小于256(第一個for循環無限執行),永遠大于等于0(第二個for循環無線執行)。需要說明的是,賦值代碼i=256是被C語言允許的,即使這個初值已經超出了變量i可以表示的范圍。C語言會千方百計的為程序員創造出錯的機會,可見一斑。

假如你在if語句后誤加了一個分號改變了程序邏輯,編譯器也會很配合的幫忙掩蓋,甚至連警告都不提示。代碼如下:

if(a>b);//這里誤加了一個分號
a=b;//這句代碼一直被執行

不但如此,編譯器還會忽略掉多余的空格符和換行符,就像下面的代碼也不會給出足夠提示:

if(n<3)
return????//這里少加了一個分號
logrec.data=x[0];
logrec.time=x[1];
logrec.code=x[2];

這段代碼的本意是n<3時程序直接返回,由于程序員的失誤,return少了一個結束分號。編譯器將它翻譯成返回表達式logrec.data=x[0]的結果,return后面即使是一個表達式也是C語言允許的。這樣當n>=3時,表達式logrec.data=x[0];就不會被執行,給程序埋下了隱患。

可以毫不客氣的說,弱小的編譯器語義檢查在很大程度上縱容了不可靠代碼可以肆無忌憚的存在。

上文曾提到數組常常是引起程序不穩定的重要因素,程序員往往不經意間就會寫數組越界。一位同事的代碼在硬件上運行,一段時間后就會發現LCD顯示屏上的一個數字不正常的被改變。經過一段時間的調試,問題被定位到下面的一段代碼中:

intSensorData[30];
for(i=30;i>0;i--)
{
SensorData[i]=…;
…
}

這里聲明了擁有30個元素的數組,不幸的是for循環代碼中誤用了本不存在的數組元素SensorData[30],但C語言卻默許這么使用,并欣然的按照代碼改變了數組元素SensorData[30]所在位置的值。

SensorData[30]所在的位置原本是一個LCD顯示變量,這正是顯示屏上的那個值不正常被改變的原因。真慶幸這么輕而易舉的發現了這個Bug。

9、關鍵數據多區備份,取數據采用“表決法”

RAM中的數據在受到干擾情況下有可能被改變,對于系統關鍵數據必須進行保護。關鍵數據包括全局變量、靜態變量以及需要保護的數據區域。數據備份與原數據不應該處于相鄰位置,因此不應由編譯器默認分配備份數據位置,而應該由程序員指定區域存儲。

可以將RAM分為3個區域,第一個區域保存原碼,第二個區域保存反碼,第三個區域保存異或碼,區域之間預留一定量的“空白”RAM作為隔離。

可以使用編譯器的“分散加載”機制將變量分別存儲在這些區域。需要進行讀取時,同時讀出3份數據并進行表決,取至少有兩個相同的那個值。

假如設備的RAM從0x1000_0000開始,我需要在RAM的0x1000_0000~0x10007FFF內存儲原碼,在0x1000_9000~0x10009FFF內存儲反碼,在0x1000_B000~0x1000BFFF內存儲0xAA的異或碼,編譯器的分散加載可以設置為:

LR_IROM10x000000000x00080000{;loadregionsize_region
ER_IROM10x000000000x00080000{;loadaddress=executionaddress
*.o(RESET,+First)
*(InRoot$$Sections)
.ANY(+RO)
}

RW_IRAM10x100000000x00008000{;保存原碼
.ANY(+RW+ZI)
}

RW_IRAM30x100090000x00001000{;保存反碼
.ANY(MY_BK1)
}

RW_IRAM20x1000B0000x00001000{;保存異或碼
.ANY(MY_BK2)
}
}

如果一個關鍵變量需要多處備份,可以按照下面方式定義變量,將三個變量分別指定到三個不連續的RAM區中,并在定義時按照原碼、反碼、0xAA的異或碼進行初始化。

uint32plc_pc=0;//原碼
__attribute__((section("MY_BK1")))uint32plc_pc_not=~0x0;//反碼
__attribute__((section("MY_BK2")))uint32plc_pc_xor=0x0^0xAAAAAAAA;//異或碼

當需要寫這個變量時,這三個位置都要更新;讀取變量時,讀取三個值做判斷,取至少有兩個相同的那個值。

為什么選取異或碼而不是補碼?這是因為MDK的整數是按照補碼存儲的,正數的補碼與原碼相同,在這種情況下,原碼和補碼是一致的,不但起不到冗余作用,反而對可靠性有害。

比如存儲的一個非零整數區因為干擾,RAM都被清零,由于原碼和補碼一致,按照3取2的“表決法”,會將干擾值0當做正確的數據。

10、非易失性存儲器的數據存儲

非易失性存儲器包括但不限于Flash、EEPROM、鐵電。僅僅將寫入非易失性存儲器中的數據再讀出校驗是不夠的。強干擾情況下可能導致非易失性存儲器內的數據錯誤,在寫非易失性存儲器的期間系統掉電將導致數據丟失,因干擾導致程序跑飛到寫非易失性存儲器函數中,將導致數據存儲紊亂。

一種可靠的辦法是將非易失性存儲器分成多個區,每個數據都將按照不同的形式寫入到這些分區中,需要進行讀取時,同時讀出多份數據并進行表決,取相同數目較多的那個值。

對于因干擾導致程序跑飛到寫非易失性存儲器函數,還應該配合軟件鎖以及嚴格的入口檢驗,單單依靠寫數據到多個區是不夠的也是不明智的,應該在源頭進行阻截。

11、軟件鎖

軟件鎖可以實現但不局限于環環相扣。對于初始化序列或者有一定先后順序的函數調用,為了保證調用順序或者確保每個函數都被調用,我們可以使用環環相扣,實質上這也是一種軟件鎖。此外對于一些安全關鍵代碼語句(是語句,而不是函數),可以給它們設置軟件鎖,只有持有特定鑰匙的,才可以訪問這些關鍵代碼。

比如,向Flash寫一個數據,我們會判斷數據是否合法、寫入的地址是否合法,計算要寫入的扇區。之后調用寫Flash子程序,在這個子程序中,判斷扇區地址是否合法、數據長度是否合法,之后就要將數據寫入Flash。

由于寫Flash語句是安全關鍵代碼,所以程序給這些語句上鎖:必須具有正確的鑰匙才可以寫Flash。這樣即使是程序跑飛到寫Flash子程序,也能大大降低誤寫的風險。

/***************************************************************
*名稱:RamToFlash()
*功能:復制RAM的數據到FLASH,命令代碼51。
*入口參數:dst 目標地址,即FLASH起始地址。以512字節為分界
* src 源地址,即RAM地址。地址必須字對齊
*no復制字節個數,為512/1024/4096/8192
*ProgStart軟件鎖標志
*出口參數:IAP返回值(paramout緩沖區) CMD_SUCCESS,SRC_ADDR_ERROR,DST_ADDR_ERROR,
SRC_ADDR_NOT_MAPPED,DST_ADDR_NOT_MAPPED,COUNT_ERROR,BUSY,未選擇扇區
****************************************************************/
voidRamToFlash(uint32dst,uint32src,uint32no,uint8ProgStart)
{
PLC_ASSERT("Sectornumber",(dst>=0x00040000)&&(dst<=0x0007FFFF));
????PLC_ASSERT("Copy?bytes?number?is?512",(no==512));
????PLC_ASSERT("ProgStart==0xA5",(ProgStart==0xA5));
????paramin[0]?=?IAP_RAMTOFLASH;?//?設置命令字
????paramin[1]?=?dst;?//?設置參數
????paramin[2]?=?src;
????paramin[3]?=?no;
????paramin[4]?=?Fcclk/1000;
????if(ProgStart==0xA5)?//只有軟件鎖標志正確時,才執行關鍵代碼
????{
????????iap_entry(paramin,?paramout);?//?調用IAP服務程序
????????ProgStart=0;
????}
????else
????{
?????paramout[0]=PROG_UNSTART;
????}

}

該程序段是編程lpc1778內部Flash,其中調用IAP程序的函數iap_entry(paramin, paramout)是關鍵安全代碼,所以在執行該代碼前,先判斷一個特定設置的安全鎖標志ProgStart,只有這個標志符合設定值,才會執行編程Flash操作。

如果因為意外程序跑飛到該函數,由于ProgStart標志不正確,是不會對Flash進行編程的。

12、通信數據的檢錯

通訊線上的數據誤碼相對嚴重,通訊線越長,所處的環境越惡劣,誤碼會越嚴重。拋開硬件和環境的作用,我們的軟件應能識別錯誤的通訊數據。對此有一些應用措施:

制定協議時,限制每幀的字節數;

每幀字節數越多,發生誤碼的可能性就越大,無效的數據也會越多。對此以太網規定每幀數據不大于1500字節,高可靠性的CAN收發器規定每幀數據不得多于8字節,對于RS485,基于RS485鏈路應用最廣泛的Modbus協議一幀數據規定不超過256字節。因此,建議制定內部通訊協議時,使用RS485時規定每幀數據不超過256字節;

使用多種校驗

編寫程序時應使能奇偶校驗,每幀超過16字節的應用,建議至少編寫CRC16校驗程序。

增加額外判斷

增加緩沖區溢出判斷。這是因為數據接收多是在中斷中完成,編譯器檢測不出緩沖區是否溢出,需要手動檢查,在上文介紹數據溢出一節中已經詳細說明。

增加超時判斷。當一幀數據接收 到一半,長時間接收不到剩余數據,則認為這幀數據無效,重新開始接收。

可選,跟不同的協議有關,但緩沖區溢出判斷必須實現。這是因為對于需要幀頭判斷的協議,上位機可能發送完幀頭后突然斷電,重啟后上位機是從新的幀開始發送的,但是下位機已經接收到了上次未發送完的幀頭,所以上位機的這次幀頭會被下位機當成正常數據接收。

這有可能造成數據長度字段為一個很大的值,填滿該長度的緩沖區需要相當多的數據(比如一幀可能1000字節),影響響應時間;另一方面,如果程序沒有緩沖區溢出判斷,那么緩沖區很可能溢出,后果是災難性的。

重傳機制

如果檢測到通訊數據發生了錯誤,則要有重傳機制重新發送出錯的幀。

13、開關量輸入的檢測、確認

開關量容易受到尖脈沖干擾,如果不進行濾除,可能會造成誤動作。一般情況下,需要對開關量輸入信號進行多次采樣,并進行邏輯判斷直到確認信號無誤為止。多次采樣之間需要有一定時間間隔,具體跟開關量的最大切換頻率有關,一般不小于1ms。

14、開關量輸出

開關信號簡單的一次輸出是不安全的,干擾信號可能會翻轉開關量輸出的狀態。采取重復刷新輸出可以有效防止電平的翻轉。

15、初始化信息的保存與恢復

微處理器寄存器值也可能會因外界干擾而改變,外設初始化值需要在寄存器中長期保存,最容易被破壞。由于Flash中的數據相對不易被破壞,可以將初始化信息預先寫入Flash,待程序空閑時比較與初始化相關的寄存器值是否被更改,如果發現非法更改則使用Flash中的值進行恢復。

16、while循環

有時候程序員會使用while(!flag);語句來等待標志flag改變,比如串口發送時用來等待一字節數據發送完成。這樣的代碼時存在風險的,如果因為某些原因標志位一直不改變則會造成系統死機。良好冗余的程序是設置一個超時定時器,超過一定時間后,強制程序退出while循環。

2003年8月11日發生的W32.Blaster.Worm蠕蟲事件導致全球經濟損失高達5億美元,這個漏洞是利用了Windows分布式組件對象模型的遠程過程調用接口中的一個邏輯缺陷:在調用GetMachineName()函數時,循環只設置了一個不充分的結束條件。

原代碼簡化如下所示:

HRESULTGetMachineName(WCHAR*pwszPath,
WCHARwszMachineName[MAX_COMPUTTERNAME_LENGTH_FQDN+1])
{
WCHAR*pwszServerName=wszMachineName;
WCHAR*pwszTemp=pwszPath+2;
while(*pwszTemp!=L’\’)/*這句代碼循環結束條件不充分*/
*pwszServerName++=*pwszTemp++;
/*…*/
}

微軟發布的安全補丁MS03-026解決了這個問題,為GetMachineName()函數設置了充分終止條件。一個解決代碼簡化如下所示(并非微軟補丁代碼):

HRESULTGetMachineName(WCHAR*pwszPath,
WCHARwszMachineName[MAX_COMPUTTERNAME_LENGTH_FQDN+1])
{
WCHAR*pwszServerName=wszMachineName;
WCHAR*pwszTemp=pwszPath+2;
 WCHAR *end_addr = pwszServerName +MAX_COMPUTTERNAME_LENGTH_FQDN;
while((*pwszTemp!=L’\’)&&(*pwszTemp!=L’0’)
&&(pwszServerName

17、系統自檢

CPU、RAM、Flash、外部掉電保存存儲器以及其他線路自檢。

18、其它一些編程建議:

深入理解嵌入式C語言以及編譯器

細致、謹慎的編程

使用好的風格和合理的設計

不要倉促編寫代碼,寫每一行的代碼時都要三思而后行:可能會出現什么樣的錯誤?是否考慮了所有的邏輯分支?

打開編譯器所有警告開關

使用靜態分析工具分析代碼

安全的讀寫數據(檢查所有數組邊界…)

檢查指針的合法性

檢查函數入口參數合法性

檢查所有返回值

在聲明變量位置初始化所有變量

合理的使用括號

謹慎的進行強制轉換

使用好的診斷信息日志和工具

來源:https://blog.csdn.net/zhzht19861011/article/details/17117819





審核編輯:劉清

聲明:本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人,不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用,如有內容侵權或者其他違規問題,請聯系本站處理。 舉報投訴
  • C語言
    +關注

    關注

    180

    文章

    7604

    瀏覽量

    136700
  • 嵌入式軟件
    +關注

    關注

    4

    文章

    240

    瀏覽量

    26641
  • LCD顯示屏
    +關注

    關注

    1

    文章

    91

    瀏覽量

    13297
  • 非易失性存儲器

    關注

    0

    文章

    107

    瀏覽量

    23438

原文標題:嵌入式軟件可靠性設計的編程要點

文章出處:【微信號:工程師進階筆記,微信公眾號:工程師進階筆記】歡迎添加關注!文章轉載請注明出處。

收藏 人收藏

    評論

    相關推薦

    嵌入式軟件可靠性設計要注意的問題

    )。 嵌入式系統應用領域千差萬別、他們對嵌入式系統的要求和側重點不盡相同,(如工業控制特別強調可靠性), 但基本要求嵌入式系統功能強大、性能穩定、工作
    的頭像 發表于 10-14 11:05 ?5256次閱讀
    <b class='flag-5'>嵌入式</b><b class='flag-5'>軟件</b><b class='flag-5'>可靠性</b>設計要注意的問題

    嵌入式軟件可靠性測試方法

    嵌入式軟件可靠性測試方法
    發表于 11-05 17:18

    淺析嵌入式系統軟件可靠性測試難點

    `目前,嵌入式軟件可靠性評價主要依賴測試,因為嵌入式軟件的開發環境和軟件
    發表于 08-02 10:05

    嵌入式軟件可靠性測試與可靠性增長評估

    關于嵌入式軟件可靠性、安全測試與評估的資料,希望有幫助。
    發表于 06-17 16:53

    請問一下嵌入式軟件可靠性設計需注意什么?

    嵌入式軟件可靠性設計需注意什么?
    發表于 04-27 06:23

    如何對嵌入式軟件進行可靠性測試

    摘 要 本文針對目前嵌入式軟件設計可靠性測試用例的手段主要依靠手工分析,沿用傳統的軟件測試用例設計方法進行,不能夠滿足可靠性測試用例設計的基
    發表于 10-27 06:10

    嵌入式軟件可靠性測試方法是什么

    本文原文鏈接如下:https://www.jianshu.com/p/f6f5c3cd3fab目前,嵌入式軟件可靠性評價主要依賴測試,因為嵌入式
    發表于 12-21 07:09

    嵌入式軟件的安全可靠性控制

    不同的嵌入式系統對其安全可靠性的要求是不一樣的。一般說來,嵌入式系統對可靠性與安全的要求要高于非嵌入式
    發表于 04-22 16:49 ?21次下載

    嵌入式系統軟件可靠性設計

    本文分析了 嵌入式系統軟件的復雜度、可靠性與穩定性之間的關系,本給出了增加嵌入式系統可靠性的一般方法。
    發表于 11-17 17:43 ?38次下載

    軍用嵌入式系統的可靠性考慮因素

    1 可靠性是軍用嵌入式系統的重要因素嵌入式系統往往工作環境惡劣、受電噪聲干擾較大,而且隨著軟件越來越復
    發表于 08-18 11:00 ?700次閱讀

    嵌入式系統的可靠性設計

    嵌入式應用系統是一個有計算機內核,軟、硬件整合的智能化電子系統。與傳統的激勵響應型電子系統的本質差異,是它的智力嵌入,從而形成嵌入式應用系統全新的可靠性設計觀念、方法與技術。這些全新的
    發表于 11-30 10:04 ?1369次閱讀
     <b class='flag-5'>嵌入式</b>系統的<b class='flag-5'>可靠性</b>設計

    軍用嵌入式系統的可靠性考慮因素

    1 可靠性是軍用嵌入式系統的重要因素 嵌入式系統往往工作環境惡劣、受電噪聲干擾較大,而且隨著軟件越來越復雜,系統運行不穩定的現象愈來愈嚴重,因此,
    發表于 12-02 19:42 ?705次閱讀

    嵌入式系統硬件可靠性分析

    嵌入式系統硬件的可靠性是十分重要的,它直接關系到嵌入式系統的質量和壽命。為了對嵌入式系統的硬件可靠性進行分析,利用Copula方法從硬件角度
    發表于 01-17 13:46 ?1次下載
    <b class='flag-5'>嵌入式</b>系統硬件<b class='flag-5'>可靠性</b>分析

    嵌入式軟件怎樣測試,如何對嵌入式軟件進行可靠性測試

    摘 要 本文針對目前嵌入式軟件設計可靠性測試用例的手段主要依靠手工分析,沿用傳統的軟件測試用例設計方法進行,不能夠滿足可靠性測試用例設計的基
    發表于 10-20 15:21 ?8次下載
    <b class='flag-5'>嵌入式</b><b class='flag-5'>軟件</b>怎樣測試,如何對<b class='flag-5'>嵌入式</b><b class='flag-5'>軟件</b>進行<b class='flag-5'>可靠性</b>測試

    嵌入式軟件可靠性設計

    設備的可靠性涉及多個方面:穩定的硬件、優秀的軟件架構、嚴格的測試以及市場和時間的檢驗等等。這里著重談一下作者自己對嵌入式軟件可靠性設計的一些
    的頭像 發表于 06-22 10:00 ?814次閱讀
    主站蜘蛛池模板: 国产亚洲精品99一区二区| 久久精品国产在热亚洲完整版| 国内精品久久久久影院亚洲| 久久人妻少妇嫩草AV蜜桃99| 区久久AAA片69亚洲| 亚洲精品久久7777777| 99re.05久久热最新地址| 国产 亚洲 中文在线 字幕| 久久草福利自拍视频在线观看| 妻中蜜在线播放| 亚洲日韩KKK444KKK聚色| 爱啪国产精品视频在线| 精品久久久久久久高清| 人人插人人射| 在线免费观看成年人视频| 国产h视频在线观看免费| 麻豆E奶女教师国产精品| 无限好资源免费观看| FREE乌克兰嫩交HD| 久九九精品免费视频| 涩涩在线观看免费视频| 91精品国产入口| 好爽胸大好深好多水| 三级全黄的视频在线观看| 最新国产三级在线不卡视频| 国产香蕉视频| 日本人HD18HD18| 37大但人文艺术A级都市天气| 国产综合在线视频| 色综合久久中文色婷婷| 97精品国产高清在线看入口| 红桃传媒少妇人妻网站无码抽插| 日本中文字幕巨大的乳专区| 最新 国产 精品 精品 视频| 国产亚洲日韩欧美视频| 日日噜噜噜夜夜爽爽狠狠| 91麻豆久久| 久久精品亚洲AV高清网站性色| 午夜亚洲精品不卡在线| www.伊人网| 免费人成在线观看网站视频|