Mikroprocesszoros eszközök tervezésére szolgáló programok. Mikroprocesszorok. Operátorok és műveletek

A mikroprocesszoros adatgyűjtő rendszernek a következő követelményeknek kell megfelelnie: nagy teljesítményűnek és egyszerűen kivitelezhetőnek kell lennie, stabil és problémamentes működést kell biztosítania, viszonylag olcsónak kell lennie és kevés erőforrást fogyasztania. A rábízott feladatok elvégzésére és az alapkövetelményeknek megfelelően a K1816BE51 sorozatú mikrokontroller alkalmas.

3. ábra - Mikroprocesszoros adatgyűjtő rendszer blokkvázlata.

mikroprocesszoros program algoritmus chip

A mikroprocesszoros rendszer (MPS) a következő blokkokból áll: mikrokontroller (MC), véletlen hozzáférésű memória (RAM), csak olvasható memória (ROM), programozható időzítő (PT), párhuzamos programozható interfész (PPI), analóg-digitális konverter (ADC), digitális-analóg konverter (DAC), multiplexer (MUX), programozható megszakításvezérlő (PIC).

Az MK egy címbuszt (ABA), egy adatbuszt (SD) és egy vezérlőbuszt (CC) alkot. A buszokhoz RAM, ROM, PT, PPI, PKP blokkok kapcsolódnak.

A RAM az érzékelő felmérési adatainak, valamint a közbenső adatok tárolására szolgál. A ROM programkód és különféle állandók tárolására szolgál.

A PT-t úgy tervezték, hogy megszámolja az MK parancsok végrehajtásához szükséges időintervallumot. A művelet végrehajtása előtt a PT elindul. Ha a művelet sikeres, az MK alaphelyzetbe állítja a PT-t. Ha nem érkezik számláló-visszaállítási parancs az MC-től (lefagyás történt), a PT az időintervallum számlálása végén MC reset jelet generál.

A PPI csatlakozásra szolgál külső eszközök. Az SPI-hez egy ADC, egy diszkrét multiplexer és egy DAC csatlakozik.

Az ADC-t úgy tervezték, hogy átalakítsa az érzékelőktől származó analóg jelet és egy digitális kódot, amelyet a PPI-n keresztül továbbítanak az MK-hoz. Az analóg érzékelők analóg multiplexeren keresztül csatlakoznak az ADC-hez.

A diszkrét érzékelők adatai egy diszkrét multiplexeren keresztül érkeznek.

A DAC-t úgy tervezték, hogy vezérlési műveleteket generáljon.

A központ külső megszakítások kiszolgálására szolgál.

Mikroprocesszoros rendszerek tervezésének szakaszai

A mikroprocesszoros rendszerek összetettségükben, követelményeikben és funkcióikban jelentősen eltérhetnek megbízhatósági paraméterekben, térfogatban szoftver, legyen egyprocesszoros és többprocesszoros, egy vagy több típusú mikroprocesszorkészletre épüljön stb. Ebben a tekintetben a tervezési folyamat a rendszerekkel szemben támasztott követelmények függvényében módosítható. Például az egymástól ROM-tartalomban eltérő MPS-ek tervezési folyamata programok fejlesztéséből és ROM-ok gyártásából fog állni.

A többféle mikroprocesszor készletet tartalmazó többprocesszoros mikroprocesszoros rendszerek tervezésénél meg kell oldani a memóriaszervezés, a processzorokkal való interakció, a rendszereszközök és a külső környezet közötti csere megszervezése, a különböző működési sebességű eszközök működésének összehangolása stb. Az alábbiakban egy hozzávetőleges lépéssorozat látható, amely jellemző a mikroprocesszoros rendszer létrehozására:
1. A rendszerkövetelmények formalizálása.
2. A rendszer szerkezetének és architektúrájának fejlesztése.
3. Rendszer hardver és szoftver fejlesztése és gyártása.
4. Átfogó hibakeresés és elfogadási tesztelés.

1. szakasz. Ebben a szakaszban elkészítik a külső specifikációkat, felsorolják a rendszer funkcióit, formalizálják a rendszer műszaki specifikációit (TOR), és a fejlesztő terveit hivatalos dokumentációban rögzítik.

2. szakasz. Ebben a szakaszban meghatározzák az egyes eszközök és szoftverek funkcióit, kiválasztják a mikroprocesszor készleteket, amelyek alapján a rendszert megvalósítják, meghatározzák a hardver és a szoftver közötti interakciót, valamint az egyes eszközök és programok időzítési jellemzőit. .

3. szakasz. A hardver és a programok által megvalósított funkciók meghatározása után az áramkörtervezők és a programozók egyszerre kezdik meg a prototípus, illetve a szoftver fejlesztését és gyártását. A berendezések fejlesztése és gyártása szerkezeti és kapcsolási rajzok kidolgozásából, prototípusgyártásból és off-line hibakeresésből áll.
A szoftverfejlesztés algoritmusok fejlesztéséből áll; forrásprogramok szövegének megírása; forrásprogramok fordítása objektumprogramokká; offline hibakeresés.

4. szakasz. Lásd: Átfogó hibakeresés.

Az MPS tervezésének minden szakaszában az emberek hibákat vezethetnek be, és helytelen tervezési döntéseket hozhatnak. Ezen túlmenően a berendezésben hibák is előfordulhatnak.

Hibaforrások

Tekintsük a hibaforrásokat a tervezés első három szakaszában.

1. szakasz. Ebben a szakaszban a hibaforrások a következők lehetnek: a követelmények logikai inkonzisztenciája, kihagyások, az algoritmus pontatlansága.

2. szakasz Ebben a szakaszban a hibaforrások lehetnek: funkciók kihagyása, a berendezések és programok közötti interakció protokolljának inkonzisztenciája, a mikroprocesszorkészletek helytelen megválasztása, az algoritmusok pontatlansága, a műszaki követelmények helytelen értelmezése, egyes információáramlások kihagyása.

3. szakasz. Ebben a szakaszban hibaforrások lehetnek: a berendezések fejlesztése során - egyes funkciók kihagyása, a műszaki követelmények helytelen értelmezése, a szinkronizációs áramkörök hibái, a tervezési szabályok megsértése; prototípus gyártása során - az alkatrészek meghibásodása, telepítési és összeszerelési hibák; szoftverfejlesztéskor - egyes funkciók kihagyása feladatmeghatározás, pontatlanságok az algoritmusokban, kódolási pontatlanságok.

A felsorolt ​​hibaforrások mindegyike nagyszámú szubjektív vagy fizikai hibát generálhat, amelyeket lokalizálni és kiküszöbölni kell. A hibafelismerés és a hiba lokalizálása több okból is nehéz feladat: egyrészt a hibák nagy száma miatt; másodszor, amiatt, hogy a különböző hibák egyformán megnyilvánulhatnak. Mivel a szubjektív hibáknak nincsenek modelljei, ez a feladat nincs formalizálva. Némi előrelépés történt a hibák észlelésére és a fizikai hibák lokalizálására szolgáló módszerek és eszközök létrehozása terén. Ezeket a módszereket és eszközöket széles körben alkalmazzák a diszkrét rendszerek üzemállapotának ellenőrzésére és hibáinak diagnosztizálására az utóbbiak tervezése, gyártása és üzemeltetése során.

A szubjektív meghibásodások abban különböznek a fizikaiaktól, hogy észlelés, lokalizáció és korrekció után már nem fordulnak elő. Azonban, ahogy a hibaforrások listája is sugallja, a rendszerspecifikáció kidolgozása során szubjektív hibák is bekerülhetnek, vagyis a rendszer külső specifikációihoz képest történő legalaposabb tesztelése után is előfordulhatnak szubjektív hibák a rendszerben.

A tervezési folyamat iteratív folyamat. Az átvételi tesztelés szakaszában feltárt meghibásodások a specifikációk korrekciójához, következésképpen a teljes rendszer tervezésének megkezdéséhez vezethetnek. A hibákat a lehető legkorábban fel kell fedezni, ehhez minden fejlesztési szakaszban ellenőrizni kell a projekt helyességét.

A terv érvényesítése

A tervezés helyességének ellenőrzésének főbb módszerei a következők: ellenőrzés - a tervezés helyességének bizonyításának formális módszerei; modellezés; tesztelés.

Sok munka folyik a szoftver, a firmware és a hardver ellenőrzésén. Ezek a munkák azonban elméleti jellegűek. A gyakorlatban még mindig használják az objektumok viselkedésének modellezését és tesztelését.

A projekt helyességének minden tervezési szakaszban történő ellenőrzéséhez szükséges a rendszer absztrakt ábrázolásának különböző szintjein modellezést végezni, és teszteléssel ellenőrizni kell az adott modell helyes megvalósítását. A követelmények formalizálásának szakaszában a helyességellenőrzés különösen szükséges, mivel sok tervezési cél nincs formalizálva, vagy elvileg nem formalizálható. A funkcionális specifikációt egy szakértői csoport felülvizsgálhatja, vagy szimulálhatja és tesztelheti annak meghatározására, hogy a kívánt célokat elérik-e. A funkcionális specifikáció jóváhagyása után megkezdődik a funkcionális tesztprogramok kidolgozása a rendszer funkcionális specifikációinak megfelelő megfelelő működésének megállapítására. Ideális esetben olyan teszteket dolgoznak ki, amelyek teljes mértékben ezen a specifikáción alapulnak, és lehetővé teszik egy olyan rendszer bármely megvalósításának tesztelését, amelyről azt állítják, hogy képes a specifikációban meghatározott funkciók végrehajtására. Ez a módszer szöges ellentéte a többinek, ahol a tesztek meghatározott implementációkhoz kapcsolódnak. Az implementációtól független funkcionális verifikáció általában csak elméleti szempontból vonzó, gyakorlati jelentősége azonban nagyfokú általánossága miatt nincs.

A tesztprogramok írásának fáradságos munkájának automatizálása nemcsak a tervezési/hibakeresési időszakot csökkenti azáltal, hogy tesztprogramokat generál a tervezési fázisban (mivel azok közvetlenül a rendszerkövetelmények generálása után generálhatók), hanem lehetővé teszi a tervező számára, hogy anélkül módosítsa a specifikációkat. aggódnia kell az összes tesztprogram újraírása miatt. A gyakorlatban azonban a tesztfejlesztés gyakran alacsonyabb prioritást kap, mint a tervezés, így tesztprogramok sokkal később jelenik meg, mint a befejezése. De még ha részletes tesztek felkészültnek bizonyulnak, sokszor nem praktikus szimulátoron futtatni, mivel a részletes modellezés nagy programfejlesztési és számítási időráfordítást igényel, ebből adódóan a hibakeresési munkák nagy részét el kell halasztani egy prototípus rendszer megalkotásáig.

A hiba észlelése után annak forrását lokalizálni kell, hogy a rendszer megfelelő absztrakciós szintjén és a megfelelő helyen végezzük el a javítást. A hiba forrásának hamis azonosítása vagy a rendszer absztrakt reprezentációjának más szintjén végzett javítások ahhoz a tényhez vezetnek, hogy a rendszerre vonatkozó információk felsőbb szintek hibássá válik, és nem használható további hibakeresésre a rendszer gyártása és működése során. Például, ha egy assembly nyelven írt program forrásszövegébe hibát vezetnek be, és a javítást objektumkódban hajtják végre, akkor a program további hibakeresése objektumkódban történik; ebben az esetben a program assembly nyelven történő megírásának minden előnye semmivé válik.

A készülék blokkvázlata az A függelékben található.

Ez a mikroprocesszoros rendszer a következő blokkokból áll: mikroprocesszor, RAM, ROM, programozható párhuzamos interfész, analóg-digitális átalakító, időzítő, kijelző.

Az érzékelők analóg jelei az ADC-be épített analóg multiplexer bemenetére érkeznek, amely minden időintervallumban az analóg-digitális átalakító bemenetére kapcsolja az egyik jelet.

Egy analóg-digitális átalakítót használnak arra, hogy az analóg jelet digitális kóddá alakítsák, amellyel a mikroprocesszor működik.

A mikroprocesszor egy programozható párhuzamos interfészen keresztül éri el az ADC-t. Információkat olvas be az ADC kimenetekről, és egy RAM memóriacellában tárolja. Ezenkívül az MP az állomás kimeneténél lévő olajnyomás-érzékelőtől kapott információk alapján kiszámítja a szabályozási hatást. Ez a mennyiség a formában digitális kód az aktuátort továbbítják.

A RAM az érzékelőktől kapott információk és a mikroprocesszoros számítások közbenső eredményeinek ideiglenes tárolására szolgál.

A rendszerszoftver a ROM-ban (csak olvasható memória) van tárolva. Az olvasási műveletet a mikroprocesszor vezérli.

A ROM-ban tárolt program a következő rendszerműveleteket biztosítja:

Szenzorok szekvenciális lekérdezése;

Analóg jel analóg-digitális átalakításának vezérlése;

Olajnyomás szabályozás;

Jelzés és riasztás;

Válasz az áramkimaradásra.

A rendszeralgoritmus kidolgozása

Az algoritmus blokkvázlata a B. függelékben található.

Inicializálás

Ebben a szakaszban a vezérlőszavak a programozható párhuzamos interfész RUS-jába íródnak. A PPI DD10 nulla üzemmódban működik. A portok a következőképpen működnek: A port - bemenet, B port - kimenet, C port - kimenet. A PPI DD1 nulla üzemmódban működik. A portok a következőképpen működnek: A port - kimenet, B port - kimenet, C port - kimenet.

Szenzoros lekérdezés

Az analóg érzékelőket az ADC lekérdezi. A PPI 1 A porton keresztüli diszkrét érzékelőket lekérdezi a mikroprocesszor.

Mentés RAM-ba

Az érzékelők lekérdezése után kapott eredmények egy véletlen hozzáférésű memóriaeszközbe kerülnek ideiglenes tárolásra.

Irányító művelet

A mikroprocesszoros rendszer elemzi a kapott adatokat, és digitális vezérlési műveletet generál.

Sematikus diagram kidolgozása

A készülék sematikus diagramja a D mellékletben látható.

A címbusz egy pufferregiszter és egy buszmeghajtó segítségével jön létre. A regiszter kiválasztása a mikroprocesszor ALE jelével történik. A buszmeghajtóra a cím magas bájtjának terhelhetőségének növeléséhez van szükség.

Az adatbuszt egy buszmeghajtó segítségével alakítják ki, amelyet a DT/R és az OE jelek alkalmazásával választanak ki.

A rendszerbusz a DD10 dekóderen keresztül jön létre M/IO, WR, RD jelek kombinációjának alkalmazásával.

1. táblázat - Vezérlőjelek

A ROM, RAM és egyéb eszközök kiválasztása a címbusz A13-A15 soraival történik egy dekóderen keresztül. A ROM cellák a 0000h címen találhatók.

2. táblázat - Eszközválasztás

			Eszköz

A PPI vezérlőszó portjának vagy regiszterének kiválasztása a címbusz A0, A1 vonalain keresztül történik. A PPI DD12 A PA0-PA7 portjának bemenetei különálló érzékelőket kapnak; a B port bemeneteire - az ADC-ről; A LED-ek a C port bemeneteire csatlakoznak.

Az analóg multiplexert arra használjuk, hogy kiválassza azt az eszközt, amelyről az információ olvasható. Az ADC-be egy analóg multiplexer van beépítve. Az ADC szélessége egybeesik az adatbusz szélességével és 8 bit.

Az R2-R4 ellenállások a 4...20 mA egységes áramjel 1...5V feszültséggé alakítására szolgálnak.

Az "Archívum letöltése" gombra kattintva teljesen ingyenesen letölti a szükséges fájlt.
Letöltés előtt ez a fájl gondoljon azokra a jó absztraktokra, tesztekre, kurzusokra, szakdolgozatokra, cikkekre és egyéb dokumentumokra, amelyek igény nélkül hevernek a számítógépén. Ez az Ön munkája, részt kell vennie a társadalom fejlődésében és az emberek javára. Keresse meg ezeket a műveket, és küldje be a tudásbázisba.
Mi és minden diák, végzős hallgató, fiatal tudós, aki a tudásbázist tanulmányai és munkája során használja, nagyon hálásak leszünk Önnek.

Egy dokumentumot tartalmazó archívum letöltéséhez írjon be egy ötjegyű számot az alábbi mezőbe, majd kattintson az "Archívum letöltése" gombra.

Hasonló dokumentumok

Tervezési megoldási lehetőségek elemzése és ez alapján az optimális megoldás kiválasztása. Mikroprocesszoros rendszer funkcionális diagramjának szintézise a forrásadatok elemzése alapján. Mikroprocesszoros rendszer hardver- és szoftverfejlesztési folyamata.

tanfolyami munka, hozzáadva 2014.05.20


Elméleti alap mikrokontrolleren és olvasókészüléken alapuló mikroprocesszoros rendszer fejlesztése e-könyvek, műszaki és gazdasági mutatóik elemzése és analógokkal való összehasonlítása. A munkavédelem alapvető szabványai számítógéppel végzett munka során.

szakdolgozat, hozzáadva: 2010.07.13


MP eszköz használatának megvalósíthatósága. Mikroprocesszoros rendszer architektúra. LSI VT szerkezeti felépítése izolált buszokkal. A mikrokontroller tartalma és lehetséges fókusza. Egy egyszerű beágyazott mikrokontroller általános felépítése.

absztrakt, hozzáadva: 2011.04.28


A mikroprocesszoros rendszer felépítése, vezérlésének és jelátvitelének algoritmusa. Cím elosztási térkép. Elektromos fejlesztés sematikus ábrájaés az elemalap kiválasztása. Áramfelvétel számítása, tápegység, szoftver.

tanfolyami munka, hozzáadva 2014.01.22


Funkciók elosztása a mikroprocesszoros rendszer hardver és szoftver részei között. Mikrokontroller kiválasztása, szerkezeti, működési és kapcsolási rajz kidolgozása, leírása. Programozási környezet kiválasztása, algoritmus diagram és programlista.

tanfolyami munka, hozzáadva 2013.08.17


Mikroprocesszoros vezérlőrendszer célja és kialakítása. A mikroprocesszoros vezérlőrendszer működési diagramjának leírása. A mérőcsatorna statikai jellemzőinek számítása. Mikroprocesszoros vezérlőrendszer működésére szolgáló algoritmus kidolgozása.

tanfolyami munka, hozzáadva 2010.08.30


A mikrokontrollerek általános fogalma, felhasználásuk és rendeltetésük. Mikroprocesszoros adatgyűjtő rendszer projekt kidolgozása SDK 1.1 és SDX 0.9 standok felhasználásával. Szoftver létrehozása és betöltése a laboratóriumi standra SDK-1.1.

tanfolyami munka, hozzáadva 2014.01.31

A VT berendezések elemi bázisában bekövetkezett minőségi és mennyiségi változások oda vezettek

kialakításuk bevett elveinek megváltoztatása (például merev

struktúra, következetes központi irányítás, vonalszervezés

memória és képtelenség a számítógép szerkezetét a sajátosságokhoz igazítani

probléma megoldás alatt).

A számítógépes rendszerek szervezésének klasszikus Von Neumann-elveit felváltották az MPS problémaorientáltságának, a párhuzamos és csővezetékes információfeldolgozásnak, az adatfeldolgozás táblázatos módszereinek alkalmazásának, az MPS-struktúrák szabályszerűségének és homogenitásának elvei; valósággá válik

adaptívan újrakonfigurálható rendszerek létrehozásának lehetősége, valamint

szoftver funkciók hardveres megvalósítása. Ezért jelenleg

a kapott MPS-en alapuló számítógépes rendszerek tervezése során

az úgynevezett „3M” elv alkalmazása: modularitás, csatornázás,

mikroprogramozhatóság.

A moduláris szervezés elve magában foglalja a számítási és

az MPS vezérlése egy sor modul alapján: szerkezeti, funkcionális és

elektromosan komplett számítástechnikai eszközök, amelyek lehetővé teszik az önálló

vagy más modulokkal kombinálva az osztály problémáinak megoldására. Moduláris

A mikroszámítógépek és rendszerek tervezésének megközelítése lehetővé teszi (ha úgy valósítják meg

univerzális és speciális modulok) biztosítják a családok létrehozását

(sorok) MPS, eltérő funkcionalitásés jellemzői,

az alkalmazások jelentős körét lefedi, segít csökkenteni

tervezési költségeket, valamint leegyszerűsíti a kapacitásbővítést és

rendszerek újrakonfigurálása, késlelteti a számítástechnika elavulását

Az információcsere gerincmódszere ellentétben a szervezés módjával

tetszőleges kapcsolatok (a „mindenki mindenkivel” elv szerint) lehetővé teszi a rendszerezést és

minimalizálja a kapcsolatok számát az MPS-ben. Megkönnyíti az információcserét között

különböző szintű funkcionális és szerkezeti modulok felhasználásával

bemeneti és kimeneti buszokat összekötő autópályák. Van egy-két-,

három- és többvonalas csatlakozások. Meg kell jegyezni a kapcsolatot

áramkör tervezés és a megvalósítás során megjelenő szerkezeti megoldások

ez a módszer csere speciális kétirányú puffer létrehozása formájában

kaszkádok három stabil állapottal és ideiglenes használattal

cserecsatornák multiplexelése.

Firmware vezérlés a legnagyobb rugalmasságot biztosítja a szervezésben

többfunkciós modulok, és lehetővé teszi a probléma orientációt

MPS, és makróműveleteket is használjon bennük, ami hatékonyabb, mint a használata

standard rutinok. Ezen kívül az ellenőrzött szavak továbbítása a formában

titkosított kódsorozatok megfelelnek a minimalizálási feltételeknek

a VLSI érintkezők száma és a modulok összekapcsolásának csökkentése.

Az MPS tervezés fentebb felsorolt ​​főbb jellemzői mellett annak kell lennie

vegye figyelembe a szabályosság elvét, amely természeteset feltételez

az MPS szerkezetének elemeinek megismételhetősége és a köztük lévő kapcsolatok. Ennek alkalmazása

elv lehetővé teszi az integrálsűrűség növelését, a kötések hosszának csökkentését

chipen, csökkenti a topológiai és az áramkör tervezési idejét

tervezése LSI és VLSI, csökkenti a kereszteződések számát és típusai funkcionális

és szerkezeti elemek.

Az MPS architektúra (rendszerfázis) fejlesztésénél a következőket szükséges megoldani

Mutassa be a rendszer funkcionális viselkedésének fogalmi felépítését azzal

építése és szervezése során figyelembe veszi a felhasználó érdekeit

számítási folyamat benne;

Határozza meg a konstrukciós szoftver felépítését, nómenklatúráját és jellemzőit, és

mikroprogram eszközök;

Ismertesse az adatáramlások és az ellenőrzés belső szervezésének jellemzőit!

információ;

Végezze el a fizikai funkcionális szerkezetének és jellemzőinek elemzését

rendszereszközök megvalósítása a szoftveregyensúly szemszögéből,

mikroprogram és hardver.

Az MPS tervezésének főbb lépései az ábrán láthatók. 3.1.

A tervezés kezdeti szakaszában az MPS-t az egyikben leírhatjuk

a következő fogalmi szintek: „fekete doboz”, szerkezeti, program,

logikai, áramkör.

A „fekete doboz” szinten az MPS-t külső specifikációk írják le, ahol

külső jellemzők vannak felsorolva.

Rizs. 3.1. Az MPS tervezés szakaszai

A szerkezeti szintet az MPS hardverelemei hozzák létre, amelyek

az egyes eszközök funkciói, azok összekapcsolása és információi írják le

patakok.

A szoftverszint két alszintre oszlik (processzor utasítások és

nyelv) és az MPS-t operátorok sorozataként ill

parancsok, amelyek egy bizonyos adatszerkezeten valamilyen műveletet okoznak.

A logikai szint kizárólag a diszkrét rendszerekben rejlik, és fel van osztva

két alszint: kapcsolóáramkörök és regiszterátvitelek.

Az első alszintet a kapuk (kombinációs áramkörök és memóriaelemek) és az ezekre épülő adatfeldolgozó operátorok alkotják. A második alszintet magasabb fokú absztrakció jellemzi, és a regiszterek leírását és a köztük lévő adatátvitelt jelenti. Kettőt tartalmaz

részek: információ és ellenőrzés: az elsőt nyilvántartások alkotják,

operátorok és adatátviteli útvonalak, a második attól függően biztosít

regiszterek közötti adatátvitelt kezdeményező időjelek.

Az áramköri szint a diszkrét eszközelemek működésének leírásán alapul.

Az MPS életciklusának, mint minden diszkrét rendszernek, három szakasza van:

tervezés, gyártás és üzemeltetés.

Minden szakasz több fázisra van felosztva, amelyeknél fennáll a szerkezeti vagy fizikai hibák valószínűsége. A hibákat okaik szerint osztályozzuk: fizikai, ha az ok az elemek hibája, és szubjektív, ha az ok tervezési hiba.

A szubjektív hibákat tervezési és interaktív hibákra osztják. Tervezés

a meghibásodásokat a rendszer különböző szakaszaiban bevitt hiányosságok okozzák

az eredeti feladat végrehajtása. Interaktív hibák fordulnak elő

munkavégzés közben a szervizszemélyzet (kezelő) hibájából. Az eredmény

a meghibásodás megnyilvánulása hiba, egy meghibásodás pedig lehet

számos hibát okozhatnak, és ugyanaz a hiba is előidézhető

sok meghibásodás.

Létezik a hiba fogalma is – a paraméterek fizikai változása

rendszerelemek, amelyek túllépik a megengedett határértékeket. A hibákat ún

kudarcok, ha átmenetiek, és kudarcok, ha tartósak.

Hiba nem észlelhető a feltételek teljesüléséig

az ebből fakadó meghibásodás fellépése, aminek az eredménye annak kell lennie

sor, átadva a vizsgált objektum kimenetének, hogy létrejöjjön

megfigyelhető meghibásodás.

A hibadiagnózis az a folyamat, amelynek során meghatározzák a hiba okát

vizsgálati eredmények.

A hibakeresés a hibák észlelésének és meghatározásának folyamata

megjelenésük forrásai az MPS tervezése során végzett vizsgálatok eredményei szerint.

A hibakereső eszközök eszközök, komplexek és programok. Néha alatta

A hibakeresés a hibák észlelésére, lokalizálására és kiküszöbölésére vonatkozik. Siker

a hibakeresés attól függ, hogy a rendszer hogyan van kialakítva, hogy

tulajdonságok, amelyek kényelmessé teszik a hibakeresést, valamint a használt eszközöktől

hibakereséshez.

A hibakeresés végrehajtásához a tervezett MPS-nek rendelkeznie kell

az irányíthatóság, a megfigyelhetőség és a kiszámíthatóság tulajdonságai.

Irányíthatóság – egy rendszer olyan tulajdonsága, amelyben a viselkedése érzékeny

menedzsment, azaz Lehetőség van a rendszer működésének leállítására

bizonyos állapotba, és indítsa újra a rendszert.

Megfigyelhetőség– egy rendszer tulajdonsága, amely lehetővé teszi a viselkedés megfigyelését

rendszer, belső állapotainak változása mögött.

Előreláthatóság– rendszertulajdonság, amely lehetővé teszi a rendszer telepítését

olyan állapot, amelyből minden további állapot előre jelezhető.

Az MPS összetettségében, követelményeiben és funkcióiban jelentősen eltérhet

működési paraméterek, szoftver mennyisége, típusa

mikroprocesszor készlet stb. Ebben a tekintetben a tervezési folyamat lehet

a rendszer követelményeitől függően változhat.

A tervezési folyamat iteratív folyamat. Az átvételi tesztelési szakaszban észlelt meghibásodások specifikációjavításhoz vezethetnek, és

ezért a teljes rendszer tervezésének elejéig. megtalálja

a hibákat a lehető legkorábban észlelni kell; ehhez irányítani kell

a projekt helyessége a fejlesztés minden szakaszában. A következő módszerek léteznek

tervezési helyesség ellenőrzése: ellenőrzés (formális módszerek

a projekt helyességének igazolása); modellezés; tesztelés.

Az utóbbi időben sok munka jelent meg a szoftverellenőrzéssel kapcsolatban

szoftver, firmware, hardver. Ezek a művek azonban még mindig

elméleti jellegű. Ezért a gyakorlatban gyakrabban alkalmazzák a modellezést

objektum viselkedés és tesztelés különböző absztrakt szinteken

rendszerábrázolások.

A rendszerkövetelmények formalizálásának szakaszában a projekt helyességének ellenőrzése

különösen azért szükséges, mert sok tervezési cél nincs formalizált ill

elvileg nem formalizálható. A funkcionális specifikáció lehet

szakértői csoport elemzi, vagy szimulálja és teszteli

kísérleti úton azonosítani a kívánt célok elérését. Jóváhagyás után

a funkcionális specifikáció megkezdi a tesztprogramok fejlesztését,

szerinti rendszer megfelelő működésének megállapítására tervezték

a specifikációja. Ideális esetben a teszteket teljesen kidolgozzák

ezen a specifikáción alapul, és lehetővé teszi bármely

a funkciók ellátására alkalmasnak nyilvánított rendszer megvalósítása

specifikációban meghatározott. Ez a módszer teljesen ellentétes a többi módszerrel,

ahol a tesztek konkrét megvalósításokhoz kapcsolódóan épülnek fel. A gyakorlatban azonban

tesztfejlesztés gyakran alacsonyabb prioritást kap, mint

projekt, így a tesztprogramok sokkal később jelennek meg nála