Гибкая автоматизация

В этой статье есть несколько проблем. Помогите улучшить ее или обсудите эти проблемы на странице обсуждения . ( Узнайте, как и когда удалять эти сообщения ) Эта статья может оказаться слишком сложной для понимания большинством читателей .Пожалуйста, помогите улучшить его, чтобы сделать его понятным для неспециалистов , не удаляя технические детали. ( март 2014 г. )( Узнайте, как и когда удалить это сообщение ) Эта статья написана в формате личных размышлений, личного эссе или аргументационного эссе , в котором излагаются личные чувства редактора Википедии или приводится оригинальный аргумент по теме.Пожалуйста, помогите улучшить его, переписав в энциклопедическом стиле . ( Январь 2017 )( Узнайте, как и когда удалить это сообщение ) Эту статью , возможно, необходимо реорганизовать для соответствия правилам оформления Википедии . Please help by editing the article to make improvements to the overall structure. (November 2020) (Learn how and when to remove this message) (Learn how and when to remove this message)

Agile Automation относится к применению отдельных принципов, шаблонов и практик разработки Agile-программного обеспечения в области промышленной автоматизации и разработки программного обеспечения для управления процессами. Термин был введен компанией HAL Software (Ирландия) в 2013 году. Первоначальная идея заключалась в том, чтобы просто заимствовать некоторые принципы из современной разработки программного обеспечения. Например, предоставление макета/прототипа или «пилота конференц-зала» в начале спринта для информирования заинтересованных сторон о том, что должно быть доставлено к концу спринта. Однако некоторые подходы, такие как модульное тестирование, не могут быть легко заимствованы, поскольку проприетарная природа промышленных языков программирования не позволяет проводить модульное тестирование и модификацию классов только через расширение. Если модульное тестирование реализуется, оно неизменно осуществляется с помощью языка с открытым исходным кодом и библиотек, таких как Python, и технологии API-интерфейса, такой как OPCDA или OPCUA. И HAL Software, и CoDeSys использовали этот подход)

Традиционно программное обеспечение для промышленной автоматизации разрабатывалось с использованием языков, которые не полностью реализуют объектно-ориентированное программирование . Жизненный цикл разработки программного обеспечения соответствует модели Waterfall . Например, модель GxP ( Good Automated Manufacturing Practice ) V , которая широко распространена во всех регулируемых фармацевтических отраслях. Однако росло мнение, что эта модель слишком жесткая, не допускает достаточных изменений на протяжении всего жизненного цикла разработки программного обеспечения и не нацелена на тестирование в соответствии с рисками. Последняя версия модели GxP в некоторой степени приблизилась к тестированию на основе оценки рисков.

Последняя модель GxP рекомендует проводить тестирование и документирование в соответствии с предполагаемым риском для конечного пользователя (пациента в случае фармацевтической промышленности).

Фактически, в руководстве GAMP5 2008 года прямо упоминалось гибкое программирование;

«Подход, описанный в этом документе, разработан с учетом совместимости с широким спектром других моделей, методов и схем, включая: методы разработки программного обеспечения, такие как RAD , Agile, RUP или Extreme programming ». (GAMP5) ^[1]

Однако ведутся споры о том, могут ли методы Agile действительно удовлетворять нормативным требованиям, как указано в статье об альтернативных моделях и методах разработки программного обеспечения в средах GxP, написанной ISAP GMAP D_A_C_H SIG ASDMM. (Фармацевтическая инженерия, январь 2012 г., том 32, № 1). В отрасли есть некоторый опыт плохо выполненных проектов программного обеспечения Agile для систем управления производством , и этот опыт, как правило, укрепляет традиционное представление о том, что жизненный цикл разработки программного обеспечения Waterfall является самым простым способом обеспечения строгости проектирования и бюджетных/графиковых ограничений для команды разработчиков программного обеспечения.

По состоянию на 2025 год Agile-управление проектами проникло в регулируемые отрасли, особенно в отношении развертывания ИТ-систем. Часто это зависит от предпочтений менеджеров проектов, поскольку спорно, какой подход лучше. В гибридной области ИТ/ОТ (где информационные технологии или традиционные ИТ-приложения интегрированы с технологией операций или пользовательскими приложениями промышленного управления) использование различных вариантов Agile-методологии является обычным явлением. Однако это по-прежнему затрудняется тем фактом, что контроль изменений GxP в регулируемой отрасли следует запланированной последовательности/порядку событий, который по своей природе является «водопадным».

Разработка программного обеспечения Agile Automation имеет потенциал для сокращения жизненного цикла разработки и в то же время охватывает автоматизированное модульное тестирование. Это то, чего требует отрасль. Кроме того, аспекты «не повторяйтесь» в разработке Agile объектно-ориентированного программного обеспечения, охватывающие расширение классов программного обеспечения через интерфейсы (класс программного обеспечения открыт для расширения, но закрыт для модификации), очень привлекательны в регулируемой отрасли, где проверка изменений программного обеспечения особенно дорога. Разработка программного обеспечения Agile способствует истинному объектно-ориентированному программированию программного обеспечения, что в свою очередь приводит к созданию программного обеспечения, которое более поддается изменениям и менее склонно к поломкам. ^[2]

Два наиболее широко используемых шаблона разработки стратегии в фармацевтических и других системах промышленного автоматизированного пакетного производства ( SCADA , Batch и MES ) — это ISA S88 и ISA S95. Эти шаблоны могут быть реализованы таким образом, что поведение действий (например, метод чтения/записи или метод включения/выключения команды Valve) инкапсулируется в виде интерфейсов с использованием таких языков, как C# или Java . ^[3] Разработка программного обеспечения для коммерческих систем управления склоняется к наследованию и подтипированию, а другие принципы ООП ( инкапсуляция , полиморфизм ) не раскрываются программисту в той же степени. Эта неполная реализация ООП увеличивает объем требуемых усилий по проектированию. Даже коммерческие проприетарные системы DCS, такие как Emerson DeltaV, склоняются к подтипированию и наследованию без простого способа реализации поведения через интерфейс или подобную конструкцию. (Нет способа реализовать множественное наследование .)

Язык программирования IEC 61131-3 является наиболее широко используемым языком для программирования систем PLC и DCS . Это не по-настоящему объектно-ориентированный язык, реализующий только 1 принцип ООП (наследование/подтипирование), а не инкапсуляцию или полиморфизм. Это ограничивает его пригодность для автоматизированного модульного тестирования и инкапсуляции поведения для расширения класса.

Как правило, в большинстве промышленных контроллеров возможности инкапсуляции поведения ограничены, за исключением платформ, работающих под управлением более продвинутой операционной системы (например, платформы Beckhoff Twincat), которую можно программировать с помощью высокоуровневых IDE, таких как Visual Studio .

Существует заменяющий стандарт (IEC 61499), который более объектно-ориентирован, но до недавнего времени (2024 г.) его внедрение в отрасли было незначительным. Однако теперь появилась новая отраслевая/университетская инициатива, сосредоточенная вокруг организации, стоящей за https://universalautomation.org. Кроме того, инициатива «Открытый форум автоматизации процессов» (OPAF), продвигаемая Exxon Mobile с 2014 г. (но теперь управляемая https://www.opengroup.org/), по сути, направлена ​​на стандартизацию как аппаратных, так и программных компонентов в системе автоматизации процессов с выгодой от снижения «привязки к поставщику». По состоянию на 2025 г. такие компании, как Schneider Electric, даже открыли исходный код/выпустили среду выполнения iec61499, чтобы другие поставщики могли создавать инженерные инструменты и разрабатывать, моделировать и тестировать код в одном и том же приложении для ПК. Есть шаги к консолидации IEC61131-3, в частности, через стандарт PLCOpen . Такой подход к разработке абстрактного класса XML может привести к созданию библиотеки протестированных модулей/типов классов, которые впоследствии можно будет создать и импортировать на целевую платформу .

Был определенный интерес к гибкому программированию на основе архитектуры, управляемой моделями (MDA), при котором сначала разрабатывается независимая от платформы модель. В результате нормативных требований к подаче заявок и необходимости защиты от судебных разбирательств фармацевтическая промышленность записывает и сохраняет данные, которые должны быть восстановлены для последующей подачи заявок или выпуска партии (электронные записи партии). Модель, разработанная в пилотной лаборатории и используемая в качестве руководства для масштабирования производства, может помочь в подаче заявок. Однако к 2025 году большинство новых инициатив переориентируются на машинное обучение с целью разработки повторно используемых моделей. Такие организации, как opc foundation, теперь имеют специальные рабочие группы по ИИ. ^{[4] [5] [6]}