Кіріспе
Заңмен бекітілген қауіпсіздік және сенімділік талаптары бар кіріктірілген бағдарламалық жасақтама.
Авиациялық бағдарламалық жасақтама – авиация техникасында қолданылатын, заңмен бекітілген қауіпсіздік және сенімділік талаптары бар кіріктірілген бағдарламалық жасақтама. Авионикалық бағдарламалық қамтамасыз ету мен дәстүрлі кіріктірілген бағдарламалық қамтамасыз етудің басты айырмашылығы – әзірлеу процесі заңмен міндетті және қауіпсіздікке бағытталған. Төменде сипатталған процесс коммерциялық бағдарламалық жасақтама үшін қолданылатын әдеттегі процестерге қарағанда шамалы ғана баяу және қымбатқа түсуі мүмкін (шамамен 15 пайыз). Көптеген бағдарламалық жасақтамалар қателерге байланысты сәтсіздікке ұшырайтындықтан, қателерді ең ертерек кезеңде жою – бағдарламалық жасақтаманы жасаудың салыстырмалы түрде арзан және сенімді жолы. Дегенмен, кейбір жобаларда техникалық тапсырмадағы қателер енгізілгенге дейін анықталмайды. Мұндай жағдайда оларды түзету өте қымбатқа түсуі мүмкін. Кез келген бағдарламалық жасақтаманы әзірлеу моделінде жобалау процесінің әр қадамы "жеткізілімдер" деп аталады. Егер жеткізілімдер дұрыстығына тексеріліп, түзетілсе, қарапайым қателер қауіпті немесе қымбат проблемаларға айналуы қиын. Көптеген өндірушілер жобалау өнімдерін үйлестіру үшін каскадты модельді қолданады, бірақ олардың көпшілігі бұрынғы жұмысты қайта қарауға рұқсат береді. Нәтижесі көбінесе спиральді модельге жақын болады. Кіріктірілген бағдарламалық жасақтама туралы толық мәліметтер үшін кіріктірілген жүйелер және бағдарламалық жасақтаманы әзірлеу модельдерін қараңыз. Осы мақаланың қалған бөлігі осы ақпаратты білуді болжайды және коммерциялық кіріктірілген жүйелер мен коммерциялық даму модельдері арасындағы айырмашылықтарды талқылайды.
Жалпы шолу
Көптеген авиаэлектроника өндірушілері бағдарламалық жасақтаманы салмақ қосылмай құндылықты арттыру жолы ретінде қарастыратындықтан, авиаэлектроника жүйелеріндегі кіріктірілген бағдарламалық жасақтаманың маңызы артып келеді. Көптеген қазіргі заманғы автопилотты коммерциялық ұшақтар ұшу компьютерлерін және ұшуды басқару жүйелерін (FMS) пайдаланады, олар ұшудың белгілі бір кезеңдерінде ұшқыштың тікелей араласуынсыз ұшақты басқара алады. Сондай-ақ, әзірленуде немесе өндірісте ұшқышсыз аппараттар: зымырандар мен дрондар бар, олар ұшқышсыз ұшуға, круиздік режимде ұшуға және қонуға қабілетті. Мұндай жүйелердің көпшілігінде қателіктерге жол беруге болмайды. Әуедегі көлік құралдарында (әскери немесе азаматтық) қолданылатын бағдарламалық жасақтаманың сенімділігін әуедегі апаттардың көпшілігі адам жасаған қателіктерден туындайтыны көрсетеді. Айынықса, сенімді бағдарламалық жасақтама әрқашан қолдануға оңай немесе түсінікті бола бермейді, нашар пайдаланушы интерфейсі дизайны көптеген әуе-ғарыш апаттары мен өлім-жітімдеріне себеп болған.
Регламенттік мәселелер
Қауіпсіздік талаптарына байланысты көптеген елдер авиациялық құрал-жабдықтарын реттейді немесе кем дегенде одақтас елдер тобы немесе кеден одағы қолданатын стандарттарды қабылдайды. Халықаралық авиация дамуына ең көп әсер ететін үш реттеуші ұйым – АҚШ, Еуроодақ және Ресей. АҚШ-та авиациялық және басқа да ұшақ құрауларының қауіпсіздік және сенімділік стандарттары Федералдық авиациялық ережелерде, Көліктік ұшақтар үшін 25-бөлімде, Шағын ұшақтар үшін 23-бөлімде және Вертолеттер үшін 27 және 29-бөлімдерде белгіленген. Бұл стандарттарды FAA-ның «тағайындалған инженерлік өкілдері» сақтайды, олар әдетте өндірушілермен төленеді және FAA-мен сертификатталған. Еуроодақта IEC қауіпсіздікке маңызды жүйелерге қатысты «ұсынылған» талаптарды сипаттайды, оларды үкіметтер әдетте өзгеріссіз қабылдайды. Қауіпсіз және сенімді авиациялық құралдар «CE белгісімен» таңбаланады. Бұл реттеушілік жүйе АҚШ және Канададағы өрт қауіпсіздігіне ұқсас. Үкімет сынақ зертханаларын сертификаттайды, ал зертханалар өндірілген өнімдерді және ұйымдарды сертификаттайды. Негізінен, инженерлік бақылау үкімет пен өндірушіден сынақ зертханасына ауыстырылады. Қауіпсіздік пен сенімділікті қамтамасыз ету үшін ұлттық реттеуші органдар (мысалы, FAA, CAA немесе DOD) бағдарламалық жасақтаманы әзірлеу стандарттарын талап етеді. Кейбір стандарттар әскери жүйелер үшін MIL STD 2167, ал азаматтық авиация үшін RTCA DO 178B және оның жаңа нұсқасы DO 178C болып табылады. Бұл бағдарламалық жасақтамаға қойылатын талаптар басқа бағдарламалық жасақтамаға қарағанда қымбатқа түсуі мүмкін, бірақ қажетті қауіпсіздікті қамтамасыз ету үшін олар әдетте ең төменгі деңгей саналады.
Даму процесі
Авионика бағдарламалық жасақтамасы мен басқа кіріктірілген жүйелердің басты айырмашылығы – нақты стандарттар көбінесе коммерциялық стандарттардан әлдеқайда толық және қатаң болады, олар әдетте жүздеген беттен тұратын құжаттармен сипатталады. Ол әдетте нақты уақыт операциондық жүйеде іске қосылады. Бұл процесс заңмен міндетті болғандықтан, көптеген процестерде талаптарды техникалық ерекшеліктер мен жобалардағы нөмірленген абзастардан бастап, кодтың нақты бөліктеріне дейін, оларға сәйкес нақты сынақтармен және соңғы сертификаттау тізіміндегі белгілі бір пункттерге дейін іздеуге арналған құжаттар немесе бағдарламалық жасақтама болады. Мұның мақсаты – заңмен бекітілген стандартқа сәйкестілікті дәлелдеу. Балама әдістерді пайдалану немесе қауіпсіздік деңгейінің талаптары төмен болған жағдайларда, нақты жобалар үшін осы сипатталған процестерден ауытқулар болуы мүмкін. Бағдарламалық жасақтаманы әзірлеудің барлық стандарттары дерлік, техникалық ерекшеліктерді, жобалауды, кодтауды және сынауды қалай орындау және жақсарту жолдарын сипаттайды (Бағдарламалық жасақтаманы әзірлеу моделіне қараңыз). Дегенмен, авионика бағдарламалық жасақтамасын әзірлеу стандарттары қауіпсіздік пен сертификаттау үшін әзірлеу процесіне қосымша қадамдар енгізеді.
Адам интерфейстері
Адаммен тікелей байланысы бар жобалар көбінесе прототиптеледі немесе модельделеді. Видеожазба әдетте сақталады, бірақ прототип сынақтан өткен соң дереу қолданудан шығарылады, себебі басшылық пен клиенттер жүйе дайын деп ойлауы мүмкін. Басты мақсат – қауіпсіздік пен қолдануға ыңғайлылыққа әсер ететін адам-интерфейсі мәселелерін анықтау.
Қауіптерді талдау
Қауіпсіздікке маңызды авиациялық жүйелерде әдетте қауіптерді талдау жүргізіледі. Жобаның бастапқы кезеңдерінде жобаның негізгі бөліктері туралы жалпы түсінік қалыптасады. Инженер блок-схеманың әрбір блогын қарастырып, осы блокпен қандай ақаулар болуы мүмкін екенін және олардың жүйеге қалай әсер ететінін зерделейді. Содан кейін қауіптердің салдары мен орын алу ықтималдығы бағаланады. Осы мәселелер дизайнның техникалық талаптарына енгізіледі. Әскери криптографиялық қауіпсіздікті қамтитын жобалар көбінесе қауіптерді талдауға ұқсас қауіпсіздік талдауын қамтиды.
Техникалық қызмет көрсету нұсқаулығы
Инженерлік сипаттама толыққаннан кейін техникалық қызмет көрсету жөніндегі нұсқаулықты жазуға кірісуге болады. Техникалық қызмет көрсету жөніндегі нұсқаулық жөндеу үшін өте маңызды, және әрине, егер жүйені жөндеу мүмкін болмаса, ол қауіпсіз болмайды. Көптеген стандарттар бірнеше деңгейден тұрады. Ұшу кезіндегі ойын-сауық құрылғысы (ұшақ ішіндегі теледидар) сияқты қауіпсіздігі төмен өнімдер схемасымен және орнату мен реттеу процедураларымен ғана шектелуі мүмкін. Навигациялық жүйе, автопилот немесе қозғалтқыш процедуралардың, тексерулердің және құрастыру нұсқауларының мыңдаған беттерін қамтуы мүмкін. Құжаттар қазір (2003 жыл) әдетте мәтін мен суреттерді қамтитын стандартты форматтағы CD-ROM дискілерінде жеткізіледі. Құжаттама талаптарының бірі – көптеген коммерциялық шарттар жүйелік құжаттаманың белгісіз мерзімге қолжетімді болатынына кепілдік беруді талап етеді. Бұл кепілдікті берудің кәдімгі коммерциялық тәсілі – кішкентай қор немесе траст құру және оны қаржыландыру. Содан кейін траст пошта жәшігін ұстап, көшірмелерді (әдетте ультрафишкада) қауіпті жерге, мысалы университет кітапханасындағы жалға алынған орынға (арнайы коллекция ретінде басқарылады) немесе (қазіргі уақытта сирек кездеседі) үңгірге немесе шөлге орналастырады.
Жобалау және техникалық сипаттама құжаттары
Олар көбінесе басқа бағдарламалық жасақтаманы әзірлеу үлгілеріндегідей болады. Маңызды айырмашылық талаптардың жоғарыда сипатталғандай іздестірілуінде. Ірі жобаларда талаптарды іздестіру өте үлкен және қымбат жұмыс болып табылады, оны басқару үшін үлкен және қымбат компьютерлік бағдарламалар қажет.
Кодты жасау және қайта қарау
Код жазылады, содан кейін оны әдетте бастапқыда жазбаған бағдарламашы (немесе бағдарламашылар тобы, көбінесе тәуелсіз) қарап шығады (бұл тағы бір заңды талап). Арнайы ұйымдар да көбінесе мүмкін қателіктердің тізімімен кодты тексеріп шығады. Жаңа түрдегі қате табылды десе, ол тізімге қосылып, кодтың барлық бөлігінде түзетіледі. Кодты дұрыстығын талдайтын арнайы бағдарламалар (Статикалық кодты талдау) жиі тексереді, мысалы, SPARK (Ada бағдарламалау тілінің кіші жиынтығы) немесе C бағдарламалау тілдері отбасы үшін lint (көбінесе C тілі үшін). Компиляторлар немесе "lint" сияқты арнайы тексеру бағдарламалары деректер түрлері оларға қолданылатын операциялармен сәйкес келе ме екенін тексереді. Сондай-ақ, осындай құралдар бағдарламалау тілінің дұрыс кіші топтарын және бағдарламалау стильдерін қатаң сақтау үшін жүйелі түрде қолданылады. Тағы бір бағдарламалар жиынтығы бағдарламалық метрикаларды өлшейді, кодтың қате болуы мүмкін бөліктерін анықтау үшін. Барлық мәселелер түзетіледі немесе, кем дегенде, түсініліп, қайта тексеріледі. Кейбір кодтар, мысалы, цифрлық сүзгілер, графикалық интерфейстер және инерциялық навигациялық жүйелер, соншалықты жақсы түсінілгендіктен, бағдарламалық жасақтаманы жазу үшін арнайы құралдар жасалған. Мұндай жағдайларда, техникалық ережелер жасалады және сенімді бағдарламалық жасақтама автоматты түрде құрылады.
Бөлшекті сынау
"Бөлімдік тест" коды кодтың әрбір нұсқауын кемінде бір рет орындау үшін, 100% кодты қамтуды қамтамасыз ету мақсатында жазылады. "Қамту" құралы әдетте әрбір нұсқаудың орындалғанын тексеру үшін қолданылады, содан кейін тест қамтуы заңдық себептермен құжатталады. Бұл тесттер ең тиімділерінің қатарына жатады. Олар бағдарлама логикасын егжей-тегжейлі қарауға итермелейді және көптеген кодтау, компиляция және кейбір жобалау қателерін анықтайды. Кейбір ұйымдар кодты жазудың алдында бөлімдік тесттерді жазады, бағдарламалық жасақтаманы модульдік сипаттама ретінде пайдаланады. Бөлімдік тест коды орындалады және барлық мәселелер түзетіледі.
Интеграциялық сынақ
Кодтың бөліктері қолжетімді болған кезде, олар кодтың негізгі құрылымына (қаңқасына) қосылады және әр интерфейстің дұрыс жұмыс істейтінін тексеру үшін сынақтан өтеді. Әдетте, электрониканың ішкі сынақтарын бірінші болып аяқтаған жөн, содан кейін электрониканың қыздыру және радио толқындарының шығарылу сынақтарын бастау керек. Келесі кезекте бағдарламалық қамтамасыздандырудың ең маңызды мүмкіндіктері біріктіріледі. Интеграторлар үшін кодтың шағын, таңдалған бөліктерін орындау мүмкіндігі, мысалы, қарапайым мәзірлік жүйе арқылы, өте ыңғайлы. Кейбір бағдарлама басқарушылары осы біріктіру процесін осылай ұйымдастыруға тырысады: қандай да бір минималды деңгейдегі функционалдық мүмкіндіктер орындалғаннан кейін, жүйе кез келген уақытта тапсырылатын болады, ал уақыт өте келе мүмкіндіктер саны арта түседі.
Қара қорап және қабылдау сынағы
Осы уақытта, сынақ инженерлері әдетте сынақ стендін құрастыруды бастайды және бағдарламалық жасақтама инженерлеріне алдын ала сынақтарды ұсынады. Бір кезде, сынақтар инженерлік ерекшелемелердегі барлық функцияларды қамтиды. Осы сәтте, авиаэлектрондық блоктың толық сынағы басталады. Қабылдау сынағының мақсаты – блоктың қауіпсіз және сенімді жұмыс істейтінін растау. Бағдарламалық жасақтаманың алғашқы және тар мерзімде орындалуы ең қиын сынақтарының бірі – құрылғының радиоэмиссиясын шынайы түрде тексеру. Бұл, әдетте, электрондық құрылғының дизайнына қажетті өзгерістер енгізуге уақыт жететініне көз жеткізу үшін жобаның басында басталуы тиіс. Бағдарламалық жасақтама сондай-ақ құрылымдық жабуды талдаудан өтеді, онда сынақтар жүргізіледі және кодтық жабу жиналып, талданады.
Сертификаттау
Әрбір қадам нәтиже береді, яғни құжат, код немесе сынақ есебі дайындалады. Бағдарламалық жасақтама барлық сынақтардан сәтті өткеннен кейін (немесе қауіпсіз сатуға жеткілікті болса), бұл деректер сертификаттау есебіне біріктіріледі, ол мыңдаған беттен тұруы мүмкін. Содан кейін, аяқтауға тырысқан белгіленген инженерлік өкіл нәтиженің қабылдануға лайықты екендігіне шешім шығарады. Егер нәтиже жарамды деп табылса, ол оған қол қояды, соның арқасында авиациялық бағдарламалық қамтамасыз ету сертификатталады.