Tarkvarasüsteemid ja vahevara

Mis on Tarkvara?

Programmeeritav riistvara ja tarkvarasüsteemide tekkimine

Eelmises peatükis tutvustati elektroonilist riistvara ja elektroonikakomponentide rolli süsteemi funktsionaalsuse juurutamisel. Riistvara füüsiline olemus ja mehaaniliste, elektriliste ja loogiliste valdkondade projekteerimise keerukus seab aga põhimõttelised piirangud kiirusele ja paindlikkusele, millega saab uusi süsteemivõimalusi arendada. Nende piirangute lahendamiseks arenesid riistvaraplatvormid pärast valmistamist programmeeritavuse toetamiseks. See programmeeritavus võimaldab eraldada füüsilise teostuse ja funktsionaalse käitumise, võimaldades süsteeme kohandada ilma aluseks olevat riistvara ümber kujundamata.

1. Konfiguratsioon: paljudes kaasaegsetes süsteemides saab riistvarakomponente pärast räni valmistamist konfigureerida, et toetada mitut töörežiimi või tootevarianti. Näiteks saab selliseid parameetreid nagu siini laiused, vahemälu suurused või funktsioonikomplektid valida konfiguratsiooniregistrite või püsivara poolt juhitavate sätete kaudu.
2. Riistvarafunktsioonide realiseerimine: teatud riistvaraplatvormid toetavad riistvara funktsionaalsuse ränijärgset realiseerimist programmeeritavate loogikastruktuuride kaudu. Kanooniline näide on Field Programmable Gate Array (FPGA), mis võimaldab disaineritel pärast tootmist rakendada kohandatud digitaalseid vooluahelaid. Need seadmed on programmeeritud kasutades riistvara kirjelduskeeli (HDL), nagu Verilog või VHDL, ning neist on saanud manustatud süsteemide, prototüüpide ja spetsialiseeritud andmetöötluse aluseks.
3. Programmeeritavad protsessorid: sellesse kategooriasse kuulub suur hulk salvestatud programmide arvutusmootoreid, mis põhinevad von Neumanni arhitektuuril, sealhulgas mikroprotsessorid ja mikrokontrollerid. Ajalooliselt programmeeritud montaažikeeles, on need seadmed nüüd peamiselt programmeeritud kõrgetasemeliste keelte, näiteks C, abil koos kõrgema taseme abstraktsioonidega keerukamates süsteemides.

Need programmeerimisparadigmad tutvustavad mitmeid olulisi süsteemitasandi kaalutlusi:

1. Arendusökosüsteem: Programmeeritavus eeldab toetavat tarkvaraarenduse tööriistaahelat, sealhulgas kompilaatoreid, koostajaid, linkereid ja silujaid. See arendusökosüsteem muutub süsteemi lahutamatuks osaks ning seda tuleb hooldada, valideerida ja toetada kogu toote elutsükli jooksul.
2. Toote elutsükkel: Ajalooliselt viidi süsteemi programmeerimine läbi tootmise ajal, mille tulemuseks oli suures osas staatiline ja hästi sisustatud toode. Kasutuselevõtujärgne ümberprogrammeerimine oli suhteliselt haruldane, märkimisväärsete eranditega sellistes valdkondades nagu kosmosesüsteemid. Seevastu kaasaegsed süsteemid toetuvad üha enam väliuuendustele ja pidevale tarkvara arengule, muutes põhjalikult elutsükli juhtimist.
3. Välisseadmed ja ühendused: Standardiseeritud riistvaravälisseadmete abil suurendati veelgi süsteemi paindlikkust. Need seadmed integreerivad mehaanilisi, elektrilisi ja arvutuslikke funktsioone ning suhtlevad täpselt määratletud ühendusstandardite (nt PCI ja USB) kaudu. See modulaarsus võimaldab süsteemide laiendatavust ja koostalitlusvõimet.

Programmeeritava riistvara mõiste arenes märkimisväärselt edasi 1960. aastatel, kui võeti kasutusele IBM System/360, mis vormistas stabiilse arvutiarhitektuuri mõiste. See areng tähistas kriitilist üleminekut seadmepõhiselt disainilt platvormipõhisele andmetöötlusele ja tutvustas mitmeid püsivaid omadusi:

1. Abstraktsioon ja ühilduvus: Arvutiarhitektuurid säilitasid põhilise von Neumanni mudeli, mis sisaldab mitut abstraktsioonirakendust. See abstraktsioon võimaldas tagasiühilduvust, võimaldades ühe põlvkonna riistvara jaoks välja töötatud tarkvara tulevastes süsteemides käivitada. Selle tulemusel võivad jõudluse paranemist soodustada pooljuhtprotsesside ja mikroarhitektuuri edusammud, ilma et oleks vaja muuta rakendustarkvara.
2. Operatsioonisüsteemid: Stabiilse riistvaraabstraktsiooni olemasolu võimaldas arendada kõrgema taseme süsteemitarkvara, nagu operatsioonisüsteemid, protsesside isoleerimine, ajastamine ja ressursside haldamine vormistati operatsioonisüsteemides. Need süsteemid pakkusid järjepidevat täitmiskeskkonda ning parandasid oluliselt programmeeritavust, teisaldatavust ja süsteemi kasutamist.
3. Võrgustiku loomine: kui arvutussüsteemid levisid, viis vajadus geograafiliselt hajutatud masinate vahelise suhtluse järele võrkude loomiseni. Kihilised abstraktsioonid – alates füüsilisest edastamisest kuni rakendusprotokollideni – võimaldasid usaldusväärset andmevahetust ning lõppkokkuvõttes toetasid hajutatud süsteemide ja globaalse ühenduvuse teket.

Alates arvutiarhitektuuride kasutuselevõtust 1960. aastatel on pooljuhttehnoloogia, süsteemikujunduse ja võrkude kiire areng ajendanud arvutusvõimekuse hüppelist laienemist. Need arengud on muutnud peaaegu kõiki kaasaegse ühiskonna aspekte läbi nn infotehnoloogia. Nende süsteemide programmeerimine, mis hõlmab konfiguratsiooni, juhtimist ja rakendusloogikat, on ühiselt tuntud kui tarkvara.

Avatud lähtekoodiga süsteemid on mänginud infotehnoloogia arengus muutvat rolli, kiirendades innovatsiooni, alandades turule sisenemise tõkkeid ja standardiseerides tarkvara infrastruktuuri heterogeensetes keskkondades. Põhiplatvormid, nagu Linux, Apache HTTP Server ning keeled ja ökosüsteemid, nagu Python ja GCC, võimaldasid globaalset koostööl põhinevat arendusmudelit, milles üksikisikud, akadeemilised ringkonnad ja tööstus said panustada jagatud tarkvaravirnadesse. See mudel soodustas kiiret iteratsiooni, läbipaistvust ja kaasaskantavust, võimaldades tarkvara skaleerida üksikutelt masinatelt pilvepõhiselt hajutatud süsteemidele. Avatud lähtekoodiga litsentsimine võimaldas ettevõtetel ehitada ka kommertstooteid jagatud infrastruktuuri peale, mille tulemusel tekkisid pilvandmetöötluse, andmeanalüütika ja tehisintellekti ümber terved ökosüsteemid. Selle tulemusel sai avatud lähtekoodiga tarkvarast kaasaegse IT nurgakivi, mis on aluseks veebiteenustest kõrgjõudlusega andmetöötluseni ning võimaldas uuendustempot, mida oleks olnud keeruline saavutada üksnes patenteeritud arendusega.

Kuigi IT-ökosüsteem ajendas tohutuid uuendusi ja ehitas uskumatuid võimalusi, ei saanud neid võimalusi küberfüüsilistes süsteemides otseselt kasutada. Küberfüüsiline tarkvara erineb tavapärasest manus- või ettevõttetarkvarast, kuna see töötab rangete reaalajas piirangute alusel ning vajab tugevat tõrketaluvust ja ohutuse järgimist. Tarkvara ajalooline kasutuselevõtt küberfüüsikalistes süsteemides järgis maa-, õhu-, mere- ja kosmosevaldkonnas erinevaid ajakavasid, kuid pikaajaline suundumus oli kõigil neljal juhul sama: tarkvara arenes kitsaste juhtimisfunktsioonide toetamisest keskseks koordineerivaks kihiks tuvastus-, otsustus-, suhtlus- ja käivitamises. Nende süsteemide varaseimas põlvkonnas oli enamik funktsioone mehaanilised, hüdraulilised, analoog- või elektromehaanilised. Digitaalse elektroonika arenedes hakati tarkvara kasutama juhtimistäpsuse parandamise, kaalu vähendamise, diagnostika toetamise ja paindlikkuse suurendamise viisina. Aja jooksul ei olnud tarkvara aga pelgalt täiustus ja muutus süsteemi toimimiseks hädavajalikuks. See nihe oli üks peamisi autonoomia võimaldajaid.

Maasüsteemides, eriti autodes, tekkis tarkvara praktilises tootmises 1970. aastatel ja 1980. aastate alguses, kui karmistatud heitgaaside reguleerimine sundisid tootjaid mikroprotsessoripõhise mootori juhtimise poole. Varajane autotööstuse tarkvara oli suhteliselt kitsa ulatusega, keskendudes süüte ajastusele, kütuse sissepritsele ja mootori juhtimisele. Kui elektroonika levis mitteblokeeruvateks piduriteks, veojõukontrolliks, turvapatjadeks, roolisüsteemiks, kere elektroonikaks ja teabe- ja meelelahutussüsteemiks, kasvas tarkvara sisseehitatud juhtimisloogikast hajutatud süsteemiks, mis töötab paljudes elektroonilistes juhtseadmetes. Sõidukisiseste võrkude, nagu CAN ja FlexRay, hilisem kasutuselevõtt laiendas veelgi tarkvara rolli, sest nüüd pidid juhtüksused vahetama andmeid ja koordineerima tegevust erinevate domeenide vahel, mitte töötama isoleeritud seadmetena. 2010. aastateks oli elektrifitseerimise ja ADAS-iga tarkvara muutunud tajust, energiahaldusest, diagnostikast, sidest ja sõiduki käitumisest lahutamatuks.

Õhusüsteemides sisenes tarkvara varem ja rangemate ohutusnõuete alusel, kuna avioonika seoti kiiresti navigatsiooni, stabiilsuse ja lennujuhtimisega. Varajane lennukielektroonika oli suures osas analoog- ja liittehnoloogia, kuid üleminek digitaalsele juhtimisele kiirenes 1970. ja 1980. aastatel, mis kulmineerus “fly-by-wire” süsteemide levikuga. NASA märgib, et tema F-8 Digital Fly-By-Wire lennukist sai 25. mail 1972 esimene lennuk, mis lendas täielikult elektroonilisest lennujuhtimissüsteemist, mis tähistas olulist pöördepunkti tarkvara aktsepteerimisel juhtimisahelas. Hilisemad arendused, nagu klaasist kokpitid, FADEC ja integreeritud avioonika, muutsid tarkvara keskseks mitte ainult juhtimise, vaid ka kuvarite, koondamise haldamise, rikete jälgimise ja missioonisüsteemide jaoks. Kuna tarkvara usaldati lennukriitiliste funktsioonide täitmisele nii varakult, töötasid õhus olevad süsteemid välja ranged tagamisraamistikud varem kui enamik teisi sektoreid.

Meresüsteemides võeti tarkvara kasutusele järk-järgult ja see näis sageli esmalt navigeerimise, tõukejõu jälgimise ja laevahalduse abivahendina, mitte laeva juhtimise vahetu tuumana. 1980. ja 1990. aastatel muutus tarkvara GPS-i integreerimise, elektroonilise kaardistamise, digitaalsete tõukejõu regulaatorite, häireseire ja võrgustandardite (nt NMEA 0183 ja NMEA 2000) kaudu üha olulisemaks. Kuna laevad võtsid kasutusele integreeritud sillasüsteemid ja integreeritud platvormihaldussüsteemid, omandas tarkvara integreeritavama rolli, ühenduvate radarite, seadmete, kaartide ja ohutuskaartide loomisel. jagatud konsoolidele ja koordineeritud töövoogudele. Meresektor liikus üldiselt aeglasemalt kui kosmose- või autotööstus madalamate tootmismahtude, pikkade laevade elutsüklite ja ajalooliselt tugevama sõltuvuse tõttu mehaanilistest ja inimkäitavatest süsteemidest. Siiski ilmnes sama alusmuster: tarkvara nihkus operaatorite abistamise asemel teabevoo ja kontrolli struktureerimisele üle laeva.

kosmosesüsteemides muutus tarkvara oluliseks väga varakult, sest kosmoseaparaadid pidid töötama piiratud või hilinenud inimsekkumisega. Isegi varased missioonid nõudsid juhtimiseks, juhtimiseks, telemeetria- ja rikete haldamiseks sisseehitatud digitaalloogikat. Apollo on oluline näide: NASA andmed kirjeldavad Apollo peamist juhtimis-, navigatsiooni- ja juhtimissüsteemi, mis on keskendunud Apollo juhtimisarvutile, muutes tarkvara 1960. aastate Kuuprogrammi kosmoselaevade käitamise missioonikriitiliseks osaks. Hilisematel aastakümnetel laienes kosmoseaparaadi tarkvara, et toetada hoiaku juhtimist, kasuliku koormuse toimimist, pardal olevat andmetöötlust, autonoomset rikete tuvastamist ja üha enam tarkvara määratletud missioonikäitumist. Kaasaegsed kosmosesüsteemid lisavad ümberkonfigureeritavat kasulikku koormust, autonoomset navigeerimist ja pardal olevat tehisintellekti, kuid ajalooline muster jääb pidevaks: kuna kosmosesüsteemid töötavad eemalt ja äärmuslike piirangute all, on tarkvara juba ammu olnud oluline mitte ainult mugavuse, vaid ka põhiülesannete ellujäämise ja autonoomia jaoks.

Kui tarkvarameetodid migreerusid traditsiooniliselt andmetöötluselt küberfüüsikalistesse süsteemidesse (CPS), tekkis tarkvara infrastruktuuri klass, mis haldab arvutuse ja füüsilise maailma vahelist tihedat seost. Selle evolutsiooni keskmes oli reaalaja operatsioonisüsteemide (RTOS) kasutuselevõtt, mis pakuvad deterministlikku ülesannete ajastamist, piiratud katkestuse latentsust ja prognoositavat ajastuskäitumist – omadused, mis on olulised andurite, täiturmehhanismide ja juhtahelatega suhtlemiseks. Erinevalt üldotstarbelistest operatsioonisüsteemidest on RTOS-id loodud tagama, et kriitilised ülesanded täidetakse rangete ajaliste piirangute raames, kasutades sageli prioriteedipõhist ennetavat ajastamist ja hoolikalt hallatud ressursside jagamist. RTOS-i tüüpiliste rakenduste hulka kuuluvad VxWorks, mida kasutatakse laialdaselt kosmose- ja kaitsesüsteemides; QNX, levinud auto- ja tööstusplatvormidel; ja FreeRTOS, mida kasutatakse laialdaselt manustatud ja asjade Interneti-seadmetes. Lisaks RTOS-i tuumadele virnastab CPS-i tarkvara üha enam kaasatud seadmedraivereid, suhtluse vahevara (nt sõnumijärjekorrad ja avaldamis-tellimisraamistikud, nagu DDS) ja riistvara abstraktsioonikihte (HAL), et eraldada rakendusloogika platvormipõhistest üksikasjadest. Need komponendid võimaldasid modulaarset tarkvaraarhitektuuri, säilitades samal ajal juhtimiseks ja ohutuseks vajaliku determinismi. Erinevates valdkondades, nagu maa-, õhu-, mere- ja kosmosesüsteemid, said RTOS-põhised arhitektuurid süsteemidisaini aluseks koos domeenispetsiifiliste kohandustega. Maasüsteemides standardiseerivad autoplatvormid tarkvarapakke, nagu AUTOSAR, kus RTOS-i ajakava toetab mootori juhtseadmeid (ECU), pidurisüsteeme (ABS) ja täiustatud juhiabisüsteeme (ADAS). Õhusüsteemides toetuvad avioonikaplatvormid, nagu Boeing 787, eraldatud RTOS-keskkondadele (mis põhinevad sageli VxWorksil), et täita rangeid ohutussertifikaadi nõudeid (nt DO-178C), tagades lennukriitiliste funktsioonide vahel ajalise ja ruumilise isolatsiooni. Meresüsteemides kasutavad integreeritud silla- ja navigatsioonisüsteemid (nt need, mida kasutatakse kaasaegsetel kommertslaevadel ja mereväelaevadel) reaalajas (sageli QNX-põhist) tarkvara, et koordineerida radari, GPS-i ja autopiloodi juhtimisahelaid selliste standardite kohaselt nagu IEC 61162 (NMEA). Kosmosesüsteemides kasutavad kosmoselaevad, nagu Mars Perseverance Rover, RTOS-platvorme, nagu VxWorks, et juhtida juhendamist, navigeerimist ja juhtimist keskkondades, kus kaugjuhtimine ja tõrketaluvus on olulised. Aja jooksul arenesid need süsteemid tihedalt seotud monoliitsetest rakendustest kihilisemate ja komponentsemate arhitektuurideni, mis hõlmasid standardiseeritud liideseid ja üha keerukamat vahevara. See areng pani aluse kaasaegsetele suundumustele, nagu tarkvaraga määratletud sõidukid, autonoomsed süsteemid ja hajutatud CPS-platvormid, kus tarkvara mitte ainult ei juhi füüsilisi protsesse, vaid võimaldab ka pidevaid värskendusi, kohanemisvõimet ja kõrgema taseme süsteemi intelligentsust.

Küberfüüsikalistes süsteemides (CPS) on avatud lähtekoodiga tarkvara roll olnud järkjärgulisem, kuid üha olulisem, eriti kuna süsteemid on muutunud keerukamaks, võrgustatumaks ja tarkvarapõhisemaks. Platvormid, nagu FreeRTOS, Zephyr ja vahevararaamistikud, nagu ROS, on võimaldanud laiemat juurdepääsu manustatud ja robotsüsteemide arendamisele, soodustades innovatsiooni sellistes valdkondades nagu autonoomsed sõidukid, tööstusautomaatika ja droonid. CPS-i avatud lähtekoodiga lähenemisviisid pakuvad eeliseid läbipaistvuse, paindlikkuse ja kogukonnapõhise valideerimise osas, mis on eriti väärtuslikud teadusuuringute ja prototüüpide loomise jaoks. Kuid nende kasutuselevõtt ohutuse seisukohalt kriitilistes valdkondades – nagu avioonika, autode ohutussüsteemid ja kosmosemissioonid – on nõudnud hoolikat integreerimist sertifitseerimisprotsesside, pikaajaliste tugimudelite ning rangete kontrolli- ja valideerimistavadega. Üha enam kerkivad esile hübriidmudelid, milles avatud lähtekoodiga komponendid moodustavad arendusplatvormide aluse, samas kui sertifitseeritud, domeenispetsiifilised kihid tagavad vastavuse ohutus- ja töökindlusnõuetele, peegeldades IT avatud innovatsioonimudeli ja küberfüüsikaliste süsteemide rangete tagatisvajaduste lähenemist.

Kuna tarkvara liikus nõuande- ja mugavusrollidelt suletud ahela juhtimiseks, tõrkehalduseks ja autonoomiaks, pidid ohutusstandardid nihkuma peamiselt riistvara töökindlusele keskendumisest tarkvara käitumise, arendusprotsessi, jälgitavuse ja kontrollitõendite käsitlemisele. Suur ajalooline samm oli järgmine: riistvara võis sageli analüüsida juhuslike rikete ja kulumismehhanismide alusel, kuid tarkvara tõi kaasa teistsuguse riski – nõuete vigadest tulenevad süstemaatilised vead, disainivead, juurutusvead ja ootamatud vastasmõjud. See sundis iga domeeni koostama standardeid, mis rõhutasid olelusringi rangust, nõuete jälgitavust, kontrolli sõltumatust, konfiguratsiooni juhtimist ja struktureeritud ohutusargumente, mitte ainult komponentide vastupidavust. IEC 61508 sai programmeeritavate elektrooniliste süsteemide laiaulatuslikuks funktsionaalse ohutuse võrdluspunktiks ja sisaldab 3. osas selgesõnaliselt tarkvaranõudeid, samas kui hilisemad domeenispetsiifilised standardid kohandasid seda loogikat oma töökeskkondadega.

Maapealsetes süsteemides, eriti autotööstuses, oli tarkvara ohutuse varane ajastu suhteliselt mitteametlik: originaalseadmete tootjad ja tarnijad kasutasid sisemist inseneridistsipliini, testimist ja FMEA-stiilis mõtlemist, kuid sõidukite tarkvarale kohandatud ühtset raamistikku ei olnud. Kuna sõidukid muutusid tarkvaramahukaks – esmalt mootori juhtimises, seejärel pidurdamises, roolis, turvapatjades, võrgus ja ADASis –, vajas tööstus standardit, mis käsitleks tarkvara osana täielikust ohutuse elutsüklist. See tuli ISO 26262 kaudu, mis avaldati esmakordselt 2011. aastal maanteesõidukite jaoks mõeldud IEC 61508 kohandusena. ISO 26262 tutvustas autode ohutuse terviklikkuse taset (ASIL), ohuanalüüsi ja riskide hindamist, elutsükli protsesse ja ohutusmeetmeid nii riist- kui ka tarkvara jaoks, lisades tarkvara tagatise sõidukite arendusse, mitte jättes selle hilises etapis testimisprobleemiks. Praktikas suunas standard autotööstusele tugevamate nõuete kavandamise, kahesuunalise jälgitavuse, turvalisema tarkvaraarhitektuuri, kontrollimise planeerimise ja tarkvara ametliku integreerimise süsteemitaseme ohutusjuhtumitesse.

Lennusüsteemides tekkisid tarkvara ohutusstandardid varem ja rangemalt, kuna tarkvara sisenes lennukriitilistesse funktsioonidesse varem. Kui digitaalsed lennujuhtimis-, navigatsiooni- ja avioonikakuvarid muutusid missiooni- ja ohutuse seisukohast kriitiliseks, ei saanud lennundus tarkvara käsitleda lihtsalt järjekordse insenerikihina. Seetõttu sai algselt 1981. aastal avaldatud DO-178 nii mõjukaks: see määratles õhus leviva tarkvara disainikindluse ja sidus arenduse ranguse funktsiooni kriitilisusega. Aja jooksul küpses see läbi DO-178B ja seejärel DO-178C 2011. aastal, mis jääb FAA poolt AC 20-115D kaudu tunnustatud tarkvaratagatise põhiraamistikuks. Õhutranspordisektori ajaloolise tähtsusega samm oli muuta tarkvara ohutus sõltuvaks mitte ainult testimisest, vaid dokumenteeritud eesmärkidest, elutsükli tõenditest, konfiguratsioonikontrollist, struktuursest katvusest, vajaduse korral tööriistade kvalifitseerimisest ja tarkvara tasemele vastavast kontrollist. Teisisõnu, lennundus liikus kõige varem ja selgemalt idee poole, et ohutut tarkvara demonstreeritakse distsiplineeritud tagamisprotsessi kaudu, mitte ainult näidates, et programm “paistab töötavat”.

Meresüsteemides oli areng aeglasem ja killustatum. Merejuhtimine keskendus ajalooliselt rohkem mehaanilisele terviklikkusele, koondamisele, merekõlblikkusele ja ettekirjutavatele seadmete reeglitele kui tarkvaraspetsiifilisele elutsükli tagatisele. Kuna laevad võtsid kasutusele integreeritud sillasüsteemid, dünaamilise positsioneerimise, digitaalse navigatsiooni ja autonoomsed funktsioonid, pidid klassifikatsiooniühingud nagu DNV, ABS ja Lloyd’s Register üha enam arvestama tarkvara kvaliteedi, kübervastupidavuse ja juhtimissüsteemide rikete käitumisega. Kuid erinevalt lennundusest ja autotööstusest ei lähenenud meresektor ühtse universaalselt domineeriva tarkvara ohutusstandardi järgi nii varakult. Selle asemel on see üldiselt tuginenud klassireeglitele, IEC-st tuletatud funktsionaalse ohutuse mõtteviisile, seadmete standarditele ja süsteemispetsiifiliste tagatiste tavadele. Seega on ajalooline liikumine merenduses toimunud seadmete heakskiitmise ja koondamise reeglitest tarkvarateadlikuma mudeli poole, kuid see on siiski vähem ühtne ja vähem protsessikeskne kui kosmose- või autotööstuses. See erinevus peegeldab sektori väiksemat tootmismahtu, erinevaid laevatüüpe, pikki elutsükkele ja vähem tsentraliseeritud sertifitseerimisstruktuuri. Peatükk, mida jagasite, kajastab seda hästi, märkides, et merejuhtimine on jäänud rohkem ettekirjutavaks ja tulemuspõhiseks kui protsessi tagamise põhiseks.

Kosmosesüsteemides arenes tarkvara ohutus äärmuslike missiooni tagamise piirangute tõttu, mitte ühe kaubandusliku sertifitseerimisviisi kaudu. Kosmoseprogrammid mõistsid varakult, et tarkvaravead võivad olla katastroofilised, kuna parandamine on keeruline või võimatu, sideviivitused on pikad ja missioonid on kallid. Pikka aega käsitleti ohutust agentuurispetsiifilise usaldusväärsuse doktriini, koondamise, konservatiivse disaini ja süsteemitehnoloogia distsipliini, mitte ühe tarkvara sertifitseerimisstandardi, nagu DO-178, kaudu. NASA enda tarkvara ohutusraamistik muutus selgemaks NASA-STD-8719.13 abil, mis anti esmakordselt välja 1997. aastal ja mida on pärast seda ajakohastatud; NASA kirjeldab seda kui ohutuse tagamiseks vajalike tegevuste täpsustamist agentuuri hangitud või arendatud tarkvarasse. Kosmosesektori ajalooline liikumine on seega olnud missioonipõhisest töökindluse praktikast ametlikumate tarkvara ohutustoimingute, dokumentatsiooni ja riskipõhise ranguse suunas. Võrreldes õhus olevate süsteemidega on sageli vähem rõhku tootesarja korduvaks kasutamiseks mõeldud sertifitseerimisel, vaid rohkem selle tagamisel, et missioonipõhised tarkvaraohud tuvastatakse, leevendatakse ja hallatakse osana laiemast süsteemiohutusest.

Tarkvara sisenes keerukatesse konstrueeritud toodetesse ammu enne, kui keegi midagi “tarkvara määratletud” teemast rääkis. Elektroonikatoodete esimeste põlvkondade puhul oli tarkvara väike, tihedalt seotud konkreetse riistvarafunktsiooniga ja seda käsitleti sageli peaaegu nagu püsivara: fikseeritud juhtkiht, mis põletati ROM-i või mida hooldas väike insenerimeeskond. Tootmine oli sel ajastul peamiselt riistvaradistsipliin. Kui disain oli külmutatud ja kvalifitseeritud, eeldati, et tarkvara püsib stabiilsena aastaid, mõnikord kogu toote eluea jooksul. Hooldatavus oli olemas, kuid enamasti defektide parandamise, teenusevärskenduste väljastamise ja asendusriistvaraga ühilduvuse säilitamise näol. Tarneahela fookus oli samamoodi füüsiline: pooljuhid, plaadid, pistikud ja mehaanilised osad domineerisid riskide ja planeerimise üle. Tarkvarasõltuvused olid piisavalt piiratud, et organisatsioonid said sageli sisemiselt kogu pinu aru saada. See hakkas muutuma, kui tooted said võrku ühendatud, funktsioonirikkad ja digitaalselt värskendatavad.

Alates 1980. aastatest kuni 2000. aastateni muutus tarkvara toote väärtuses palju suuremaks, eriti manussüsteemides, telekommunikatsioonis, kosmosetööstuses ja autoelektroonikas. See muutis tootestamise ühekordsest väljalasketegevusest pidevaks elutsükli probleemiks. Toode tuli nüüd turule tuua, värskendada, hooldada, turvata ja mõnikord ka ümber seadistada. Hooldatavusest sai enamat kui puhas kood või modulaarne disain; see tähendas versioonikontrolli riistvaravariantide lõikes, jälgitavust nõuetest juurutatud binaarfailideni, pikaajalist tuge vananevatele platvormidele ja võimet diagnoosida tõrkeid interakteeruvates alamsüsteemides. Samal ajal muutus tarkvara tarneahel keerukamaks. Enamasti sisemise koodi asemel sõltusid tooted üha enam kolmanda osapoole operatsioonisüsteemidest, vahevarast, protokollivirnadest, kompilaatoritest, teekidest, tarnija SDK-dest ja lõpuks avatud lähtekoodiga komponentidest. NIST kirjeldab nüüd tarkvara tarneahelat kui tarkvara tootmise ja tarnimisega seotud tegevuste kogumit, märkides, et selle terviklikkus sõltub nende tegevuste turvalisusest ja distsipliinist; kaasaegsed juhised rõhutavad selliseid tavasid nagu SBOM-id, müüja riskihindamine, haavatavuse haldamine ja turvalised arendusraamistikud. Ajalooliselt tähistab see suurt nihet: tarkvara ei olnud enam lihtsalt midagi, mida ettevõte kirjutas, vaid see, mida ta koostas, integreeris, pärandas ja pidevalt juhis.

Kaasaegne faas laiendab seda loogikat veelgi. Ühendatud toodetes, eriti sõidukites, on tarkvara nüüd peamine vahend eristamiseks, funktsioonide tarnimiseks ja isegi ärimudeli arendamiseks. Siin tulebki sisse tarkvaraga määratletud sõiduki (SDV) idee. Ajalooliselt ehitati sõidukid paljude funktsioonispetsiifiliste ECU-de ümber, mille riistvara ja tarkvara olid omavahel tihedalt seotud ning uus võimalus saabus tavaliselt alles uue mudeliaasta või riistvara ümberkujundamisega. SDV kontseptsioon peegeldab liikumist sellest paradigmast tsentraliseeritud või tsoonipõhise andmetöötluse, rikkalikumate abstraktsioonikihtide ja õhu kaudu värskendatavuse poole, nii et funktsioonid, jõudlus, kasutajakogemus ja isegi teatud platvormi käitumine võivad pärast sõiduki müümist areneda. Tööstusanalüütikud kirjeldavad seda nihet kui osa laiemast üleminekust autotööstuse E/E arhitektuuris, kus tarkvarast ja tsentraliseeritud andmetöötlusest saavad innovatsiooni ja pideva väärtuse loomise peamised võimaldajad. Ajaloolisest vaatenurgast on SDV pika kaare lõpp-punkt: tooted said alguse riistvarast, millel oli väike sisseehitatud koodi, neist said integreeritud süsteemid, mille edu sõltus tarkvara elutsükli haldamisest, ja nüüd mõistetakse neid üha enam riistvaras sisalduvate värskendatavate tarkvaraplatvormidena.

IT-põhist tarkvara kontrollitakse nõuetepõhise testimise, koodianalüüsi ja käitusaja valideerimise struktureeritud kombinatsiooni kaudu, mida täiendavad Carnegie Melloni ülikooli tarkvaratehnika instituudi metoodikate põhimõtted, nagu suutlikkuse küpsusmudeli integreerimine ja distsiplineeritud tarkvaratehnika praktikad. Kontrollimine algab selle tagamisega, et nõuded on täpselt määratletud, jälgitavad ja testitavad – kooskõlas CMMI rõhuasetusega nõuete haldamisel ja valideerimisel. Arendus toimub üksuse, integreerimise ja süsteemi testimise kaudu, mida toetavad vastastikused eksperdihinnangud, ametlikud kontrollid ja staatiline analüüs, mis peegeldab SEI keskendumist varajasele defektide eemaldamisele ja protsessidistsipliinile. Mõõtmisel ja analüüsil on võtmeroll, kusjuures mõõdikuid kogutakse defektide tiheduse, katvuse ja protsesside toimivuse hindamiseks. Konfiguratsioonihaldus tagab, et kõik artefaktid (kood, testid, nõuded) on versioonipõhiselt juhitavad ja reprodutseeritavad, samas kui protsesside küpsustasemed suunavad organisatsioone üha prognoositavamate ja optimeeritumate kontrollitavade poole. Pidevad integreerimiskonveierid automatiseerivad regressioonitesti ning kõrgema küpsusastmega keskkondades kasutatakse protsesside kvantitatiivset juhtimist ja põhjuslikku analüüsi, et süstemaatiliselt parandada kvaliteeti. Lõpuks laieneb kontrollimine toimingutele seire- ja tagasisideahelate kaudu, kehastades SEI filosoofiat protsesside pideva täiustamise kohta kogu tarkvara elutsükli jooksul.

Küberfüüsilise tarkvara valideerimine paneb suurt rõhku riistvara/tarkvara kaasverifitseerimisele, kasutades simulatsiooni- ja emuleerimistehnikate spektrit, et tagada õige käitumine enne füüsilises maailmas kasutuselevõttu. Varasematel etappidel hindavad mudeli-in-the-loop (MIL) ja tarkvara-in-the-loop (SIL) simulatsioonid juhtimisalgoritme ja tarkvaraloogikat keskkonna ja taimedünaamika matemaatiliste mudelite suhtes. Nendele järgneb riistvara-in-the-loop (HIL) lähenemisviis, kus tegelik juhtimistarkvara töötab siht- või tüüpilisel riistvaral, suhtledes samal ajal simuleeritud andurite, täiturmehhanismide ja füüsiliste protsessidega reaalajas – mida tavaliselt kasutatakse automootorite juhtimises, avioonika lennusüsteemides ja tööstusautomaatikas. Süsteemi keerukuse kasvades võimaldavad protsessor-in-the-loop (PIL) ja kogu süsteemi emulatsiooniplatvormid manustatud tarkvara ajastamist ja kinnitamist realistliku töökoormuse korral. Pooljuhtide ja täiustatud manustatud domeenides võimaldavad platvormid, nagu QEMU ja kaubanduslikud FPGA-põhised emulaatorid, tarkvara varajast käivitamist enne räni kättesaadavust. Nendes etappides ei keskendu valideerimine mitte ainult funktsionaalsele korrektsusele, vaid ka ajastuse determinismile, rikete käsitlemisele ja koostoimele füüsiliste protsessidega. See mitmekihiline lähenemisviis võimaldab järk-järgult riske vähendada, ületades lõhe abstraktsete mudelite ja reaalse maailma kasutuselevõtu vahel, toetades samal ajal küberfüüsikaliste süsteemide rangeid ohutus- ja töökindlusnõudeid.

Kokkuvõttes juhib domineeriv IT elektrooniline ökosüsteem riist- ja tarkvaraarenduse põhirütmi. Tunduvalt väiksema helitugevusega küberfüüsikalised süsteemid on pidanud selle domineeriva rütmiga kohanema järgmistel viisidel:

1. Riistvara vananemine ja töökindlus: IT-ökosüsteemis toimub tootearendus 18–24 kuu jooksul, samal ajal kui küberfüüsikaliste süsteemide tööiga on pikem kui viis aastat. See tõstatab nõude pooljuhtkomponentide tarneahela väga hoolika juhtimise järele.
2. Tarkvara ökosüsteem: operatsioonisüsteemid, kompilaatorid, avatud lähtekoodiga tarkvara, sidestandardid ja vahevara on pidevalt arenevad küberfüüsilised ökosüsteemid. Selleks on vaja spetsiaalset arhitektuuri, kus ohutuse seisukohalt olulised/reaalajas komponendid saaksid töötada koos IT-komponentidega (nt teabe- ja meelelahutussüsteemid).
3. Arenduskulud: täielikult kapseldatud küberfüüsikaliste toodete (nt autoplatvormid) traditsioonilised mudelid nihkuvad üha enam IT-väljalasketsüklile koos õhu kaudu toimuvate värskendustega.
4. Küberjulgeolek: Sidesüsteemide ja traditsioonilise IT-tarkvara kasutuselevõtt küberfüüsikalistes süsteemides on avanud rünnakupinna halbadele tegijatele.

Kokkuvõttes tähendab üleminek suures osas mehaanilistelt süsteemidelt tarkvaraga määratletud sõidukitele tohutut nihet disainis, tootmises, toes ja isegi seaduslikus omandis. Tarkvara litsentsitakse tavaliselt originaalseadmete tootjale ja seejärel lõpptarbijale.