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

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

Да, уже сейчас в TIA Portal V16 появился свой собственный контроль версий.  

  

Но меня больше интересуют организационные меры.  

Как сделать, чтобы программисты пользовались одними и теми же актуальными библиотеками, чтобы при их изменении поднимались гарантийные проекты?  

Чтобы на сервер уходила последняя закачанная в ПЛК версия.  

Чтобы наименование тэгов было одинаковым.  

Чтобы не приходилось перебирать десятки проектов для нахождения подходящих для нового использования.  

Чтобы программист, заменивший коллегу на проекте, мог спокойно его вести.  

  

Ну и всё в таком духе.  

Был бы благодарен за умные мысли. 

 Ну чтож, попробую я тогда что-нибудь написать.  

Извиняюсь за канцелярит невольный, сочинлось для начальства.  

  

> План мероприятий по унификации ПО и подходов к его написанию и поддержанию  
> 
>   
> 
> Замечание: изложение будет выполнено неакадемическим языком и в свободной манере. Предназначено для оценочного обзора.  
> 
> Вариант идеальный:  
> 
> 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 со встроенным контролем версий. Или же использование специализированного ПО/дополнительных модулей для данного функционала.