Какие могут быть организационные меры по контролю версий (и не только) в промышленной автоматизации?

Question

[Дмитрий]

Уже как-то задавался вопрос, какие есть программные средства по контролю версий в промышленной автматизации, программировании ПЛК. Как понимаю, на сегодняшний день ничего общепринятого и действующего нет.
Да, уже сейчас в TIA Portal V16 появился свой собственный контроль версий.

Но меня больше интересуют организационные меры.
Как сделать, чтобы программисты пользовались одними и теми же актуальными библиотеками, чтобы при их изменении поднимались гарантийные проекты?
Чтобы на сервер уходила последняя закачанная в ПЛК версия.
Чтобы наименование тэгов было одинаковым.
Чтобы не приходилось перебирать десятки проектов для нахождения подходящих для нового использования.
Чтобы программист, заменивший коллегу на проекте, мог спокойно его вести.

Ну и всё в таком духе.
Был бы благодарен за умные мысли.

Answer 1

[Дмитрий]

Ну чтож, попробую я тогда что-нибудь написать.
Извиняюсь за канцелярит невольный, сочинлось для начальства.

План мероприятий по унификации ПО и подходов к его написанию и поддержанию

Замечание: изложение будет выполнено неакадемическим языком и в свободной манере. Предназначено для оценочного обзора.
Вариант идеальный:
1. Всё создаваемое ПО загружается на сервер с контролем доступа и сохранением архивов.
2. Программа, залитая в ПЛК на объекте, сохраняется под своим номером версии, производится запись времени/даты и версии загруженного ПО, записывается контрольная сумма проекта в ПЛК.
Все дальнейшие корректировки программы и её модулей/библиотек производятся под новой версией.
Просмотр контрольной суммы проекта в контроллере возможен (при соответствующих настройках) также через веб-интерфейс (т.е. без использования специализированного программного обеспечения), в том числе для контроля целостности проекта, отсутствии несанкционированных изменений.
3. Существует общая и обязательная к использованию база библиотек. Хранятся все использованные версии библиотек/модулей. Любое изменение библиотеки сопровождается комментарием в её свойствах.
При переходе на новую версию инженерного ПО обновляется вся база библиотек.
4. Ведётся (предпочтительнее автоматическая) запись в таблицу/базу данных всех модулей, особенностей ПО, использованных в проектах.
a. При помещении на сервер производится сохранение структуры ПО и подсчёт контрольной суммы проекта.
b. Становится возможным как использование библиотек и ПО на новых объектах, так и при нахождении ошибок в коде исправление в уже существующих.
5. Общие принципы наименования переменных (самый простой вариант, с которого и следует начинать). Наименование объектов на принципиальной/технологической схеме и используемые в переменных должны совпадать или явно определяться, например из таблицы соответствий.
Пример наименования: IAA0_FAC3_SEP15_P02_PressOut_KPa – входной аналоговый сигнал 0-20 мА, третий цех, сепаратор №15, второй насос, давление на выходе, в Килопаскалях.
6. Общие принципы наименования подпрограмм, распределения данных по блокам данных.
Определение общей структуры программ, например, все входные сигналы обрабатываются в подпрограмме Inputs, выходные Outputs, настройки программы хранятся в блоке данных DB_Settings, а данные для диспетчеризации DB_SCADA.
7. Использование однотипных языков программирования для каждой из составляющей проекта.
Например, для библиотек используется SCL, для обработки входных сигналов LAD.
8. Переход на программное обеспечение, такое как TIA Portal V16 со встроенным контролем версий. Или же использование специализированного ПО/дополнительных модулей для данного функционала.