Разработка на критични системи

Software Engineering, 7th edition. Chapter 20 Slide 1

Разработка на критични системи


Цели

Да обясни как възстановяването след грешки и избягването им допринася за разработката на надеждни с-ми.

Да опише характеристиките на надежден софтуерен процес.

Да направи въведение в техниките за избягване на грешки.

Да опише механизмите за възстановяване след грешки и използването за това на разнообразие и излишък.


Теми

Надежден процес Надеждно програмиране Нечувствителност към грешки Архитектури за възстановяване


Надеждност на софтуера

Като цяло, клиентите очакват целият софтуер да бъде надежден. Но за некритични приложения, те може да приемат и някои грешки.

Някои приложения имат много високи изисквания по отношение на надеждност и трябва да се използват специални софтуерни техники, за да се постигнат.


Достигане на надеждност

Избягване на грешки• С-мата е разработена по такъв начин, че се избягват

човешки грешки и по този начин се минимизират грешките в с-мата

• Процесът на разработка е така организиран, че грешките в системата се откриват и поправят преди доставката на клиента.

Откриване на грешките• Използват се техники за верификация и валидиране,

за да се открият и премахнат грешките преди предаването на с-мата

Нечувствителност към грешки• С-мат е проектирана така, че софтуерна грешка да не

води до срив на с-мата.


Разнообразие и излишък

ИзлишъкПази се повече от 1 версия на компонента така, че ако тя

се скапе да има на разположение последната работеща версия

РазнообразиеЕдна и съща функционалност се осъществява по

различни начини, така че да не се сринат по един същ начин или в един и същ момент

Но, добавянето на разнообразие и излишък увеличава сложността и с това увеличава вероятността за грешки.

Някои инженери препоръчват простота и екстензивен V & V като по ефективен път за постигане на надеждност.


Примери за разнообразие и излишък

Излишък. Където е критична достъпността (напр. в с-ми за електронна търговия), компаниите обикновено поддържат бекъп сървъри и при срив превключват автоматично на тях.

Разнообразие. Могат да се реализират различни сървъри, които използват различни операционни с-ми (напр. Windows и Linux), за да бъде с-мата устойчива срещу външни атаки.


Софтуер без грешки

Съвременните методи на софтуерното инженерство позволяват производството на с-ми без грешки, като това важи най-малко за относително малки с-ми.

Софтуер без грешки означава, че софтуерът отговаря на спецификациите си. това не означава, че софтуерът винаги работи правилно, защото може да има грешки в спецификациите.

Разходите за производство на такъв софтуер са много високи. Това е изгодно само в изключителни ситуации. Често е по-евтино да се приемат грешки и да се плати за техните последствия.


Разработка на софтуер без грешки

Надежден софтуерен процес Управление на качеството. Формални спецификации Статична верификация Силно типизиране Strong typing Безопасно програмиране Защитена информация (капсулиране)


Разходи за отстраняване на грешките

FewNumber of residual errors

Many Very few


Надеждни процеси

С цел да се осигури минимален брой грешки, е важно да имаме добре дефиниран, повторяем софтуерен процес.

Добре дефинираният повторяем процес е този, който не зависи изцяло от индивидуалните способности; а може да бъде изпълнен от различни хора.

Ясно е, че процесът трябва да изисква значителни усилия за V&V за откриване на грешките.


Характеристики на надеждния процес

Да може да се документира

Процесът трябва да има дефиниран модел, който задава дейностите в процеса и документацията, която трябва да се напише по време на тези дейности

Стандартизиран Трябва да има разбираемо множество от стандарти, които дефинират, как трябва да се произвежда софтуера и документацията.

Проверяем Процесът трябва да е разбираем от външни на процеса хора, които могат да проверяват дали се следват стандартите и да правят предложения за подобряване на процеса..

Разнообразен Процесът трябва да включва разнообразни и с излишък дейности по V&V.

Робаст Процесът трябва да е способен да се възстановява при несполуки в отделните дейности


Дейности по избягване и нечувствителност към грешки

Инспекция на изискванията Управление на изискванията Проверка на модела Инспекция на проекта и на кода Статичен анализ Планиране и управление на тестовете Управление на конфигурацията.


Надеждно програмиране

Да се използват програмни конструкции и техники, които допринасят за избягването на грешки и нечувствителност към такива.• Проектиране на прости решения• Защита на информацията от неправомерен

достъп.• Минимизиране на използването на опасни

програмни структури


Защита на информацията

Информацията трябва да е достъпна само за тези части от програмата, които имат нужда от нея. Това предизвиква създаването на обекти или абстрактни типове от данни, които поддържат състояние и имат операции в/у това състояние.

Това води до избягване на грешки по 3 причини:• намалява се вероятността от случайна повреда на

информацията;• информацията е оградена от "защитни стени" което

намалява вероятността от разпространение на проблемите;• тъй като информацията е локализирана, по-малко е

вероятно разработчикът да направи грешки и е по-вероятно проверяващият да ги открие.


Спецификация на опашка в Java


Декларация на Signal в Java


Безопасно програмиране

Дефектите в програмите са обикновено последица от грешки на програмиста.

Тези грешки възникват, защото хората често не могат да проследят връзките м/у променливите в програмата.

Някои програмни структури са по-предразположени към грешки от останалите, така че избягването им намалява грешките при програмирането.


Структурно програмиране

За първи път предложено през 1968 като подход, който прави програмите по-лесни за разбиране, с което се избягват програмните грешки.

Програмиране без goto Цикъла While и операторът If са единствените

управляващи структури. Проектиране отгоре-надолу Важна стъпка, която накара хората да се

замислят и да дискутират въпросите на програмирането.


Структури предразположени към грешки

Числа с плаваща запетаяНеточността им е присъща. Може да доведе до

неправилни сравнения. Указатели

Указатели, които сочат към неправилно място в паметта могат да повредят данните. Използването на псевдоними може да направи програмите трудни за разбиране и промяна.

Динамично заемане на паметЗаемането на памет по време на изпълнение може да

предизвика препълване на паметта. Паралелизъм

Може да предизвика коварни грешки поради недовидяно взаимодействие м/у паралелните процеси.

РекурсияГрешките тук могат да доведат до препълване на паметта.


Структури предразположени към грешки

ПрекъсванияТе могат да причинят прекъсването на критични операции и

правят програмата трудно разбираема. Наследяване

Кодът не е локализиран. Това може да доведе до неочаквано поведение, когато се правят промени и създава проблеми на разбирането.

Използване на псевдонимиИзползването на повече от 1 име за един и същ обект.

Масиви без границиАко не се прави проверка на границите на масива, може

да се получи препълване на буфер. Обработка на входа по подразбиране

Действие на въвеждане на данни, което се извършва независимо от входа на програмата.


Обработка на изключенията Програмното изключение е грешка или

неочаквано събитие като прекъсване на захранването.

Обработката на прекъсванията позволява такива събития да бъдат обработени без да се налага непрекъсната проверка на състоянието, за да се открие изключението.

Използването на нормални управляващи структури за откриване на изключението изисква много допълнителни оператори, което води до претрупване и е потенциално предразположено към грешки.


Изключения в Java 1


Изключения в Java 2


Термостат

Изключенията могат да се използват като нормална програмна техника, а не само като начин постигане на нечувствителност към грешки.

Пример. Термостат на фризер, който поддържа температурата в даден интервал.

Включва и изключва компресора на фризера. Включва аларма, ако се надмине максимално

разрешената температура. Използва изключенията като нормална техника

за програмиране.


Термостат 1


Термостат 2


Нечувствителност към грешки Софтуерните с-ми трябва да могат да се

възстановяват в критични ситуации. Нечувствителността към грешки е нужно когато

има изискване за достъпност или когато срив нас-мата има висока цена.

Нечувствителност към грешки означава, че с-мата може да продължи да работи въпреки появяването на грешка.

Дори когато за с-мата е било доказано, че отговаря на спецификацията си, тя трябва да е нечувствителна към грешки, защото може да има неточности в спецификацията или процесът на валидиране да е бил неправилен.


Действия за постигане на нечувствителност

Откриване на грешкатаС-мата трябва да открие, че настъпила грешка

(неправилно състояние). Оценка на вредите

Трябва да се определят частите от системното състояние, засегнати от грешката.

ВъзстановяванеС-мата трябва да се възстанови до познато безопасно

състояние. Поправка на грешката

С-мата трябва да се промени, за да се предотврати ново появяване на грешката. Тъй като много софтуерни грешки са мимолетни, това често не е необходимо.


Откриване на грешката и оценка на вредите

Първият етап е да се определи, че се проявила или ще се прояви грешка ( грешно състояние на с-мата).

Откриването на грешка включва дефинирането на ограничения, на които трябва да отговарят всички допустими състояния и да се проверява състоянието за удовлетворяване на тези ограничения.


Ограничения за инсулинова помпа


Откриване на грешката

Превантивно откриванеМеханизмът за откриване на грешката се

включва преди да се извърши промяна на състоянието. Ако се открие грешно състояние, промяната не се извършва.

Ретроспективно откриванеМеханизмът за откриване на грешката се

включва след промяната на състоянието. То се използва, когато неправилна последователност от правилни действия води до грешно състояние или когато превантивното откриване е твърде е ресурсоемко.


Превантивното откриване на грешки в действителност разширява с-мата от типове, като до се добавят допълнителни ограничения като част от дефиницията на типа.

Тези ограничения се реализират чрез дефиниране на базови операции в дефиницията на класа.

Разширение на с-мата от типове


PositiveEvenInteger 1


PositiveEvenInteger 2


Оценка на вредите

Анализира се системното с-яние, за да се прецени степента на увреждане предизвикано от срива на с-мата

Оценката трябва да провери, кои части от пространството на с-янието е било засегнато.

Обикновено се основава на "функции на валидност", които могат да се приложат за елементите на с-янието, за да оценят дали стойностите им са в зададен интервал.


Robust array 1


Robust array 2


При пренасяне на данни се използват контролни суми.

За проверка на интегритета на структурите от данни се използват допълнителни указатели.

За незавършващи процеси се използват наблюдаващи (Watch dog) таймери. Ако известно време няма отговор, се предполага, че има проблем.

Техники за оценка на вредата


Възстановяване напредПрилага поправките към повреденото състояние

Възстановяване назадВъзстановява с-мното с-яние към познато безопасно с-

яние Възстановяването напред е обикновено

специфично за приложението – изисква се познание на областта, за да се изчислят възможни корекции на с-янието.

Възстановяването назад е по=просто.Поддържат се подробност за безопасните с-яния и с някое от тях се замества повреденото състояние.

Възстановяване от грешка и поправяне


Повреда на кодирани данни• Кодиращи техники, които добавят излишък, могат да

се използват при поправяне на данни повредени по време на пренос.

Допълнителни указатели• Когато се използват допълнителни указатели в

структурите данни (напр. дву-свързан списък), то повреденият списък или файлова с-ма може да се изгради наново, ако има достатъчен брой неповредени указатели.

• Често се използват при баси от данни и файлови с-ми.

Възстановяване напред


Транзакциите са често използван метод. Промените не се прилагат докато не завърши изчислението. Ако се настъпи грешка, с-мата се оставя в с-янието преди транзакцията.

Периодични контролни точки позволяват с-мата да се върне в "добро" с-яние.

Възстановяване назад


Безопасна процедура за сортировка

Операция за сортиране, която следи собственото си изпълнение и оценява, дали сортировката е била коректно изпълнена.

Тя поддържа копие на входните данни и ако възникне грешка последните не са повредени.

Основава се на идентифициране и обработка на изключения

Тя е възможна в този случай, защото се знае условието за 'правилна' сортировка. Но в много случаи е трудно да се напишат проверки за правилност.


Safe sort 1


Safe sort 2


Архитектура, нечувствителна към грешки

Защитното програмиране не може да се справя със с-ми, включващи взаимодействие м/у софтуера и хардуера

Неразбирането на изискванията може да доведе до това, че проверките и свързания с код са некоректни.

Когато с-мите имат силни изисквания за достъпност, може да се изисква специфична архитектура, проектирана да бъде нечувствителна към грешките.

Това важи из хардуера и софтуера.


Нечувствителност нас хардуера

Използва се троен излишък на модулите (TMR). Иам3 идентични компоненти, които получават

един и същ вход и изходите им се сравняват Ако един изход е различен, той се отхвърля и се

приема срив на компонентата. Основава се на това, че повечето грешки са

причинени от сривове в компонентите, не от проектни грешки и вероятността за едновременен срив на 2 компоненти е много ниска.


Надеждност на хардуер с TMR

A2

A1

A3

Outputcomparator


Избор на изхода

У-вото за сравняване на изходите е сравнително просто.

То сравнява входните (за него) сигнали и ако един е различен, го отхвърля. Изборът на истинския изход се решава от болшинството еднакви сигнали.

У-вот е свързано с управлението на грешките, което може да се опита да поправи грешащото у-во или да го изключи от с-мата.


Софтуерни архитектури, нечувствителни към грешки

Успехът TMR се базира на 2 предположения:• Хардуерните компоненти нямат общи проектни

грешки;• Компонентите дефектират случайно и вероятността

за едновременна грешка е много ниска. Никое от тези предположения не е вярно за

софтуера:• Не е възможно де се копира компонентата, тъй като

тя може да има проектни грешки• Следователно едновременния отказ на компонентите

е напълно възможен и неизбежен. Следователно софтуерните с-ми трябва да са

разнообразни (с различни компоненти).


Проектиране на разнообразието

Проектират се различни версии на с-мата и се осъществяват по различни начини. Следователно има различен моменти на отказ.

Различни проектни подходи (напр. обектно-ориентиран и функционален)• Осъществяване на различни програмни езици;• Използване на различни средства и програмни среди;• Използване на различни алгоритми


Софтуерни аналогии на TMR

N-версии• Различни екипи осъществяват няколко версии по една

и съща спецификация. Всички версии работят едновременно и изходът се избира с болшинство.

• Това е на използвания подход, напр. в много от моделите на Airbus.

Блокове за възстановяване• Няколко явно различни версии на една и съща

спецификация са написват и изпълняват последователно.

• Използва се тест за приемливост, за да се избере валидния изход.


N-версии

Version 2

Version 1

Version 3

Outputcomparator

N-versions

Agreedresult

Faultmanager

Input


Сравнение на изходите

Както при хардуерните с-ми, модулът за сравнение е прост и използва същия механизъм за избор на изхода.

В с-мите с реално време трябва да има изискване, че всички версии изработват резултат в определен времеви интервал.


N-версии

Различните версии се проектират и разработват от различни екипи. Предполага се, че вероятността да допуснат едни и същи грешки е малка. Алгоритмите би трябвало, но не задължително, да са различни

Има емпирични данни, че екипите по-един същ начин схващат погрешно спецификациите и избират един и същ алгоритъм в техните с-ми.


Блокове за възстановяване

Acceptancetest

Algorithm 2

Algorithm 1

Algorithm 3

Recovery blocks

Test forsuccess

Re-testRetry

Re-test

Try algorithm1

Continue execution ifacceptance test succeedsSignal exception if allalgorithms fail

Acceptance testfails – retry


Блокове за възстановяване

Тук е задължително да се използва различен алгоритъм за всяка версия, така че се намалява вероятността за общи грешки.

Но проектирането на теста за приемане е труден и трябва да е независим от използваните изчисления.

Този подход има проблеми в с-мите с реално време поради последователното изпълнение на допълнителните версии.


Проблеми с проектирането на разнообразие

Културата на екипите е подобна, затова те общо взето подхождат към проблемите по един и същи начин.

Характерни грешки• Различните екипи правят същите грешки. Някои части

от осъществяването са по-трудни и затова е по-вероятно екипите там да допуснат грешка.

• Грешки в спецификацията:• Ако има грешки в спецификацията, тя се отразява във

всички версии.• Това може да се избегне в известна степен, като се

използват различни представяния на спецификацията.


Надеждност на спецификацията

И двата подхода са податливи на грешките в спецификацията. Ако спецификацията е грешна, то и с-мата ще е грешна.

Това също е и хардуерен проблем, но софтуерните спецификации са по-сложни и по трудни за валидиране.

Това може да се избегне в някои случаи, като от една потребителска спецификация се разработят няколко системни такива.


Надеждността на една с-ма може да бъде постигната чрез избягване на грешките, откриване на грешките и нечувствителност към грешките.

Използването на излишък и разнообразие е съществено за разработката на надеждни с-ми

Използването на добре дефиниран повторяем процес е важно за минимизирането на грешките в с-мата.

Някои програмни конструкции са предразположени към грешки – те трябва да се избягват, където е възможно.

Обобщение


Обобщение

В надеждните с-ми се използват изключения за поддръжка на управлението на грешките.

Четирите аспекта на нечувствителността към грешки са откриване на отказ, оценка на вредите, възстановяване и поправка.

N-версиите и блоковете за възстановяване са алтернативни подходи за нечувствителните към грешки архитектури.

Разработка на критични системи

Documents

Transcript of Разработка на критични системи