Оборудования?
Вот у нас есть управляющая программа. Если привязать блоки то должны быть модули ввода/вывода. (Что это за модули ввода/вывода?) Т. Е подробно описать процесс создания управляющей программы - есть картинка и нужен конкретный процесс разбора данной составляющей. Например S1 - контакт нормально разомкнутый. Смысл в том - нужно описать что происходит в каждой части управляющей программы. Допустим если срабатывает датчик индуктивный такой-то такой-то и не срабатывает такой-то. Уточнить какие функциональные блоки предназначены для сетевого взаимодействия с оборудованием по интерфейсам.
Без внешних схем (ответной части) это не сделать.
S1-S17 это внутренние маркеры, завязанные на ответную часть.
Не понимая что к чему привязано, не видя картины целиком, описать ничего не получиться.
И да, этим должен заниматься не технолог, а автоматчик.
"Вот у нас есть управляющая программа. Если привязать блоки..."??? Обычно программу пишут под технологический процесс, выбрав оборудование и модули управления. А так будет все через задницу извиняюсь)
1) Зависит от сложности. Например, можно словами описать, как вы примерно выше сделали. Можно в виде схемы, например, в виде конечного автомата - точки- различные состояния системы, стрелочки - правила перехода из одного состояния в другое. Можно таблицы составить или вообще, на каком-нибудь специализированном языке правила сформулировать. Тут же еще зависит от того, кто это будет читать, что исполнителю будет понятнее.
2) Да, еще не совсем понятно, вам нужно описать что программа должна сделать или именно технологию создания программы? Это, вообще-то, две совершенно разные вещи - функционал ПО и процесс создания ПО.
3) Полное описание проектируемого ПО, по-хорошему, включает в себя общее описание назначения, вход и выход, требования к надежности, требования к платформе и технологии, требования к квалификации персонала, условия применимости, критерии оценки и контроля и еще кучу всего. Собственно функционал - это лишь один раздел из десятка. Есть даже ГОСТ на составление ТЗ на разработку ПО. И составить хорошее техзадание - это отдельная, довольно сложная и ответственная работа. Т. к. ошибки, допущенные на этом этапе будут самыми дорогими в последствии. Но в этом документе не описывают "процесс создания", в нем пишут ЧТО нужно сделать, и только частично "как". Лучше, когда над документом работают обе стороны. Ну и ждать, что кто-то будет делать такую работу "по-быстренькому" и бесплатно - это себе проблемы создавать. Приглашайте специалиста.
Есть общие правила, включающие 5...7 этапов, начиная с постановки задачи (цели) и кончая совокупным тестированием созданного. Они известны и описаны: там и разбиение на модули и их создание, тестирование каждого, при неправильной работе или невозможности реализации — возврат на предыдущий этап. Далее следует сопряжение с ОС компьютера. В промежутках — выдача подробных указаний для программистов, которые перводят в управляющий код на заключительных этапах. Опять же, с тестированием.
Всё просто, но мелких деталей там много, что только опытный разработчик может учесть такое их количество.
Это можно описать только с привязкой к конкретному аппарату и технологическому процессу. У любого контроллера могут быть сотни программ в зависимости от необходимой задачи
технологи не занимаются автоматизацией.
это творческая работа, в схемы, чертежи и в отчётность её не втиснуть, По задачам по функционалу разрабатывается потом апробывается если возможно, устраняются ошибки, далее подключается следующий уровень, блок, снова пробуется. Расписать на бумажке можно только детский утренник в детском саду
