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

прежде всего, знаю, что бывалым и опытным программистам, накопившим "немало наработок и отлаженных блоков" может быть не по себе такое строение программы, они привыкли по-другому
так же всем, кто боится большого количества Instance DB этот способ покажется неприемлемым

чтобы не тратить попусту слова, часа за полтора сделал демо-проект (STEP+WinCC 7.0 SP2), доносящий основную идею подхода, в основе лежит программа на STEP7 и интегрированный проект WinCC, разработкой которых занимается один человек

теперь коротко об основных моментах:
1. практические любая программа управления технологическим процессом в основном состоит из обработки внешних сигналов и управления механизмами

2. большинство механизмов и датчиков однотипные по входным/выходным сигналам сигналам, принципу работы. электрический проект и символьная таблица для таких механизмов типовая, поэтому логично написать одну FB с логикой работы этого типового механизма или датчика (получается класс механизма)

3. написанный FB вызывается для каждого механизма со своей Instance DB (объект или экземпляр механизма или датчика). DB желательно называть именем, связанным с названием механизма - не будет проблем с названием и не запутаешься

4. для каждого механизма пишется FB "Драйвер-имитатор". через драйвер происходит взаимодействие FB механизма с образом процесса. каждый механизм можно перевести в режим "Имитация", когда реальные входы и выходы отключаются от передаваемых на FB механизма входов/выходов. в этом случае состояние имитируемых тегов можно задавать с HMI. сигналы обратной связи в режиме "Имитация" имитируются программно. драйвер так же вызывается для каждого механизма с созданием Instance DB драйвера.

5. в драйвере можно производить инверсию и другое преобразование переменных. в драйвер можно включить логику управления насосом через контактор, ЧРП, УПП, ВВ ячейку или Симокод. для FB механизма это изменение не существенно. FB механизма содержит лишь логику работы механизма, а через что он включается - это ему не важно. происходит разделение логики. FB по-прежнему будет выдавать сигнал включить двигатель, а драйвер формировать слово управления и задание скорости на ЧРП и отправлять данные например через SFC15. через SFC14 получив слово состояния сформирует сигнал "двигатель работает" и отдаст его FB механизма. тот и успокоится.

6. для группы механизмов можно создать супервизорный FB, который будет управлять ими через предусмотренные входа в определенных режимах, получая дополнительную информацию: давление, расход, уровень и режим и состояние этих механизмов.

7. аналоговые сигналы обрабатываются с помощью FB, в которую заложены функции имитации и подстановки сигнала, чтобы можно было отключить/снять или даже не ставить датчик.

8. при переводе всех необходимых механизмов и аналоговых сигналов в режим имитации становится возможным отладка работы алгоритма в офисе или дома на PLCSim без подключения к ПЛК и реальному объекту. супервизорный блок в этом случае даже не знает, что работа механизмов имитируется, он просто выполняет свою логику работы.

9. даже если в проекте не предусмотрена визуализация на WinCC, ее можно сделать для отладки программы, это ускоряет процесс в разы - программист очень наглядно видит процесс и управляет им

10. написание драйвера для механизма гарантирует полное понимание принципа работы механизма, так как в драйвере закладывается реакция на любое воздействие (включение, превышение времени включения, переезд за конечники, долгое открытие/закрытие, заклинивание, повышенный ток при работе и прочее). на все это FB механизма должен адекватно реагировать.

11. достигается гибкость, масштабируемость и прозрачность программы. типовое изменение делается в типовом блоке и применяется ко всем типовым механизмам одновременно.