Проектиране на безопасно управление на рецепти в Logix и PanelView
Архитектура за рецепти, центрирана около контролера, за Logix и PanelView, която разделя редактирането, валидирането, съхранението и активирането, като същевременно налага ограничения, управление н...
Една рецепта може да променя температурата, скоростта, налягането, времето, движението и качеството на продукта без изтегляне на програма към контролера. Това прави данните за рецептите оперативно важни, дори когато са съхранени в обикновен масив от Logix UDT. Целта на дизайна не е просто да запазва стойности, а да предотвратява превръщането на непълни, остарели, неоторизирани или несъвместими стойности в активни.
Контролираният работен процес отделя редактирането от оператора от стойностите, които в момента управляват машината.
Определете четири отделни роли на данните за рецептата
Използвайте отделни структури за съхранените рецепти, избрания източник, редактируемото работно копие и активното копие за процеса. HMI редактира само работното копие. Заявката за запазване валидира това копие и го записва в избран запис за съхранение. Отделна заявка за активиране валидира отново и прехвърля един пълен одобрен запис в активната структура.
Това разделяне предотвратява промяната на активна зададена стойност при всяко натискане на клавиш от HMI. То също така поддържа отмяна, сравнение, одобрение, възстановяване и ясни съобщения към оператора. Активната рецепта остава стабилна, докато друга рецепта се преглежда.
Хардуерът PanelView е подреден в колекцията Allen-Bradley PanelView, а платформите за контролери са достъпни чрез PLC и PAC системи. Изборът на хардуер не заменя правилата за транзакции, реализирани в приложението.
Проектирайте UDT като управляван запис
Групирайте свързаните технологични стойности в UDT, така че съхранението, сравнението и прехвърлянето да използват една дефинирана структура. Добавете метаданни като идентификатор на рецептата, име, версия на формата, продуктов код, редакция, време на създаване, време на промяна, състояние на валидност и ролята, отговорна за промяната. Дръжте оперативния статус извън структурата със зададени стойности, когато той не трябва да се копира заедно с рецептата.
Всеки числов член трябва да има мерни единици, допустим диапазон и обосновка за този диапазон. Използвайте ограничени изброими стойности или валидирани кодове за дискретни режими вместо свободен текст. Дефинирайте стойности по подразбиране само когато те са безопасни и технически обосновани.
Версията на формата е важна при надграждане на софтуера. Ако по-нова програма на контролера добави полета или промени мерните единици, старите записи трябва да бъдат отхвърлени или мигрирани по умишлено зададени правила. Копирането на старо двоично оформление в по-нов UDT без правило за съвместимост може да създаде зададени стойности, които изглеждат валидни, но са неправилни.
Валидирайте взаимовръзките, а не само отделните ограничения
Проверката на всяко поле спрямо минимална и максимална стойност е необходима, но недостатъчна. Горната граница трябва да остане над долната. Времето за рампиране трябва да съответства на скоростта и разстоянието. Продължителностите на фазите трябва да са съвместими с последователността. Взаимно изключващи се опции не могат да бъдат активирани едновременно. Една скорост може да е приемлива за един размер на продукта, но опасна при друга конфигурация на инструменталната екипировка.
Изградете валидирането в логиката на контролера, защото контролерът управлява реакцията на процеса. HMI може да повтаря проверките за незабавна обратна връзка, но не трябва да бъде единственият слой за прилагане на правилата. Връщайте конкретен код за валидиране и посочвайте члена или взаимовръзката, която не е преминала проверката. Самото съобщение „Рецептата е невалидна“ кара екипа по поддръжката да търси сред десетки стойности.
Разграничете предупреждението от отхвърлянето. Предупреждението може да изисква потвърждение или преглед от ръководител, докато отхвърленият запис не може да бъде запазен или активиран. Никога не позволявайте общ бутон за потвърждение да заобикаля твърдо ограничение на оборудването или безопасността.
Използвайте изрична машина на състоянията за транзакции
Моментните HMI команди могат да бъдат пропуснати, повторени или да останат активни след прекъсване на комуникацията. Реализирайте последователност от заявка и потвърждение с номер на транзакцията. HMI записва работните данни, увеличава номера на заявката и изчаква. Контролерът улавя стабилно копие, валидира го, изпълнява заявеното действие еднократно и връща същия номер на транзакцията заедно с резултат и код за грешка.
Отхвърляйте нова заявка, докато друга транзакция е в процес. Прилагайте изчакване в HMI и съхранявайте резултата от контролера достатъчно дълго, за да може операторът да го прочете. След повторно свързване HMI трябва да сравни номерата на транзакциите, вместо да приема, че предишното запазване е неуспешно.
Контролерът трябва да прехвърля целия валидиран запис в една определена точка на изпълнение. Разпръснатите прехвърляния, управлявани от отделни условия, могат да създадат смес от стари и нови стойности. Ако данните могат да бъдат променяни едновременно от друга задача или комуникационен канал, проектирайте стабилна снимка и проверете дали нейната последователност не се е променила по време на копирането.
Разделете запазването от активирането
Запазването записва прегледано работно копие в хранилището. Активирането променя стойностите, използвани от процеса. Тези действия трябва да имат отделни права, съобщения и блокировки. На техник може да бъде разрешено да подготви рецепта, без да има право да я стартира.
Определете кога активирането е разрешено: машината е спряна, цикълът е завършен, изпълнителните механизми са в безопасно състояние, правилната инструментална екипировка е потвърдена, няма критична повреда и е налице необходимата операторска роля. Ако някои стойности могат да се променят по време на производство, избройте ги изрично и контролирайте прехвърлянето им. Не разчитайте операторът да помни кои полета могат да се променят онлайн.
След активиране върнете към HMI идентификатора и редакцията на активната рецепта. Сравнете активното копие с одобрения източник и подайте аларма при неочаквана разлика. Логиката на последователността надолу по веригата трябва да използва само активното копие, никога работните тагове на HMI.
Направете правата и доказателствата съразмерни
Като минимум разграничете действията за преглед, редактиране, запазване, активиране, изтриване и възстановяване. Ограничете изтриването по-строго от избора. Избягвайте споделени идентификационни данни, когато приложението изисква индивидуална отчетност. Ако платформата поддържа одит, записвайте потребителя, времето, действието, идентификатора на рецептата, старата редакция, новата редакция и резултата.
Контролерът също трябва да съхранява оперативни доказателства, които не зависят изцяло от HMI: активен идентификатор, редакция, последна транзакция, резултат от валидирането и време на активиране. Дневниците на HMI са полезни, но могат да бъдат загубени при подмяна на терминала или изтегляне на приложението.
Бъдете ясни относно ограниченията. Обикновената история на машинни рецепти не е автоматично електронна система за записи за регулирано производство. Ако се изискват подписи, доказателства за защита от подправяне, срокове за съхранение или валидирани одитни следи, оценете цялостната архитектура и процедурите.
Проектирайте поведението при включване и загуба на комуникация
Определете коя рецепта става активна след рестартиране на контролера, изтегляне на програма, възстановяване на паметта или подмяна на HMI. Сляпото зареждане на запис нула може да бъде опасно. Запазените данни трябва да бъдат валидирани преди използване, включително версията на формата и всички взаимовръзки. Ако валидността не може да бъде доказана, задръжте машината в определено състояние и изискайте избор и потвърждение.
Загубата на комуникация с HMI не трябва да активира частично рецепта. Контролерът продължава с последния пълен активен запис или следва безопасната реакция, специфична за процеса. Когато комуникацията се възстанови, изчистете остарелите състояния на редактиране и покажете действителния статус на транзакцията в контролера, преди да разрешите друга команда.
Тествайте сценариите на отказ
При въвеждане в експлоатация проверете нормално запазване, невалидно поле, невалидна взаимовръзка, неоторизирано действие, повторно натискане на бутон, прекъсване на мрежата по време на прехвърляне, рестартиране на контролера, рестартиране на HMI, запълнено хранилище, изтриване, възстановяване и запис в стар формат. Потвърдете, че нито един сценарий не създава смесена активна рецепта.
Извършете граничен тест за всяко важно числово поле и проверете мерните единици в HMI и контролера. Сравнете всички активни членове след прехвърлянето. Запишете резултатите и съхранявайте известна добра рецепта извън резервното копие на контролера, така че възстановяването да не зависи от едно устройство.
Надеждната система за рецепти прави предложените промени видими, валидира ги в контролера, активира една пълна редакция в контролирано състояние и оставя достатъчно доказателства за възстановяване на случилото се. Тази дисциплина е по-важна от това дали съхранението започва като масив от UDT или компонент за рецепти в HMI.