Raamatu kaastööliste nimekiri on toodud allpool.

• Rahul Razdan, Ph.D
• Mohsen Malayjerdi, Ph.D

• Roman Czyba, Ph.D., DSc., Ing.
• Piotr Czekalski, Ph.D., ingl.
• Tomasz Grzejszczak, Ph.D., ingl.

• Agris Nikitenko, Ph.D., ingl.
• Karlis Berkolds, M. sc., ing.
• Larisa Survilo, M. sc., ingl.

• Raivo Sell, Ph.D., ING-PAED IGIP

• Tomasz Siwy, tegevjuht

• Ing. Libor Přeučil, CSc. (Ing. = tehnika magister, CSc. = Ph. D.)
• Ing. Karel Košnar, Ph.D. (Ing. = Inseneriteaduste magister)

• Airi Veber
• Marta Nikitenko

See sisu viidi ellu projekti raames: SafeAV – Kõrghariduse autonoomse sõidukiohutuse valideerimise ja kontrollimise ühtlustamine.

Projekti number: 2024-1-EE01-KA220-HED-000245441.

Konsortsium

• ITT Group, Tallinn, Eesti (koordinaator).
• Sileesia Tehnikaülikool, Gliwice, Poola,
• Riia Tehnikaülikool, Riia, Läti,
• Tšehhi Tehnikaülikool Prahas, Praha, Tšehhi Vabariik
• Tallinna Tehnikaülikool, Tallinn, Eesti
• Prodron, Gliwice, Poola

Erasmus+ lahtiütlus
Seda projekti on rahastatud Euroopa Komisjoni toetusel.
See väljaanne kajastab ainult autori seisukohti ja komisjon ei vastuta selles sisalduva teabe võimaliku kasutamise eest.

Autoriõiguste teatis
Selle sisu lõi SafeAV konsortsium 2024–2027.
Sisu on autoriõigustega kaitstud ja seda levitatakse CC BY-NC Creative Commons Licence alusel ning see on mitteäriliseks kasutamiseks tasuta.

Elektroonika disaini suundumused on ühiskonnas revolutsiooniliselt muutnud. Algus oli tsentraliseeritud andmetöötlusega, mida juhtisid sellised ettevõtted nagu IBM ja DEC. Need tehnoloogiad suurendasid ülemaailmse äritegevuse tootlikkust, mõjutades märkimisväärselt rahandus-, personali- ja haldusfunktsioone, kõrvaldades vajaduse ulatusliku paberimajanduse järele. Majanduse kujundamise tehnoloogiate järgmine laine koosnes servaarvutusseadmetest (alloleval joonisel punane), nagu personaalarvutid, mobiiltelefonid ja tahvelarvutid. Selle võimalusega saaksid sellised ettevõtted nagu Apple, Amazon, Facebook, Google ja teised globaalse äri jaoks reklaami- ja levitamisfunktsioonidele tohutult tootlikkust lisada. Järsku võis jõuda otse iga kliendini kõikjal maailmas. See megatrend on põhjalikult häirinud selliseid turge nagu haridus (online), jaemüük (pood), meelelahutus (voogedastus), kommertskinnisvara (virtualiseerimine), tervishoid (telemeditsiin) ja palju muud. Järgmine elektroonikalaine on tehisintellekti dünaamiline integreerimine füüsiliste varadega ning selle võimekuse tipp on autonoomia.

Autonoomiauuringud ulatuvad 20. sajandi keskpaiga küberneetika ja juhtimisteooriani, kus teadlased, nagu Norbert Wiener, Ross Ashby ja varased robootika pioneerid, uurisid, kuidas masinad suudavad tajuda, töödelda tagasisidet ja sihipäraselt tegutseda. 1960.–1980. aastad tõid olulisi läbimurdeid: Shakey the Robot demonstreeris SRI-s integreeritud taju, planeerimist ja tegevust; DARPA autonoomse maismaasõiduki projekt edendas varajast arvutinägemist ja navigeerimist; ja edusammud tõenäosuslikus robootikas – nagu Kalmani filtreerimine, Bayesi hindamine ja SLAM – muutsid ametlikuks selle, kuidas autonoomsed süsteemid teevad otsuseid ebakindluse tingimustes. Sel perioodil oli autonoomia suuresti reeglipõhine ja domineeris deterministlik juhtimine, piiratud tundlikkus ja kitsad arvutusvõimalused.

Kaasaegne autonoomia hakkas kiirenema 1990. ja 2000. aastatel koos suurenenud arvutusvõimsuse, masinõppe leviku ja suuremahuliste valitsusprogrammidega. DARPA Grand Challenges (2004–2007) tähistas pöördepunkti, mis tõestas, et isejuhtivad sõidukid saavad hakkama keerulistes ja struktureerimata keskkondades ning katalüseerides nii akadeemilisi kui ka kommertsinvesteeringuid. 2010. aastatel muutis sügav õppimine tajumise murranguliseks, võimaldades tugevat objektide tuvastamist, stseeni mõistmist ja täielikku juhtimist. See laiendas autonoomiat traditsioonilisest robootikast autonoomsete süsteemideni maa-, mere-, õhu- ja kosmosekontekstis.

Arvestades tohutut uurimistöö mahtu, on autonoomia kohta kirjutatud mitu raamatut. Näiteks pakub autonoomsete robotite sissejuhatus terviklikku ja juurdepääsetavat alust autonoomsete süsteemide kujundamiseks, hõlmates olulisi ehitusplokke, nagu roboti mehhanismid, tuvastusviisid, käivitamine, tajumine, lokaliseerimine, kaardistamine ja planeerimine. Seda kasutatakse laialdaselt ülikoolikursustel, kuna see ühendab teooria praktiliste algoritmidega, pakkudes selgeid selgitusi selle kohta, kuidas autonoomsed robotid tõlgendavad oma keskkonda ja teevad otsuseid. Distributed Autonomous Robotic Systems seevastu keskendub mitme roboti ja sülemi süsteemide väljakutsetele ja arhitektuuridele, uurides hajutatud keskkondades detsentraliseeritud juhtimist, koordineerimist, sidet ja töökindlust. Üheskoos hõlmavad need kaks raamatut spektrit ühe roboti autonoomiast mitme agentuuriga koostöösüsteemideni, andes lugejatele põhjaliku ülevaate nii robootikast kui ka hajutatud autonoomia keerukusest.

Erinevalt olemasolevast kirjandusest keskendub see raamat uuendustele, mis on vajalikud põhikujunduse integreerimiseks ühiskonna juhtimissüsteemidesse. See protsess on eriti keeruline autonoomsete süsteemide jaoks, kuna need integreerivad nelja laia domeeni, mis traditsiooniliselt ei ole üksteisega suhelnud:

1. Õiguslikud ja regulatiivsed struktuurid, mis on kaudselt eeldanud inimtegevuses osalejaid.
2. Küberfüüsikaliste süsteemide traditsioonilised mehaaniliselt fokusseeritud ohutusprotokollid.
3. Traditsioonilised tarkvara tootearendusvood.
4. Uued tehisintellektil põhinevad algoritmid, mis asendavad autonoomia juhi.

Ülejäänud osa sellest raamatust on korraldatud järgmiselt. 2. peatükk annab kõrgetasemelise sissejuhatuse autonoomsetesse süsteemidesse, sealhulgas nende aluseks olevatesse tehnoloogiatesse ja nende koostoimesse regulatiivsete, ohutus- ja standardikeskkondadega. 3. peatükis uuritakse riistvaraarhitektuure, pöörates erilist tähelepanu anduritele, suure jõudlusega andmetöötlusplatvormidele ja riistvara tarneahelate esilekerkivatele väljakutsetele. 4. peatükk keskendub tarkvaraarhitektuurile, sealhulgas reaalajas täitmisele, ohutuse seisukohalt olulisele tarkvaraarendusele ning stabiilsete ja turvaliste tarkvara tarneahelate kasvavale tähtsusele. 5. peatükis uuritakse kõrgema taseme autonoomia algoritme tajumiseks, kaardistamiseks ja lokaliseerimiseks, keskendudes süsteemi ohutusele ja töökindlusele. 6. peatükis käsitletakse planeerimist, kontrolli ja otsuste tegemist, uurides, kuidas autonoomsed süsteemid muudavad taju turvaliseks ja tõhusaks tegevuseks. Lõpuks, 7. peatükis uuritakse autonoomsete süsteemide, inimeste ja infrastruktuuri vahelist suhtlust, sealhulgas inimese ja masina liideste (HMI) ja sõiduki ja kõige vahel (V2X) vahelist sidet, rõhuasetusega integreeritud süsteemi ohutusele ja töökindlusele.

Autonoomsed süsteemid kasutavad keskkonna kohta teabe kogumiseks andureid (nt kaamerad, radarid, ultraheliandurid). Kogutud andmeid töödeldakse ja nende alusel tehakse otsused edasise tegevuse kohta. Mis täpselt on autonoomia? Süsteemi autonoomiat võib defineerida kui selle võimet tegutseda vastavalt oma eesmärkidele, normidele, sisemistele seisunditele ja teadmistele, ilma inimese välise sekkumiseta. See tähendab, et autonoomsed süsteemid ei piirdu ainult robotite või mehitamata sõidukitega. See määratlus hõlmab kõiki automaatseid funktsioone, mis võivad vähendada töökoormust või toetada sõidukit juhtivat inimest.

Autonoomsed süsteemid kasutavad ülesannete iseseisvaks täitmiseks arenenud tehnoloogiaid, nagu tehisintellekt, masinõpe, närvivõrgud, asjade Internet ja muud. Autonoomsed süsteemid on tänapäeva tööstus 4.0 ja neid kasutatakse erinevates valdkondades alates robootikast, transpordi ja logistika kaudu ning lõpetades meditsiini ja haridusega. Näitena võiks tuua autonoomse auto, mis teeb otsuseid ise andurite andmete põhjal, või autonoomne transpordivahend (AGV ehk Automated Guided Vehicles), mis on loodud lasti ohutuks ja tõhusaks transportimiseks laos ilma operaatori järelevalveta. Teiseks autonoomsete süsteemide rakenduseks on tootmissüsteemid, mis tööstusandurite andmete põhjal juhivad automaatselt tootmisprotsesse, juhivad masinaid ja optimeerivad tootmist. See võimaldab lühendada tootmisaegu, vähendada tootmiskulusid ja tõsta toote kvaliteeti. Autonoomsed süsteemid on kasutusel ka transpordis ja logistikas, kus need võimaldavad kaupade kiiremat ja tõhusamat kohaletoimetamist. Tänu asjade internetile ja monitooringusüsteemidele saab jälgida iga transpordietappi alates laadimisest kuni kohaletoimetamiseni, mis võimaldab protsessi paremini kontrollida. Autonoomsed süsteemid on muutumas meie elu üha olulisemaks osaks ning nende arendamine ja rakendamine mõjutab tulevikku üha enam.

Autonoomsed süsteemid töötavad põhimõtteliselt erinevates füüsilistes keskkondades maa-, mere-, õhu- ja kosmosevaldkonnas ning need keskkonnaalased erinevused mõjutavad tugevalt süsteemi ülesehitust, tuvastust, ohutust ja tööarhitektuuri. Maapealsed süsteemid töötavad kõrgelt struktureeritud, kuid ettearvamatutes keskkondades, kus on tihedad takistused, inimestevaheline suhtlus ja suure ribalaiusega ühenduvus, mis nõuavad reaalajas tajumist, kiiret reaktsiooniaega ja tugevat inimeste ohutuse tagamist. Meresüsteemid töötavad vähem struktureeritud, kuid aeglasemalt liikuvates kolmemõõtmelistes keskkondades, kus on vähem takistusi, piiratud ühenduvus ja tugevad keskkonnahäired, nagu lained, hoovused ja korrosioon, pannes suuremat rõhku pikaajalisele töökindlusele, navigatsiooni töökindlusele ja kaugjärelevalvele. Õhusõidukisüsteemid töötavad kolmemõõtmelistes, ohutuskriitilistes keskkondades, mida juhib range õhuruumi kontroll, mis nõuab rikke tõsiste tagajärgede tõttu äärmiselt suurt töökindlust, täpset navigeerimist, veataluvust ja ametlikku sertifitseerimist. Kosmosesüsteemid töötavad kõige ekstreemsemates ja eraldatud keskkonnas, mida iseloomustavad kiirgus, vaakum, äärmuslikud temperatuurikõikumised ja pikad sideviivitused, mis muudavad inimeste reaalajas sekkumise võimatuks ja nõuavad, et süsteemid oleksid väga autonoomsed, tõrketaluvusega ja suutma töötada iseseisvalt pikema aja jooksul. Selle tulemusena on autonoomia arhitektuurid, ohutusnõuded, tuvastusviisid ja kontrollimeetodid nendes valdkondades märkimisväärselt erinevad, kuigi neil on ühised taju, otsuste tegemise ja kontrolli aluspõhimõtted.

Üldiselt on autonoomia transformatsioonitehnoloogia, mis juhib majandusprotsesse, mis muudavad ühiskonda. Et olla tõhus, peab autonoomia integreeruma ühiskonna kriitiliste elementidega ja ülejäänud peatükis käsitletakse neid üksikasjalikumalt.

Intuitiivselt tähendab mehitamata süsteemide autonoomia nende võimet ise juhtida, teha otsuseid ja täita ülesandeid minimaalse või ilma inimese sekkumiseta. Teiste süsteemide või inimestega koostöö tegemiseks on autonoomia jaoks vaja süsteemi selget määratlust. See määratlus mitte ainult ei edasta partneritele ja kasutajatele funktsiooni, vaid seab ka ootusfunktsiooni. Ootusfunktsioonid on kesksel kohal paljudes tehnilistes (valideerimine), juhtimis- (litsentsimine) ja juriidilistes (vastutus) protsessides. Kõik füüsilised domeenid on loonud mõnevõrra sarnased autonoomia “tasemed”, mis hakkavad seadma ootusfunktsioone.

Ameerika organisatsioon Society of Automotive Engineers (SAE) International võttis 2014. aastal maismaasõidukite jaoks vastu kuuest autonoomse sõidu tasemest koosneva klassifikatsiooni, mida hiljem 2016. aastal muudeti. Riikliku maanteeliiklusohutuse administratsiooni (NHTSA) otsuse alusel on see Ameerika Ühendriikides ametlikult kohaldatav standard, mis on ka autonoomse sõidu tehnoloogiate uuringutes kõige populaarsem Euroopas.

Olukorra selgitamiseks on SAE International määratlenud 5 autonoomsete sõidukite automatiseerimise taset, mis on vastu võetud tööstusstandardina (vt joonis 2).

• Tase 0: Juhil on sõiduki üle täielik kontroll ja puuduvad automatiseeritud süsteemid.

• 1. tase: Tuntud ka kui “käeline”, juhib juht kõiki standardseid sõidufunktsioone, nagu roolimine, kiirendamine, pidurdamine ja parkimine. Mõned automatiseeritud süsteemid, nagu püsikiiruse hoidja, parkimisabi ja sõidurea hoidmise abi, ehitatakse autosse. Juht peab jälgima oma ümbrust ja suutma igal ajal täieliku kontrolli enda kätte haarata.

• 2. tase: “Käed vabad” automaatika tähendab, et automatiseeritud süsteem suudab täielikult juhtida sõidukit, roolida, kiirendada ja pidurdada. Küll aga peab juht olema valmis vajadusel sõiduki üle kontrolli haarama. “Käed-vabad” põhimõtet ei tohiks võtta sõna-sõnalt ja SAE soovitab hoida käed rooliga kontaktis, kinnitamaks, et juht on valmis kontrolli üle võtma.

• 3. tase: 3. taset nimetatakse “ilma silma vaatamata” automatiseerimiseks. Juht saab keskenduda muudele tegevustele peale juhtimise, näiteks telefoni kasutamine või filmi vaatamine. Automatiseeritud süsteem suudab reageerida olukordadele, mis nõuavad viivitamatut tegutsemist, näiteks hädapidurdus, kuid juht peab siiski sekkuma, kui tehnoloogia sellest teavitab.

• 4. tase: Järgmine tase on “mind-off” automatiseerimine. See sarnaneb sisuliselt 3. tasemega, kuna juht ei pea oma ümbrust jälgima. Tegelikult võivad nad magama jääda, kuna juhi sekkumine pole vajalik isegi hädaolukordades. Seda autonoomia taset toetatakse aga ainult piiratud piirkondades või teatud asjaoludel, näiteks liiklusummikutes.

• Tase 5: Tase 5 tähendab “rool valikuline”. Auto on täielikult autonoomne ega vaja inimese sekkumist.

Tänapäeval on need tasemed muutunud ootuste edastamiseks ning regulatiivsete ja õiguslike lahingute objektiks.

Üldjuhul määratletakse autonoomia või autonoomne võime süsteemisisese otsustamise või enesejuhtimise kontekstis. Lennundustehnoloogia instituudi (ATI) andmetel saavad autonoomsed süsteemid sisuliselt iseseisvalt otsustada, kuidas missiooni eesmärke saavutada, ilma inimese sekkumiseta ^[2]. Need süsteemid on samuti võimelised õppima ja kohanema muutuvate töökeskkonna tingimustega. Autonoomia võib aga sõltuda missiooni või süsteemi ülesehitusest, funktsioonidest ja spetsiifikast ^[3]. Autonoomiat võib laias laastus vaadelda kui võimaluste spektrit nullautonoomiast kuni täieliku autonoomiani. Pilot Authorization and Task Control (PACT) mudel määrab autoriseerimistasemed alates tasemest 0 (täielik piloodivolitus) kuni tasemeni 5 (täielik süsteemi autonoomia), mida kasutatakse ka autotööstuses autonoomsete sõidukite puhul (vt joonis 3).

Droonitehnoloogia autonoomia tasemed jagunevad tavaliselt viieks erinevaks tasemeks, millest igaüks tähistab drooni iseseisva töötamise võime järkjärgulist suurenemist.

• Tase 0: Piloodil on täielik kontroll iga liigutuse üle. Platvormid on alati 100% käsitsi juhitavad.

• 1. tase – kaugjuhtimispult: Piloot säilitab kontrolli üldiste toimingute ja sõiduki ohutuse üle. Siiski võib droon teatud aja jooksul üle võtta ühe või mitu olulist funktsiooni. Kuigi piloodil puudub pidev kontroll sõiduki üle ning ta ei kontrolli kunagi samaaegselt kiirust ja suunda, võib ta abistada navigeerimisel ja/või säilitada kõrgust ja asukohta. Drooni toetab lennu stabiliseerimiseks GNSS ning kõik suuna, kõrguse ja kiiruse sisendid sisestatakse käsitsi. Takistuste tuvastamise funktsioonid on sellel tasemel saadaval, kuid vältimise teostab piloot käsitsi.

• 2. tase – automaatne lennujuhtimine (abistatud autonoomia): eelprogrammeeritud lennutrajektoori edastatakse autopiloodile ja droon alustab oma missiooni, lennates mööda teekonnapunkte. Piloot vastutab endiselt sõiduki ohutu juhtimise eest ja peab olema valmis drooni kontrolli alla võtma, kui peaks juhtuma ootamatu sündmus. Kuid teatud tingimustel saab droon ise kontrollida drooni kursi, kõrgust ja kiirust. Piloodil on endiselt täielik kontroll, sealhulgas õhuruumi, lennutingimuste jälgimine ja hädaolukordadele reageerimine. Enamik tootjaid ehitab praegu sellel tasemel droone, kus platvorm saab aidata navigeerimisfunktsioone ja lubada piloodil teatud ülesannetest lahti saada.

• 3. tase – osaline autonoomia (poolautonoomne): Sarnaselt 2. tasemele suudab droon lennata autonoomselt, kuid piloot peab olema tähelepanelik ja valmis igal ajal kontrolli üle võtma. Droon annab piloodile sekkumisvajadusest teada, toimides hädaabisüsteemina. See tase tähendab, et droon suudab täita kõiki funktsioone “teatud tingimustel”.

• 4. tase – kognitiivne autonoomia (täiustatud poolautonoomne): drooni saab juhtida ka inimene, kuid see ei pea alati nii olema. Õigetes tingimustes suudab see igal ajal iseseisvalt lennata. Eeldatakse, et droonil on üleliigsed süsteemid, nii et kui üks süsteem ebaõnnestub, jätkab see tööd. Sellel autonoomia tasemel muutub funktsioon “mõistke ja vältige” “mõistke ja navigeeri”. See tähendab, et droon tuvastab oma lennutrajektooril olevad takistused ja väldib aktiivselt kontakti, muutes oma lennutrajektoori.

• 5. tase – täielik autonoomia: droon juhib ennast igas olukorras iseseisvalt, ilma inimese sekkumiseta. See hõlmab kõigi lennuülesannete täielikku automatiseerimist kõikides tingimustes. Praegu selliseid droone veel ei eksisteeri. Siiski on oodata, et lähitulevikus saavad nad lendude planeerimiseks kasutada tehisintellekti tööriistu – teisisõnu autonoomseid õppesüsteeme, mis on võimelised muutma rutiinset käitumist.

Teine üldine, kuid kasulik mudel, mis kirjeldab autonoomia taset mehitamata süsteemides, on Autonomy Levels for Unmanned Systems (ALFUS) mudel ^[5]. Euroopa Liidu Lennundusohutusamet (EASA) esitas ühes oma tehnilises aruandes teavet autonoomia tasemete ja juhiste kohta inimese ja autonoomia koostoime kohta. EASA andmetel ei ole autonoomia mõiste, selle tasemed ja inimese ja autonoomse süsteemi koostoimed välja kujunenud ning neid arutatakse aktiivselt erinevates valdkondades (sh lennundus), kuna praegu puudub nendest mõistetest ühtne arusaam ^[6]. Kuna need kontseptsioonid on veel mõnevõrra arenemisjärgus, muutub see mehitamata õhusõidukite reguleeriva keskkonna jaoks tohutuks väljakutseks, kuna need on suures osas kehtestamata.

Autonoomiatasemete klassifikatsioon mitme drooniga süsteemides on mõnevõrra erinev. Mitme drooniga süsteemides teevad mitu drooni konkreetse ülesande täitmiseks koostööd. Mitme drooniga süsteemide projekteerimine eeldab, et üksikutel droonidel oleks suurem autonoomia tase. Autonoomiatasemete klassifikatsioon on otseselt seotud jaotusega lendudeks, mis sooritatakse piloodi või vaatleja vaateväljas (VLOS) ja lendudeks, mis sooritatakse väljaspool piloodi vaatevälja (BVLOS), kus erilist tähelepanu pööratakse lennuohutusele. Üks võimalus autonoomiaprobleemi lahendamiseks on klassifitseerida droonide ja mitme drooniga süsteemide autonoomia tasemetesse, mis on seotud täidetavate ülesannete hierarhiaga ^[7]. Nendel tasemetel on standardsed määratlused ja protokollid, mis juhivad tehnoloogia arendamist ja regulatiivset järelevalvet. Ühe drooniga autonoomse mudeli jaoks pakutakse välja kaks erinevat taset: sõiduki juhtimiskiht (1. tase) ja missiooni juhtimiskiht (2. tase), vt joonis 5. Mitme drooniga süsteemidel on seevastu kolm taset: ühe sõiduki juhtimine (1. tase), mitme sõiduki juhtimine (2. tase) ja missiooni juhtimine (3. tase). Selles hierarhilises struktuuris on 3. tasemel madalaim prioriteet ja selle saab tühistada 2. või 1. tasemega.

Meresüsteemide puhul määratleb Rahvusvaheline Mereorganisatsioon (IMO) autonoomia oma meresõiduautonoomse pinnaselaeva (MASS) raamistiku kaudu, mis kirjeldab nelja järkjärgulist autonoomia taset, mis põhinevad inimeste kaasamise astmel ja pardal otsustamisvõimel. Madalamatel tasanditel kasutavad laevad automatiseerimist peamiselt inimmeeskondade abistamiseks navigeerimisel, tõukejõul ja ohutuse jälgimisel, samal ajal kui inimesed jäävad pardale ja vastutavad operatiivotsuste eest. Vahetasemed võimaldavad kaugjuhtimist, kus laevad võivad töötada ilma meeskonnata, kuid neid jälgitakse ja juhitakse kaldal asuvatest juhtimiskeskustest. Kõrgeimal tasemel suudavad täielikult autonoomsed laevad tajuda oma keskkonda, teha iseseisvalt navigeerimis- ja missiooniotsuseid ning viia neid otsuseid ellu ilma inimese sekkumiseta. See raamistik peegeldab meremissioonide tegelikku tegelikkust, kus pikad kestused, prognoositav dünaamika ja kaugseire võimaldavad järk-järgult liikuda autonoomia poole.

Kosmosesüsteemides kirjeldatakse autonoomiat tavaliselt NASA mehitamata süsteemide autonoomiatasemete (ALFUS) raamistiku abil, mis hindab autonoomiat, mis põhineb süsteemi sõltumatusel inimese kontrollist, selle võimest toime tulla keskkonna keerukusega ja võimega täita missiooni eesmärke ilma sekkumiseta. Madalamatel tasanditel toetuvad kosmoseaparaadid juhtimisel ja juhtimisel suuresti maapealsetele operaatoritele, kes täidavad etteantud juhiseid minimaalse otsuse tegemisega pardal. Autonoomia suurenedes omandavad kosmoseaparaadid võime täita selliseid funktsioone nagu rikete tuvastamine ja taastamine, autonoomne navigeerimine ja adaptiivne missioonide planeerimine. Kõrgeimal tasemel saavad süsteemid iseseisvalt tajuda oma keskkonda, hinnata missiooni eesmärke ja dünaamiliselt kohandada oma käitumist eesmärkide saavutamiseks ilma inimese reaalajas juhendamiseta. See areng on eriti oluline süvakosmose missioonidel, kus sideviivitused muudavad pideva inimliku kontrolli ebapraktiliseks.

Miks mere- ja kosmoseautonoomia raamistikud maapealsest autonoomiast erinevad?

Mere- ja kosmoseautonoomia raamistikud erinevad põhimõtteliselt maapealsest autonoomiast, kuna nende tööpiirangud rõhutavad pigem vastupidavust, kaugjuhtimist ja süsteemi vastupidavust, mitte pidevat suhtlemist inimestega tihedas ettearvamatus keskkonnas. Maapealsed sõidukid peavad töötama ohutult inimestest juhtide, jalakäijate ja keeruka infrastruktuuri vahetus läheduses, mis nõuab väga reageerivat reaalajas tajumist ja otsuste tegemist. Seevastu meresüsteemid töötavad suhteliselt struktureeritud keskkondades, kus on vähem vahetuid ohte, võimaldades autonoomial keskenduda rohkem navigeerimise tõhususele ja kaugjärelvalvele. Kosmosesüsteemid kujutavad endast veelgi suuremaid väljakutseid, sealhulgas äärmuslik side latentsus, karmid keskkonnatingimused ja inimese reaalajas sekkumise võimatus, mis nõuab, et kosmoselaev tuvastaks autonoomselt vigu, säilitaks töövõime ja tagaks missiooni ellujäämise. Selle tulemusena on autonoomia mere- ja kosmosesüsteemides ajendatud pigem tegevuse sõltumatusest ja missiooni järjepidevusest kui vahetutest inimeste ohutuse vastasmõjudest. Allolevas tabelis on kokkuvõte kõigist neljast domeenist.

Autonoomia liigitamine struktureeritud tasanditeks ei ole pelgalt tehniline taksonoomia; see toimib juriidilise vastutuse, regulatiivse heakskiidu ja eetilise juhtimise aluskonstruktsioonina. Need autonoomiatasemed määratlevad ootusfunktsiooni, mis määrab, kes (inimene või masin) vastutab tuvastamise, otsuste tegemise ja tegevuse teostamise eest määratletud töötingimustes. Sellest ootusfunktsioonist saab sertifitseerimise, valideerimise, vastutuse määramise ja tegevusloa aluseks, mida käsitleme järgmises jaotises.

Joonis 1

Ühiskonnas toimivad tooted seadusliku juhtimisstruktuuri piirides. Õiguslik juhtimisstruktuur on tsivilisatsiooni üks suuremaid leiutisi ja selle peamine roll on kanalisatsioon vaidlused struktureerimata väljendusviisist ja võib-olla isegi vägivallast kuni kohtute valdkonda (joonis 1). Selleks et õiguslikud juhtimisstruktuurid oleksid tõhusad, peavad need olema õiglased ja etteaimatavad. Õigluse eesmärk saavutatakse mitmete meetoditega, nagu nõuetekohane menetlus, läbipaistvus ja avalik menetlus ning neutraalsed otsustajad (kohtunikud, žüriid, vahekohtunikud). Prognoositavuse eesmärk saavutatakse ülimuslikkuse mõiste kasutamisega. Eelistatavus on idee, et varasematele otsustele omistatakse otsuste tegemisega võrreldes suurem kaal ning ülimuslikkusest kõrvale kaldumine on erakordne sündmus. Üliolulisus annab õigussüsteemile stabiilsuse. Õigluse ja prognoositavuse kombinatsioon nihutab vaidluste lahendamise korrapärasemale protsessile, mis edendab ühiskondlikku stabiilsust.

Kuidas see mehaaniliselt töötab ja kuidas see tootearendusega seostub?

Joonis 2

Nagu on näidatud joonisel 2, on kolm peamist etappi. Esiteks kehtestavad õigusraamistikud seadusandlikud organid (seadusandjad). Praktikas ei saa aga seadusandjad kõiki aspekte täpsustada ja volitada haldusüksusi (regulaatoreid) seaduse üksikasju kodifitseerima. Lõpuks ei ole reguleerivatel asutustel sageli tehnilisi teadmisi seaduse kõigi aspektide kodifitseerimiseks ja nad toetuvad tehniliste teadmiste saamiseks sõltumatutele tööstusrühmadele, nagu Automotive Engineering (SAE) või Elektri- ja Elektroonikainseneride Instituut (IEEE). Teiseks, selles valdkonnas tekivad vaidlused ja neid tuleb lahendada õigussüsteem. Tüüpiline protsess on kohtuprotsess õigluse tagamiseks kehtestatud rangete protsesside alusel. Kohtuprotsessi tulemuseks on faktide kohaldamine õigusraamistikus ja kohtuotsuse kohaldamine. Juhtumi faktid võivad kaasa tuua kolm võimalikku tulemust. Esimesel juhul on faktid reguleeritud õigusraamistikuga, seega ei ole juhtimisstruktuuriga seoses edasisi meetmeid. Teisel juhul paljastavad faktid juhtimisstruktuuri “serva” tingimuse. Sellises olukorras otsib kohus varasemaid juhtumeid, mis võiksid sobida (prioriteetsuse mõiste) ja kasutab seda oma otsuse tegemiseks. Kui sellist juhtumit ei ole, saab kohus määrata oma otsusega antud juhul ülimuslikkuse. See kaalub ka tulevasi otsuseid. Lõpetuseks, harvadel juhtudel on juhtumi asjaolud niivõrd uudses valdkonnas, et seadusandluses on vähe. Sellises olukorras võivad kohtud teha otsuse, kuid sageli kutsutakse seadusandlikke organeid üles looma sügavamaid õigusraamistikke.

Tegelikult peetakse üheks sellisteks olukordadeks autonoomseid sõidukeid (AV-sid). Miks? Traditsioonilistes autodes on tootevastutusega seotud seaduste kogum seotud autoga ja vastutus auto kasutamisega seotud toimingute eest juhiga. Lisaks juhitakse tootevastutust sageli föderaalsel tasandil ja juhilitsentse rohkem kohalikul tasandil. Ent üllataval kombel, nagu allolevalt jooniselt näha, on olemas seaduste kogum, mis käsitleb autonoomseid sõidukeid kaugest minevikust. Hobuste päevil juhtus õnnetusi ja tekkis keerukas vastutusstruktuur. Selles struktuuris oli kontseptsioon, et kui inimene juhtis oma hobuse õnnetusse, siis on süüdi juht. Kui aga kõrvalseisja tegi midagi, et hobust “ära ajada”, oli see kõrvalseisja süü. Lõpuks oli ka mõiste “süüdi ei ole”, kui hobune ootamatult kallale läks. Tähelepanelik lugeja võib hästi mõista, et see seaduste kogum tuleneb hobuse omaduste sügavast mõistmisest. Juriidilises mõttes loob see “ootuse”. Millised on “ootused” kaasaegsele autonoomsele sõidukile? See on praegu tööstuses väga vaieldav punkt.

Üldiselt kaalutakse toodete tarbijatele pakutavat väärtust toote poolt tekitatud võimaliku kahju suhtes ja see toob kaasa seadusliku tootevastutuse kontseptsiooni. Kuigi seadused erinevad erinevates geograafilistes piirkondades, on põhiprintsiibid ootuste ja kahju põhielemendid. Ootus, mida hinnatakse „faktide kogumit arvestades mõistliku käitumise alusel”, toob kaasa vastutuse. Näiteks on selge ootus, et kui seisate rongi ees, ei saa see koheselt peatuda, samas kui enamiku autonoomse sõidu olukordade puhul seda ei eeldata. Kahju on veel üks võtmekontseptsioon, mille puhul filmide tehisintellekti soovitussüsteemid ei vasta autonoomsete sõidukite standarditele. Vastutuse juhtimisraamistik töötatakse välja mehaaniliselt seadusandlike meetmete ja nendega seotud määruste kaudu. Raamistiku testitakse kohtusüsteemis juhtumi konkreetsetel asjaoludel või faktidel. Süsteemi stabiilsuse tagamiseks vaadeldakse kohtuasjade ja otsuste andmebaasi kui tervikut prioriteetsuse mõiste all. Õigusküsimuste selgitamise annab apellatsiooniõigussüsteem, kus seaduse kohaldamise argumentide üle otsustatakse, mis on ülimuslik.

Mis on kogu selle olukorra näide? Mõelge ülaltoodud joonisel olevale õhuruumile, kus juhtimisraamistik koosneb kehtestatud seadusest (antud juhul USA-st) ja nendega seotud juhtumitest, mis pakuvad õiguslikku ülimuslikkust, eeskirju ja tööstusstandardeid. Kõik õhutranspordisektori tooted peavad oma lahenduse turule toomiseks vastama nõuetele.

Viide:

1. Razdan, R., (2019) „Seadmata tehnoloogiavaldkonnad autonoomsetes sõidukite testimises ja valideerimises”, 12. juuni 2019, EPR2019001.
2. Razdan, R., (2019) „Automatiseeritud sõidusüsteemide ja transpordi ökosüsteemi lahendamata teemad”, 5. november 2019, EPR2019005.
3. Ross, K. Tootevastutuse seadus ja selle mõju tooteohutusele. Ajakirjas Compliance Magazine 2023, [veebis]. Saadaval: https://incompliancemag.com/product-liability-law-and-its-effect-on-product-safety/

Nagu juhtimismoodulis arutatud, kaalutakse toodete tarbijatele pakutavat väärtust toote võimaliku kahju vastu ja see toob kaasa seadusliku tootevastutuse kontseptsiooni. Tootearenduse vaatenurgast moodustab seaduste, määruste ja õigusliku ülimuslikkuse kombinatsioon ülekaaluka juhtimisraamistiku, mille ümber süsteemi spetsifikatsioon tuleb üles ehitada [3]. Valideerimisprotsess tagab toote disaini vastavuse kasutaja vajadustele ja nõuetele ning kontrollimine tagab, et toode on ehitatud õigesti vastavalt disaini spetsifikatsioonidele.

Joonis 1. V&V ja juhtimisraamistik. Master V&V (MaVV) protsess peab näitama, et toodet on mõistlikult testitud, arvestades mõistlikku kahju tekitamise ootust. Ta teeb seda kolme olulise kontseptsiooni abil [4]:

1. Operatsiooniline disainidomeen (ODD): see määratleb keskkonnatingimused ja töömudeli, mille alusel toode on kavandatud töötama.
2. Katvus: see määrab toote kinnitamise ODD täielikkuse.
3. Välisreageerimine: tõrgete ilmnemisel kasutatakse protseduure toote disaini puuduste parandamiseks, et vältida tulevasi kahjusid.

Nagu jooniselt 1 on näha, on kontrolli- ja kinnitamisprotsess (V&V) peamine sisend juhtimisstruktuuris, millega kaasneb vastutus, ja vastavalt juhtimisstruktuurile peavad kõik elemendid näitama „mõistlikku hoolsuskohustust”. Ebamõistliku ODD näide oleks see, kui autonoomne sõiduk loobub juhitavusest millisekund enne õnnetust.

Joonis 2. Täitmine on ruum.

Mehaaniliselt rakendatakse MaVV-d Minor V&V (MiVV) protsessiga, mis koosneb:

1. Testi genereerimine: lubatud ODD-st genereeritakse teststsenaariumid.
2. Täitmine: see test “käivitatakse” arendatava toote puhul. Matemaatiliselt funktsionaalne teisendus, mis annab tulemusi.
3. Korrektsuse kriteeriumid: Täitmise tulemusi hinnatakse edu või ebaõnnestumise suhtes selgete õigsuse kriteeriumidega.

Praktikas võib igaüks neist etappidest olla üsna keerukas ja seotud kuludega. Kuna ODD võib olla väga lai olekuruum, on stiimuli intelligentne ja tõhus genereerimine ülioluline. Tavaliselt tehakse alguses stiimuli genereerimine käsitsi, kuid see ebaõnnestub skaleerimise tõhususe testis kiiresti. Virtuaalsetes täitmiskeskkondades kasutatakse selle protsessi kiirendamiseks pseudojuhuslikult suunatud meetodeid. Piiratud olukordades saab sümboolseid või formaalseid meetodeid kasutada suurte olekuruumide matemaatiliseks kandmiseks kogu projekteerimise faasis. Sümboolsete meetodite eeliseks on täielikkus, kuid need seisavad silmitsi algoritmiliste arvutuste plahvatusprobleemidega, kuna paljud toimingud on NP-Complete'i algoritmid.

Täitmisetappi saab teha füüsiliselt (näiteks ülaltoodud testrada), kuid see protsess on kallis, aeglane, piiratud juhitavusega ja jälgitavusega ning ohutuskriitilistes olukordades potentsiaalselt ohtlik. Seevastu virtuaalsete meetodite eeliseks on kulu, kiirus, ülim juhitavus ja jälgitavus ning ohutusprobleemide puudumine. Virtuaalsetel meetoditel on ka suur eelis, et nad täidavad V&V ülesande palju enne füüsilise toote koostamist. See toob kaasa klassikalise V-diagrammi, mis on näidatud joonisel 1. Kuna aga virtuaalsed meetodid on reaalsuse mudel, toovad need kaasa ebatäpsuse testimisvaldkonnas, samas kui füüsilised meetodid on määratluse järgi täpsed. Lõpuks saab virtuaalseid ja füüsilisi meetodeid kombineerida selliste mõistetega nagu tsüklis tarkvara või riistvara. Stiimuli genereerimise vaadeldavad tulemused fikseeritakse õigsuse kindlakstegemiseks. Korrektsust määratleb tavaliselt kas kuldne mudel või antimudel. Kuldne mudel, tavaliselt virtuaalne, pakub sõltumatult kontrollitud mudelit, mille tulemusi saab võrrelda testitava tootega. Isegi sellises olukorras on tavaliselt erinevus kuldse mudeli abstraktsioonitaseme ja toote vahel, mida tuleb hallata. Kuldmudeli meetodeid kasutatakse sageli arvutiarhitektuurides (nt ARM, RISCV). Mudelivastane olukord koosneb veaseisunditest, kuhu toode siseneda ei saa ja seega on õige käitumine veaolekutest väljaspool olev olekuruum. Näide võib olla autonoomses sõidukiruumis, kus tõrkeseisund võib olla õnnetus või muude piirangute rikkumine. MaVV koosneb ODD olekuruumi erinevate uurimiste andmebaasi loomisest ja selle põhjal täielikkuse argumendi loomisest. Argumendil on tavaliselt tõenäosusanalüüsi olemus. Pärast seda, kui toode on põllul, diagnoositakse põllu tagastus ja alati tuleb esitada küsimus: miks minu algne protsess seda probleemi ei tabanud? Kui testimismetoodika on leitud, värskendatakse seda, et vältida edaspidiste paranduste probleeme. V&V protsess on kriitilise tähtsusega sellise toote loomisel, mis vastab klientide ootustele ja dokumenteerib “mõistliku” hoolsuskohustuse vajaduse tootevastutuse eesmärgil juhtimisraamistikus.

Enamikul juhtudel peab üldine V&V protsess võitlema tohutute ODD-ruumide, piiratud täitmisvõimsuse ja kõrgete hindamiskuludega. Lisaks tuleb seda kõike teha õigeaegselt, et toode oleks turul kättesaadav. Traditsiooniliselt on V&V režiimid jagatud kahte laia kategooriasse: füüsikapõhine ja otsustuspõhine. Räägime nüüd igaühe peamistest omadustest.

MaVV jaoks on kriitilised tegurid MiVV “mootori” tõhusus ja valideerimise täielikkuse argument. Ajalooliselt nõudsid mehaanilised/mittedigitaalsed tooted (nt autod või lennukid) keerukat V&V-d. Need süsteemid olid näited laiemast tooteklassist, millel oli füüsikapõhise täitmise (PBE) paradigma. Selles paradigmas on aluseks oleva mudeli teostusel (sealhulgas reaalses elus) järjepidevuse ja monotoonsuse tunnused, kuna mudel toimib füüsikamaailmas. Sellel olulisel arusaamal on V&V jaoks tohutu mõju, kuna see piirab oluliselt uuritavat potentsiaalset olekuruumi. Olekuruumi vähendamise näited on järgmised:

- Stsenaariumi genereerimine: tuleb muretseda ainult füüsikaseadustega piiratud olekuruumi pärast. Seega ei saa eksisteerida objekte, mis järgivad füüsikat. Iga näitleja on selgesõnaliselt piiratud füüsikaseadustega.

1. Monotoonsus: paljudes huvitavates mõõtmetes on monotoonsuse tugevad omadused. Näiteks kui pidurdamiseks mõeldakse peatumisteekonnale, on kriitiline kiirus, mille ületamisel toimub õnnetus.

Kriitiline on see, et kõik kiirusribad, mis jäävad allapoole seda kriitilist kiirust, on ohutud ja neid ei pea uurima. Mehaaniliselt ehitab traditsioonilistes PBE valdkondades ohutusregulatsiooni filosoofia (ISO 26262 [5], AS9100 [6] jne) ohutusraamistiku protsessina, kus

1. tuvastatakse rikkemehhanismid;
2. rikkemehhanismi käsitlemiseks koostatakse katse- ja ohutusargument;
3. reguleerija (või iseregulatsiooni dokumentatsioon) viib läbi ohutusprotsessi, mis hindab neid kahte ja tegutseb heakskiitmise/keeldumise kohtunikuna.

Traditsiooniliselt peetakse riketeks peamiselt mehaanilisi rikkeid. Näiteks auto pidurisüsteemi ISO 26262 järgi kontrollimise voog sisaldab järgmisi samme:

1. Määratlege ohutuseesmärgid ja -nõuded (kontseptsioonifaas): ohuanalüüs ja riskihindamine (HARA): tuvastage pidurisüsteemiga seotud võimalikud ohud (nt sõiduki peatamine, tahtmatu pidurdamine). Hinnake riskitasemeid selliste parameetrite abil nagu tõsidus, kokkupuude ja juhitavus. Määrake iga ohu jaoks autoohutuse terviklikkuse tasemed (ASIL) (vahemikus ASIL A kuni ASIL D, kus D on kõige rangem). Määrake ohutuseesmärgid ohtude leevendamiseks (nt tagage piisav pidurdamine kõikides tingimustes).
2. Töötage välja funktsionaalne ohutuskontseptsioon: muutke ohutuseesmärgid pidurisüsteemi kõrgetasemelisteks ohutusnõueteks. Veenduge, et on kaasatud liiasus-, diagnostika- ja tõrkekindlad mehhanismid (nt kahekontuuriline pidurdus või elektrooniline jälgimine).
3. Süsteemi projekteerimine ja tehniline ohutuskontseptsioon: jaotage funktsionaalsed ohutusnõuded tehnilisteks nõueteks, kujundage pidurisüsteem koos turvamehhanismidega, nagu riistvara (nt andurid, täiturmehhanismid) ja tarkvara (nt mitteblokeeruvad pidurdusalgoritmid). Rakendage rikete tuvastamise ja leevendamise strateegiaid (nt tõrkeüleminek mehaanilistele või elektroonilistele juhtimisteedele).
4. Riistvara- ja tarkvaraarendus: riistvara ohutuse analüüs (HSA): kontrollige, kas komponendid vastavad ohutusstandarditele (nt usaldusväärsed pidurdusandurid). Tarkvaraarendus ja kontrollimine: kasutage kodeerimiseks, kontrollimiseks ja kinnitamiseks ISO 26262-ga ühilduvaid protsesse. Katsetage pidurdusalgoritme erinevates tingimustes.
5. Integreerimine ja testimine: kontrollige üksikuid komponente ja alamsüsteeme, et tagada nende vastavus tehnilistele nõuetele. Viige läbi kogu pidurisüsteemi integratsioonitestid, keskendudes funktsionaalsetele testidele (nt pidurdusteekond), ohutustestidele (nt käitumine rikketingimustes) ja stressi-/keskkonnatestidele (nt kuumus, vibratsioon).
6. Valideerimine (sõiduki tase): kontrollige pidurisüsteemi kontseptsioonifaasis määratletud ohutuseesmärkide suhtes. Ohutu kasutamise kinnitamiseks tehke reaalseid sõidustsenaariume, äärmuslikke juhtumeid ja vea sissepritseteste. Kontrollige vastavust ASIL-i spetsiifilistele nõuetele.
7. Tootmine, kasutamine ja hooldus: tagage, et tootmine oleks kooskõlas kinnitatud kavanditega. Rakendage tööohutuse meetmeid (nt perioodiline diagnostika, hooldus), jälgige ja lahendage ohutusprobleeme toote elutsükli jooksul (nt tarkvaravärskendused).
8. Kinnitus ja audit: kasutage sõltumatuid kinnitusmeetmeid (nt ohutusauditid, hindamisülevaatused), et tagada pidurisüsteemi vastavus standardile ISO 26262.

Lõpuks on määrustes kindel ettekujutus autoohutuse terviklikkuse tasemete (ASIL) ohutustasemetest. Õhusõidukisüsteemid järgivad disainikindluse tasemete (DAL) kontseptsiooniga sarnast trajektoori (sõnamäng). V&V ülesande põhiosa on igal ASIL-i tasemel nõutavate standardite täitmine. Ajalooliselt on traditsiooniliste autosüsteemide kontrollimiseks välja töötatud keerukas V&V tehnikate komplekt. Need meetodid hõlmasid hästi struktureeritud füüsilisi teste, mida sageli kinnitasid reguleerivad asutused või sanktsioneeritud sõltumatud ettevõtted (ex TUV-Sud [7]). Aastate jooksul on virtuaalse füüsikal põhinevate mudelite kasutamine suurenenud mudelikujundusülesanneteks, nagu keredain [8] või rehvide jõudlus [9]. Nende mudelite üldine struktuur on luua simulatsioon, mis ennustab aluseks olevat füüsikat, et võimaldada laiemat ODD uurimist. See loob väga olulise iseloomustuse, mudeli genereerimise, ennustava täitmise ja parandusvoo. Lõpuks, kuna täitmist piirab tugevalt füüsika, võib virtuaalsetel simulaatoritel olla piiratud jõudlus ja sageli on vaja simulatsiooni kiirendamiseks ulatuslikku riistvaratuge. Kokkuvõttes on PBE paradigma peamised alused V&V vaatepunktist järgmised:

1. Piiratud ja hästi käitutud ruum stsenaariumitestide genereerimiseks.
2. Kallid füüsikapõhised simulatsioonid.
3. mehaanilistele riketele keskendunud eeskirjad.
4. Ohutusolukordades keskendusid eeskirjad ohutuse demonstreerimise protsessile, mille põhiidee on projekteerimiskindluse tasemed.

Küberfüüsikaliste süsteemide arenedes muutis infotehnoloogia (IT) maailma kiiresti.

Joonis 4. Süsteemi spetsifikatsiooni edenemine (HW, SW, AI).

Nagu on näidatud joonisel 4, on elektroonikas toimunud süsteemi funktsioonide ehituse edenemine, kus esimene etapp oli riistvara või pseudo-riistvara (FPGA, mikrokood). Järgmine etapp hõlmas protsessori arhitektuuri leiutamist, millele tarkvara saaks süsteemi funktsiooni jäljendada. Tarkvara oli disainiartefakt, mille inimesed kirjutasid standardkeeltes (C, Python jne). Protsessori abstraktsiooni revolutsiooniline aspekt võimaldas muuta funktsiooni, ilma et oleks vaja nihutada füüsilisi varasid. Tarkvara ehitamiseks oli aga vaja leegioneid programmeerijaid. Tänapäeval on tehisintellekti (AI) suur läbimurre võime luua tarkvara aluseks olevate mudelite, andmete ja mõõdikute kombinatsiooniga.

Oma põhikujul ei olnud IT-süsteemid ohutuskriitilised ja sarnasel tasemel juriidilist vastutust IT-toodetega kaasnenud ei ole. Kuid IT suurus ja kasv on sellised, et suurte tarbekaupade probleemidel võivad olla katastroofilised majanduslikud tagajärjed [10]. Seega oli V&V funktsioon väga oluline. IT-süsteemid järgivad V&V jaoks samu üldisi protsesse, nagu eespool kirjeldatud, kuid neil on kaks olulist erinevust täitmise paradigma ja vigade allika osas. Esiteks, erinevalt PBE paradigmast järgib IT täitmisparadigma otsustuspõhist täitmisrežiimi (DBE). See tähendab, et aluseks oleva mudeli funktsionaalsele käitumisele ei ole loomulikke piiranguid ega monotoonsuse loomupäraseid omadusi. Seega tuleb uurida kogu tohutut ODD-ruumi, mis muudab testide genereerimise ja leviala demonstreerimise töö äärmiselt keeruliseks. Selle raskuse vastu võitlemiseks on välja töötatud rida protsesse, et luua tugevam V&V struktuur. Nende hulka kuuluvad: 1) Koodi katvus: siin kasutatakse virtuaalse mudeli struktuurset spetsifikatsiooni piiranguna, mis aitab juhtida testi genereerimise protsessi. Seda tehakse tarkvara või riistvaraga (RTL-kood). 2) Struktureeritud testimine: Vigade leviku minimeerimiseks on välja töötatud komponentide, alajaotuste ja integratsiooni testimise protsess. 3) Disaini ülevaated: parimaks tavaks peetakse struktureeritud disainiülevaateid koos tehniliste andmete ja tuumaga.

Selle protsessivoo hea näide on CMU võimekuse küpsusmudeli integratsioon (CMMI) [11], mis määratleb protsesside komplekti kvaliteetse tarkvara tarnimiseks. Suurt osa CMMI arhitektuurist saab kasutada tehisintellekti jaoks, kui tehisintellekt asendab olemasolevaid tarkvarakomponente. Lõpuks jaguneb DBE domeeni testimine järgmisteks filosoofilisteks kategooriateks: “Teadaolevad:” tuvastatud ja arusaadavad vead või probleemid, “Teadaolevad tundmatud” Võimalikud riskid või probleemid, mis on eeldatavad, kuid mille täpne olemus või põhjus on ebaselge, ja “Teadmatud tundmatud” Täiesti ootamatud probleemid, mis ilmnevad hoiatuseta või katsetamisel, sageli mõistmisel, mõistmisel, katsetamisel. Viimane kategooria on DBE V&V jaoks kõige problemaatilisem ja kõige olulisem. Pseudojuhuslik testide genereerimine on olnud selle kategooria paljastamise põhitehnika [12]. Kokkuvõttes on DBE paradigma peamised alused V&V vaatepunktist järgmised: 1) piiranguteta ja mitte hästi käituv täitmisruum stsenaariumitestide genereerimiseks, 2) üldiselt odavam simulatsiooni täitmine (mitte füüsilisi seadusi simuleerida), 3) V&V keskendub loogilistele vigadele, mitte mehaanilistele riketele, 4) üldiselt ei ole määratletud ohutusega seotud kriitiliste rakenduste jaoks. Enamik tarkvara on “parimad jõupingutused”, 5) “Teadmatud-tundmatud” on valideerimise põhifookus.

DBE-ruumi peamine tagajärg on see, et PBE-maailma idee koostada vigade loend ja koostada nende jaoks ohutusargument on vastuolus DBE valideerimise fookusega.

Lõpuks keskendub tootearendusprotsess tavaliselt ODD määratlemisele ja selle olukorra kontrollimisele. Tänapäeval on aga lisaprobleemiks võistlevad rünnakud (küberturvalisus). Sellises olukorras soovib vastane süsteemi pahatahtlike kavatsuste eest tõsta. Sellises olukorras ei pea toote omanik mitte ainult kinnitama ODD-d, vaid ka tuvastama, kui süsteem töötab väljaspool ODD-d. Pärast tuvastamist on parim stsenaarium süsteem ohutult ümber suunata ODD-ruumi. Küberjulgeolekuprobleemidega seotud risk jaguneb küberfüüsikaliste süsteemide puhul tavaliselt kolmele tasemele.

1. OTA turvalisus: kui vastane saab üle õhu (OTA) tarkvaravärskendustega manipuleerida, võib ta kiiresti üle võtta massilise hulga seadmeid. Halvima olukorra näide oleks Tesla OTA, mis muudab Tesla kokkupõrkemootoriteks.
2. Kaugjuhtimispuldi turvalisus: kui vastane saab auto kaugjuhtimisega üle võtta, võivad nad kahjustada nii sõitjaid kui ka kolmandaid osapooli.
3. Anduri võltsimine: selles olukorras kasutab vastane sihtmärgi andurite petmiseks kohalikke füüsilisi varasid. GPS-i segamine või võltsimine on aktiivsed näited.

Juhtimise osas eeldab tootearendaja mõistlikku hoolsuskohustust, et neid probleeme minimeerida. Nõutav valideerimise tase on olemuselt dünaamiline ja seotud tööstusharu normidega.

Domeenide osas on juhtivaks teguriks operatiivse disaini domeen (ODD) ja sellel on tavaliselt kaks mõõdet. Esimene on töömudel ja teine ​​füüsiline valdkond (maa, õhus, meres, kosmoses). Maapinna osas on reisijate AV-d ehk autonoomia tuntuim nägu – robo-taksoteenused ja isejuhtivad tarbesõidukid sisenevad järk-järgult linnakeskkonda. Sellised ettevõtted nagu Waymo, Cruise ja Tesla on kasutanud ODD-dele erinevaid lähenemisviise. Waymo täielikult juhita autod töötavad Phoenixi päikesepaistelistes geotaraga äärelinnades koos üksikasjaliku kaardistamise ja kaugjälgimisega. Kruiis alustas teenust San Franciscos, mis töötas keerukuse vähendamiseks algselt ainult öösel. Tesla täieliku isejuhtimise (FSD) beetaversiooni eesmärk on laiem üldistus, kuid see sõltub siiski suuresti juhi järelevalvest ning seda piiravad ilmastiku- ja nähtavusprobleemid.

Transiitbussidest, ehkki vähem avalikustatud, on vaikselt saanud AV-de praktiline rakendus kontrollitud keskkondades. Need aeglased sõidukid töötavad tavaliselt geopiirdega piiratud aladel, nagu ülikoolilinnakud, lennujaamad või äripargid. Sellised ettevõtted nagu Navya, Beep ja EasyMile kasutavad süstikuid, mis järgivad fikseeritud marsruute ja sõiduplaane ning suhtlevad keeruliste liiklusstsenaariumitega minimaalselt. Nende ODD-d on täpselt määratletud: nad ei pruugi töötada vihma või lumega, sageli töötavad ainult päevavalguses ja väldivad kiireid või segaliiklustingimusi. Paljudel juhtudel jälgib kaugoperaator toiminguid või on vajadusel saadaval sekkumiseks. Tarnerobotid esindavad autonoomse mobiilsuse kolmandat klassi – kompaktsed ja kerged sõidukid, mis on mõeldud viimase kilomeetri kohaletoimetamiseks. Nende ODD-d on võib-olla kõige kitsamad, kuid see on disaini järgi. Need selliste ettevõtete nagu Starship, Kiwibot ja Nuro robotid navigeerivad äärelinna või ülikoolilinnaku keskkondades kõnniteedel, ülekäiguradadel ja lühikestel tänavalõikudel. Need töötavad jalakäijate kiirusel (tavaliselt alla 10 miili tunnis), kannavad väikest kandevõimet ja väldivad äärmuslikke ilmastikuolusid, tihedat liiklust või struktureerimata maastikku. Kuna nad ei vea reisijaid, võivad ohutusläved ja regulatiivne järelevalve oluliselt erineda.

Ilm on kõigi autonoomsete süsteemide puhul eriti piirav tegur. Vihm, lumi, udu ja pimestamine häirivad LIDARi, radari ja kaamera jõudlust – eriti väiksemate robotite puhul, mis töötavad maapinna lähedal. Enamik AV kasutuselevõttu piirab tänapäeval toiminguid ilusate ilmastikutingimustega. See kehtib eriti tarnerobotite ja transiitbusside kohta, mis sageli peatavad tormi ajal tegevuse. Kuigi täiustatud andurite liitmine ja ennustav modelleerimine lubavad täiustusi, jääb tõeline autonoomia iga ilmaga oluliseks tehniliseks väljakutseks. Ilmastiku ja autonoomia ristumiskoht on aktiivne uurimisvaldkond [1]

Teine ODD dimensioon on kellaaeg. Öine töö toob AV-dele ainulaadseid raskusi: halvenenud nähtavus, jalakäijate suurem ettearvamatus ja linnapiirkondades juhi ebaühtlasem käitumine. Mõned süsteemid (nt Waymo Chandleris, AZ) töötavad nüüd ööpäevaringselt, kuid enamik kasutuselevõttu – eriti kohaletoimetamisrobotid ja süstikud – on piiratud päevavalgustundidega. Tesla FSD töötab küll öösel, kuid nõuab siiski inimlikku järelevalvet. Infrastruktuur kujundab ka ODD-sid olulisel viisil. Paljud AV-süsteemid sõltuvad otsuste tegemisel kõrglahutusega kaartidest, sõiduraja tasemel GPS-ist ja isegi nutikatest liiklussignaalidest. Geopiirdega keskkondades, kus marsruut ja ümbrus on hästi etteaimatavad, on see infrastruktuuri sõltuvus hallatav. Kuid laiemate ODD-de puhul, kus keskkonnad võivad sageli muutuda või puuduvad digitaalsed kaardid, on turvalise autonoomia saavutamine palju raskem. Seetõttu väldivad reisijate AV-d tänapäeval üldiselt maapiirkondi, katmata teid või äsja ehitatud alasid.

Regulatiivsed keskkonnad kujundavad ODD-sid veelgi. USA-s on sellised osariigid nagu California, Arizona ja Florida välja töötanud AV-testimise raamistikud, kuid igaüks neist erineb selle poolest, mida see võimaldab. Näiteks lubab California täielikult juhita sõidukeid teatud linnapiirkondades, kus kehtivad ranged aruandlusnõuded. Kohaletoimetamisrobotid on sageli reguleeritud linna tasandil - mõned linnad lubavad kõnnitee roboteid, teised keelavad need täielikult. Transiitbussid saavad sageli eriload väikese kiirusega sõitmiseks piiratud marsruutidel. Need regulatiivsed piirid tõlgivad otseselt ODD piiranguid.

Füüsiliste valdkondade osas on maapealsed autonoomsed süsteemid, eriti autotööstuse kontekstis, kaubanduslikult kõige nähtavamad. Isejuhtivad sõidukid töötavad inimestetihedas keskkonnas, mistõttu on jalakäijate, jalgratturite, sõidukite ja liiklusinfrastruktuuri tuvastamiseks vaja tajusüsteeme. Valideerimine sõltub siin suuresti stsenaariumipõhisest testimisest, simulatsioonist ja kontrollitud pilootrakendustest. Sellised standardid nagu ISO 26262 (funktsionaalne ohutus), ISO/PAS 21448 (SOTIF) ja UL 4600 (autonoomse süsteemi ohutus) juhivad ohutuse tagamist. Regulatiivsed raamistikud arenevad osariigi või riigi lõikes, kusjuures operatiivse disaini valdkonna (ODD) piirangud on kasutuselevõtu praktilised piirangud.

Autonoomsed õhusõidukid (nt droonid, linnaõhu liikuvuse platvormid ja valikuliselt juhitavad süsteemid) peavad töötama kõrgelt struktureeritud ja ohutuskriitilistes keskkondades. Valideerimine hõlmab rangeid formaalseid meetodeid, tõrketaluvuse analüüsi ja vastavust lennundusohutusstandarditele, nagu DO-178C (tarkvara), DO-254 (riistvara), ning uusi juhiseid, nagu ASTM F38 ja EASA SC-VTOL. Õhuruumi juhtimine on tsentraliseeritud ja arenenud ning nõuab sageli tüübisertifikaati ja lennukõlblikkuse kinnitusi. Erinevalt autosüsteemidest peab õhusõiduki autonoomia tõestama usaldusväärsust ühenduse katkemise stsenaariumide korral ja näitama tõrgeteta töövõimet kõigis lennufaasides.

Autonoomsed pinna- ja veealused meresüsteemid seisavad silmitsi struktureerimata ja suhtluspiirangutega keskkonnaga. Need peavad töötama usaldusväärselt GPS-keelatud või RF-blokeeritud tingimustes, tuvastades samas takistusi, nagu poid, laevad või veealune maastik. Valideerimine on empiirilisem, hõlmates sageli pikendatud merekatsetusi, navigatsioonisüsteemide koondamist ja adaptiivset missiooni planeerimist. IMO (Rahvusvaheline Mereorganisatsioon) ja klassifikatsiooniühingud, nagu DNV, töötavad meresõiduautonoomse pinnalaeva (MASS) reguleeriva raamistiku kallal, kuigi ülemaailmsed standardid on alles kujunemas. Mereautonoomia (tsiviil- ja kaitse) kahesuguse kasutusega olemus muudab juhtimise keerukamaks. Kosmosepõhised autonoomsed süsteemid (nt planetaarkulgurid, autonoomsed dokkimisaparaadid ja kosmosepuksiirid) töötavad äärmuslike piirangute all: sideviivitused, kokkupuude kiirgusega ja reaalajas inimjärelevalve puudumine. Valideerimine toimub range testimise kaudu Maa-põhistes analoogkeskkondades, kriitilise tarkvara ametliku kontrollimise ja tõrkekindla disaini põhimõtete kaudu. Juhtimine kuulub riiklike kosmoseagentuuride (nt NASA, ESA) ja rahvusvaheliste raamistike, nagu kosmoseleping, alla. Kindlus tugineb pigem missioonispetsiifilistele autonoomia ümbrikutele ja eelnevalt määratletud otsustuspuudele kui reaktiivsele autonoomiale.

Ka valitsemine on erinev. Lennundus ja kosmos toimivad tsentraliseeritud, rahvusvaheliselt koordineeritud reguleerimissüsteemides (ICAO, FAA, EASA, NASA), samas kui maapealne autonoomia on jurisdiktsioonide lõikes endiselt väga killustatud. Merendusjuhtimine edeneb, kuid puudub ühtlustamine. Kuigi kosmosejuhtimine on lepingutesse ankurdatud, võitleb see üha enam äritegevuse ja riiklike huvidega, nõudes ajakohastatud riskijuhtimisprotokolle.

Uued jõupingutused, nagu SAE G-34/SC-21 standard tehisintellekti jaoks lennunduses, NASA adaptiivse autonoomia uurimine ja ISO töö tehisintellekti funktsionaalse ohutuse alal, näitavad suundumust domeeniagnostiliste põhimõtete poole intelligentse käitumise valideerimiseks. Üha enam tunnistatakse, et autonoomsed süsteemid, olenemata keskkonnast, vajavad ranget servajuhtumite testimist, süsteemi kavatsuste selgust ja reaalajas tagamise mehhanisme.

Viide:

[1] Vargas, J.; Alsweiss, S.; Toker, O.; Razdan, R.; Santos, J. Ülevaade autonoomsete sõidukite anduritest ja nende haavatavusest ilmastikutingimuste suhtes. Andurid 2021, 21, 5397. https://doi.org/10.3390/s21165397

See peatükk on andnud ülevaate autonoomsetest süsteemidest (maa, õhus, merel, kosmoses), autonoomia ootuste funktsioonide esialgsest raamistikust, juhtimisstruktuuridest, milles autonoomia peab toimima, ülevaate nende juhtimisstruktuuride toetamiseks kasutatavatest valideerimis- ja kontrollimehhanismidest ning lõpuks ülevaate autonoomiast igas füüsilises valdkonnas.

Järgmistes peatükkides süveneme nendesse teemadesse põhjalikumalt autonoomia abstraktsioonide alusel, nagu on näidatud alloleval joonisel. Nende abstraktsioonide “allosas” on füüsilised objektid, nagu mehaanilised seadmed ja nendega seotud elektroonika riistvara. Elektroonika riistvarakihi kohal on mitmesugused tarkvarakihid, mis algavad vahevarast/infrastruktuurist, algoritmikihtidest ja lõpuks ühendusest inimestega.

Neid teemasid käsitletakse kontseptuaalsel tasandil ja ka nelja füüsilise valdkonna jaoks konkreetselt (näidis joonis allpool).

Kõigi elektrooniliste süsteemide aluseks olevad aktiivsed füüsilised komponendid on pooljuhid. Pooljuhid hõlmavad mitmeid peamisi kategooriaid, mis põhinevad funktsioonil, materjalisüsteemil ja integratsioonitasemel. Kõige elementaarsemal tasemel on diskreetsed seadmed, nagu dioodid, MOSFET-id, IGBT-d ja alaldid, mis juhivad voolu ja pinget ning mida kasutatakse laialdaselt võimsuse muundamisel ja mootoriajamites. Analoog- ja segasignaaliga pooljuhid tegelevad tuvastuse, võimenduse, signaali konditsioneerimise ja toitehaldusega (nt ADC-d, DAC-id, pingeregulaatorid, anduriliidesed). Mälu pooljuhid – nagu DRAM, SRAM, NAND-välkmälu ja uued püsimälud, nagu MRAM – salvestavad andmeid ja programmikoodi. Jõupooljuhtides kasutatakse selliseid materjale nagu räni, ränikarbiid (SiC) ja galliumnitriid (GaN), et tõhusalt lülitada kõrgepingeid ja voolusid elektrisõidukites, lennukite toitesüsteemides ja taastuvenergia muundurites. Lõpuks toetavad spetsialiseeritud seadmed, nagu RF esiotsa kiibid, pildiandurid (CMOS), FPGA-d ja AI kiirendid, sidet, taju ja suure jõudlusega andmetöötlusülesandeid. Need kategooriad koos moodustavad kihilise pooljuhtide ökosüsteemi, mis on aluseks kaasaegsetele auto-, õhu-, mere- ja kosmoseelektroonikatele. Oluline kategooria on digitaalsed loogikaseadmed, sealhulgas mikrokontrollerid (MCU), mikroprotsessorid (MPU) ja süsteemipõhised (SoC) seadmed, mis teostavad teatud vormis programmeerimist (FPGA, tarkvara, AI). Seda käsitleme üksikasjalikumalt järgmises tarkvara peatükis.

Selles peatükis vaatleme pooljuhtide neeldumise ajaloolist tausta erinevates liikuvusvaldkondades. Selle tausta osana toome välja mõned peamised “tootmise” väljakutsed, nagu ohutus, juhtimine ja tarneahela juhtimine. Selle taustaga tutvustame autonoomiaga kaasnevat hüppelist keerukust ja vaatame uuesti läbi peamised “tootmise” väljakutsed.

Ajalooliselt põhinesid küberfüüsikalised süsteemid mehaaniliselt, kuid kaasaegse elektroonika tulekuga liikusid kriitilised funktsioonid kiiresti üle elektroonika alamsüsteemidesse. Näiteks autoelektroonika 1970ndatel ja 1980ndate alguses, karmistatud heitgaasistandardid USA-s, Euroopas ja Jaapanis sundisid autotootjaid kasutusele võtma mikroprotsessoripõhiseid mootorijuhtimisseadmeid (ECU). See, mis sai alguse lihtsatest süüteajastusmoodulitest, arenes välja suletud ahelaga mootori juhtimissüsteemideks, mis käitlevad kütuse sissepritse ja koputuse juhtimist – graafikul näidatud “jõuülekande” plokk. Need varajased pooljuhtide juurutused olid vastupidavad analoog-/segasignaaliga konstruktsioonid, mis optimeeriti töökindluse tagamiseks kõrge temperatuuriga keskkondades, mitte arvutusliku keerukuse tõttu.

1980. aastate lõpu ja 1990. aastate jooksul laienes elektroonika jõuülekandest šassii ja turvasüsteemideni. Mitteblokeeruvad pidurisüsteemid (ABS), elektrooniline stabiilsuskontroll, veojõukontroll ja lõpuks elektriline roolivõimendi (EPS) nõudsid reaalajas tuvastamist ja käivitamist. See vastab pildil olevatele “Chassis” ja “Safety and Control” domeenidele (ABS, turvapadja kontrollerid, TPMS, kokkupõrkehoiatus). Siin võimaldasid pooljuhid hajutatud andurit (rattakiiruse andurid, kiirendusmõõturid, rõhuandurid) ja deterministlikku manustöötlust. Arhitektuur jäi domeenikeskseks: igal funktsioonil oli oma ECU, piiratud domeenidevahelise integratsiooniga. Järgmisel lainel, ligikaudu aastatel 1995–2010, ajendas vähem regulatsioon ja rohkem tarbijate ootused. Sõidukid said teabe- ja meelelahutus- ja mugavuselektroonika platvormideks, mis on näidatud graafiku jaotistes “Infotainment” ja “Mugavus ja juhtimine” (armatuurlaua ekraanid, navigatsioon, kliimaseade, istmemoodulid, kere elektroonika). See etapp tähistas suurema jõudlusega digitaalsete SoC-de, mälu alamsüsteemide ja inimese-masina liidese protsessorite kasutuselevõttu. Oluline on see, et just sel ajal muutusid oluliseks sõidukisisesed võrgustandardid, nagu CAN, LIN ja hiljem FlexRay (loetletud jaotises “Võrgud”). Auto läks üle isoleeritud ECU-delt hajutatud elektroonilisele arhitektuurile, mida ühendasid andmesiinid – pooljuhid ei olnud enam lihtsalt kontrollerid; need olid sidevõrgu sõlmed.

Joonis 1: Autoelektroonika

2010. aastateks oli pooljuhtide sisaldus sõiduki kohta plahvatuslikult kasvanud, eriti hübriid- ja elektrisõidukite puhul. Jõuelektroonika (IGBT-d, MOSFET-id, hiljem SiC-seadmed), akuhaldussüsteemid ja kõrgepinge juhtimisaasad suurendasid järsult täiustatud pooljuhtmaterjalide ja segasignaalide integreerimise rolli. Samal ajal vajasid täiustatud juhiabisüsteemid (ADAS) – kokkupõrkehoiatus, parkimisabi, öine nägemine – nägemisprotsessoreid, radari esiosasid ja andurite liitkiipe, mis laiendavad “Ohutuse ja juhtimise” plokki suure jõudlusega andmetöötluse territooriumile.

Õhusektor

Kui autotööstuse graafika kujutab elektroonika hajutatud, domeenipõhist valmimist autodes, järgis õhusektor sarnast, kuid ohutuskriitilisemat ja sertifitseerimispõhist trajektoori. Varasemal reaktiivlennukite ajastul (1950.–1970. aastad) oli lennukielektroonika, mida tollal nimetati avioonikaks, suures osas analoogne ja liit. Radar, navigatsioon, lennuinstrumendid, mootori seire ja autopiloodisüsteemid olid eraldiseisvad kastid, millel oli piiratud ühendus. Algselt asendasid pooljuhid töökindluse ja kaalu vähendamise huvides vaakumtorud, kuid arvutusvõime oli tagasihoidlik. Sarnaselt varasematele automootorite kontrolleritele võeti elektroonika kasutusele konkreetsete töövajaduste lahendamiseks (navigatsiooni täpsus, raadioside ja lennu stabiliseerimine), mitte integreeritud digitaalse platvormi loomiseks. Suurim pöördepunkt tekkis 1980. ja 1990. aastatel digitaalse lennujuhtimise ja “fly-by-wire” arhitektuuride tõusuga, mida tsiviillennunduses lõid teerajajad lennukid, nagu Airbus A320, ja laienesid sõjalistele platvormidele, nagu F-16 Fighting Falcon. Siin läksid pooljuhid nõuandvatest rollidest ohutuskriitiliste juhtkontuuride juurde. Digitaalsed signaaliprotsessorid ja kiirgust taluvad mikrokontrollerid rakendasid stabiilsuse suurendamiseks, mähiskaitse ja mootori juhtimiseks (FADEC) deterministlikke reaalajas algoritme.

1990.–2000. aastatel astus avioonika “klaasist kokpiti” ajastusse. Sellised lennukid nagu Boeing 777 asendasid analoogmõõturid integreeritud digitaalsete ekraanidega, mida juhivad kõrge töökindlusega protsessorid ja graafika alamsüsteemid. Andmesiinid, nagu ARINC 429 ja hilisem AFDX (ARINC 664), võimaldasid deterministlikku võrku luua lennuarvutite, andurite ja kuvarite vahel – analoogselt CAN-i ja FlexRay-ga autode diagrammil. Kuid erinevalt autotööstuse võrkudest ehitati õhus olevad andmesiinid rangete partitsioonide, koondamise ja rikete piiramise piirkondade ümber. Lennukriitiliste funktsioonide puhul muutusid tavaliseks kolmemooduliline koondamine ja erinevad protsessorid. Tõukejõu- ja toitesüsteemides laienesid pooljuhid seirelt aktiivsele juhtimisele. Full Authority Digital Engine Control (FADEC) üksused kasutasid segasignaaliga ASIC-e ja mikroprotsessoreid, et optimeerida kütusevoolu, vähendada heitkoguseid ja parandada töökindlust. “Elektrilisemate õhusõidukite” kontseptsioonide esilekerkimisega (näiteks Boeing 787) suurenes jõuelektroonika sisaldus märkimisväärselt. Kõrgepingemuundurid, mootoriajamid ja pooljuhtvõimsuse kontrollerid asendasid hüdraulilised alamsüsteemid, peegeldades (ehkki turvalisuse rangelt varem) autode HEV/EV platvormidel nähtud elektrifitseerimislainet.

Meresektor

Meretööstuse elektroonikakasutus arenes isoleeritud navigatsioonivahenditest väga integreeritud digitaalsete laevasüsteemideni, järgides konstruktsiooniliselt autotööstusega sarnast trajektoori, kuid palju suurema võimsuse ja pikema varade elutsükliga. 1950.–1970. aastatel oli mereelektroonika peamiselt analoog ja funktsionaalselt eraldatud: radar, sonar, gürokompassid, VHF-raadiod ja põhiautopiloodid töötasid eraldiseisvate süsteemidena. Varajane pooljuhtide kasutuselevõtt keskendus töökindluse parandamisele ja suuruse vähendamisele, eriti radari- ja sideseadmetes. Need süsteemid olid oma olemuselt nõuandvad; tõukejõud ja juhtimine jäid suures osas mehaaniliseks või hüdrauliliseks. Esimene suurem digitaalne üleminek toimus 1980. ja 1990. aastatel mikroprotsessoripõhise mootorijuhtimise, satelliitnavigatsiooni (GPS) ja elektrooniliste kaardistamissüsteemide saabumisega. Laevadel hakati kasutama digitaalseid tõukejõu regulaatoriid, kütuse optimeerimise süsteeme ja tsentraliseeritud häireseiret. See periood sarnaneb autotööstuse üleminekuga karburaatoritelt mootori juhtseadmetele ja ABS-süsteemidele. Oluline on see, et võrgustandardid, nagu NMEA 0183 ja hilisem NMEA 2000, võimaldasid anduritel ja navigatsioonisüsteemidel andmeid vahetada, tähistades üleminekut isoleeritud mõõteriistadelt hajutatud mereelektroonika arhitektuuridele.

2000. aastateks võtsid suured kommerts- ja merelaevad kasutusele integreeritud sillasüsteemid (IBS) ja integreeritud platvormihaldussüsteemid (IPMS), koondades radari, kaardistamise, sonari, tõukejõu oleku ja ohutushoiatused ühtsetesse digitaalsetesse konsoolidesse. Jõuelektroonika sisu suurenes märkimisväärselt elektriliste ajamite, tõukuri juhtimise, hübriidlaevade toitesüsteemide ja dünaamiliste positsioneerimissüsteemidega. See faas peegeldab autotööstuse laienemist elektrifitseerimisele ja kerevaldkonna integreerimisele. Viimastel aastatel on pooljuhtide tihedus veelgi kasvanud tänu andurite liitmisele kokkupõrke vältimiseks, laevastiku kaugseire, ennustava hoolduse ja varajases staadiumis autonoomsete pinnasõidukite abil. Kuigi regulatiivsed raamistikud jäävad konservatiivseks, koosneb merearhitektuur nüüd omavahel ühendatud tõukejõu-, navigatsiooni-, ohutuse-, energiajaotuse ja autonoomia alamsüsteemidest – mis on kontseptuaalselt analoogne autode graafika domeeniplokkidega.

Kosmosesektor

Kosmosesektor järgis paralleelset, kuid rohkem töökindlusest lähtuvat arengut, mille kujundasid kiirgustaluvus, äärmuslikud keskkonnad ja missiooni tagamise nõuded. Varasel kosmoseajastul ehitati kosmoselaevade elektroonikat diskreetsest loogikast ja väga piiratud arvutusvõimega kiirguskindlatest komponentidest. Süsteemid olid rangelt ühendatud: juhtimine, telemeetria, toite konditsioneerimine, side ja soojusjuhtimine olid eraldi alamsüsteemid, millel oli sisseehitatud liiasus. Varased digitaalarvutid, nagu näiteks Apollo juhisarvutis kasutatavad arvutid, näitasid, et pooljuhid võivad võimaldada autonoomset navigeerimist, kuid arvutusvarud olid minimaalsed ja tõrketaluvus oli ülimalt oluline. 1990ndatel ja 2000ndate alguses võimaldasid kiirguskindlad mikroprotsessorid ja standardiseeritud kosmoseaparaadi andmesiinid, nagu MIL-STD-1553 ja SpaceWire, modulaarsemat digitaalset arhitektuuri. Satelliidid võtsid kasutusele struktureeritud alamsüsteemid hoiaku määramiseks ja juhtimiseks, pardal andmete töötlemiseks, kasuliku koormuse töötlemiseks ja võimsuse reguleerimiseks. Sellised missioonid nagu Hubble'i kosmoseteleskoop ja süvakosmose platvormid, nagu Mars Reconnaissance Orbiter, hõlmasid navigeerimiseks, instrumentide juhtimiseks ja rikete haldamiseks üha keerukamat pardatöötlust. See etapp meenutab hajutatud ECU ajastut autotööstuses, kus iga domeeni juhiti digitaalselt, kuid need olid omavahel ühendatud deterministlike siinide kaudu. Kaasaegsel ajastul on pooljuhtide võimalused kosmosesüsteemides dramaatiliselt laienenud. Suure läbilaskevõimega sidesatelliidid, FPGA-põhised ümberkonfigureeritavad kasulikud koormused, täiustatud tahkis-toitekontrollerid, elektrilised tõukejõusüsteemid ja autonoomsed rikete tuvastamise algoritmid määravad praeguse arhitektuuri. Ärilised konstellatsioonid, mille on välja töötanud sellised ettevõtted nagu SpaceX, on kasutusele võtnud vertikaalselt integreeritud avioonikavirnad ja rohkem tarkvaraga määratletud kosmoselaevade platvorme. Erinevalt autotööstusest seab pooljuhtide disain ruumis siiski kulude optimeerimise asemel esikohale kiirguse kõvenemise, koondamise ja pikaajalise töökindluse. Üldine trajektoor peegeldab autotööstuse diagrammi kihilist kasvu: mõõteriistade digiteerimisest suletud ahela juhtimiseni, võrku ühendatud alamsüsteemideni ja nüüd üha autonoomsemate, tarkvaraga määratletud kosmoseplatvormide suunas.

Mere- ja kosmosevaldkonnas – nagu ka autotööstuses – arenes pooljuhtide kasutuselevõtt jälgimisest juhtimiseni, isoleeritud alamsüsteemidest võrguarhitektuurini ning mehaanilisest domineerimisest elektriliselt ja arvutuslikult vahendatud platvormideni. Arhitektuursed plokid erinevad nimetamise poolest (tõukejõud, navigatsioon, asendikontroll, jõu konditsioneerimine), kuid struktuurilt esindavad nad sama ajaloolist kihistumist, mis on nähtav autofiguuril.

Kuna pooljuhtide sisaldus sõidukites suurenes, arenesid autotööstuse ohutusprotokollid mitteametlikest inseneritavadest hästi struktureeritud elutsüklipõhisteks juhtimisraamistikeks, mis ulatuvad nüüd kuni räni IP ja AI käitumiseni. 1980. ja 1990. aastatel, kui elektroonilised süsteemid, nagu ABS ja turvapatjade kontrollerid, esmakordselt laialt levima hakkasid, hakati ohutuse tagamisega tegelema suures osas ettevõttespetsiifiliste protsesside kaudu. OEM-id ja Tier-1 tarnijad toetusid sisemistele FMEA meetoditele, koondamistavadele ja mõnel juhul ka lennunduse juhiste kohandamisele, nagu DO-178 kontseptsioonid. Puudus ühtne autode elektrooniline ohutusstandard, isegi kui sõidukid läksid üle isoleeritud ECU-delt üha enam võrku ühendatud süsteemidele.

Esimene suurem ametlik autoelektroonikat mõjutanud raamistik oli IEC 61508, mis avaldati 1998. aastal. IEC 61508 tutvustas ohutuse terviklikkuse taset (SIL), elutsükli ohutusjuhtimist, tõenäolisi riistvara rikkemõõdikuid ja struktureeritud ohutusjuhtumi kontseptsiooni. Kuid see oli mõeldud tööstuslike programmeeritavate elektrooniliste süsteemide üldiseks standardiks. Kuna sõidukite arhitektuurid muutusid hajutatumaks ja pooljuhtide keerukus kasvas – liikudes lihtsatelt mikrokontrolleritelt CAN-i kaudu ühendatud mitme domeeni ECU-dele –, mõistsid autotööstuse sidusrühmad vajadust sektorispetsiifilise kohandamise järele.

See viis standardi ISO 26262 avaldamiseni 2011. aastal. ISO 26262 oli muutlik samm, mis võttis kasutusele mootorsõidukite ohutuse terviklikkuse tasemed (ASIL A–D), ametliku ohuanalüüsi ja riskianalüüsi (HARA), riistvaraarhitektuurimõõdikud, nagu ühepunktiline veamõõdik (SPFM), ranged nõuded kogu tõrke meetrikale (SPFM) ja kogu laarendus. elutsükkel. Oluline on see, et ISO 26262 mõjutas otseselt pooljuhtide disaini. Ränimüüjad hakkasid süsteemiintegraatorite toetamiseks pakkuma ASIL-valmidusega mikrokontrollereid, millel on lockstep CPU südamikud, ECC-kaitstud mälu, valvekoera taimerid ja dokumenteeritud FMEDA andmed. Ohutus liikus sõidukitasemel valideerimisest kiibiarhitektuuri ja arendusprotsessidesse integreerituks.

Ohutusprotokollide ajalooline areng õhusõidukites peegeldab kasvavat sõltuvust pooljuhtidest avioonikas, lennujuhtimises ja missioonikriitilises tarkvaras. Erinevalt autotööstusest võttis lennundus struktureeritud ohutusjuhtimise kasutusele väga varakult, kuna elektroonika sisenes otse ohutuse seisukohalt kriitilistesse juhtimisaasadesse, nagu autopiloot ja juhtmevaba juht. Samuti viis kohandatud ASIC-ide ja programmeeritavate loogikaseadmete üha suurem integreerimine avioonikasse DO-254 avaldamiseni 2000. aastal. DO-254 vormistas õhus leviva elektroonilise riistvara, sealhulgas FPGA-de ja keerukate mikroskeemide projekteerimise kinnituse. See nõudis dokumenteeritud arendustsükleid, kontrollimise rangust, mis oli proportsionaalne riistvara disaini kindluse tasemetega, ja jälgitavust nõuetest rakendamiseni.

Kui digitaalsed navigatsiooni- ja tõukejõu juhtimissüsteemid 1980. ja 1990. aastatel laienesid, kandus meresüsteemide puhul regulatiivne tähelepanu elektrooniliste süsteemide töökindlusele ja liiasusele. Klassifikatsiooniühingud nagu DNV, Lloyd's Register ja American Bureau of Shipping töötasid välja laevade elektri- ja juhtimissüsteemide reeglid. Need reeglid nõuavad roolimise ja tõukejõu juhtimise koondamist, dünaamiliste positsioneerimissüsteemide tõrketaluvust ning elektroonika keskkonnaalast kvalifikatsiooni vibratsiooni, niiskuse ja soolaga kokkupuute osas. Ülemaailmse merehäda- ja ohutussüsteemi (GMDSS) kasutuselevõtt 1990. aastatel tähistas suurt digitaalset verstaposti. Satelliitside, automatiseeritud hädasignaalide edastamine ja integreeritud sillasüsteemid suurendasid pooljuhtide tihedust. Kuna laevad võtsid kasutusele integreeritud sillasüsteemid (IBS) ja integreeritud platvormihaldussüsteemid (IPMS), hakkasid klassifikatsiooniühingud välja andma ametlikumaid juhiseid tarkvara kvaliteedi, tõrkerežiimi analüüsi ja kübervastupidavuse kohta. Siiski jäi merejuhtimine suures osas ettekirjutavaks ja tulemuspõhiseks, mitte protsessi tagamisel põhinevaks.

Lõpuks arenesid kosmoseohutuse ja elektroonika tagamine algusest peale äärmuslike usaldusväärsuse piirangute tõttu remondi võimatuse ja missiooni ebaõnnestumise kõrgete kulude tõttu. Varased kosmoseprogrammid töötasid agentuurispetsiifiliste töökindluse ja koondamise doktriinide, mitte ametlike tarkvarastandardite alusel. NASA ja kaitseagentuurid rõhutasid kiirguse kõvenemist, riistvaralist koondamist ja konservatiivseid disainimarginaale. Kosmoselaevad on algusest peale kasutanud rikete tuvastamise, isoleerimise ja taastamise (FDIR) tehnikaid.

Üldiselt on ohutusstandardid jälginud elektrooniliste süsteemide tarbimise suurenemist.

Nagu 2. peatükis arutatud, töötavad kõik need süsteemid juhtimisstruktuuri all, kus valideerimis- ja kontrollitehnoloogia seob tehnilise maailma juhtimisstruktuuriga. Nende protsesside võimaldamisel on kriitilise tähtsusega elektroonilise disaini automatiseerimise (EDA) valdkond. EDA viitab tarkvaratööriistadele ja töövoogudele, mida kasutatakse pooljuhtseadmete ja elektroonikasüsteemide projekteerimiseks, kontrollimiseks ja tootmiseks ettevalmistamiseks. Kiibi tasemel algab voog tavaliselt süsteemi arhitektuuri ja spetsifikatsioonidega, millele järgneb eraldi, kuid koonduv analoog- ja digitaalkujundusvoog. Digitaalses disainis kirjeldavad insenerid funktsionaalsust riistvara kirjelduskeelte (HDL) (nt Verilog või VHDL) abil, simuleerivad funktsionaalse korrektsuse tagamiseks, sünteesivad loogikaväravateks ja teostavad füüsilise paigutuse loomiseks koha ja marsruudi. Sellele järgneb staatiline ajastuse analüüs, võimsuse analüüs, signaali terviklikkuse kontroll ja üha enam formaalne kontrollimine ja funktsionaalse ohutuse valideerimine (nt ISO 26262 kontekstis). Analoog-/segasignaali kujunduses on voog seadme- ja paigutuskesksem: skemaatiline püüdmine, SPICE-taseme simulatsioon (nurk, Monte Carlo, müra, mittevastavus), paigutus hoolika parasiitide eraldamisega ja iteratiivne kontrollimine (LVS/DRC). Täiustatud sõlmedes häguneb piir analoog- ja digitaalse vahel segasignaaliga SoC-des, mis nõuab tihedat koossimuleerimist ja domeenidevahelist kontrolli.

Kui räni disain on valmis, laieneb voog paketikujundusele, mis on muutunud arenenud sõlmede ja heterogeensete integratsioonikontekstides (nt kiibid, 2.5D/3D integratsioon) üha kriitilisemaks. Pakendatud EDA tööriistad modelleerivad signaali terviklikkust, võimsuse terviklikkust, termilist käitumist ja mehaanilist pinget substraatide, vahekihtide ja konaruste vahel. Pakend ei ole enam passiivne kandja; see on stantsi elektriline pikendus, mis mõjutab ajastuse sulgemist, toiteedastust ja kiireid liideseid (nt UCIe, HBM). Lõpuks integreerivad plaadikujundustööriistad PCB tasemel skemaatilist püüdmist, komponentide paigutust, marsruutimist ja mitme füüsikalise analüüsi (signaali terviklikkus, EMI/EMC, termiline) analüüsi. Kiired digitaalsed süsteemid nõuavad impedantsi juhtimise ja ajastuse marginaalide säilitamiseks kiibi sisendi/väljundi, paketi evakuatsioonimarsruutimise ja PCB virnastamise ühisprojekteerimist. Kaasaegsed EDA töövood rõhutavad üha enam domeenidevahelist ühisdisaini – alates transistorist kuni plaadini –, sest jõudlus, töökindlus ja ohutus on kogu elektroonilise süsteemi, mitte ainult räni esilekerkivad omadused.

Elektroonilise disaini automatiseerimise (EDA) tööstus on väga kontsentreeritud ning domineerivad ülemaailmsed müüjad kontrollivad enamikku täiustatud pooljuhtide projekteerimise töövoogudest. Synopsys, Cadence Design Systems ja Siemens EDA (endine Mentor Graphics) pakuvad ühiselt täielikke tööriistaahelaid, mis hõlmavad digitaalset juurutamist, analoog-/segasignaali disaini, verifitseerimist, IP-integratsiooni, pakkimist, PCB-de disaini ja mitme füüsikalist analüüsi. Synopsys on eriti tugev digitaalsünteesi, verifitseerimise ja IP valdkonnas; Cadence'il on suured võimalused kohandatud/analoogdisaini ja süsteemianalüüsi alal; ja Siemens EDA on hästi tuntud PCB projekteerimise, kontrollimise ja tootmise integreerimise poolest. Lisaks kolmele suurele mängivad sellised ettevõtted nagu Ansys olulist rolli sisselogimisfüüsikas (signaali terviklikkus, toite terviklikkus, soojus-, elektromagnetilisus), samas kui uued mängijad keskenduvad tehisintellektiga toetatud disaini automatiseerimisele ja spetsiaalsetele valdkondadele, nagu fotoonika või kiibi integreerimine. Kõrge tehniline keerukus, sügav valukodade integreerimine (nt TSMC, Samsungi, Inteliga) ning arenenud sõlmedes nõutavad ulatuslikud teadus- ja arendusinvesteeringud loovad turule sisenemisel olulisi tõkkeid, tugevdades tööstuse oligopoolset struktuuri.

Elektroonika füüsiline testimine hõlmab vahvlisondi, pakendatud seadme kvalifikatsiooni, plaaditaseme valideerimist ja täielikku süsteemi stressitesti ning seda toetab kontsentreeritud globaalsete tarnijate komplekt. Pooljuhtide tootmistestis domineerivad automatiseeritud testimisseadmete (ATE) liidrid, nagu Teradyne ja Advantest, suure mahuga loogika-, mälu- ja SoC-testides, võimaldades parameetrilist iseloomustamist, funktsionaalset kontrolli ja kiiruse piiramist vahvli- ja lõpptestis. Töökindluse ja keskkonnakoormuse (HTOL, temperatuuritsükli, vibratsiooni ja niiskuse) tagamiseks kasutatakse kambrite pakkujaid, nagu ESPEC ja Thermotron, laialdaselt auto- ja kosmosetööstuse kvalifikatsioonivoogudes. Elektrilised mõõtmised ja vastavuse valideerimine seadme ja plaadi tasemel sõltuvad suuresti Keysight Technologiesi ja Rohde & Schwarzi mõõteriistadest, eriti kiirete liideste ja RF-süsteemide puhul. Ülevaatus ja tõrkeanalüüs, mis on täiustatud pakendamise ja heterogeense integratsiooni jaoks ülioluline, kasutavad sageli Nordsoni röntgen- ja akustilise mikroskoopia süsteeme, aga ka Thermo Fisher Scientificu materjalianalüüsi platvorme. Üheskoos toetavad need müüjad füüsilist valideerimiskihti, mis täiendab disaini kontrollimist, tagades jõudluse, töökindluse ja ohutuse enne missioonikriitilistes rakendustes kasutuselevõttu.

Joonis 1

Teine valitsemise oluline aspekt on jagatud ressursside haldamine. Mehaanikamaailma puhul tähendab see seadusi ja eeskirju transpordis seoses liiklusseaduste ja liiklustaristuga. Elektroonikas tähendab see jagatud sagedusspektri ja terviseohutuse küsimuste haldamist. Ühiskasutuseks oli USA-s esmaseks õiguslikuks aluseks 1934. aastal vastu võetud kommunikatsiooniseadus, millega loodi regulaator (Federal Communications Commission [FCC]). FCC haldab raadiospektrit (joonis 1) mitmete regulatiivsete ja tehniliste meetmete abil, et tagada selle tõhus ja häiretevaba kasutamine. See eraldab konkreetsed sagedusalad erinevatele teenustele, nagu ringhääling, mobiilside, satelliit, avalik turvalisus ja amatöörraadio, lähtudes riiklikest vajadustest ja rahvusvahelistest lepingutest. FCC väljastab litsentse kommerts- ja mitteärilistele kasutajatele, kehtestades võimsuspiirangute, levialade ja töötingimuste tingimused. Samuti korraldab see spektroksjoneid, et määrata sagedusi kommertskasutuseks (nt 5G), reserveerides samal ajal osa avalike teenuste jaoks ja litsentseerimata kasutusteks, nagu WiFi.

Lisaks jõustab FCC eeskirjad kahjulike häirete vältimiseks, koordineerib spektri jagamise ja ümberjagamise jõupingutusi ning juhib selliseid algatusi nagu dünaamiline juurdepääs spektrile ja sagedusribade ümberjaotamine, et kohaneda muutuvate tehnoloogiliste nõudmistega. Nende standardite jõustamiseks nõuab FCC, et paljud seadmed läbiksid testimise ja sertifitseerimise, enne kui neid saab Ameerika Ühendriikides turustada või müüa. Seda protsessi viivad läbi FCC tunnustatud katselaborid, mida tuntakse akrediteeritud vastavushindamisasutustena (CAB), mis hindavad tooteid muu hulgas kohaldatavate 15. osa või 18. osa eeskirjade järgi. Sertifitseeritud seadmed peavad vastama emissiooni, häirekindluse ja erineeldumiskiiruse (SAR) piirangutele, kui need on kohaldatavad. Kui toode läbib testimise, esitab labor aruande telekommunikatsiooni sertifitseerimisasutusele (TCB), mis väljastab FCC ID ja annab loa toote müügiks. Need laborid mängivad olulist rolli vastavuse tagamisel, innovatsiooni toetamisel, säilitades samal ajal spektri terviklikkuse ja avaliku turvalisuse.

FCC osad 15 ja 18 erinevad peamiselt reguleeritava raadiosagedusliku (RF) kiirguse tüübi ja eesmärgi poolest. 15. osa reguleerib seadmeid, mis tahtlikult või tahtmatult kiirgavad raadiosageduslikku energiat sidepidamiseks, nagu Wi-Fi ruuterid, Bluetoothi ​​seadmed ja arvutid. Need seadmed ei tohi põhjustada kahjulikke häireid ja peavad aktsepteerima litsentsitud kasutajate häireid. Seevastu 18. osa reguleerib tööstuslikke, teaduslikke ja meditsiinilisi (ISM) seadmeid, mis kiirgavad raadiosageduslikku energiat mitte suhtlemiseks, vaid füüsiliste funktsioonide (nt kuumutamine, keevitamine või meditsiiniline ravi) täitmiseks – näiteks mikrolaineahjud ja RF-diatermiamasinad. Kuigi mõlemad osad piiravad elektromagnetilisi häireid, töötavad 15. osa seadmed rangemate emissioonipiirangutega, kuna need on sidesagedusalade läheduses, samas kui osa 18 seadmetel on määratud ISM-i sagedusaladel lubatud suurem emissioon. Lisaks jälgivad 18. osa seadmete tervise- ja ohutusnõudeid tavaliselt teised agentuurid, nagu FDA või OSHA, samas kui FCC keskendub häirete leevendamisele.

Joonis 2

Elektromagnetilise testimise võtmeinstrument on kajavaba kamber (joonis 2). Kajavaba kamber on spetsiaalne heli- ja raadiolaineid neelav korpus, mis on loodud peegelduste ja väliste häireteta keskkonna loomiseks. Selle seinad, lagi ja põrand on tavaliselt vooderdatud kiilukujuliste vaht- või ferriitplaatidega, mis neelavad sõltuvalt rakendusest elektromagnetilisi või akustilisi laineid. Raadiosageduse (RF) testimiseks on kamber valmistatud juhtivatest materjalidest (nt teras või vask), et moodustada Faraday puur, mis isoleerib selle välistest RF-signaalidest. Akustilistes kambrites kõrvaldab heli neelav vaht kaja ja simuleerib vabavälja tingimusi. Kajakambrid on kriitilise tähtsusega sellistes tööstusharudes nagu telekommunikatsioon, kaitse, lennundus ja olmeelektroonika, kus neid kasutatakse antenni jõudluse, elektromagnetilise ühilduvuse (EMC), emissioonide vastavuse, radarisüsteemide või heliseadmete testimiseks kõrgelt kontrollitud ja korratavates tingimustes. Kamber tagab, et testmõõtmised kajastavad ainult testitava seadme (DUT) omadusi ilma keskkonnamõjudeta.

Kogu riistvara kõigis huvipakkuvates valdkondades (maa-, õhu-, mere-, kosmoses) peab vastama FCC standarditele ning inimkontaktide korral FDA tervise- ja ohutusstandarditele!

Lõpuks, testimislaborid ja teenindusorganisatsioonid mängivad olulist rolli elektroonika sertifitseerimisel vastavalt riiklikele ja rahvusvahelistele standarditele, eelkõige ohutuse, elektromagnetilise ühilduvuse (EMC), keskkonnakindluse ja töökindluse osas. Ülemaailmsed vastavushindamisfirmad, nagu UL Solutions, TÜV SÜD, Intertek ja Bureau Veritas, pakuvad kolmandate osapoolte testimist ja sertifitseerimist sellistele standarditele nagu IEC 61000 (EMC), IEC 62368 (tooteohutus), ISO 26262 (autode funktsionaalne ohutus), DO-160 (aerospace-testing (keskkonnatingimused)). Need organisatsioonid haldavad akrediteeritud laboreid (sageli ISO/IEC 17025 sertifikaadiga), mis viivad läbi emissioonide ja häirekindluse testimist, termotsüklit, vibratsiooni, sissepääsukaitset (IP) ja ohutushinnanguid, mis on vajalikud CE-märgistuse, FCC volituse, autode AEC kvalifikatsiooni ja muude regulatiivsete kinnituste jaoks. Kõrgelt reguleeritud sektorites – auto-, lennundus-, meditsiini- ja tööstussektoris – pakub sõltumatu labori valideerimine mitte ainult vastavustõendeid, vaid ka vastutuse leevendamist ja turulepääsu tagamist, muutes standarditel põhineva testimise oluliseks sillaks inseneri valideerimise ja kommertskasutuse vahel.

Tootearenduses keskendutakse esmalt funktsionaalsusele ja diferentseeritud väärtusele. Nagu juhtimisosades arutatud, on järgmine etapp tagada, et toode vastaks ohutuse ja ühiskasutusega seotud asjakohastele regulatiivsetele raamistikele. Viimane etapp ja võib-olla kõige olulisem etapp on toote järjepidev tarnimine ja toetamine turul. Toote järjepidevaks tarnimiseks tuleb juhtida tarneahelat, mis juhib toote edasist tarnimist. Lisaks toimub kliendi tootega suhtlemisel vastupidine voog, mis hõlmab parandamist, diagnostikat ja enamikus olukordades ohutut kõrvaldamist.

Enamiku toodete puhul on mehaaniliste komponentide tarneahelal, hooldusel ja kalibreerimisel hästi välja kujunenud rikkalik ajalugu. Nagu arutatud, on lähiajalugu näinud pooljuhtide suurt infusiooni. Supply Chain Management (SCM) viitab hanke-, tootmis-, logistika- ja turustusprotsesside strateegilisele koordineerimisele, et tagada materjalide ja süsteemide õigeaegne ja kulutõhus tarnimine [61]. Tarneahela nõukogu (SCC) välja töötatud SCOR-mudel on tarneahelate kavandamise ja hindamise laialdaselt kasutatav raamistik [62].

Igas etapis on integreeritud digitaalsed tööriistad ja reaalajas analüütika, et tagada tarnekindlus ja jõudluse jälgitavus.

Lean tarneahela juhtimine

Lean SCM keskendub raiskamise (aeg, materjal, kulud) minimeerimisele kogu ahela ulatuses, maksimeerides samal ajal kliendi jaoks väärtust [63]. Autonoomse süsteemi tootmisel hõlmavad Lean meetodid:

• Kanbani ajastamine komponentide õigeks tarnimiseks.
• Korduvate integratsioonietappide standardiseeritud tööprotseduurid.
• Testi tagasiside põhjal pidev täiustamine (Kaizen).

Lean mõtlemine parandab paindlikkust kiiretele tehnoloogilistele muutustele ja komponentide vananemisele reageerimisel.

Agiilsed ja digitaalsed tarneahelad

Hiljutised arengud on kasutusele võtnud Agile Supply Chain kontseptsioonid, mis rõhutavad kohanemisvõimet, nähtavust ja kiiret ümberkonfigureerimist [64]. Digital Supply Chain (DSC) tehnoloogiad, näiteks:

• IoT-põhine varade jälgimine
• Blockchain-toega jälgitavus
• AI-põhine nõudluse prognoosimine
• Toitevõrkude digitaalsed kaksikud

Riskijuhtimine ja vastupidavuse suurendamine

Tarneahela riskijuhtimine (SCRM) autonoomsetes süsteemides hõlmab häirete ennetavat tuvastamist ja leevendamist:

• Tarnijate mitmekesistamine: kriitiliste komponentide jaoks on mitu kvalifitseeritud tarnijat.
• Regionaliseerimine: kohalike tootmiskeskuste arendamine.
• Varude puhvrid: kõrge riskiga osade ohutusvarude säilitamine.
• Stsenaariumi simulatsioon: geopoliitilistele või pandeemiaga seotud sündmustele reageerimise modelleerimine.

AI-põhised SCRM-i tööriistad (nt Resilinc, Everstream) jälgivad nüüd tarnijate tervist ja logistika viivitusi reaalajas.

Tarneahela juhtimise väljakutsed

Keskkonna- ja eetilised piirangud Autonoomiaga seotud tehnoloogiate tarneahelad sõltuvad sageli andurites ja akudes kasutatavad materjalid, nagu liitium, koobalt ja haruldased muldmetallid. Eetiline hankimine, jätkusuutlikkus ja süsinikuaruandlus on nüüd tarneahela kriitilised mõõtmed [53].

Näide: eeskirjad, mille eesmärk on takistada mineraalide hankimist konfliktidest mõjutatud piirkondadest (eriti Kesk-Aafrika osades), keskenduvad konflikti mineraalidele, nagu tina, volfram, tantaal ja kuld (3TG). Ameerika Ühendriikides nõuab Dodd-Franki Wall Streeti reformi- ja tarbijakaitseseaduse jaotis 1502, et börsil noteeritud ettevõtted viiksid läbi hoolsuskontrolli ja avalikustaksid, kas need mineraalid pärinevad Kongo Demokraatlikust Vabariigist või sellega piirnevatest riikidest, samas kui Euroopa Liit jõustab sarnase tarneahela hoolsuskohustuse EL Conflict Miner määruse alusel. Need raamistikud sunnivad ettevõtteid jälgima tarneahelaid, rakendama riskide maandamise protsesse, mis on kooskõlas OECD juhistega, ja avalikult aru andma hankimistavadest, et vähendada relvastatud rühmituste rahastamist.

Tarneahela küberjulgeoleku tõus Kuna riist- ja tarkvara on omavahel seotud, on tarneahela küberjulgeolek muutunud kriitiliseks riskivaldkonnaks. Ohustatud püsivara või kloonitud mikrokontrollerid võivad tekitada turvaauke sügaval süsteemi riistvara usaldusjuures [54]. Nende ohtude leevendamiseks rakendatakse turvaraamistikke, nagu NIST SP 800-161, ISO/IEC 27036 ja küberturvalisuse küpsuse mudeli sertifikaat (CMMC).

Maasüsteemid:

Maapealsete süsteemide osas on autotööstus aja jooksul arenenud väga optimeeritud tarnijate struktuuriks koos originaalseadmete tootjatega (OEM), mitmetasandiliste tarnijate seeriaga (tabel 1).

Tabel 1. Lühike elutsükkel võrreldes LLC toodetega.

Lisaks, sarnaselt USA kaitseministeeriumiga, nõuavad autotööstuse ettevõtted traditsiooniliselt autotööstuse sertifikaadiga kiipe. Autotööstuse komponendid nõuavad ranget vastavust. (Passiivsed komponendid vajavad AEC Q200, ASILI/ISO 26262 klass B, IATF 16949 kvalifikatsiooni, samas kui aktiivsed komponendid, sealhulgas autokiibid, peaksid vastama standarditele AEC Q100, ASILI/ISO 26262 klass B, IATF 16949).

Õhus (lennundus)

Lennunduses arenes tarneahel regulatiivse sertifitseerimisasutuse ja süsteemiohutuse ümber ammu enne seda, kui kulude optimeerimine sai domineerivaks. Kuna lennukisüsteemid läksid üle analoog- ja tarkvaramahukatele arhitektuuridele, sundisid sellised standardid nagu DO-178 (tarkvara), DO-254 (riistvara) ja ARP4754 (süsteemi arendus) struktuurimuutust: 1. taseme tarnijad lõid sügavalt sisse sertifitseerimisartefakti, mitte ainult riistvara tarnimise. Sellised ettevõtted nagu Honeywell ja Raytheon Technologies (Collins Aerospace) ei tarni ainult komponente; nad on FAA/EASA nõutud kontrollitõendite, ohutusanalüüside ja jälgitavusmaatriksite kaasomanikud. See loob tihedalt seotud, pika tsükliga ökosüsteemi, kus sellised esindustootjad nagu Boeing toimivad süsteemide integreerijatena ning tarnijate vahetamine on sertifitseerimise taassertifitseerimise koormuse tõttu äärmiselt kulukas. Seetõttu arenes õhusõiduki mudel kõrgete tõketega, riskijagamise ja kindlustunde keskseks hierarhiaks.

Meremees

Meresõidukite tarneahelad on ajalooliselt keskendunud laevatehastele ja mehaanilistele süsteemidele, mille tasandite struktuur oli vähem formaalne kui kosmoselennundus. Järelevalve tuli pigem klassifikatsiooniühingutelt (nt DNV, ABS), mitte tsentraliseeritud regulaatoritelt, ja laevad olid sageli pooleldi kohandatud ehitusega. Kuna digitaalne navigatsioon, dünaamiline positsioneerimine ja nüüdne autonoomia on aga suurendanud süsteemi keerukust, on Tier-1 meretehnoloogia ettevõtted, nagu Kongsberg Gruppen ja Wärtsilä, liikunud lähemale lennundus-stiilis süsteemiintegratsiooni rollidele. Erinevalt autotööstuse mastaabipõhistest tasemetest arenesid meretasandid projekti integreerimise ning lipuriigi ja klassi nõuete järgimise ümber. Praegune autonoomia tõuge kiirendab üleminekut tarkvarakesksetele tarneahelatele, kuid tootmismaht on endiselt madal ja kohandamine kõrge, hoides merenduse struktuuriliselt killustatumalt kui kosmosesektorit.

Ruum

Kosmosetööstus sai alguse vertikaalselt integreeritud, valitsuse juhitud ökosüsteemist, kus domineerisid sellised esindusettevõtted nagu Lockheed Martin ja Boeing ning mille alusel sõlmiti kululisahinnaga lepingud selliste agentuuridega nagu NASA ja DoD. Usaldusväärsus ja missiooni tagamine, mitte kuluefektiivsus, määratletud tarnijasuhted ja spetsialiseerunud kiirguskindlad komponentide müüjad moodustasid niši Tier-2/3 kihid. Viimasel kümnendil on sellised ettevõtted nagu SpaceX aga uuesti kasutusele võtnud vertikaalse integratsiooni, et tihendada arendustsükleid ja kontrollida riske tõukejõu, avioonika ja käivitusoperatsioonide vahel. Tulemuseks on kaheharuline tarneahel: üks kõrge kindlusega riikliku turvalisuse ahel traditsiooniliste tasandistruktuuridega ja üks äriliselt agar NewSpace kett, mis ühendab COTS-i komponendid vertikaalselt integreeritud algarvudega. Sertifitseerimine ja missioonirisk, mitte mahuökonoomika, jäävad domineerivateks struktuurijõududeks.

Pooljuhtide ökonoomika:

Pooljuhtseadme ehitamise maksumuses domineerivad kolm vastastikku mõjuvat tegurit: disain (NRE), vahvlite valmistamine ja maht, mis kõik on tihedalt seotud litograafiasõlmega. Täiustatud sõlmedes (nt 5 nm, 3 nm) võivad ühekordsete inseneritööde (NRE) kulud maskide komplektide, EDA keerukuse, kontrollimise ja IP-integratsiooni tõttu ületada sadu miljoneid dollareid, samas kui vahvlite kulud tõusevad järsult EUV litograafia, rangema protsessikontrolli ja madalama algsaagi tõttu. Selle tulemusena on tipptasemel sõlmedel majanduslikult mõttekas ainult väga suurte tootmismahtude korral, kus fikseeritud disaini- ja maskikulusid saab amortiseerida miljonite ühikute kaupa; vastasel juhul muutub stantsi hind üle jõu käivaks. Vastupidi, küpsetel sõlmedel (nt 28 nm, 40 nm, 65 nm) on palju madalamad maskide ja vahvlite kulud, stabiilne saagikus ja lühemad arendustsüklid, mis muudab need majanduslikult atraktiivseks autotööstuses, tööstuses ja segasignaaliga rakendustes, kus jõudlustihedus on vähem kriitiline ja tootmismahud võivad olla pigem mõõdukad kui suured.

Tootmismahud erinevad täiustatud ja küpsete pooljuhtsõlmede vahel märkimisväärselt ökonoomsuse ja rakenduste kombinatsiooni tõttu. Täiustatud sõlmed (nt 5 nm, 3 nm) on tavaliselt õigustatud ainult väga suure mahuga turgudel, nagu lipulaevad nutitelefonid, andmekeskuste CPU-d/GPU-d ja tehisintellekti kiirendid, kus kümned miljonid või isegi sajad miljonid ühikud võivad amortiseerida tohutuid disaini- ja maskeerimiskulusid. Seevastu küpsed sõlmed (nt 28 nm, 40 nm, 65 nm ja rohkem) toetavad palju laiemat toodete mitmekesisust – autode MCU-sid, toitehalduse IC-sid, analoog-, RF- ja tööstuskontrollereid –, mida toodetakse sageli mõõdukates, kuid pikaealistes kogustes paljude aastate jooksul. Kuigi üksikud küpsete sõlmede programmid võivad aastas tarnida vähem ühikuid kui tipptasemel mobiilprotsessorid, on rakenduste kogumaht äärmiselt suur ja aja jooksul stabiilsem, mis selgitab, miks küpsete sõlmede võimsus on endiselt strateegiliselt oluline, hoolimata tööstuse keskendumisest tipptasemel skaleerimisele.

Tänapäeval on autotööstuse mahud piisavad unikaalsete pooljuhtide disainide juhtimiseks küpsetel sõlmedel, kuid üldiselt peavad kõik küberfüüsikalised valdkonnad kasutama standardseid osi.

Sisseehitatud protokollid (sh domeenispetsiifilised), andurid, täiturmehhanismid, pika- ja lähiside ning komponendid, navigeerimine ja positsioneerimine.

Riistvara vaatenurgast on funktsionaalsuse suur hüpe andurite kasutuselevõtt, maailma tõlgendamise arvutamine ja seejärel autonoomia tagamiseks käivitamine.

Maapind.

Graafika illustreerib autonoomsete sõidukite jaoks tavaliselt vajalikku mitmekihilist andurite pinu, mis ühendab täiendavaid andurimeetodeid, et saavutada koondamine, ulatuse katvus ja keskkonnakindlus. Pikamaaradar ja ettepoole suunatud kaamerad võimaldavad kõige pikematel vahemaadel sõidukite, takistuste ja tee geomeetria varajase tuvastamise. Pikamaaradar töötab usaldusväärselt vihmas, udus ja vähese valgusega tingimustes, mõõtes Doppleri nihete abil objekti kaugust ja suhtelist kiirust. Kaamerad seevastu pakuvad kõrge eraldusvõimega semantilist teavet – sõiduraja märgistused, liiklusmärgid, foorid ja objektide klassifikatsioon (auto vs jalakäija vs jalgrattur). Kuigi kaamerad on klassifikatsioonis suurepärased, on nad valgustuse ja ilmastiku suhtes tundlikumad, mistõttu on radari liiasus hädavajalik ohutuse seisukohalt oluliste funktsioonide jaoks, nagu adaptiivne püsikiiruse hoidja ja maanteel autopiloot.

Sõidukit ümbritsevas keskmises ja lühikeses tegevusulatuses suurendavad lühimaaradar ja LiDAR (valguse tuvastamine ja ulatus) olukorrateadlikkust. Lühimaaradar jälgib külgnevaid sõiduradasid, pimealasid ja ristliiklust. LiDAR pakub ülitäpseid 3D-punktipilvi, mis võimaldab täpselt kaardistada objekti kontuure, vaba ruumi ja teepiire. LiDAR on eriti väärtuslik täpseks lokaliseerimiseks ja takistuste tuvastamiseks linnakeskkonnas. Üheskoos toetavad need andurid selliseid funktsioone nagu sõiduraja vahetamine, ühendamine, ristmike juhtimine ja takistuste vältimine. Sõidukile väga lähedal pakuvad ultraheliandurid ja lähiväljakaamerad madala kiirusega manööverdamist. Ultraheliandurid tuvastavad äärekivid, parkimispiirded ja lähedalasuvad objektid mõne meetri raadiuses, võimaldades parkimisabi ja tihedat manööverdamist. Ruumilise vaatega kaamerasüsteemid toetavad 360-kraadist taju, mis tagab väikese kiiruse autonoomia ja automatiseeritud parkimise. Kõiki neid andurikihte katab sõiduki-kõik (V2X) või traadita side, mis laiendab taju vaateväljast kaugemale, vahetades teavet infrastruktuuri ja muude sõidukitega. Ühiselt tugineb autonoomsuspakett andurite sulandumisele, mis ühendab radari töökindluse, kaamera semantika, LiDAR-i täpsuse ja ultraheli läheduse, et luua usaldusväärne keskkonnamudel, mis sobib ohutuskriitiliste otsuste tegemiseks.

Arvutamise osas vajavad autonoomsed maapealsed sõidukid suure läbilaskevõimega madala latentsusega servade arvutusi, et töödelda multimodaalseid andurivooge (kaamera, radar, LiDAR, ultraheli) reaalajas. Arvutuspinn integreerib tavaliselt heterogeenseid arhitektuure – CPU-sid juhtimisloogika jaoks, GPU-sid/NPU-sid sügava närvivõrgu järelduste tegemiseks ja spetsiaalseid ohutusmikrokontrollereid, mis töötavad ISO 26262-ga ühilduva tarkvaraga. Need platvormid peavad kümnete millisekundite jooksul hakkama saama tajumisega (objekti tuvastamine, segmenteerimine), lokaliseerimisega (SLAM, andurite liitmine), ennustamisega (trajektoori prognoosimine) ja planeerimisega (tee optimeerimine) ja seda kõike autode soojus- ja võimsuspiirangute korral. Funktsionaalsete ohutuseesmärkide saavutamiseks kasutatakse sageli üleliigseid arvutusteid ja lockstep protsessoreid, kusjuures õhu kaudu värskendamise võimalus võimaldab pidevat täiustamist.

Õhus.

Õhus töötavad autonoomsed süsteemid põhinevad inertsiaalsete, õhuandmete, navigatsiooni- ja väliste tajuandurite liitmisel, et töötada 3D-s, kiires ja ohutuskriitilises keskkonnas. Põhiandurite hulka kuuluvad inertsiaalsed mõõtühikud (IMU) ja õhuandmesüsteemid (Pitot-torud, lööginurga labad) asendi ja aerodünaamilise oleku hindamiseks; mitme konstellatsiooniga GNSS globaalseks positsioneerimiseks; ja radari kõrgusemõõtjad täpse kõrguse maapinnast maandumisel. Takistuste ja liikluse tuvastamiseks kasutavad õhusõidukid üha enam ilmaradarit, ADS-B vastuvõtjaid (liiklusteadlikkus), elektro-optilisi/infrapuna (EO/IR) kaameraid ja mõnikord ka LiDAR-i tuvastamiseks ja vältimiseks (eriti UAV-des). Erinevalt maapealsetest süsteemidest peab õhusõiduki autonoomia hakkama saama hõredate maamärkide, suure sulgemiskiiruse ja suurte vertikaalsete ümbristega. Andurite töökindlus ja liiasus on kriitilise tähtsusega ning inertsiaalsete ja väliste navigatsiooniallikate ristkontroll, et täita lennuohutuse nõudeid.

Õhus leviv autonoomne arvutus seab prioriteediks determinismi, sertifitseerimise jälgitavuse ja veataluvuse tehisintellekti töötlemata läbilaskevõime ees. Lennukriitilised süsteemid peavad vastama nõuetele DO-178C (tarkvara) ja DO-254 (riistvara), mis rõhutab kontrollitud, piiratud täitmist ja ranget testimist. Arvutusplatvormid jaotatakse sageli aja- ja ruumieralduse abil (nt ARINC 653 arhitektuurid), tagades, et autonoomia funktsioonid ei saaks lennujuhtimisseadmeid segada. Võrreldes autotööstusega, võib õhuarvutus kasutada vähem tipptasemel räni, kuid rõhutab koondamist (kolmekordne modulaarne liiasus, ristseire protsessorid) ja deterministlikke reaalajas kasutatavaid operatsioonisüsteeme. Võimsuse ja kaalu piirangud on kriitilised ning soojusjuhtimine peab arvestama kõrgusega seotud jahutuspiirangutega.

Meremees.

Autonoomsed merelaevad töötavad peegeldavas, segaduses ja dünaamiliselt muutuvas pinnakeskkonnas. Peamiste andurite hulka kuuluvad mereradar (kaugmaatuvastus udus ja vihmas), GNSS globaalseks positsioneerimiseks ning kõrgekvaliteedilised IMU-d kursi ja liikumise stabiliseerimiseks. Automaatne identifitseerimissüsteemi (AIS) vastuvõtjad võimaldavad ühist veresoonte jälgimist, optilised kaamerad aga aitavad visuaalselt tõlgendada. Lähivälja teadvustamiseks tuleb järgida COLREGi merereegleid, laevadel kasutatakse maandamise vältimiseks optilisi kaameraid, termokaameraid (öine ja halva nähtavusega), sonari (maa-aluse takistuse tuvastamiseks) ja sügavusloode. Võrreldes maapealsete süsteemidega peab mereandur juhtima laine liikumist, vee mitmesuunalisi peegeldusi, soola korrosiooni ja väga pikki tuvastusvahemikke vähese infrastruktuuriga. Maa-alune autonoomia (nt AUV-d) sõltub veelgi akustilisest positsioneerimisest ja Doppleri kiiruslogidest, kuna GNSS pole vee all saadaval.

Mereautonoomia arvutamine töötab väiksema kiirusega, kuid väga muutuvas keskkonnas, sageli kombineerides pardal olevaid arvutusi kaldal asuvate või pilvepõhise süsteemiga. Laevad võivad kasutada tugevaid tööstusliku kvaliteediga protsessoreid, mis käitavad radari, AIS-i (automaatse identifitseerimissüsteemi), sonari ja kaamera sisendite jaoks taju- ja navigeerimispinu. Kuna meresüsteemid töötavad merel sageli pikemat aega, on energiatõhusus ja keskkonnamõju (sool, niiskus, vibratsioon) olulised. Autonoomiaarvutus peab integreerima marsruudi optimeerimise, kokkupõrke vältimise (COLREG-i vastavus) ja kaugseire, mõnikord osalise inimliku järelevalvega. Erinevalt kosmosetööstusest on sertifitseerimine vähem tsentraliseeritud, võimaldades arvutusarhitektuuris mõnevõrra suuremat paindlikkust.

Ruum.

Kosmose autonoomia toimib äärmuslikus, infrastruktuurivabas keskkonnas, kus navigeerimine ja olekuteadlikkus sõltuvad suuresti inertsiaalsest, optilisest ja taevaandurist. Satelliidid kasutavad ülitäpse asendi määramiseks tähejälgijaid, jämedaks orientatsiooniks päikeseandureid ja nurkkiiruse mõõtmiseks güroskoope. GNSS-vastuvõtjaid võib kasutada madalal Maa orbiidil, kuid süvakosmose missioonid tuginevad pardal olevale optilisele navigatsioonile (planeedi/tähtede jälgimine), LIDAR-i kõrgusemõõtjatele (planeedile maandumiseks) ja radarile pinna kaardistamiseks. Lähedustoimingud (nt dokkimine, lendamine) kasutavad nägemispõhist navigeerimist ja suhtelisi LIDAR- või radarandureid. Erinevalt maa-, õhu- või meresüsteemidest peavad kosmoseandurid taluma kiirgust, vaakumit ja äärmuslikke temperatuuritsükleid ning sageli töötavad nad side latentsuse tõttu minimaalse reaalajas inimese järelevalvega. Andurite sulandumine ruumis rõhutab rikete tuvastamist, graatsilist lagunemist ja pikaajalist töökindlust võrreldes töötlemata keskkonnatihedusega.

Ruumi autonoomia arvutamist piiravad kiirgustaluvus, toite saadavus ja side latentsus. Traditsioonilised kosmosesüsteemid kasutavad kiirguskindlaid protsessoreid, millel on madalam taktsagedus, kuid ülimalt kõrge töökindlus ja veaparandusvõime. Üha enam hõlmavad kommerts- ja NewSpace-missioonid suurema jõudlusega COTS-protsessoreid, millel on varjestus ja rikete tuvastamine, et võimaldada pardal asuvat AI-d navigeerimiseks, rikete haldamiseks ja autonoomsete toimingute jaoks (nt satelliidi konstellatsiooni haldamine või planeedi maandumine). Kuna sideviivitused võivad olla minutid või pikemad, peavad süvakosmosesüsteemid toetama autonoomset otsuste tegemist minimaalse maapealse sekkumisega. Arhitektuurse disaini valikutes domineerivad tõrketaluvus, graatsiline lagunemine ja pikk tööiga (sageli 10–20+ aastat).

Autonoomsed sõidukid seavad oma anduritele erakordsed nõudmised. Kaamerad, LiDAR-id, radarid ja inertsiaal-/GNSS-seadmed teevad enamat kui jäädvustavad keskkonda – need määravad piirid, mida sõiduk võib teada saada. Planeerija ei saa vältida ohtu, mida ta kunagi ei tajunud, ja kontroller ei saa kompenseerida latentsust või triivi, millest talle kunagi ei räägita. Seetõttu on andurite valideerimisel ohutuse tagamisel oluline roll: see iseloomustab seda, mida andurid näevad ja mida ei näe, kuidas need signaalid muudetakse masintõlgendatavateks üksusteks ja kuidas jääkpuudused levivad süsteemi tasemel riskiks kavandatud tööprojekti domeenis (ODD).

Praktikas ühendab valideerimine kolm kihti, mis peavad jääma tõendusjälje ühendatuks. Esimene on riistvarakiht, mis puudutab sisemist jõudlust, nagu eraldusvõime, ulatus, tundlikkus ja dünaamiline ulatus; välisgeomeetria, mis kinnitab iga anduri sõiduki raami külge; ja ajaline käitumine, sealhulgas latentsus, värinad, ajatempli täpsus ja kella triiv. Teine on signaali-taju kiht, kus töötlemata mõõtmised filtreeritakse, sünkroonitakse, sulatatakse ja teisendatakse kaartideks, tuvastamisteks, radadeks ja semantilisteks siltideks. Kolmas on töökiht, mis testib, kas tuvastussüsteem, mida kasutab autonoomiapinn, käitub kogu ODD-s vastuvõetavalt, kaasa arvatud haruldane valgustus, ilm ja liiklusgeomeetria. Usaldusväärne programm seob tõendid nende kihtide vahel struktureeritud ohutusjuhtumiga, mis on kooskõlas funktsionaalse ohutuse (ISO 26262), SOTIF-i (ISO 21448) ja süsteemitaseme tagamise raamistikega, esitades selgesõnalisi väiteid piisavuse ja teadaolevate piirangute kohta.

Üldine eesmärk ei ole ainult testide läbimine, vaid piirata ebakindlust ja säilitada jälgitavus. Meeskond otsib iga modaalsuse puhul kvantifitseeritud arusaama jõudluspiiridest: kuidas tuvastamise tõenäosuse ja vigade jaotus nihkub kauguse, nurga, peegelduvuse, ego kiiruse, oklusiooni, sademete, päikese nurga ja elektromagnetilise või termilise pingega. Need ümbrikud on kasulikud ainult siis, kui need on tõlgitud taju põhinäitajateks ja lõpuks ka ohutusnäitajateks, nagu minimaalne kaugus kokkupõrkeni, kokkupõrkeni kuluv aeg, missiooni õnnestumise määr ja mugavusindeksid. Sama oluline on jälgitavus alates süsteemitaseme tulemusest kuni tuvastustingimuste ja töötlemisvalikuteni – nii saab hilinenud tõrkeid diagnoosida kalibreerimise triivi, ajatempli viltu, rabeda maapinna filtreerimise, liiga enesekindla jälgimise või planeerija eeldusena takistuste kontuuride kohta. Valideerimisartefaktid – kalibreerimisaruanded, ajastuse analüüsid, parameetrite pühkimistulemused ja andmekogumi manifestid – peavad seetõttu olema korraldatud nii, et ohutusjuhtumis esitatud nõudeid toetaksid reprodutseeritavad tõendid.

Pink algab geomeetriast ja ajast. Sisemine kalibreerimine (kaamerate puhul: fookuskaugus, põhipunkt, moonutus; LiDARi puhul: kanalinurgad ja süütamise ajastus) tagab, et töötlemata mõõtmised on geomeetriliselt tähendusrikkad, samas kui väline kalibreerimine fikseerib jäiga kere teisendused andurite vahel ja sõiduki raami suhtes. Ajaline valideerimine määrab ajatempli täpsuse, andurite vahelise joonduse ja otspunktidevahelise latentsusaja eelarved. Väikesed ajastuse ebakõlad, mis tunduvad eraldiseisvalt healoomulised, võivad liitmise ajal põhjustada mitmemeetriseid ruumilisi lahknevusi, eriti kui jälgitakse kiiresti liikuvaid näitlejaid või kui egosõiduk pöördub. Kaasaegsed virnad sõltuvad sellest alusest: LiDAR-kaamera fusioonikonveier, mis projitseerib punktipilved kujutise koordinaatideks, nõuab nii täpseid väliseid andmeid kui ka alamkaadri tasemel ajalist joondamist, et vältida kummitatud servi ja valesti joondatud semantilisi silte. Kalibreerimine ei ole ühekordne sündmus; temperatuuritsüklid, vibratsioon ja hooldus võivad väliseid omadusi nihutada ning püsivara värskendused võivad muuta ajastust. Käsitlege kalibreerimist ja ajastust jälgitavate tervisesignaalidena perioodiliste enesekontrollidega – kaamerate tahvlimustrid, ahela sulgemise või NDT-mõõdikud LiDAR-i lokaliseerimiseks ja GNSS/IMU järjepidevuse testid –, et tabada triivi, enne kui see kahjustab ohutusvarusid.

Valideerimine peab ulatuma andurist kaugemale eeltöötlus- ja liitmistorustikuni. Maapinna eemaldamise, liikumise kompenseerimise, pimestamise käsitsemise, huvipakkuva piirkonna kärpimise või raja kinnitamise loogika puudutavad valikud võivad muuta tõhusat tajuvahemikku ja valenegatiivseid määrasid rohkem kui nominaalne riistvaravahetus. Seetõttu on kontrollitud parameetrite tundlikkuse uuringud hädavajalikud. Muutke ühte eeltöötlusparameetrit realistlikus vahemikus ja mõõtke, kuidas esimese tuvastamise kaugus, valehäire sagedus ja raja stabiilsus arenevad. Need uuringud on katserajal simulatsioonis ja kirurgiliselt odavad ning rabedus ilmneb varakult, enne kui see tundub liikluses ebamugava pidurdamise või möödalastud takistusena. Eelkõige võivad LiDAR-i maapinnafiltri lävede muudatused lühendada maksimaalset vahemaad, mille juures peatunud sõiduk tuvastatakse, kümnete meetrite võrra, vähendades reaktsiooniaega sekundeid ja suurendades riski – seda mõju tuleks mõõta ja siduda selgesõnaliselt ohutusvarudega.

Tajumise KPI-d tuleb määratleda järgnevaid otsuseid silmas pidades. Koondsed AUC-d on vähem informatiivsed kui sellised avaldused, nagu “peatatud sõiduki tuvastamise vahemik üheksakümne protsendi juures tagasikutsumisel kuiva päevavalguses linnatingimustes”. Lokaliseerimise tervist väljendatakse paremini aegrea mõõdikuna, mis on korrelatsioonis kaardi tiheduse ja stseeni sisuga, kui ühe RMS-i näitajana. Eesmärk on luua mõõdikuid, mida planeerija saab puhvrite ja käitumisviiside määramisel kaaluda. Need tajutaseme KPI-d tuleks siduda süsteemitaseme ohutusmeetmetega – minimaalne kaugus kokkupõrkeni, kokkupõrke esinemine, pidurdamise agressiivsus, roolimise sujuvus –, et saaks veenvalt näidata, et muutused anduris või eeltöötluses suurendavad või vähendavad riski.

Andurite kalibreerimise üks huvitavaid tagajärgi on nõue lisada toodete hooldusvõimalustesse kalibreerimisvõime.

Sõidetud miilid on nõrk asendusnäitaja kindlustunde tuvastamiseks. Oluline on see, milliseid olukordi kasutati ja kui hästi need riskimaastikku katavad. Stsenaariumipõhine valideerimine asendab ad hoc läbisõidu struktureeritud, parameetritega stseenidega, mis on suunatud stressitegurite tuvastamisele: madala kontrastsusega jalakäijad, osaliselt nihke nurga all suletud sõidukid, horisondilähedane päikesevalgus, keerukad peegeldavad taustad või vihmast tingitud sumbumine. Stsenaariumi kirjelduskeeled võimaldavad neid stseene määratleda jaotustena positsioonide, kiiruste, käitumise ja keskkonnatingimuste järgi, andes anekdootlike kohtumiste asemel pigem reprodutseeritavaid ja häälestatavaid teste. Ametlikud meetodid suurendavad seda protsessi võltsimise kaudu – automatiseeritud otsingud, mis leiavad aset konfiguratsioonides, mis kõige tõenäolisemalt rikuvad jälgitavaid ohutusomadusi, nagu minimaalse eraldusvõime säilitamine või sõiduraja vaba ruumi kinnitamine fikseeritud ooteaja jooksul. See formalism annab kaks dividendi: see muudab ebamäärased nõuded omadusteks, mida saab simulatsioonis ja õigel teel kontrollida, ning see toob esile täpsed piirtingimused, kus tundlikkus muutub hapraks, mis on täpselt need piirangud, millele ohutusjuhtum peab viitama ja toimingud peavad ODD-piirangutega leevendama.

Kõrge täpsusega in-the-loop tarkvara vähendab lõhe abstraktsete stsenaariumide ja juurutatud virna vahel. Virtuaalsed kaamerad, LiDAR-id ja radarid võivad juhtida tõelist tajutarkvara vahevara sildade kaudu, võimaldades haruldaste juhtumite kontrollitud reprodutseerimist, täpseid oklusioone ja värskenduste ohutut hindamist. Kuid virtuaalsed andurid on mudelid, mitte peeglid; renderdamistorustikud ei pruugi tabada radari mitmeteed, rulluva katiku moonutusi, märjal teel toimuvat peegeldust või konkreetse LiDAR-i täpset kiiret lahknemist. Seetõttu tuleks simulaatorit käsitleda kui instrumenti, mis vajab oma valideerimist. Praktiline lähenemine on paarisstsenaariumide säilitamine: testide alamhulga jaoks koguge reaalmaailma jooksud töötlemata logide ja keskkonnamõõtmistega ning seejärel rekonstrueerige need simulatsioonis võimalikult tõetruult. Võrrelge tuvastamise ajaskaalasid, raja stabiilsust ja minimaalse vahemaa tulemusi ning kvantifitseerige erinevusi aegridade mõõdikute abil, nagu dünaamiline ajakõverdus vahemaaprofiilidel, lahknevused esimese tuvastamise ajatemplites ja lahknevused raja ID-des. Eesmärk ei ole kustutada sim-to-real lõhet – ebareaalne eesmärk –, vaid seda piirata ja mõista, kus simulatsioon on konservatiivne versus optimistlik.

Kuna eelarved on piiratud, kasutab tõhus programm kahekihilist töövoogu. Esimene kiht kasutab reaalajas kiiremaid ja madalama täpsusega komponente, et uurida suuri stsenaariumiruume, kärpida mitteinformatiivseid piirkondi ja hinnata tingimusi hinnangulise ohutusmõju alusel. Teine kiht taasesitab kõige informatiivsemad juhtumid fotorealistlikus keskkonnas, mis voogesitab virtuaalse anduri andmed tegelikku autonoomia virna ja sulgeb juhtimisahela tagasi simulaatorisse. Mõlemad kihid logivad identseid KPI-sid ja ajaliselt joondatud jälgi, nii et tulemused on võrreldavad ja jälgimiskatsetele ülekantavad. See laiuse ja täpsuse kombinatsioon paljastab kiiresti nurgapealsed juhtumid, kvantifitseerib nende ohutuse tagajärjed ja annab lõpliku kinnituse jaoks valmis katseraja protseduurid.

Kaasaegne valideerimine peab hõlmama juhuslikke rikkeid ja pahatahtlikke häireid. Andureid võivad häirida võltsimised, küllastus või meisterdatud mustrid; radarid võivad häirida; GPS võib olla ummistunud või võltsitud; IMU-d triivivad. Käsitlege neid struktureeritud negatiivsete testide komplektidena, mitte järelmõtetena. Muutke võltsimise tihedust, kestust ja geomeetriat; süstida pimestamist või küllastust ohutute katseprotokollide raames; simuleerida või riistvaralisi radarihäireid; ja salvestage, kuidas taju KPI-d ja süsteemitaseme ohutusmõõdikud reageerivad. Eesmärk on kahekordne: kvantifitseerida degradeerumine – kui palju varem tuvastamine ebaõnnestub, kui sageli jäljed langevad – ja hinnata kaitsemehhanisme, nagu ristmodaalsuse järjepidevuse kontrollid, tervisekontrolli hääletamine ja tagasilöögid, mis vähendavad kiirust ja suurendavad edusamme, kui tuvastuskindlus langeb alla läve. See töö ühendab otse SOTIF-iga, paljastades jõudlusega piiratud ohud, mida võimendavad võistlevad tingimused, ja funktsionaalse ohutusega, näidates rikete korral ohutuid olekuid.

Valideerimine toodab andmeid, kuid kinnitus nõuab argumenti. Leiud tuleks korraldada nii, et iga kõrgeima taseme väidet – nagu tuvastuspinu piisavus määratletud ODD jaoks – toetaksid selgelt piiritletud alamväited ja tõendid: kalibreeritud geomeetria ja ajastus jälgitavates piirides; modaalsusespetsiifilised avastamise ja jälgimise KPI-d esinduslike keskkonnakihtide lõikes; kvantifitseeritud sim-to-real erinevused kriitiliste stseenide jaoks; stsenaariumi katvuse mõõdikud, mis näitavad, kus usaldus on kõrge ja kus rakendatakse operatiivseid leevendusi; ning töökindlus- ja turvatestide tulemused. Kui piirangud jäävad alles – nagu alati –, tuleks need selgelt välja öelda ja siduda leevendustega, olgu see siis vähendatud töökiirus tugeva vihma korral üle määratud sumbumistaseme, piiratud ODD, kus lumi kõrvaldab sõiduraja semantika, või selgesõnalisi hooldusintervalle ümberkalibreerimiseks.

Viimane pragmaatiline soovitus on käsitleda valideerimisandmeid esmaklassilise tootena. Töötlemata logid, konfiguratsiooni hetktõmmised ja töötlemisparameetrid peaksid olema versioonidega, päringutega ja taasesitavad. Reprodutseeritavus muudab valideerimise takistusest insenertehniliseks varaks: kui pärast väiksemat tarkvaravärskendust ilmneb taju regressioon, saab muudatuse kindlakstegemiseks uuesti esitada samu stsenaariume; kui pakutakse välja uus anduri mudel, saab tuvastamise mähiseid ja ohutusvarusid kiiresti ja usaldusväärselt võrrelda. Sel viisil muutub tajuandurite valideerimine distsiplineeritud, stsenaariumipõhiseks programmiks, mis seob füüsilise anduri jõudluse tajukäitumisega ja lõpuks süsteemitaseme ohutustulemustega, teavitades samal ajal pidevalt disainivalikuid, mis muudavad järgmise valideerimisvooru kiiremaks ja tõhusamaks.

Juhtimis- ja ohutusalased väljakutsed:

EMI:

Millised on tagajärjed autotootjatele? Kaasaegsetes sõidukites ei piirdu elektroonika enam teabe ja meelelahutuse või mootori juhtimisega – andurid, sidemoodulid ja kontrollerid on nüüd sõiduki ohutuse ja jõudluse seisukohalt kesksel kohal. Need süsteemid kiirgavad ja võtavad vastu elektromagnetenergiat, mis võib põhjustada elektromagnetilisi häireid (EMI), kui neid ei hallata õigesti. EMI võib kahjustada ohutuse seisukohalt olulisi rakendusi, nagu radaripõhine adaptiivne püsikiiruse hoidja või kaamerapõhine sõiduraja hoidmine. Sensortehnoloogiad toovad kaasa ainulaadsed EMI väljakutsed. Radari- ja lidariandurid, mis on juhiabi ja autonoomsete süsteemide jaoks kriitilise tähtsusega, ei pea mitte ainult vältima üksteisega seotud häireid, vaid peavad töötama ka FCC ja ülemaailmsete organite, nagu ITU, määratletud spektrieraldiste piires. Sarnaselt on kaamerad ja ultraheliandurid vastuvõtlikud läheduses asuva jõuelektroonika mürale, eriti elektrisõidukites. Halvasti varjestatud kaablitest või kõrgsageduslikest lülituskomponentidest tulenev EMI võib põhjustada andmete rikkumist, tuvastamata jätmist või signaali terviklikkuse halvenemist, mis tõstab nii funktsionaalse ohutuse kui ka regulatiivseid probleeme.

Side seisukohast peab FCC-ga ühilduva süsteemi projekteerimisel arvestama ka koostalitlusvõimet ja kooseksisteerimist. Bluetoothi, Wi-Fi, GPS-i, DSRC või C-V2X ja mobiilsidemoodulitega varustatud sõidukis nõuab raadiosagedusliku harmoonia säilitamine hoolikat sageduse planeerimist, varjestamist ja filtreerimist. FCC arenevad reeglid 5,9 GHz sagedusala kohta – osade ümberjaotamine DSRC-lt C-V2X-le – illustreerivad, kuidas reguleerivad raamistikud mõjutavad otseselt toote arhitektuuri. OEM-id peavad neid arenguid jälgima ja kinnitama, et nende sidemoodulid ei tööta mitte ainult heakskiidetud sagedusalades, vaid ei kiirga ka valesignaale, mis võiksid rikkuda FCC emissiooni piirmäärasid. FCC standardite täitmiseks, tagades samas süsteemi kõrge töökindluse, peavad autoarendajad arvestama EMI-ga seotud kaalutlused juba projekteerimistsükli alguses. Vastavuseelne testimine, EMI-teadlik PCB paigutus ja komponenditaseme sertifitseerimine aitavad kaasa sujuvamale teele regulatiivse heakskiidu saamiseks. Lisaks aitab FCC nõuete vastavusse viimine rahvusvaheliste autotööstuse elektromagnetilise ühilduvuse standarditega, nagu CISPR 25 ja UNECE R10, tagada ülemaailmse turu valmisoleku. Kuna sõidukid muutuvad üha enam tarkvarapõhiseks, ühendatud ja autonoomsemaks, on EMI haldamine nutika projekteerimise ja regulatiivse ettenägelikkuse abil innovatsiooni, ohutuse ja vastavuse kriitilise tähtsusega.

Nagu öeldud, keskenduvad FCC eeskirjad peamiselt elektromagnetilistele häiretele. Kui aga raadiosagedusenergia võib põhjustada terviseprobleeme, on kaasatud teised regulaatorid. FCC osa 18 seadmete (nt mikrolaineahjud ja meditsiinilised raadiosagedusseadmed) tervise- ja ohutuseeskirjadega tegelevad peamiselt agentuurid. Toidu- ja ravimiamet (FDA) jälgib kiirgust kiirgavaid elektroonikatooteid, et tagada nende vastavus inimeste kokkupuute ohutusstandarditele, eriti tarbeseadmete ja meditsiiniseadmete puhul. Tööohutuse ja töötervishoiu amet (OSHA) kehtestab raadiosagedusliku kokkupuute töökohal ohutuspiirangud, et kaitsta töötajaid, kes töötavad või töötavad selliste seadmete läheduses. Samal ajal viib Riiklik Tööohutuse ja Töötervishoiu Instituut (NIOSH) läbi uuringuid ja annab juhiseid ohutu raadiosagedusliku kokkupuute taseme kohta töökeskkonnas. Kuigi FCC reguleerib 18. osa seadmete raadiosageduskiirgust, et vältida häireid litsentsitud sidesüsteemidega, tugineb ta nendele teistele agentuuridele, et tagada, et seadmed ei kujutaks ohtu kasutajate ega töötajate tervisele.

Sõidukitootjate puhul ilmnevad 18. osa terviseprobleemid sellistes kasutusmudelites nagu juhtmevaba toiteallikas, kus SAR-i tase võib ohutust otseselt mõjutada.

Lõpuks, kuigi ülaltoodud näited pärinevad USA kontekstist, eksisteerivad sarnased struktuurid kõigis teistes geograafilistes piirkondades.

Viimasel kümnendil on õhusektor selle aluse peale kihistanud autonoomia ja täiustatud taju. Kaasaegsed mehitamata õhusõidukid ja täiustatud õhu liikuvuse platvormid integreerivad sensorite liitprotsessoreid, nägemissüsteeme ja tehisintellekti kiirendeid, et tuvastada ja vältida ning autonoomne navigeerimine. Kommertstranspordid hõlmavad täiustatud nägemissüsteeme, ennustavat hooldusanalüüsi ja üha enam tarkvaraga määratletud võimalusi. Erinevalt autotööstuse kiirest tarbijapõhisest skaleerimisest piiravad õhus levivat elektroonikat siiski sertifitseerimise ajakava, toote pikad elutsüklid (20–30+ aastat) ja äärmuslikud keskkonnanõuded (temperatuur, vibratsioon, kiirgus).

Autonoomsetele süsteemidele omased tarneahela väljakutsed

Autonoomsed süsteemid lisavad nii riistvara integreerimisele kui ka tarneahela juhtimisele mitu ainulaadset keerukuse taset:

Sõltuvus mitmest tarnijast Üks autonoomne platvorm võib kasutada komponente kümnetelt tarnijatelt – tehisintellekti kiirenditest GNSS-mooduliteni. Versioonikontrolli, püsivara värskenduste ja riistvara ühilduvuse haldamine selles ökosüsteemis nõuab mitmetasandilist koordineerimist ja pidevat konfiguratsiooni jälgimist [55].

Ohutuskriitilise tähtsusega sertifikaat Riistvara peab vastama ohutus- ja regulatiivsetele sertifikaatidele, näiteks:

• ISO 26262 (autode funktsionaalne ohutus)
• DO-254 (lennunduse riistvara disaini tagatis)
• IEC 61508 (tööstuslik funktsionaalne ohutus)

Iga sertifikaat lisab kulusid, aega ja dokumentatsiooninõudeid.

Reaalajas ja deterministlik jõudlus Integratsioon peab tagama madala latentsusaja ja deterministliku käitumise – see tähendab, et andurid, protsessorid ja täiturmehhanismid peavad suhtlema mikrosekundi täpsusega. See mõjutab riistvara valikut ja võrgu disaini [56].

Kiire tehnoloogia vananemine AI ja manustatud andmetöötlus arenevad kiiremini kui mehaanilised süsteemid. Komponendid vananevad enne platvormi elutsükli lõppu, sundides tarneahelaid haldama tehnoloogia värskendustsükleid ja komponentide pikaajalist saadavuse planeerimist [57].

Võimalikud lahendused ja parimad tavad

Olulisemad väljakutsed ja võimalikud lahendused on kokku võetud järgmises tabelis:

Tüüpiline tarneahela juhtimine (SCM) läheneb strateegilisele partnerlusele ja vertikaalsele integratsioonile

Paljud ettevõtted liiguvad vertikaalse integratsiooni poole, kontrollides mitut tarneahela etappi. Näiteks:

• Tesla toodab ise akupakette ja tehisintellekti kiipe.
• DJI projekteerib ettevõttesiseseid lennukontrollereid ja optilisi andureid.

Selline lähenemine suurendab varustuskindlust ja vähendab sõltuvust kolmandatest osapooltest, kuigi nõuab olulisi kapitaliinvesteeringuid.

Jätkusuutlikkus ja eetiline SCM

Tarneahelate jätkusuutlikkus keskendub süsiniku jalajälje vähendamisele, eetilise hankimise tagamisele ja ringlussevõetavuse edendamisele [65]. Peamised tavad:

• Keskkonnamõju elutsükli hinnangud (LCA).
• Elektroonikajäätmete suletud ahelaga taaskasutus.
• Tarnijate jätkusuutlikkuse auditid.
• ISO 14001 sertifikaat keskkonnajuhtimissüsteemidele.

Tõhus riistvara integreerimine ja tarneahela juhtimine on tihedalt läbi põimunud. Integreerimine sõltub kvaliteetsete ja ühilduvate komponentide olemasolust, samas kui tarneahelad tuginevad tugevale tagasisidele integreerimisest ja testimisest, et prognoosida vajadusi, vähendada raiskamist ja säilitada töökindlus. Kaasaegsed SCM-raamistikud, eriti Lean, Agile ja Digital mudelid, pakuvad strateegiaid autonoomiatööstuse muutmiseks vastupidavamaks, jätkusuutlikumaks ja reageerivamaks.

Selles peatükis selgitatakse, kuidas pooljuhtidest ja elektroonikast sai tänapäevaste autonoomsete süsteemide alus maa-, õhu-, mere- ja kosmoseplatvormidel. See näitab ühist ajaloolist mustrit: süsteemid algasid enamasti mehaaniliste või isoleeritud elektrooniliste funktsioonidega, seejärel arenesid digiteeritud juhtimise, võrku ühendatud alamsüsteemide ja üha autonoomsema töö suunas. Autode puhul tähendas see liikumist mootori juhtimiselt šassii, teabe- ja meelelahutussüsteemi, elektrifitseerimise ja ADAS-i juurde; lennukites, laevades ja kosmosesõidukites tähendas see sarnast üleminekut eraldiseisvatelt avioonikalt või navigatsioonivahenditelt integreeritud, ohutuskriitiliste digitaalsete arhitektuuride poole.

Peatükis rõhutatakse ka seda, et autonoomia ei seisne ainult andurite lisamises. See nõuab riistvara, arvutuste, valideerimise ja juhtimise täielikku ökosüsteemi. Erinevad domeenid tuginevad erinevatele andurite segudele – nagu radar, kaamerad, LiDAR, GNSS, IMU-d, sonar või tähejälgijad –, kuid kõik peavad andmed ühendama ja reaalajas ohututeks otsusteks teisendama. Kuna need süsteemid on ohutuse seisukohalt kriitilised, tõstab peatükk esile standardite, nagu ISO 26262, IEC 61508 ja DO-254, tähtsust koos valideerimisprotsessidega, mis hõlmavad kalibreerimist, ajastuse analüüsi, stsenaariumipõhist testimist, simulatsiooni ja struktureeritud ohutusjuhtumeid.

Lõpuks väidetakse peatükis, et edukad autonoomsed süsteemid sõltuvad enamast kui tehnilisest jõudlusest: nad peavad liikuma ka EMI regulatsioonis, tervise- ja ohutusjärelevalves ning vastupidavates tarneahelates. Arutelu hõlmab FCC spektri- ja heitkoguste vastavust, elektromagnetilise ühilduvuse testimist ja akrediteeritud laborite rolli ning seejärel käsitletakse tarneahela probleeme, nagu komponentide nappus, küberturvalisus, sertifitseerimiskoormus, eetiline hankimine ja tehnoloogia vananemine. Peamine järeldus on see, et autonoomsed süsteemid ei ole lihtsalt arenenud masinad – need on keerulised, tihedalt integreeritud tooted, mille edu sõltub kooskõlastatud edusammudest elektroonika, tuvastuse, ohutuse, valideerimise ja tarneahela juhtimise vallas.

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.

Kaasaegsed autonoomsed süsteemid – alates isejuhtivatest autodest ja mehitamata õhusõidukitest (UAV) kuni mererobotite ja tööstuslike kaasrobotiteni – sõltuvad põhiliselt tarkvaraarhitektuuridest, mis on võimelised reaalajas tuvastama, tegema otsuseid ja juhtima. Kui mehaanilised ja elektroonilised komponendid määravad, mida süsteem saab teha, siis tarkvarapakk määratleb, kuidas see seda teeb – kuidas see maailma tajub, andmeid tõlgendab, tegevusi kavandab ja keskkonnaga ohutult suhtleb [66,67]. Autonoomiatarkvara erineb tavapärasest manus- või ettevõttetarkvarast mitmel kriitilisel viisil.

• See töötab rangete reaalajas piirangute alusel.
• See peab integreerima heterogeensete andurite andmed.
• See peab toetama tõrketaluvust ja ohutust.
• See toetab pidevat õppimist ja kohanemist tehisintellekti kaudu.
• See suhtleb füüsiliste süsteemide, ühendatud võrkude, servaseadmete ja pilveteenustega.

See ohutuskriitilise inseneri ja AI-põhise otsustusprotsessi kombinatsioon muudab autonoomiatarkvara tänapäevase andmetöötluse üheks kõige keerulisemaks valdkonnaks.

Autonoomiatarkvara peab saavutama neli peamist funktsionaalset eesmärki [68,69]:

• Taju: keskkonna tuvastamine ja tõlgendamine (LiDARi, radari, kaamerate, sonari jne kaudu).
• Lokaliseerimine: süsteemi täpse asukoha ja orientatsiooni hindamine maailmas.
• Planeerimine: selliste radade või käitumisviiside loomine, mis täidavad missiooni eesmärke, vältides samas takistusi.
• Kontroll: toimingute ohutu ja stabiilne teostamine, kompenseerides keskkonnamuutusi.

Kõik need eesmärgid vastavad autonoomia virna erinevatele tarkvarakihtidele ja moodulitele.

Need omadused juhivad arhitektuuriotsuseid ja raamistike valikut (nt ROS, AUTOSAR Adaptive, DDS).

Autonoomiatarkvara on kihiline, ühendades mitu tarkvaratehnoloogiat:

• Madala tasemega manustatud püsivara (reaalajas juhtimine ja draiverid).
• Keskvara- ja sideraamistikud (andmevahetus ja ajastamine).
• Kõrgetasemelised AI algoritmid (taju, otsuste tegemine).
• Järelevalve- või pilvetasandi süsteemid (pargihaldus, värskendused, andmeanalüütika).

Nende kihtide kombinatsioon moodustab autonoomia tarkvaravirna, mis võimaldab keerukat käitumist, säilitades samal ajal usaldusväärsuse. Autonoomsuse tarkvara määrav aspekt on selle sõltuvus vahevarast – raamistikest, mis haldavad protsessidevahelist sidet (IPC), andmete jaotust ja aja sünkroonimist hajutatud andmetöötlussõlmede vahel. Mõned laialdaselt kasutatavad standardid:

• ROS / ROS 2 (robotite operatsioonisüsteem): Modulaarne avaldamise ja tellimise side.
• DDS (Data Distribution Service): reaalajas, QoS-il põhinev sõnumite standard.
• MQTT / ZeroMQ: kerged protokollid pilve ja asjade Interneti integreerimiseks.

Täielik tarkvarapakk on tarkvarakomponentide, raamistike ja teekide kihiline kogum, mis töötavad koos, et pakkuda täielikku süsteemi funktsioonide komplekti. Iga kiht pakub teenuseid selle kohal olevale kihile ja sõltub selle all olevast kihist. Vahevara, mis on mitmekihiliste arhitektuuride oluline osa, tagab, et tarkvaravirna kõik kihid saavad teavet deterministlikult ja turvaliselt vahetada [70]. Autonoomsetes süsteemides võimaldab tarkvarapakk integreerida:

• Riistvara abstraktsioon (andurid, täiturid, arvutusüksused).
• Vahevara (side ja andmevahetus).
• Rakendustaseme moodulid (AI taju, planeerimine, juhtimine).
• Süsteemihaldus (diagnostika, simulatsioon, autopargi uuendused).

See on selgroog, mis võimaldab autonoomial toimida sidusa süsteemina, mitte lahtiühendatud moodulite kogumina (Quigley et al., 2009; Maruyama jt, 2016). Tehnilisest vaatenurgast määratleb tarkvarapakk, kuidas süsteemis on üles ehitatud funktsionaalsus, andmevoog ja juhtimine.

Modulaarsus ja abstraktsioon

Iga kiht eraldab keerukuse, pakkudes ülalolevale puhta liidese.

• Arendajad saavad muuta üht kihti (nt tajualgoritme) ilma madalamaid kihte (nt draivereid) muutmata.
• Võimaldab lihtsamat testimist, silumist ja taaskasutamist mitme sõiduki või rakenduse puhul.

Reaalajas ja deterministlik käitumine

Autonoomsed süsteemid toetuvad reaalajas reageerimisele. Virna arhitektuur tagab:

• Õigeaegne suhtlus taju, planeerimise ja kontrolli vahel.
• Deterministlik ajastamine RTOS-i tuumade või reaalajas Linuxi paikade abil [71].
• Mitme anduri andmevoogude sünkroonimine ajatempli ja ajatundliku võrgu (TSN) abil.

Koostalitlusvõime

Vahevara, nagu ROS 2 või DDS, standardib protsessidevahelise suhtluse. See võimaldab erinevate tarnijate tarkvaramoodulitel (nt ettevõtte A LiDAR-draiver ja ettevõtte B planeerija) koos töötada.

Tõrketaluvus ja koondamine

Virna kihilisus toetab ohutuse seisukohalt oluliste funktsioonide jaoks üleliigseid teid. Kui tajusõlm ebaõnnestub, võib varundusprotsess sujuvalt üle võtta, tagades vastupidavuse, eriti kosmose- ja autosüsteemides [72].

Pidev integreerimine ja simulatsioon

Kihiline disain võimaldab arendajatel:

• Integreerige tarkvarakomponente järk-järgult.
• Testige neid, kasutades riistvara-in-the-loopi (HIL) ja tarkvara ahelas (SIL) meetodeid.
• Kasutage simulaatoreid (nt CARLA, Gazebo, AirSim), et kinnitada ülemise kihi mooduleid ilma riistvara kahjustamata.

Juhtimine ja organisatsiooniline tähtsus

Tarkvaratehnoloogia juhtimise vaatenurgast pakub määratletud tarkvarapinn arendusprotsessi struktuuri ja juhtimist, mis annab järgmised peamised eelised: Tööjaotus. Meeskonnad võivad spetsialiseeruda kihtide kaupa – nt üks rühm tegeleb tajuga, teine ​​juhtimine, teine ​​vahevara. See paralleelselt arendab ja võimaldab kasutada domeenide teadmisi ilma häireteta.

Korduskasutatavus ja versioonikontroll Korduvkasutatavad moodulid ja API-d kiirendavad arendust. Sellised tööriistad nagu Git, Docker ja CI/CD torujuhtmed tagavad hajutatud meeskondade jälgitavuse, hooldatavuse ja kiired värskendused.

Skaleeritavus ja elutsükli haldamine Hästi struktureeritud pinu saab laiendada uute andurite või algoritmidega, ilma kogu süsteemi uuesti üles ehitamata. Elutsükli haldustööriistad (nt ROS 2 käivitussüsteemid, AUTOSAR Adaptive manifestid) säilitavad versioonide järjepidevuse ja sõltuvuse kontrolli.

Kvaliteedi tagamine (QA) ja sertifitseerimine Kihilised tarkvaravirnad muudavad kvaliteedikontrolli ja vastavusraamistike, näiteks ISO 26262 (autode ohutustarkvara), DO-178C (lennundustarkvara) või IEC 61508 (automaatika funktsionaalne ohutus) rakendamise lihtsamaks. Iga kihti saab valideerida eraldi, lihtsustades dokumentatsiooni ja sertifitseerimise töövooge.

Kulude ja riskide vähendamine Kui mitu projekti jagavad ühtset tarkvarapakki, langevad testimise, valideerimise ja hoolduse kulud märkimisväärselt. See lähenemisviis toetab kogu tööstust hõlmavaid algatusi, nagu AUTOSAR, mis standardib sõidukite tarkvara integreerimiskulude vähendamiseks.

Kihiline virn kui organisatsiooni plaan

Suurtes autonoomiaprojektides (nt Waymo, Tesla) toimib tarkvarapakk ka organisatsioonilise struktuurina. Meeskonnad on joondatud kihtidega:

• Taju meeskond tegeleb sensorite ühendamise ja arvutinägemisega.
• Planning & Control meeskond arendab käitumisloogikat ja trajektooride genereerimist.
• Süsteemide meeskond haldab vahevara ja andmete levitamist.
• Infrastruktuuri meeskond hooldab OS-i järge, simulatsioone ja DevOpsi torujuhtmeid.

Seega toimib tarkvarapinn nii tehnilise arhitektuuri kui ka koordineerimise ja vastutuse organisatsioonilise kaardina [73].

Reaalmaailma näide: ROS 2 kui kihiline virn

Roboti operatsioonisüsteem 2 (ROS 2) näitab, kuidas modulaarseid tarkvaravirnu rakendatakse:

• Rakenduskiht: navigeerimine, kaardistamine, tajusõlmed.
• Vahevara kiht: DDS andmevahetuseks, QoS konfiguratsioon.
• OS-i kiht: Linux või RTOS koos POSIX API-dega.
• Riistvara abstraktsioon: draiverid kaameratele, IMU-dele, LiDAR-idele.
• Ehitamise ja juurutamise kiht: CMake, Colcon, Docker reprodutseeritavuse tagamiseks.

Sellest kihilisest mudelist on saanud paljude akadeemiliste ringkondade ja tööstuse autonoomsete süsteemide alus — mobiilsetest robotitest autonoomsete sõidukiteni [74]).

Hästi määratletud tarkvaravirna eelised

Sisuliselt pole tarkvarapakk pelgalt tehniline artefakt – see on strateegiline võimaldaja, mis ühtlustab inseneriprotsesse, organisatsioonilist struktuuri ja autonoomsete platvormide pikaajalist jätkusuutlikkust. Autonoomia tarkvarapinu ning arendus- ja hooldusprobleeme käsitletakse järgmistes peatükkides.

Tarkvara elutsükkel määratleb kogu protsessi, mille käigus tarkvara luuakse, arendatakse, juurutatakse, hooldatakse ja lõpuks kasutusest kõrvaldatakse. Kaasaegse inseneritöö kontekstis – eriti keeruliste süsteemide puhul, nagu autonoomsed platvormid, manussüsteemid või ettevõttelahendused – on kvaliteedi, töökindluse ja hooldatavuse tagamiseks oluline elutsükli mõistmine. Elutsükkel toimib teekaardina, mis juhib projektimeeskondi läbi arenduse ja juhtimise etappide. Iga etapp määratleb konkreetsed tulemused, verstapostid ja tagasisideahelad, tagades, et tarkvara areneb kontrollitud, jälgitaval ja prognoositaval viisil ^[8].

“Tarkvara elutsükkel viitab struktureeritud protsesside ja tegevuste jadale, mis on vajalik tarkvarasüsteemi arendamiseks, hooldamiseks ja kasutusest kõrvaldamiseks.” — ^[9] Teisisõnu kirjeldab elutsükkel seda, kuidas tarkvaratoode läheb ideest üle vananemiseni – hõlmab kõiki projekteerimis-, haldus- ja hooldusetappe. Elutsükkel tagab:

• Järjepidevus: meeskondade ja sidusrühmade ühine raamistik.
• Kvaliteedi tagamine: võimaldab kinnitada ja kinnitada igas etapis.
• Jälgitavus: loob selged seosed nõuete, disaini, koodi ja testide vahel.
• Riskihaldus: pakub kontrollpunkte probleemide varaseks tuvastamiseks ja parandamiseks.
• Skaleeritavus: toetab mitme meeskonna, tehnoloogia ja versiooni integreerimist.

Reguleeritud valdkondades, nagu lennundus, autotööstus ja meditsiiniseadmed, on määratletud elutsükli järgimine ka sertifitseerimise ja vastavuse seaduslik nõue (nt ISO/IEC 12207, DO-178C, ISO 26262).

Erinevad tööstusharud ja projektid võtavad kasutusele konkreetsed elutsükli mudelid, mis põhinevad nende eesmärkidel, riskitaluvusel ja meeskonna struktuuril. Selles peatükis kirjeldatakse kõige laialdasemalt kasutatavaid mudeleid.

Waterfall Model on üks varasemaid ja enim tunnustatud tarkvara elutsükli mudeleid. See järgib lineaarset etappide jada, kus iga faas peab olema lõpetatud enne järgmise algust ^[10].

Eelised:

• Selge struktuur ja dokumentatsioon.
• Lihtne hallata väikeste ja stabiilsete projektide jaoks.
• Sobib reguleeritud keskkondades (nt lennundus, kaitse).

Piirangud:

• Paindumatu muutustele pärast arenduse algust.
• Integratsiooni või nõuetega seotud probleemide hiline avastamine.

Kose lähenemisviisi edasiarendusena rõhutab V-mudel igas arendusetapis testimist ja valideerimist. Igal “alla” sammul (arendusel) on vastav “üles” samm (testimine/valideerimine).

Eelised:

• Tugev keskendumine kontrollimisele ja kinnitamisele (V&V).
• Ideaalne ohutuskriitiliste süsteemide jaoks (nt ISO 26262, DO-178C).
• Pakub jälgitavust projekteerimise ja testimise faaside vahel.

Piirangud:

• Nõuab eelnevalt täpselt määratletud nõudeid.
• Raske kohaneda kiirete muutustega.

Selle asemel, et kogu süsteem ühes järjestuses lõpule viia, arendab iteratiivne mudel toodet mitme tsükli või sammuga. Iga iteratsioon pakub tööversiooni, mida saab üle vaadata ja täpsustada. Eelised:

• Funktsionaalsete prototüüpide varajane tarnimine.
• Lihtsam kohanemine nõuete muutustega.
• Sidusrühmade pidev tagasiside.

Piirangud:

• Suurem integratsioonikulu.
• Võib nõuda keerulist konfiguratsioonihaldust (iga iteratsioon toodab uusi versioone).

Agiilne arendus (nt Scrum, Kanban, Extreme Programming) rõhutab koostööd, kohanemisvõimet ja klientide tagasisidet. See asendab jäigad protsessid iteratiivsete tsüklitega, mida tuntakse sprintidena.

Põhiprintsiibid ^[11]:

• Isikud ja vastasmõju protsesside ja tööriistade üle.
• Töötarkvara üle põhjaliku dokumentatsiooni.
• Kliendikoostöö lepingu läbirääkimistel.
• Muudatustele reageerimine plaani järgides.

Eelised:

• Suur paindlikkus ja klientide kaasatus.
• Pidev väärtuse tarnimine.
• Parem reageerimine turu ja tehnoloogia muutustele.

Väljakutsed:

• Nõuab distsiplineeritud meeskondi ja tugevat suhtlust.
• Vähem sobiv ohutuskriitiliste sertifikaatide jaoks, välja arvatud juhul, kui see on ühendatud hübriidmudelitega (nt Agile + V-mudel).

Boehmi poolt kasutusele võetud ^[12] ühendab spiraalmudel iteratiivse arengu riskianalüüsiga. Iga spiraali silmus esindab protsessi ühte faasi, mille keskmes on riskide hindamine.

Eelised:

• Keskendutakse riskide vähendamisele.
• Sobib suurtele keerukatele süsteemidele.
• Võimaldab järkjärgulist viimistlemist ja paindlikkust.

Piirangud:

• Kompleksne haldus ja dokumentatsioon.
• Nõuab riskianalüüsi asjatundlikkust.

Kaasaegsed süsteemid võtavad üha enam kasutusele DevOpsi – integreerides arenduse, testimise, juurutamise ja toimingud pidevasse tsüklisse. See mudel kasutab automatiseerimist, CI/CD torujuhtmeid ja pilvepõhist elementi

Eelised:

• Kiire ja usaldusväärne kohaletoimetamine.
• Reaalajas jälgimine ja tagasiside integreerimine.
• Kasutusele võetud süsteemide pidev täiustamine.

Väljakutsed:

• Nõuab kultuurilist ja organisatsioonilist ümberkujundamist.
• Nõuab keerukaid tööriistaahelaid ja automatiseerimise infrastruktuuri.

Tarkvaratehnikas tähendab konfiguratsioonihaldus (CM) süstemaatilist protsessi, mille käigus tuvastatakse, korraldatakse, kontrollitakse ja jälgitakse kõiki tarkvarasüsteemis kogu selle elutsükli jooksul tehtud muudatusi. See tagab, et:

• Kasutatakse tarkvarakomponentide õigeid versioone.
• Muudatusi kontrollitakse, vaadatakse üle ja dokumenteeritakse.
• Kogu süsteem jääb järjepidevaks ja reprodutseeritavaks nii meeskondade kui ka keskkondade vahel.

Vastavalt standardile ISO/IEC/IEEE 828:2012 on CM määratletud järgmiselt: “Dipliin, mis rakendab tehnilisi ja administratiivseid juhiseid ja järelevalvet konfiguratsiooniüksuse funktsionaalsete ja füüsiliste omaduste tuvastamiseks ja dokumenteerimiseks, nende omaduste muudatuste kontrollimiseks ning muudatuste töötlemise ja rakendamise oleku registreerimiseks ja sellest teatamiseks.”

Teisisõnu hoiab konfiguratsioonihaldus tarkvara arenemise ajal stabiilsena. Konfiguratsioonihaldus on olemas:

• Tagage jälgitavus – iga muudatuse päritolu saab jälgida (nt nõue, probleemiaruanne või disainimuudatus).
• Kaose vältimine – ilma CM-ita võivad mitmed arendajad üksteise töö üle kirjutada või kasutada ühildumatuid versioone.
• Luba koostöö – ülemaailmselt levitatud meeskonnad saavad töötada sama toote kallal, kasutades ühtseid artefakte.
• Säilitage vastavus – ohutuse seisukohalt kriitilistes valdkondades (autotööstus, lennundus) nõuavad regulatiivsed standardid versioonikontrolli ja muudatuste jälgimist.
• Automatiseerimise tugi – CI/CD torujuhtmed põhinevad versiooniga juhitud hoidlatel ja konfiguratsiooni metaandmetel.

CM-i mõistmiseks tuleb määratleda mitu põhimõistet.

Konfiguratsioonielement (CI) Konfiguratsioonielement on süsteemi mis tahes komponent, mis on konfiguratsioonikontrolli all. Näited:

• Lähtekoodi failid
• Ehitage skripte ja binaarfaile
• Andmebaasid ja konfiguratsioonifailid
• Testige skripte ja aruandeid
• Dokumentatsioon ja nõuete spetsifikatsioonid
• Püsivara või juurutatud konteineri kujutised

Iga CI on kordumatult identifitseeritud, versioonistatud ja aja jooksul jälgitav ^[15].

Algtase Lähtejoon on ühe või mitme konfiguratsiooniüksuse ametlikult kinnitatud versioon, mis toimib võrdluspunktina. Pärast kindlaksmääramist peavad kõik lähtetaseme muudatused järgima määratletud muudatuste juhtimisprotsessi. Alusjoonte tüübid:

• Funktsionaalne baasjoon – arendamiseks heaks kiidetud süsteeminõuded.
• Eraldatud lähtetase – allsüsteemi projekt on lõpetatud ja kinnitatud.
• Toote baasjoon – testitud ja välja antud versioon, mis on tarnimiseks valmis.

Baasjooned loovad stabiilsuse kontrollpunkte elutsüklis ^[16].

Versioonikontroll Versioonikontrollisüsteemid (VCS), nagu Git, Mercurial või Subversion, jälgivad ja haldavad lähtekoodi ja muude failide muudatusi. Need võimaldavad:

• Meeskondlik koostöö.
• Ajalooline jälgitavus.
• Funktsioonide arendamiseks hargnemine ja ühendamine.

Versioonikontroll moodustab konfiguratsioonihalduse tehnilise selgroo.

Muudatuste juhtimine Muudatuste juhtimine määrab, kuidas muudatusi pakutakse, hinnatakse, kinnitatakse ja rakendatakse. Tüüpilised sammud:

• Taotlus – arendaja või sidusrühm esitab muutmistaotluse (CR).
• Mõjuanalüüs – hinnake mõju kuludele, ajakavale ja toimivusele.
• Kinnitamine – muudatuste juhtpaneeli (CCB) vaatab üle ja annab volitused.
• Rakendamine ja kontrollimine – viige läbi ja testige muudatust.
• Dokumenteerimine ja sulgemine – tulemused salvestatakse ja arhiveeritakse.

Selline struktureeritud lähenemine tagab vastutuse ja kvaliteedikontrolli ^[17].

Konfiguratsioonikontroll Konfiguratsiooniaudit kontrollib, et konfiguratsioonielemendid ja dokumentatsioon:

• Sobitage kinnitatud lähtetasemega.
• On läbinud nõutavad kinnitustoimingud.
• On korralikult märgistatud ja jälgitavad.

Kaks levinud tüüpi:

• Funktsionaalse konfiguratsiooni audit (FCA): kinnitab, et funktsionaalsed nõuded on täidetud.
• Füüsilise konfiguratsiooni audit (PCA): kinnitab, et füüsiline konfiguratsioon vastab dokumentatsioonile.

Auditid säilitavad terviklikkuse ja vastavuse, eriti kaitse- ja kosmoseprojektide puhul ^[18].

Kuigi CM toob kaasa struktuuri ja korra, seisab see silmitsi paljude praktiliste väljakutsetega, eriti hajutatud ja keerulistes süsteemides.

Keerukus ja ulatus Kaasaegsed süsteemid võivad sisaldada miljoneid koodiridu, sadu sõltuvusi ja mitut konfiguratsiooni erinevate platvormide jaoks. Kõigi nende variatsioonide käsitsi haldamine on võimatu. Näide: Autonoomne sõiduk võib sisaldada erinevaid konfiguratsioone:

• Arendussimulatsioonid
• Reaalajas manustatud juhtimine
• Pilveanalüütika taustaprogramm

Lahendus: automatiseeritud konfiguratsioonihaldus metaandmetel põhinevate tööriistadega (nt Ansible, Puppet, Kubernetes Helm).

Mitu arendusvoogu Suurte projektide puhul töötavad meeskonnad samaaegselt mitme haru või versiooniga (nt arendus, testimine, väljalaskmine). See suurendab riski:

• Koodide lahknemine ja liitmise konfliktid.
• Sõltuvuste mittevastavus.
• Integratsiooni kitsaskohad.

Lahendus:

• Jõustada hargnemisstrateegiad (GitFlow, tüvipõhine arendus).
• Integreerige CI/CD torujuhtmed automatiseeritud testimiseks ja ehitamiseks.

Riistvara ja tarkvara vastastikused sõltuvused Manus- või küberfüüsilistes süsteemides sõltuvad konfiguratsioonid riistvaravariantidest (protsessorid, andurid, mälu). Tarkvarajärkude ja riistvara spetsifikatsioonide vahelise vastavuse säilitamine on keeruline. Leevendus:

• Säilitage konfiguratsioonimaatriksid, mis vastavad tarkvaraversioonidele riistvaravariantidele.
• Kasutage kontrollimiseks digitaalseid kaksikuid ^[19].

Sagedased uuendused ja pidev kohaletoimetamine DevOpsi ajastul võidakse tarkvara tuhandetes seadmetes mitu korda päevas värskendada. Iga värskendus peab säilitama järjepidevuse ja tagasipööramise võimaluse. Väljakutse:

• Kiiruse tasakaalustamine (Agile/DevOps) koos juhtimisega (ohutus ja sertifikaat).

Lahendus:

• Versioonitud juurutamise torujuhtmed.
• Canary väljalasked ja A/B testimine.
• Muutumatu infrastruktuur (konteinerid ja pildid salvestatakse CI-dena).

Andmete ja konfiguratsiooni triivimine Konfiguratsiooni triiv ilmneb siis, kui süsteemi tegelik olek erineb dokumenteeritud konfiguratsioonist – see on tavaline dünaamilistes pilvepõhistes süsteemides. Põhjused:

• Käsitsi muudatused automaatikast mööda minnes.
• Jälgimata sõltuvused.
• Keskkonnaspetsiifilised alistamised.

Ennetamine:

• Täieliku jälgitavuse tagamiseks kasutage infrastruktuuri koodina (IaC).
• Perioodilised konfiguratsiooniauditid ja vastavuskontroll (nt Chef InSpec, AWS Config).

Regulatiivsed ja vastavusnõuded Sellistes valdkondades nagu lennundus, meditsiin ja autotööstus on konfiguratsioonihaldus vastavusnõue selliste standardite kohaselt nagu ISO/IEC/IEEE 12207, ISO 26262 või IEC 61508 Väljakutse:

• Nõuete, koodi ja testide jälgitavuse säilitamine pidevate muutmistsüklite kaudu.

Lahendus:

• Kasutage integreeritud rakenduse elutsükli halduse (ALM) platvorme (nt IBM DOORS, Siemens Polarion), mis seovad nõuded, kinnitavad ja katsetavad.

Inim- ja organisatsioonilised tegurid CM-i kõige keerulisem aspekt on sageli kultuuriline, mitte tehniline. Tuntud bürokraatia tõttu võivad meeskonnad olla vastu dokumentidele või ametlikule muudatuste kontrollile. Selle tulemusena:

• Muudatused toimuvad ilma läbivaatamiseta.
• Kirjed muutuvad mittetäielikuks.
• Teadmised lähevad käibe käigus kaotsi.

Lahendus:

• Kehtestada selged CM poliitikad ja koolitus.
• Edendada konfiguratsioonidistsipliini kui insenerikultuuri põhiosa.
• Integreerige CM-tavad sujuvalt igapäevastesse töövoogudesse (nt automatiseeritud tõmbamispäringud ja koodiülevaatused).

Konfiguratsioonihaldus (CM) ei ole üksik tegevus, vaid tsükliline protsess, mis on integreeritud kogu tarkvara elutsüklisse. Standard ISO/IEC/IEEE 828:2012 määratleb neli peamist tegevust:

• Konfiguratsiooni identifitseerimine
• Konfiguratsiooni juhtimine
• Konfiguratsiooni oleku arvestus
• Konfiguratsiooni audit

Kaasaegses praktikas lisatakse pidevaks täiustamiseks ja vastavuse tagamiseks ka viies samm – konfiguratsiooni kontrollimine ja ülevaatus.

Konfiguratsiooni identifitseerimine CM-i esimene samm määratleb, mida tuleb hallata. See hõlmab:

• Kõikide konfiguratsiooniüksuste (CI-de) loetlemine (nt kood, dokumendid, teegid, kahendfailid).
• Igale CI-le unikaalse identifikaatori määramine (nt versioonimärgend, järgu ID).
• Nende üksuste struktureerimine konfiguratsioonihierarhiasse.

Näidishierarhia:

Tööriistad ja tehnikad:

• Versioonikontrollisüsteemid: Git, SVN, Mercurial.
• Artefaktide hoidlad: JFrog Artifactory, Nexus.
• Konfiguratsiooniandmebaasid (CMDB-d): ServiceNow CMDB, BMC Helix.

Eesmärk: koostage iga hallatud artefakti ja selle sõltuvuste selge loend.

Tööriistad ja tehnikad:

• Probleemide ja muudatuste jälgimine: Jira, Redmine, Azure DevOps, Bugzilla.
• Koodiülevaatussüsteemid: GitHub Pull Requests, Gerrit, GitLab Merge Requests.
• Töövoo automatiseerimine: Jenkins, GitHub Actions, Bamboo.

Eesmärk: Tagada, et iga muudatus vaadatakse enne rakendamist üle, põhjendatakse ja registreeritakse korralikult.

Konfiguratsiooni oleku arvestus (CSA) CSA annab ülevaate kogu projekti konfiguratsioonide hetkeseisust. See salvestab, millised CI-de versioonid on olemas, kus neid hoitakse ja millised muudatused on toimunud. Tüüpilised väljundid hõlmavad järgmist:

• Versioonide ajalugu ja muudatuste logid.
• Algseisu aruanded.
• Väljalaske dokumentatsioon ja levitamise jälgimine.

Tööriistad ja tehnikad:

• Versiooni aruandluse tööriistad: Git logi, Git tag või kohandatud CI/CD aruanded.
• Automatiseeritud armatuurlauad: Grafana, Kibana, Jenkinsi monitor.
• ALM Suites: IBM Rational Team Concert, Siemens Polarion.

Eesmärk: tagada läbipaistvus ja jälgitavus, et projektijuhid ja audiitorid saaksid igal ajahetkel rekonstrueerida mis tahes tooteversiooni täpse konfiguratsiooni.

Konfiguratsioonikontroll Konfiguratsiooniaudit tagab, et toode vastab algtasemele ja et kõik muudatused on õigesti rakendatud ja dokumenteeritud. See kontrollib:

• Iga konfiguratsiooniüksus vastab selle spetsifikatsioonile.
• Kogu dokumentatsiooni uuendatakse.
• Volitamata muudatusi pole.

On kahte tüüpi:

1. Funktsionaalse konfiguratsiooni audit (FCA): kinnitab, et süsteem töötab ettenähtud viisil.
2. Füüsilise konfiguratsiooni audit (PCA): kinnitab, et füüsiline teostus vastab projekteerimisdokumentatsioonile.

Tööriistad ja tehnikad:

• Automatiseeritud vastavustööriistad: Chef InSpec, OpenSCAP, AWS Config.
• Käsitsi auditid: kontrollnimekirjad ja ülevaatetahvlid.
• Digitaalne kaksikvalideerimine: digitaalsete mudelite võrdlemine juurutatud varadega ^[22].

Eesmärk: tagada terviklikkus, järjepidevus ja vastavus kogu konfiguratsiooni algtaseme ulatuses.

Konfiguratsiooni ülevaatus ja kinnitamine See valikuline samm sulgeb CM-i ahela. See hindab, kas CM protsessid on tõhusad ja projekti eesmärkidega kooskõlas. Tegevused hõlmavad järgmist:

• CM dokumentatsiooni ja kirjete läbivaatamine.
• Tööriista jõudluse ja automatiseerimise ulatuse hindamine.
• Lünkade või ebatõhususe tuvastamine parandamiseks.

Tööriistad:

• CM küpsusmudelid (CMMI, ISO/IEC 15504).
• Kvaliteedijuhtimisplatvormid (nt Atlassian Confluence auditi dokumenteerimiseks).

Eesmärk: Toetada pidevat täiustamist ja protsesside optimeerimist.

Kaasaegne CM toetub suurel määral automatiseerimis- ja integreerimistööriistadele, et hallata keerukust ja jõustada distsipliini meeskondade vahel. Neid tööriistu saab liigitada funktsioonide järgi.

Versioonikontrollisüsteemid (VCS)

Ehitamise ja pideva integreerimise tööriistad

Taristu- ja keskkonnajuhtimine

Artefaktide ja väljalaskehaldus

Konfiguratsiooni jälgimine ja dokumentatsioon

Näide – integreeritud CM-i töövoog:

Tööriistaahela integreerimine autonoomsete süsteemide jaoks Autonoomsetes platvormides (nt mehitamata õhusõidukid, sõidukid) on CM-tööriistad sageli integreeritud:

• Simulatsioonitööriistad (Gazebo, CARLA) versioonide testimiseks.
• Digitaalsed kaksikud tegeliku käitumise kinnitamiseks.
• Edge juurutussüsteemid õhu kaudu (OTA) värskenduste jaoks.

See hübriidlähenemine tagab järjepideva tarkvara kõigis sõlmedes – alates pilveteenustest kuni manustatud kontrolleriteni ^[23].

Isegi täiskasvanud organisatsioonid seisavad sageli silmitsi elutsükli ja konfiguratsioonihalduse väljakutsetega:

Organisatsioonid, kellel õnnestub CM tavasid juurutada, ei pea neid bürokraatiaks, vaid usaldusväärsuse ja usalduse võimaldajaks.

Tüüpiline autonoomia tarkvarapakk on jaotatud hierarhilisteks kihtideks, millest igaüks vastutab teatud funktsioonide alamhulga eest – alates madala taseme anduri juhtimisest kuni kõrgetasemelise otsuste tegemise ja sõidukipargi koordineerimiseni. Kuigi rakendused on erinevates valdkondades (maapealne, õhust, merest) erinevad, jääb põhiline arhitektuuriloogika sarnaseks:

• Tajukiht – keskkonna tunnetamine ja mõistmine.
• Localisation Layer – asukoha ja orientatsiooni määramine.
• Planeerimiskiht – otsustamine, milliseid toiminguid teha.
• Juhtkiht – nende toimingute teostamine täiturmehhanismide kaudu.
• Süsteemikiht – side, riistvara ja käitusaja haldamine.
• Infrastruktuurikiht – pakub simulatsiooni, pilveteenuseid ja DevOpsi.

See kihiline disain ühtib tihedalt nii robootikaraamistikega (ROS 2) kui ka autotööstuse arhitektuuridega (AUTOSAR Adaptive).

Joonisel 1 on kujutatud peamised tarkvarakihid ja nende funktsioonid.

Riistvara abstraktsioonikiht (HAL) HAL pakub standardset juurdepääsu riistvararessurssidele. See teisendab riistvaraspetsiifilised üksikasjad (nt andurite sideprotokollid, pingetasemed) tarkvaraga juurdepääsetavateks API-deks. See funktsioon sisaldab tavaliselt järgmist:

• LiDAR-i, radarite, kaamerate, IMU-de ja muude autonoomse süsteemi jaoks vajalike seadmete draiverite haldamine.
• Toitesüsteemide ja diagnostika jälgimine, mis sisaldab vajadusel käitumise muutmise käivitajaid.
• Ajatempliga andurite andmevoogude pakkumine. Reaalajas või ajatembeldatud andmed on mis tahes andmepõhise süsteemi oluline osa, et tagada aegridade analüüsi algoritmide, sealhulgas süvaõppe meetodite õige töö.
• Täiturmehhanismide (mootorid, servod, pidurid) reaalajas juhtimine.

HAL tagab teisaldatavuse — tarkvaramoodulid jäävad teatud riistvaramüüjate või konfiguratsioonide suhtes agnostiliseks ^[26].

Operatsioonisüsteem (OS) ja virtualiseerimiskiht OS-i kiht haldab riistvararessursse, protsesside ajastamist ja protsessidevahelist suhtlust (IPC), samuti reaalajas töötamist, hoiatusi ja päästikute tõstmist, kasutades valvekoera protsesse. Siin on andmetöötluse paralleelsus üks võtmeid ressursside tagamisel ajakriitiliste rakenduste jaoks. Autonoomsed süsteemid kasutavad sageli:

• Linux (Ubuntu või Yocto-põhine) paindlikkuse tagamiseks.
• Reaalajas operatsioonisüsteemid (RTOS) nagu QNX või VxWorks ohutuskriitilise ajastuse jaoks.
• Konteinerimine (Docker, Podman) tarkvara isoleerimiseks ja modulaarseks juurutamiseks.

Time-Sensitive Networking (TSN) laiendused ja PREEMPT-RT plaastrid tagavad missioonikriitiliste ülesannete deterministliku ajastamise