Развитието на фабриката и IT/OT архитектурата – защо импровизираните интеграции си отмъщават след няколко години?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Най-много проблеми не произтичат от самата интеграция IT/OT, а от това, че в проекта тя се третира като бързо средство за пускане на нова функция, а не като траен елемент от архитектурата IT/OT на фабриката. Именно тогава временните връзки си отмъщават след няколко години: при разширяване на линията, подмяна на контролери, смяна на доставчика на системата от по-високо ниво или при одит по безопасност се оказва, че никой не може еднозначно да посочи собственика на интерфейса, правилата за неговата работа и последствията при отказ. За проекта това означава не само цена на натрупания технически дълг, но и организационен разход: повече съгласувания, по-дълги цялостни тестове, по-трудни приемания и по-голям риск забавянето да се появи едва в края, когато графикът вече е най-малко гъвкав. Тук темата естествено преминава към скритите разходи от погрешни проектни решения, защото източникът на проблема не е единична изпълнителска грешка, а решението добрата архитектура да бъде отложена за по-късно.

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

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

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