Регламентът на ЕС относно машините от 20 януари 2027 г.: какво изисква от софтуера на вашите машини

На 20 януари 2027 г. Директивата за машините се заменя с Регламент (ЕС) 2023/1230, Регламента относно машините. По-голямата част от него ще изглежда позната на всеки, който произвежда машини със СЕ маркировка. Една част няма да е такава. За първи път законодателството за машините възлага задължения пряко на софтуера: машината трябва да казва кой софтуер ѝ е необходим, за да работи безопасно, да забелязва кога този софтуер или конфигурацията му се променят, да устоява на повреждане и да пази следа от актуализациите на софтуера за безопасност в продължение на пет години.

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

Какво всъщност казва законът

Европейската комисия посочва, че Регламентът „се прилага задължително от 20 януари 2027 г.“ и че „включва разпоредби за киберсигурността по отношение на софтуерни данни от значение за съответствието и на системите за управление на безопасността“. В текста, публикуван през 2023 г., датата беше 14 януари; поправка я премести.

Задълженията за софтуера се съдържат в две съществени изисквания за здраве и безопасност в приложение III към Регламента.

Раздел 1.1.9, защита срещу повреждане. Накратко:

• Свързването на друго устройство към машината, пряко или дистанционно, не трябва да води до опасна ситуация.
• Софтуерът и данните, които са от решаващо значение за спазването на изискванията за безопасност, „се идентифицират като такива“ и се защитават срещу случайно или умишлено повреждане.
• Хардуерът, който пренася сигнали или данни, даващи достъп до този софтуер (например порт за програмиране или мрежов интерфейс към контролера за безопасност), също трябва да бъде защитен, а машината трябва да събира доказателства за намеса в него.
• Машината „идентифицира инсталирания в нея софтуер, който е необходим за безопасната ѝ работа, и може по всяко време да предоставя тази информация в лесно достъпна форма“.
• Машината „събира доказателства за законна или незаконна намеса в софтуера или за промяна на софтуера, инсталиран в машината или свързания продукт, или на неговата конфигурация“.

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

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

Кои машини са обхванати

Правилата се прилагат за машините, пуснати на пазара от 20 януари 2027 г. Машините, пуснати на пазара по старата директива преди тази дата, могат да продължат да се продават (член 52), а новите правила за софтуера не достигат до вече работещия парк.

Уловката е в значението на „пускане на пазара“. Синьото ръководство на Комисията гласи, че понятието „се отнася до всеки отделен продукт, а не до тип продукт“. Всяка единица, която напуска завода ви за клиент в ЕС от 20 януари 2027 г., трябва да отговаря на новите изисквания, включително по отношение на софтуера. Продуктова фамилия, която се доставя непрекъснато, трябва да има готов софтуер за управление преди първата единица за 2027 г., а не при следващата смяна на модела.

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

Какво означава това за всеки слой на машината

Контролер за безопасност и PLC

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

HMI

• Екран за идентификация на софтуера, който изброява софтуера от значение за безопасността с версиите и контролните суми. Четете стойностите в реално време от устройствата. Страница, попълнена ръчно при издаването, се отдалечава от действителността, а изискването гласи „по всяко време“.
• Екрани за параметри. Точка 1.2.1, буква г) изключва промени в настройки или правила, които биха могли да доведат до опасни ситуации. Параметрите, свързани с безопасността, трябва да са зад нива на достъп, с граници, наложени в контролера, а не само в HMI, като всяка промяна се записва: кой, кога, старата и новата стойност.

Отдалечен достъп

Раздел 1.1.9 изрично назовава дистанционните устройства. На практика:

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

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

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

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

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

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

Какво ви дава доставчикът на контролера и какво не

Платформата на контролера ви ще осигури част от това. Преди да изграждате каквото и да било, проверете какво предлага: подпис или контролна сума на програмата за безопасност, защита с парола, управление на потребители, дневник на промените, отчитане на версиите. Използвайте всичко, което има.

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

Как се отнася това към Акта за киберустойчивост

Актът за киберустойчивост има собствен график. Задълженията му за докладване се прилагат от 11 септември 2026 г., а пълните му изисквания се прилагат от 11 декември 2027 г. Регламентът относно машините влиза в сила между двете дати.

CRA признава припокриването. Съображение 53 от Регламент (ЕС) 2024/2847 гласи, че производителите на машини, които са и продукти с цифрови елементи, следва да спазват и двата акта и че спазването на CRA „би могло да улесни“ спазването на раздели 1.1.9 и 1.2.1. Тази синергия трябва да бъде доказана от производителя. Приложение I към CRA изисква защита на целостта на „командите, програмите и конфигурацията“ и докладване за повреждания, което е близо до изискванията на 1.1.9.

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

Изграждайте за Регламента относно машините още сега, защото той идва пръв, и го проектирайте така, че същото хранилище за доказателства, подписване и записи за актуализации да служат и за CRA през декември 2027 г.

Стандартите и неуспешното отлагане

Не разчитайте до 20 януари 2027 г. да бъде цитиран хармонизиран стандарт, който обхваща тези изисквания. Страницата за хармонизирани стандарти на Комисията, актуализирана през септември 2026 г., посочва, че първият списък по Регламента относно машините се подготвя. Той ще пренесе повечето стандарти, цитирани по директивата, ще ги уточни там, където те „все още не отговарят напълно“ на новите изисквания, и „може да се очаква преди края на тази година“.

През януари 2026 г. CEMA, CECE, CECIMO, EGMF и FEM поискаха в обща позиция на индустрията 1.1.9 и 1.2.1, буква е) да бъдат отложени до 11 декември 2027 г., в съответствие с CRA. Те оцениха разходите за съответствие на „над 1 милион € за всяка архитектура на платформа“ и посочиха, че очакваните стандарти остават твърде общи по отношение на дневника с данни по 1.2.1, буква е).

Искането не беше прието. Регламентът относно машините беше изменен през юли 2026 г. с Регламент (ЕС) 2026/1744, но това изменение засяга високорисковите системи с ИИ в машините и не променя датата на прилагане. Планирайте за 20 януари 2027 г.

Така в първия ден може да нямате стандарт, който дава презумпция за съответствие с тези две изисквания. Тогава техническото ви досие трябва да описва решението, което сте приложили за всяко от тях (приложение IV). Пишете го, докато изграждате, а не след това. За машините, изброени в приложение I, част Б, има още една стъпка: самооценката е възможна само ако хармонизирани стандарти или общи спецификации обхващат всички приложими изисквания; в противен случай се включва нотифициран орган (член 25). Машините, които не са изброени в приложение I, се оценяват от самия производител и в двата случая.

План за 15 седмици

От понеделник, 5 октомври 2026 г., до крайния срок остават малко над 15 седмици, с празниците по средата. Това е тясно, но изпълнимо, ако приоритизирате по дата на доставка: първо идват фамилиите, чиито единици за ЕС излизат през януари.

1. Седмици 1 и 2 (5 до 16 октомври): обхват. Избройте всяка продуктова фамилия, която ще доставя единици в ЕС след 20 януари 2027 г. За всяка избройте софтуера и данните от значение за безопасността: програма за безопасност, стандартен код от решаващо значение за съответствието, параметри за безопасност на задвижвания и сензори, HMI, фърмуер, отдалечен шлюз. Определете по един отговорник за всяка фамилия.
2. Седмици 3 и 4 (19 до 30 октомври): оценка на риска и пропуски. Актуализирайте оценката на риска за връзките, отдалечения достъп, злонамерените опити и пътя на актуализациите. Проверете какво осигурява платформата на контролера ви и какво е включено.
3. Седмици 5 до 9 (2 ноември до 4 декември): изграждане. Екран за идентификация на софтуера, сравнение с базовата линия, контрол на достъпа при инженерния и отдалечения достъп, проследяващ дневник с капацитет за пет години, подписани актуализации и записи по сериен номер в бекенда.
4. Седмици 10 и 11 (7 до 18 декември): тествайте така, както би го направил техник и както би го направил нападател. Променете параметър за безопасност директно с инструмента на доставчика и потвърдете, че машината го записва. Сменете контролер и проверете дали дневникът оцелява. Прекъснете захранването по време на актуализация.
5. Седмици 12 и 13 (21 декември до 1 януари): празници. Не планирайте инженерна работа; оставете дълготраен тест, който запълва дневника към размера му за пет години.
6. Седмици 14 и 15 (4 до 15 януари): документация и издаване. Записи в техническото досие за 1.1.9 и 1.2.1, инструкции за употреба, които обясняват как клиентът чете идентификацията на софтуера и какво може и какво не може отдалеченият достъп, и производствена стъпка, която зарежда издадената базова линия и я записва по сериен номер.

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

За кого не е тази статия

Машините, пуснати на пазара преди 20 януари 2027 г., не са засегнати от тези правила за софтуера, освен ако някой по-късно не ги модифицира съществено. Ако купувате машини, вместо да ги произвеждате, задължението е на доставчика ви; вашата част е да поискате в спецификациите си идентификацията на софтуера и достъп до дневника.

Къде да получите помощ

Ние сме софтуерна компания, а не нотифициран орган или адвокатска кантора. Изграждаме и променяме софтуера, който тези изисквания засягат: HMI и бекенд приложения, шлюзове за отдалечен достъп, процеси за актуализации и регистриране на доказателства, като работим заедно с инженерите по системи за управление, които отговарят за програмата за безопасност. Най-трудният случай са по-старите платформи с години натрупан код и обикновено оттам започва нашата работа по поддръжка на наследени системи, а страната на CRA е разгледана в нашето ръководство за Акта за киберустойчивост. Ако екипът ви има плана, но не и хората, за да го завърши до януари, пишете ни на office@c9group.dev.