Рефакторинг на старо индустриално приложение – кога има смисъл и как да се направи без риск за производството?

Защо тази тема е важна днес

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

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

Най-много грешки възникват тогава, когато рефакторирането се третира като модернизация „без влияние върху процеса“, а в действителност променя начина, по който системата взема решения. На практика е достатъчна привидно малка намеса: подмяна на комуникационен компонент, преработка на графика на задачите, промяна в логиката за буфериране на данни от сензори или подреждане на последователността на стартиране след рестарт. На хартия това са технически подобрения. В производствената среда обаче те могат да променят момента на подаване на сигнал, реда на освобождаване на блокировките, реакцията при загуба на връзка или поведението на приложението след отпадане на захранването. Именно тук темата за рефакторирането преминава в практическа оценка на риска от промяната съгласно ISO 12100: въпросът не е дали кодът е „по-добър“, а дали след промяната машината, линията или работното място продължават да се държат предвидимо в нормални режими, при смущения и след повторно пускане.

Добър тест за зрелостта на решението е да се провери дали екипът може да определи границата между промяна във вътрешната структура на приложението и промяна на функция, съществена за процеса или безопасността. Ако тази граница не може да бъде описана на ниво сигнали, състояния и условия за преход, проектът е рисков независимо от качеството на изпълнителя. В индустриална среда особено чувствителни са ситуациите, в които приложението участва в последователността на пускане, спиране, нулиране на грешки, потвърждаване на аларми или работи съвместно със системи за изключване на енергията и блокировки. В такъв момент възниква вече не само въпросът за архитектурата на софтуера, но и за защита срещу неочаквано пускане, както и дали анализът обхваща също електрическата инсталация, логиката на управление и зависимостите между устройствата. Именно тук привидно локалното рефакториране престава да бъде ИТ задача и се превръща в техническа промяна, изискваща пълен режим на вземане на решения.

Позоваването на нормативните изисквания има значение едва на този етап, защото стандартите не заместват проектното решение, а подреждат неговия обхват. Ако промяната може да влияе върху условията за пускане, спиране, възстановяване на работата след смущение или върху защитните мерки, тя трябва да се оценява като промяна на риска, а не като обикновена поддръжка на кода. Ако намесата засяга логика, която работи съвместно с изключване на енергията, блокировки или последователност за безопасен достъп, естествено се отваря и областта на изискванията, свързани със защита срещу неочаквано пускане. От гледна точка на отговорността най-важният въпрос следователно не е самото „дали да се рефакторира“, а дали организацията може да докаже, че познава границите на промяната, има критерии за приемане, основани на поведението на процеса, и умее да различава подреждането на системата от модификация, която изисква пълна идентификация на опасностите съгласно ISO 12100, цялостна оценка на риска и координация с проектирането на инсталацията и изпитванията на място.

Къде най-често нарастват разходът или рискът

Най-голямото нарастване на разходите при рефакториране на старо индустриално приложение рядко произтича от самия код. Източникът на проблема обикновено е неправилната квалификация на промяната: екипът я приема като подреждане на структурата на програмата, докато в действителност се променя поведението на системата във времето, последователността на действията или условията за преход между състоянията. В производствена среда подобна грешка има пряко отражение върху проекта. Графикът престава да съответства на реалния обхват, тестовете се планират спрямо ИТ функционалност, а не спрямо протичането на процеса, а отговорността за резултата се размива между поддръжката, автоматизацията и доставчика на софтуера. Практическият критерий тук е прост: ако след промяната трябва отново да се потвърди последователността на пускане, спиране, възобновяване на работа след смущение или реакцията на сигнали от защитните вериги, това вече не е „безопасно рефакториране“ в организационния смисъл, а промяна, която може да създаде риск за производството и да изисква друг ред на одобрение.

Втората типична област, в която разходите нарастват, е проектно решение, взето без пълна картина на зависимостите. Старите индустриални приложения често са тясно преплетени с конфигурацията на контролера, изпълнителните устройства, визуализацията, архивирането на данни и процедурите на оператора. В документацията това изглежда като една система, но на практика са слоеве, развивани с години от различни екипи. Рефакториране, което трябва да подобри четимостта на кода или да улесни по-нататъшната поддръжка, може неусетно да промени значението на закъсненията, условията за блокировки, стойностите по подразбиране след рестарт или начина на обработка на комуникационна грешка. Последицата не е само техническа корекция, а и разход за престои, допълнителни изпитвания на място и спорове дали дефектът е съществувал по-рано, или е въведен с промяната. Затова преди вземане на решение е добре да се оцени не само размерът на модификацията, а броят и критичността на точките на взаимодействие: колко сигнали, рецепти, режими на работа и експлоатационни обходни решения зависят от фрагмента код, предвиден за преработка. Колкото повече са тези точки, толкова по-малко смисъл има рефакториране „между другото“ към друга задача.

На практика особено скъпи са проектите, при които екипът открива реалните изисквания едва по време на пускането. Типичен пример е преработка на последователен модул, който според описанието „прави същото, само по-изчистено“. След внедряването обаче се оказва, че предишната версия е съдържала недокументирани поведения, компенсиращи несъвършенствата на обекта: кратко задържане на сигнал, толеранс към закъснял датчик, специфична последователност за нулиране на аларма или условие, от което зависи възможността за сервизен достъп. В кода това е изглеждало като грешка или технически дълг, но за процеса е било елемент на стабилизация. Ако рефакторирането премахне такива механизми, без да е изяснена тяхната функция, разходът се появява веднага: нараства броят на намесите след пускането, удължава се времето за приемане и се налага логиката да се възстановява под натиска на работещото производство. Затова смисълът от рефакториране трябва да се оценява и през възможността да се възпроизведе поведението на текущата система. Ако организацията не разполага с регистър на събитията, надеждни описания на режимите на работа и тестови сценарии, базирани на реалния процес, първо трябва да се изгради основа за оценка, а едва след това да се взема решение за преработка.

Тази тема пряко преминава към практическа оценка на риска от промените, когато модификацията влияе върху защитни функции, последователности за безопасен достъп, управлението на движението на изпълнителните елементи или поведението на инсталацията при отпадане и възстановяване на захранването. В такъв обхват цената на грешката не се ограничава до програмни корекции, защото възниква и въпросът за отговорността при допускане на промяната до работа. Ако приложението работи съвместно с хидравлични, пневматични системи или решения като двуръчно управление, границата между рефакториране и техническа промяна става още по-тясна и изисква проверка дали не са нарушени проектните предпоставки на защитните мерки. Именно тук е основателно да се прибегне до структурирани методи за оценка на риска, включително подхода, използван на практика на основата на ISO/TR 14121-2, а при хидравлични системи и до проектните изисквания, систематизирани в БДС EN ISO 4413. Не става дума за формализъм заради самия формализъм, а за прост принцип при вземане на решения: ако промяната може да повлияе на безопасността на процеса или на обслужването, нейната цена трябва да се изчислява заедно с валидирането, изпитванията на място и режима на отговорност, а не само с времето на програмиста.

Как да се подходи към темата на практика

На практика смисълът от рефакториране на старо индустриално приложение не се оценява по технологичната привлекателност на промяната, а по това дали едновременно може да се намали експлоатационният риск и да се запази контролът върху внедряването. За мениджъра и собственика на продукта това означава проста смяна на гледната точка: въпросът не е дали кодът „си струва да бъде подреден“, а дали текущото състояние на приложението реално затруднява поддръжката, тестването, отстраняването на неизправности или въвеждането на следващи промени в съответствие с изискванията. Ако отговорът е положителен, рефакторирането има смисъл, но само в такъв обхват, който може да бъде отделен от работата на производството и отчетен въз основа на измерими резултати. Добър критерий за решение тук е сравнението на два разхода: разхода за оставяне на приложението в сегашното му състояние, включващ престои, време за диагностика, зависимост от отделни хора и риск от грешна промяна, и разхода за контролирано преустройство заедно с тестове, валидиране и пускане в експлоатация. Без такова сравнение проектът обикновено излиза извън контрол, защото екипът финансира подреждането на кода от бюджета, предназначен за функционалност, а отговорността за последствията на обекта остава неясна.

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

Практическият пример е типичен за по-стари приложения за управление: кодът съдържа многократно дублирани фрагменти, отговорни за блокировки на движението, обработка на аларми и преходи между ръчен и автоматичен режим. Екипът иска да ги уеднакви, защото сегашната структура затруднява развитието и води до разминавания между работните места. Такова решение има смисъл едва след проверка дали уеднаквяването няма да промени условията, при които изпълнителният елемент получава разрешение за движение, както и дали след рестарт на контролера няма да се появи различна последователност за възстановяване на състоянието. Ако приложението управлява също клапани, задвижвания или системи със съхранена енергия, дори привидно „вътрешно“ рефакториране може да премине в областта на оценка на риска от промяната съгласно ISO 12100 и да изисква анализ на защитата срещу неочаквано пускане. В такъв случай разумната практика е рефакторирането да се извършва поетапно: първо възпроизвеждане на поведението в тестова среда, след това отделяне на модулите без промяна на логиката, а после проверка на обекта с подготвен сценарий за връщане назад. Това ограничава оперативната отговорност и позволява внедряването да бъде прекъснато, преди проблемът да се отрази на производството.

Едва на този етап е необходимо нормативно позоваване, защото стандартите не заместват техническото решение, но подреждат момента, в който промяната престава да бъде само програмна работа. Ако рефакторирането влияе върху защитните мерки, условията за безопасен достъп, изключването на енергията или поведението на системите след спиране и повторно пускане, то естествено попада в обхвата на практическата оценка на риска от промяната, извършвана по структуриран начин и с използване на подхода, познат от ISO/TR 14121-2. Когато се появява риск от неочаквано пускане, трябва вече да се провери не само самият код, но и логиката на изключване и възстановяване на енергията, което води пряко до въпросите, свързвани с ISO 14118. Ако пък приложението е свързано с хидравлика или пневматика, оценката не може да пренебрегва проектните предпоставки на тези системи, защото грешна последователност на управление може да наруши безопасната им работа независимо от коректността на самата програма; тогава е обосновано да се вземат предвид и изискванията, които структурират проектирането на хидравлични системи. На практика това означава едно: за обхвата на рефакторирането решава не елегантността на решението, а границата на отговорността за безопасното поведение на инсталацията след промяната.

За какво да се внимава при внедряването

Внедряването на рефакториране на старо индустриално приложение е моментът, в който дори правилно архитектурно решение може да се превърне в оперативен проблем. Смисълът на цялото начинание приключва там, където промяната подобрява кода, но влошава предвидимостта на работата на инсталацията или разширява отговорността на екипа отвъд това, което е било разпознато и одобрено. Най-честата грешка е внедряването да се третира като обикновено публикуване на нова версия. В производствена среда значение има не само дали приложението работи, но и дали след промяната всички преходни състояния се държат по идентичен начин: пускане след отпадане на захранването, рестарт на комуникацията, възстановяване на рецепти, обработка на аларми, блокировки и ръчни режими. Практическият критерий е прост: ако екипът не може еднозначно да опише кои поведения трябва да останат непроменени след внедряването, това означава, че все още няма условия за безопасно пускане.

На етапа на вземане на решение за внедряване трябва ясно да се разграничи технически обратимата промяна от промяната, която след пускане създава ново изходно състояние и затруднява връщането назад. Това има пряко отражение върху разходите и графика. Рефакториране, което изисква едновременно обновяване на драйверите, визуализацията, сървъра за данни и интерфейсите към надсистемите, престава да бъде единична програмистка задача; то се превръща в координирана производствена промяна с множество точки на отказ. Затова преди внедряване е разумно да се приеме критерий за допускане, основан не на декларацията „тестовете са преминати“, а на способността промяната да бъде контролирано оттеглена в срок, приемлив за процеса. Ако няма надеждна процедура за връщане към предишното състояние, няма и основание да се твърди, че рискът е овладян. На практика е по-полезно да се измерва не абстрактното „качество на внедряването“, а показатели като времето за възстановяване на предишната версия, броят на интерфейсите, зависими от промяната, и броят на функциите, чиято коректност може да се потвърди на инсталацията без намеса в производството.

Добър пример е ситуацията, при която рефакторирането подрежда обработката на изключения и съобщенията за грешки, но едновременно с това променя последователността на инициализация след рестарт на системата. На тестовия стенд всичко изглежда правилно, защото устройствата са налични веднага, а процесът не работи под натоварване. В предприятието обаче същият код може да стартира последователността в различен момент от досегашния, което води до загуба на синхронизация със задвижванията, неправилно тълкуване на сигналите за готовност или спиране на партида материал в междинно състояние. Такъв инцидент не е задължително да означава повреда в техническия смисъл, но генерира разходи за престой, брак, повторно пускане и допълнителна отговорност при решението за възобновяване на работата. Именно тук темата за рефакторирането преминава в практическа оценка на риска съгласно ISO 12100: не когато промяната е голяма, а когато последиците ѝ не могат да бъдат ограничени само до програмния слой.

Границата на отговорност става още по-ясна там, където приложението влияе върху защитни функции, логиката за разрешаване на движение, последователностите за разтоварване, спирането и повторното пускане след смущение. В такъв случай вече не е достатъчно сравнение между версиите на кода или функционален тест, извършен от интегратора. Необходима е структурирана оценка дали промяната изменя нивото на риска и дали не нарушава предпоставките за безопасна работа на машината или инсталацията. Това е естественият момент за навлизане в областта на оценката на риска по ISO 12100 и практиките, прилагани при оценяване на риска от промени, а при по-сложни случаи е полезен и методичният подход, познат от ISO/TR 14121-2. Ако приложението управлява хидравлични или пневматични системи, трябва допълнително да се провери дали новата логика не променя условията за безопасно управление на енергията и последователността на движенията; тогава значение имат и проектните изисквания, приложими за тези системи, а не само коректността на самата програма. За проектния екип това означава едно: внедряването може да се счита за подготвено едва когато обхватът на техническата, експлоатационната и съответствената отговорност е определен преди пускането, а не чак след първия инцидент.