Programmer for å designe mikroprosessorenheter. Mikroprosessorer. Operatører og operasjoner

Et mikroprosessor datainnsamlingssystem må oppfylle følgende krav: gi høy ytelse og være enkelt å implementere, skal sikre stabil og problemfri drift, være relativt billig og forbruke lite ressurser. For å utføre de tildelte oppgavene og i samsvar med de grunnleggende kravene, er mikrokontrolleren i K1816BE51-serien egnet.

Figur 3 - Blokkdiagram av et mikroprosessor datainnsamlingssystem.

mikroprosessorprogramalgoritmebrikke

Mikroprosessorsystemet (MPS) består av følgende blokker: mikrokontroller (MC), random access memory (RAM), read-only memory (ROM), programmerbar tidtaker (PT), parallelt programmerbart grensesnitt (PPI), analog-til-digital omformer (ADC), digital-til-analog-omformer (DAC), multiplekser (MUX), programmerbar avbruddskontroller (PIC).

MK danner en adressebuss (ABA), en databuss (SD) og en kontrollbuss (CC). RAM, ROM, PT, PPI, PKP-blokker er koblet til bussene.

RAM er designet for å lagre sensormålingsdata, så vel som mellomdata. ROM er designet for å lagre programkode og forskjellige konstanter.

PT er designet for å telle tidsintervallet som vil være nødvendig for å utføre MK-kommandoer. Før operasjonen utføres, startes PT. Hvis operasjonen er vellykket, tilbakestiller MK PT. Hvis ingen tilbakestillingskommando mottatt fra MC (en frysing har oppstått), genererer PT et MC-tilbakestillingssignal ved slutten av tidsintervalltellingen.

PPI er beregnet for tilkobling eksterne enheter. En ADC, en diskret multiplekser og en DAC er koblet til SPI.

ADC er designet for å konvertere et analogt signal fra sensorer og en digital kode, som mates til MK gjennom PPI. Analoge sensorer kobles til ADC via en analog multiplekser.

Data fra diskrete sensorer mottas gjennom en diskret multiplekser.

DAC-en er designet for å generere kontrollhandling.

Kontrollpanelet er designet for å betjene eksterne avbrudd.

Stadier av utforming av mikroprosessorsystemer

Mikroprosessorsystemer i deres kompleksitet, krav og funksjoner kan variere betydelig i pålitelighetsparametere, volum programvare, være enkeltprosessor og multiprosessor, bygget på én type mikroprosessorsett eller flere osv. I denne forbindelse kan designprosessen endres avhengig av kravene til systemene. For eksempel vil prosessen med å designe MPS-er som skiller seg fra hverandre i ROM-innhold bestå av utvikling av programmer og produksjon av ROM-er.

Når du designer multsom inneholder flere typer mikroprosessorsett, er det nødvendig å løse problemer med minneorganisering, interaksjon med prosessorer, organisering av utveksling mellom systemenheter og det eksterne miljøet, koordinering av funksjonen til enheter med forskjellige driftshastigheter, etc. Nedenfor er en omtrentlig sekvens av trinn, typisk for å lage et mikroprosessorsystem:
1. Formalisering av systemkrav.
2. Utvikling av systemets struktur og arkitektur.
3. Utvikling og produksjon av systemhardware og programvare.
4. Omfattende feilsøking og aksepttesting.

Trinn 1. På dette stadiet utarbeides eksterne spesifikasjoner, funksjonene til systemet listes opp, de tekniske spesifikasjonene (TOR) for systemet formaliseres, og utbyggers planer er formelt angitt i offisiell dokumentasjon.

Trinn 2. På dette stadiet bestemmes funksjonene til individuelle enheter og programvare, mikroprosessorsett velges på grunnlag av hvilke systemet skal implementeres, samspillet mellom maskinvare og programvare, og tidsegenskapene til individuelle enheter og programmer bestemmes .

Trinn 3. Etter å ha bestemt funksjonene implementert av maskinvaren og funksjonene implementert av programmene, begynner kretsdesignere og programmerere samtidig å utvikle og produsere henholdsvis en prototype og programvare. Utvikling og produksjon av utstyr består av utvikling av struktur- og kretsdiagrammer, prototypeproduksjon og offline debugging.
Programvareutvikling består i å utvikle algoritmer; skrive tekst kildeprogrammer; oversettelser av kildeprogrammer til objektprogrammer; frakoblet feilsøking.

Trinn 4. Se Omfattende feilsøking.

På hvert stadium av MPS-design kan folk introdusere feil og ta feil designbeslutninger. I tillegg kan det oppstå feil på utstyret.

Kilder til feil

La oss vurdere kildene til feil i de tre første stadiene av design.

Trinn 1. På dette stadiet kan kilder til feil være: logisk inkonsekvens av krav, utelatelser, unøyaktigheter i algoritmen.

Trinn 2. På dette stadiet kan feilkilder være: utelatelser av funksjoner, inkonsekvens av protokollen for interaksjon mellom utstyr og programmer, feil valg av mikroprosessorsett, unøyaktigheter i algoritmer, feil tolkning av tekniske krav, utelatelse av enkelte informasjonsstrømmer.

Trinn 3. På dette stadiet kan kilder til feil være: under utvikling av utstyr - utelatelser av noen funksjoner, feil tolkning av tekniske krav, defekter i synkroniseringskretser, brudd på designregler; under produksjon av en prototype - feil på komponenter, installasjons- og monteringsfeil; ved utvikling av programvare - utelatelser av enkelte funksjoner mandat, unøyaktigheter i algoritmer, unøyaktigheter i koding.

Hver av de listede feilkildene kan generere et stort antall subjektive eller fysiske feil som må lokaliseres og elimineres. Feildeteksjon og feillokalisering er en vanskelig oppgave av flere grunner: For det første på grunn av det store antallet feil; for det andre på grunn av at ulike feil kan vise seg på samme måte. Siden det ikke finnes noen modeller for subjektive feil, er denne oppgaven ikke formalisert. Det har vært en viss fremgang i feltet med å lage metoder og verktøy for feildeteksjon og lokalisering av fysiske feil. Disse metodene og verktøyene er mye brukt for å kontrollere driftstilstanden og diagnostisere feil til diskrete systemer under design, produksjon og drift av sistnevnte.

Subjektive funksjonsfeil skiller seg fra fysiske ved at de ikke lenger forekommer etter deteksjon, lokalisering og korrigering. Men som listen over feilkilder antyder, kan subjektive feil introduseres under utviklingen av systemspesifikasjonen, noe som betyr at selv etter den mest grundige testing av et system mot dets eksterne spesifikasjoner, kan det fortsatt være subjektive feil i systemet.

Designprosessen er en iterativ prosess. Feil som oppdages under aksepttestingsstadiet kan føre til korrigering av spesifikasjoner, og følgelig til oppstart av design av hele systemet. Det er nødvendig å oppdage feil så tidlig som mulig, for å gjøre dette, er det nødvendig å kontrollere riktigheten av prosjektet på hvert utviklingsstadium.

Validering av designet

De viktigste metodene for å overvåke riktigheten av design er som følger: verifisering - formelle metoder for å bevise riktigheten av designet; modellering; testing.

Det er mye arbeid med verifisering av programvare, fastvare og maskinvare. Disse verkene er imidlertid teoretiske. I praksis brukes fortsatt modellering av objektatferd og testing.

For å kontrollere riktigheten av prosjektet på hvert designstadium, er det nødvendig å utføre modellering på ulike nivåer av den abstrakte representasjonen av systemet og verifisere riktig implementering av en gitt modell gjennom testing. På stadiet med kravformalisering er korrekthetskontroll spesielt nødvendig, siden mange designmål ikke er formalisert eller i prinsippet ikke kan formaliseres. Funksjonsspesifikasjonen kan gjennomgås av et team av eksperter eller simuleres og testes for å avgjøre om de ønskede målene nås. Når funksjonsspesifikasjonen er godkjent, begynner utviklingen av funksjonelle testprogrammer for å etablere riktig funksjon av systemet i samsvar med funksjonsspesifikasjonen. Ideelt sett utvikles tester som er basert utelukkende på denne spesifikasjonen og gir muligheten til å teste enhver implementering av et system som hevdes å være i stand til å utføre funksjonene spesifisert i spesifikasjonen. Denne metoden er det stikk motsatte av andre, hvor tester bygges i forhold til spesifikke implementeringer. Implementeringsuavhengig funksjonell verifisering er vanligvis attraktiv kun i teoretiske termer, men har ingen praktisk betydning på grunn av sin høye grad av generalitet.

Automatisering av det kjedelige arbeidet med å skrive testprogrammer reduserer ikke bare design-/feilsøkingsperioden ved å generere testprogrammer i designfasen (siden de kan genereres umiddelbart etter at systemkravene er generert), men lar designeren også endre spesifikasjoner uten å måtte bekymre deg for å skrive om alle testprogrammene igjen. Men i praksis blir testutvikling ofte nedprioritert enn design, altså testprogrammer vises mye senere enn den er ferdig. Men selv om detaljerte tester viser seg å være forberedt, er det ofte upraktisk å kjøre dem på en simulator, siden detaljert modellering krever store utgifter til programutvikling og beregningstid, som et resultat må det meste av feilsøkingsarbeidet utsettes til opprettelsen av et prototypesystem.

Når en feil er oppdaget, må kilden lokaliseres for å kunne utføre korrigering på riktig abstraksjonsnivå av systemet og på riktig sted. Falsk identifikasjon av kilden til feilen eller foreta korrigeringer på et annet nivå av den abstrakte representasjonen av systemet fører til at informasjon om systemet er øvre nivåer blir feil og kan ikke brukes til ytterligere feilsøking under produksjon og drift av systemet. For eksempel, hvis en funksjonsfeil introduseres i kildeteksten til et program skrevet på assemblerspråk, og korrigeringen utføres i objektkode, utføres ytterligere feilsøking av programmet i objektkode; i dette tilfellet er alle fordelene ved å skrive et program på assembler-språk redusert til ingenting.

Blokkskjemaet for enheten er presentert i vedlegg A.

Dette mikroprosessorsystemet består av følgende blokker: mikroprosessor, RAM, ROM, programmerbart parallellgrensesnitt, analog-til-digital-omformer, timer, display.

Analoge signaler fra sensorene kommer til inngangene til en analog multiplekser innebygd i ADC, som ved hvert tidsintervall bytter ett av signalene til inngangen til analog-til-digital-omformeren.

En analog-til-digital-omformer brukes til å konvertere et analogt signal til en digital kode som mikroprosessoren opererer med.

Mikroprosessoren får tilgang til ADC gjennom et programmerbart parallellgrensesnitt. Leser informasjon fra ADC-utgangene og lagrer den i en RAM-minnecelle. I tillegg beregner MP, basert på informasjon mottatt fra oljetrykksensoren ved stasjonens utløp, den regulatoriske påvirkningen. Denne mengden i skjemaet digital kode aktuatoren overføres.

RAM brukes til midlertidig lagring av informasjon mottatt fra sensorer og mellomresultater av mikroprosessorberegninger.

Systemprogramvaren er lagret i ROM (skrivebeskyttet minne). Leseoperasjonen styres av mikroprosessoren.

Programmet, som er lagret i ROM, sørger for følgende systemoperasjoner:

Sekvensiell polling av sensorer;

Kontroll av analog-til-digital konvertering av et analogt signal;

Oljetrykk regulering;

Indikasjon og alarm;

Respons på strømtap.

Utvikling av systemalgoritmen

Blokkskjemaet til algoritmen er presentert i vedlegg B.

Initialisering

På dette stadiet skrives kontrollord til RUS-en til det programmerbare parallellgrensesnittet. PPI DD10 fungerer i nullmodus. Portene fungerer som følger: port A - inngang, port B - utgang, port C - utgang. PPI DD1 fungerer i nullmodus. Portene fungerer som følger: port A - utgang, port B - utgang, port C - utgang.

Sensorpolling

De analoge sensorene polles av ADC. Diskrete sensorer gjennom port A til PPI 1 blir spurt av mikroprosessoren.

Lagrer til RAM

Resultatene oppnådd etter avhør av sensorene legges inn i en minneenhet for vilkårlig tilgang for midlertidig lagring.

Kontrollhandling

Mikroprosessorsystemet analyserer de mottatte dataene og genererer en digital kontrollhandling.

Utvikling av et skjematisk diagram

Det skjematiske diagrammet av enheten er presentert i vedlegg D.

Adressebussen dannes ved hjelp av et bufferregister og en bussdriver. Registervalg utføres ved hjelp av mikroprosessorens ALE-signal. Bussjåføren er nødvendig for å øke lastekapasiteten til den høye byten til adressen.

Databussen dannes ved hjelp av en bussdriver, som velges ved å bruke DT/R- og OE-signalene.

Systembussen dannes gjennom DD10-dekoderen ved å bruke en kombinasjon av M/IO, WR, RD-signaler.

Tabell 1 - Styresignaler

Valget av ROM, RAM og andre enheter skjer ved bruk av linjene A13-A15 på adressebussen gjennom en dekoder. ROM-celler er plassert på adressen 0000h.

Tabell 2 - Valg av enhet

			Enhet

Valget av en port eller register for PPI-kontrollordet utføres gjennom linjene A0, A1 på adressebussen. Diskrete sensorer leveres til inngangene til port A PA0-PA7 til PPI DD12; til inngangene til port B - fra ADC; LED er koblet til inngangene til port C.

Den analoge multiplekseren brukes til å velge enheten som informasjon leses fra. En analog multiplekser er innebygd i ADC. ADC-bredden sammenfaller med databussbredden og er 8 bits.

Motstander R2-R4 brukes til å konvertere et enhetlig strømsignal på 4...20 mA til en spenning på 1...5V.

Ved å klikke på knappen "Last ned arkiv" laster du ned filen du trenger helt gratis.
Før nedlasting av denne filen tenk på de gode abstraktene, testene, semesteroppgavene, avhandlingene, artiklene og andre dokumenter som ikke er gjort krav på på datamaskinen din. Dette er ditt arbeid, det skal delta i samfunnsutviklingen og komme mennesker til gode. Finn disse verkene og send dem til kunnskapsbasen.
Vi og alle studenter, hovedfagsstudenter, unge forskere som bruker kunnskapsbasen i studiene og arbeidet vil være dere veldig takknemlige.

For å laste ned et arkiv med et dokument, skriv inn et femsifret nummer i feltet nedenfor og klikk på "Last ned arkiv"-knappen

Lignende dokumenter

Analyse av designløsningsalternativer og valg av den optimale løsningen basert på det. Syntese av et funksjonsdiagram av et mikroprosessorsystem basert på analyse av kildedata. Prosessen med å utvikle maskinvare og programvare for et mikroprosessorsystem.

kursarbeid, lagt til 20.05.2014


Teoretisk grunnlag utvikling av et mikroprosessorsystem basert på en mikrokontroller og en leseenhet e-bøker, analyse av deres tekniske og økonomiske indikatorer og sammenligning med analoger. Grunnleggende standarder for arbeidsbeskyttelse når du arbeider med en datamaskin.

avhandling, lagt til 13.07.2010


Muligheten for å bruke en MP-enhet. Mikroprosessorsystemarkitektur. Strukturell organisering av LSI VT med isolerte busser. Innhold og mulig fokus for mikrokontrolleren. Generalisert struktur av en enkel innebygd mikrokontroller.

sammendrag, lagt til 28.04.2011


Strukturen til mikroprosessorsystemet, algoritmen for kontroll og signaloverføring. Adressefordelingskart. Elektrisk utvikling skjematisk diagram og valg av elementbase. Beregning av strømforbruk, strømforsyning, programvare.

kursarbeid, lagt til 22.01.2014


Fordeling av funksjoner mellom maskinvare- og programvaredelene i mikroprosessorsystemet. Valg av mikrokontroller, utvikling og beskrivelse av struktur-, funksjons- og kretsskjema. Velge et programmeringsmiljø, algoritmediagram og programliste.

kursarbeid, lagt til 17.08.2013


Formål og design av et mikroprosessorkontrollsystem. Beskrivelse av funksjonsdiagrammet til mikroprosessorkontrollsystemet. Beregning av de statiske egenskapene til målekanalen. Utvikling av en algoritme for funksjonen til et mikroprosessorkontrollsystem.

kursarbeid, lagt til 30.08.2010


Generelt konsept for mikrokontrollere, deres bruk og formål. Utvikling av et mikroprosessor datainnsamlingssystemprosjekt ved bruk av SDK 1.1 og SDX 0.9 står. Oppretting av programvare og lasting av den i laboratoriestanden SDK-1.1.

kursarbeid, lagt til 31.01.2014

Kvalitative og kvantitative endringer i den elementære basen til VT-utstyr har ført til

endre de etablerte prinsippene for deres design (for eksempel stiv

struktur, konsekvent sentralledelse, linjeorganisering

minne og manglende evne til å tilpasse datamaskinstrukturen til særegenhetene

problemet løses).

De klassiske Von Neumann-prinsippene for å organisere datasystemer ble erstattet av ideene om problemorientering av MPS, parallell- og rørledningsinformasjonsbehandling, bruk av tabellformede metoder for databehandling, prinsipper for regularitet og homogenitet av MPS-strukturer; blir ekte

mulighet for å lage adaptivt rekonfigurerbare systemer, samt

maskinvareimplementering av programvarefunksjoner. Derfor for tiden

tid ved utforming av datasystemer basert på MPS mottatt

anvendelse av det såkalte "3M"-prinsippet: modularitet, trunking,

mikroprogrammerbarhet.

Prinsippet om modulær organisering innebærer konstruksjon av beregnings- og

kontrollere MPS basert på et sett med moduler: strukturell, funksjonell og

elektrisk komplette dataenheter som lar deg uavhengig

eller i kombinasjon med andre moduler for å løse problemer i denne klassen. Modulær

tilnærming til design av mikrodatamaskiner og systemer tillater (når implementert som

universelle og spesialiserte moduler) for å sikre opprettelsen av familier

(rader) av MPS, forskjellig funksjonalitet og egenskaper,

som dekker et betydelig spekter av bruksområder, bidrar til å redusere

designkostnader, og forenkler også kapasitetsutvidelse og

rekonfigurering av systemer, forsinker foreldelse av databehandling

Ryggraden metode for informasjonsutveksling i motsetning til måten å organisere seg på

vilkårlige forbindelser (i henhold til "alle med alle"-prinsippet) lar deg organisere og

minimere antall tilkoblinger i MPS. Det letter utveksling av informasjon mellom

funksjonelle og strukturelle moduler på ulike nivåer ved hjelp av

motorveier som forbinder inngangs- og utgangsbusser. Det er en-, to-,

tre- og flerlinjeforbindelser. Det er nødvendig å merke seg forholdet

kretsdesign og strukturelle løsninger som dukker opp under implementering

denne metoden utveksling i form av å lage spesiell toveis buffer

kaskader med tre stabile tilstander og bruk av midlertidig

multipleksing av utvekslingskanaler.

Fastvarekontroll gir størst fleksibilitet i organisasjonen

multifunksjonelle moduler og gir mulighet for problemorientering

MPS, og bruker også makrooperasjoner i dem, noe som er mer effektivt enn å bruke

standard rutiner. I tillegg overføring av kontrollerte ord i skjemaet

krypterte kodesekvenser tilsvarer minimeringsbetingelsene

antall VLSI-pinner og redusere antall sammenkoblinger i moduler.

I tillegg til hovedtrekkene til MPS-design som er oppført ovenfor, bør det være det

legg merke til regelmessighetsprinsippet, som forutsetter en naturlig

repeterbarhet av elementene i strukturen til MPS og forbindelsene mellom dem. Anvendelse av dette

prinsippet lar deg øke den integrerte tettheten, redusere lengden på bindinger

on-chip, reduser topologisk tid og kretsdesigntid

utforming av LSI og VLSI, redusere antall kryss og typer funksjonell

og strukturelle elementer.

Ved utvikling av MPS-arkitekturen (systemstadiet) er det nødvendig å løse følgende

Beskriv den konseptuelle strukturen til den funksjonelle oppførselen til systemet med

posisjoner for å ta hensyn til brukerens interesser under konstruksjon og organisering

databehandling i det;

Bestem strukturen, nomenklaturen og funksjonene ved å konstruere programvare og

mikroprogramverktøy;

Beskriv egenskapene til den interne organiseringen av datastrømmer og kontroll

informasjon;

Gjennomfør en analyse av den funksjonelle strukturen og trekk ved det fysiske

implementering av systemenheter fra perspektivet til programvarebalanse,

mikroprogram og maskinvare.

Hovedstadiene for å designe en MPS er vist i fig. 3.1.

På det innledende designstadiet kan MPS beskrives i en av

følgende konseptuelle nivåer: "svart boks", strukturell, program,

logisk, krets.

På nivået "black box" er MPS beskrevet av eksterne spesifikasjoner, hvor

ytre egenskaper er oppført.

Ris. 3.1. Stadier av MPS-design

Det strukturelle nivået er skapt av maskinvarekomponentene til MPS, som

beskrevet av funksjonene til individuelle enheter, deres sammenkoblinger og informasjon

bekker.

Programvarenivået er delt inn i to undernivåer (prosessorinstruksjoner og

språk) og MPS tolkes som en sekvens av operatører eller

kommandoer som forårsaker en eller annen handling på en bestemt datastruktur.

Det logiske nivået er utelukkende iboende i diskrete systemer og er delt inn i

to undernivåer: svitsjekretser og registeroverføringer.

Det første undernivået er dannet av porter (kombinasjonskretser og minneelementer) og databehandlingsoperatører bygget på deres grunnlag. Det andre undernivået er preget av en høyere grad av abstraksjon og representerer en beskrivelse av registre og dataoverføring mellom dem. Det inkluderer to

deler: informasjon og kontroll: den første er dannet av registre,

operatører og dataoverføringsveier, gir den andre avhengig av

tidssignaler som setter i gang dataoverføring mellom registre.

Kretsnivået er basert på en beskrivelse av driften av diskrete enhetselementer.

I livssyklusen til en MPS, som ethvert diskret system, er det tre stadier:

design, produksjon og drift.

Hvert trinn er delt inn i flere faser der det er sannsynligheter for strukturelle eller fysiske feil. Feil klassifiseres i henhold til årsakene deres: fysiske, hvis årsaken er feil i elementene, og subjektive, hvis årsaken er designfeil.

Subjektive feil er delt inn i design og interaktive. Design

funksjonsfeil er forårsaket av mangler som er introdusert i systemet på ulike stadier

gjennomføring av den opprinnelige oppgaven. Interaktive feil oppstår i

under arbeid på grunn av feil fra servicepersonell (operatør). Resultatet

manifestasjoner av en funksjonsfeil er en feil, og en funksjonsfeil kan

forårsake en rekke feil, og den samme feilen kan forårsakes

mange funksjonsfeil.

Det er også konseptet med en defekt - en fysisk endring i parametere

systemkomponenter som overskrider tillatte grenser. Defektene kalles

feil hvis de er midlertidige, og feil hvis de er permanente.

En mangel kan ikke oppdages før forholdene for

forekomsten av en funksjonsfeil på grunn av det, hvis resultat bør være i sin

kø, sendt til utgangen av objektet som studeres for å lage

observerbar funksjonsfeil.

Feildiagnose er prosessen med å bestemme årsaken til en feil ved

testresultater.

Feilsøking er prosessen med å oppdage feil og bestemme

kilder til deres utseende i henhold til resultatene av testing under utformingen av MPS.

Feilsøkingsverktøy er enheter, komplekser og programmer. Noen ganger under

Debugging refererer til deteksjon, lokalisering og eliminering av feil. Suksess

feilsøking avhenger av hvordan systemet er designet, om

egenskaper som gjør det praktisk for feilsøking, samt fra verktøyene som brukes

for feilsøking.

For å utføre feilsøking må den utformede MPS ha

egenskaper ved kontrollerbarhet, observerbarhet og forutsigbarhet.

Kontrollerbarhet – egenskapen til et system som dets oppførsel er mottakelig for

ledelse, dvs. Det er mulig å stoppe driften av systemet i

bestemt tilstand og start systemet på nytt.

Observerbarhet– en egenskap ved et system som lar deg overvåke dets oppførsel

systemet, bak endringen av dets interne tilstander.

Forutsigbarhet– en systemegenskap som gjør at systemet kan installeres i

en tilstand hvorfra alle påfølgende tilstander kan forutsies.

MPS kan variere betydelig i kompleksitet, krav og funksjoner

operasjonelle parametere, volum av programvare, type

mikroprosessorsett osv. I denne forbindelse kan designprosessen

varierer avhengig av kravene til systemet.

Designprosessen er en iterativ prosess. Feil som oppdages under aksepttestfasen kan føre til spesifikasjonskorreksjon, og

derfor til begynnelsen av utformingen av hele systemet. Finne

feil må oppdages så tidlig som mulig; for dette må du kontrollere

riktigheten av prosjektet i hvert utviklingsstadium. Følgende metoder finnes

kontroll av designriktighet: verifisering (formelle metoder

bevis på riktigheten av prosjektet); modellering; testing.

Den siste tiden har det dukket opp mye arbeid med programvareverifisering

programvare, fastvare, maskinvare. Imidlertid er disse arbeidene fortsatt

teoretisk av natur. Derfor brukes modellering oftere i praksis

objektatferd og testing på ulike abstrakte nivåer

systemrepresentasjoner.

På stadiet av formalisering av systemkrav, overvåking av riktigheten av prosjektet

spesielt nødvendig fordi mange designmål ikke er formalisert eller

kan i utgangspunktet ikke formaliseres. Funksjonsspesifikasjonen kan evt

analysert av et team av eksperter eller simulert og testet inn

eksperimentelt for å identifisere oppnåelse av ønskede mål. Etter godkjenning

funksjonell spesifikasjon begynner utviklingen av testprogrammer,

designet for å etablere korrekt drift av systemet iht

dens spesifikasjon. Ideelt sett utvikles tester fullstendig

basert på denne spesifikasjonen og muliggjør verifisering av evt

implementering av et system som er erklært i stand til å utføre funksjonene

spesifisert i spesifikasjonen. Denne metoden er det motsatte av andre,

hvor tester bygges i forhold til spesifikke implementeringer. Imidlertid i praksis

testutvikling er ofte nedprioritert enn

prosjekt, så testprogrammer vises mye senere enn det