Описание цифрового интерфейса

[petr2off]

Добрый день всем.
Собрал тут ПО для электрокотельной, нулевой версии.
Теперь нужно его описать в проектной документации.
Есть в составе проектной документации - такие прекрасные документы как Перечень входных данных (В1) и перечень Входных данных (В2). Но мне нужно описать взаимодействие между Панелью Оператора (Weinek) и контроллером (LP8841). Взаимодействуют они посредством Modbus/TCP. Собственно говоря нужно привести таблицу регистров Modbus и их описание сделать, Вопрос только - в какой это документ пихать. (В1) и (В2) - как то мало для этого подходят. В общую пояснительную записку, но она у меня и так уже за пределы разумного выходит. Хотел написать что то вроде Описание интерфейса с контроллером АСУ ТП ЭК, но не предусмотрен такой документ.

Отправлено спустя 1 минуту 1 секунду:
Пардон, рук дрогнула. В2 - это конечно выходные данные.

[alex45]

А кто вам запрещает сделать отдельный документ и назвать его "Описание цифрового интерфейса"?
Ну и не надо путать проектную документацию и конструкторскую.
Проектная документация - это то, что делается по постановлению Правительства № 87. А вы скорее всего имеете дело с конструкторской документацией.

[petr2off]

Не, именно с проектной. И да 87 постановление .

[Jackson]

Не, именно с проектной.

Т.е. сначала рабочий софт, а потом проект?
В проектную документацию это вообще можно не включать, а как максимум указать что разрабатывается на рабочем этапе (или вообще на ПНР) и описывается в эксплуатационной документации. Ведь сами видите, что нет этому места в проекте. И наверное неспроста. Зачем делать работу, о которой никто не просил? А в эксплуатационную включите - приложением к РЭ например.

[petr2off]

Да нет, получается забавней. По мнению начальника - софт это проектная документация, естествено - он рабочим быть не может.
Не верю я, что в АСУ ТП можно сделать рабочий софт без объекта.
Т.е. последовательность такая.
1) В качестве проектной документации - софт с описанием (естественно не рабочий, теоретически он может быть почти рабочим - если у тебя до этого были идентичные объекты, но как правило - это совсем не так)
2) Потом монтаж и пуско-наладка, в процессе которой появляется рабочий софт и рабочая и эксплутационная документация.
Особую пикантность в этом процессе составляет то - что эти 2 процесса получаются разорваны по времени и возможно организациями будут выполнятся разными.
Ну а начальник всегда прав. Поэтому я пишу софт и документацию. Разбил записку - "Описание ПО" на 3 части (ПО контроллера, ПО панели, Описание интерфейсов) и пишу. Слегка напрягает некоторая бессмысленность работы, но нам не впервой.

Причем, я уже сталкивался с таким подходом, когда приходилось на этапе монтажа и наладки работать с "проектным" софтом. Переделывать пришлось почти все, таблица переменных только совпала процентов на 80.

[Сергей]

Ну как вариант - добавьте в документы В1 и В2 отдельной таблицей эти регистры. В В1 - считываемые, в В2 - записываемые. Я бывало и все сообщения на операторской панели в В2 описывал

[Михайло]

petr2off, я тоже считаю, что вы заморачиваетесь. От вас любое поделие-документ примут, хоть и на 80% отличающееся от реальности. Если этот документ реально нужен не для галочки под названием "комплектность документации", то хорошо, будете потом исправлять. А если не нужен, то воды туда налить - это просто долг уважающего себя разработчика.

Отправлено спустя 6 минут 40 секунд:
Лирическое отступление: я сам всегда интересовался, каким образом лучше всего описывать систему. ГОСТ 34 - это фактически на 90% дублирование работы в Eplan, Autocad, Компас, Step7, Codesys и так далее. Какой смысл? При этом ускользает часть информации, которой нет ни в документации, ни в файлах проектов, ни в ТЗ... На этом я закончу свое нытье.

[kirillio]

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

Мутную воду мутить - удел дремучих невежд; для авторитета - харам, дядя Миша :)

[keysansa]

В качестве проектной документации - софт с описанием

ТЗ же...
Исполнительная - описание алгоритма = программа.

[alex-tec]

Не, именно с проектной. И да 87 постановление .

87-е постановление вроде как к СПДС относится и к 2-х стадийному проектированию, и по постановлению на стадии проект делается описание в технологических разделах, что-то типа "р) описание и обоснование применяемых систем автоматизации и диспетчеризации и контроля тепловых процессов (для объектов производственного назначения) и процессов регулирования
отопления, вентиляции и кондиционирования воздуха;", на стадии Р делается по ГОСТ 21.408-2013, в нем документы В1, В2 не предусмотрены

[Ryzhij]

Коллеги, почему вы рассматриваете карту регистров Модбас-протокола (или иного списка сетевых параметров) как рабочую документацию, а не как задание программисту? Если рабочий софт не разрабатывается в комплекте с документацией, и всё ограничивается алгоритмом, то подобные таблицы вполне могут оказаться в "Требованиях к смежным разделам проекта".

[RomTom]

Вот сколько видел описаний цифрового интерфейса Модбас в готовом изделии РФ, все были в ПС.

[petr2off]

По своей практике, в 80% случаях выдавить из поставщика нормальное описание цифрового интерфейса Модбас подвиг, особенно если начальник не понимает нужности этого документа.

[Jackson]

По своей практике, в 80% случаях выдавить из поставщика нормальное описание цифрового интерфейса Модбас подвиг, особенно если начальник не понимает нужности этого документа.

Доступность этого документа никак не связана с тем, в какой радел и этап он может быть помещён.

[Ryzhij]

Вот сколько видел описаний цифрового интерфейса Модбас в готовом изделии РФ, все были в ПС.

Нам карту сетевых параметров модбас передали в документе ИО.В6 по 34-му стандарту.

[keysansa]

Кроме таблиц Modbus регистров, в документации должны быть и схемы соединений с адресами... По моему мнению, таблицы регистров неразрывно связаны с оборудованием, и в целом, указываются или в ТЗ или в дополнении к ним, при замене оборудования.