Здравствуйте!
Как вы оформляете документацию по программам для ПЛК, по каким стандартам? Есть какие-то общие стандарты?
Вид для печати
Здравствуйте!
Как вы оформляете документацию по программам для ПЛК, по каким стандартам? Есть какие-то общие стандарты?
Погугли ЕСПД и пример ЕСПД. В инете есть. Они как раз примерно за эти годы.
За эти - имеете в виду какие? Сходу нагуглил точно то, что у меня есть. Такое ощущение, что ничего свежего и не разрабатывали.Цитата:
Сообщение от alex3000plus
лучший бумажный книжняк на эту тему:
Клюев,Глазов,Дубровский
"Проектирование систем автоматизации технологических процессов.
Справочное пособие."
2-е издание,Москва,Энергоатомидат,1990 г.
-можот скан есть в инете.
вот как она выглядит:
Ну да, там 77, 79 годаЦитата:
Сообщение от Вова
Спасибо, поищу, посмотрю.Цитата:
Сообщение от dr_gebbels
А всё-таки, какую документацию вы делаете на программы для ПЛК? Или просто программа с комментариями?
Вообще спасибо, пригодится, но а так да, немного не в тему :)
Но блин, вот ответили три человека, спрошу у вас прямо - какую документацию лично вы делаете на свои программы лично для себя? И что для заказчика? Именно по программам, алгоритмам, и всё.
Для заказчика только инструкцию с описанием на какие кнопки жать, и как это работает, но не на программу, а на САУ в целом.
а для внутреннего пользования подробных комментариев в проекте вполне достаточно.
Бумажный листинг видел только один раз на итальянском станочке 20 летней давности.
если опираться на это чтиво (которое я показал),то думаю так:
для заказчика должно быть краткое описание алгоритмов в пояснительной записке.
Цитата:
Сообщение от BETEP
Спасибо за ответы! Значит, бумажный геморрой не предвидится, это хорошо :)Цитата:
Сообщение от dr_gebbels
Для заказчика только инструкцию с описанием на какие кнопки жать
скромно замечу,инструкцию должен составлять местный персонал ИТР- с утверждением
местного Г-Л-А-В-Н-Ю-К-А,
а поставщики услуг -"внедряльщики"-должны в письменном виде (т.е. в наладошном отчоте) дать
набор рекомендаций для оперов.
В тех фирмах где я принимал участие, процесс разработки оборудования для заказчика начинается с подробного тех.задания от заказчика, как программа должна себя вести в соответствующей операции. Так что выходит, что документацию для логики ПЛК пишет заказчик, а программисты от неё стараются не отклониться. Отсается только написать инструкцию оператору, как работать с HMI
Я в своей практике ни разу не видел ТЗ от заказчика. Только сумбурные потоки сознания от человека, который знает (или думает, что знает :)), как система должна работать.Цитата:
Сообщение от capzap
ТЗ, документ как таковой, у нас всегда разрабатывается организацией-исполнителем. И согласовывается с заказчиком. Вот такая вот грустная реальность.
Я в своей практике ни разу не видел ТЗ от заказчика...
ТЗ должен составить местный гЛавнюк вместе со своей свитой:главные
технолог,механик,енергетик... и т.п.
но как показывает российская действительность-они НЕбельмеса в этом НЕ
понимают,и после ентого,начинается мучительно долгий процесс согласований с ИСПОЛНИТЕЛЯМи :о)
ТЗ пожалуй у всех больная тема.
в инете куча статей и рассуждений на эту тему, начиная с того как вместе с заказчиком его составить http://lapitskiy.ru/?p=28 что-бы правильно выполнить работу и заканчивая, как его правильно оформить исполнителю и не попасть на фразах типа "Интуитивно понятный интерфейс" т.е. можно найти рекомендации и обсуждения как сесть на шею исполнителю и прокинуть его с деньгами, (ТЗ ведь часть договора), и наоборот, как застраховаться исполнителю от чрезмерных хотелок заказчика. Даже есть люди которые ТЗ профессионально занимаются, некоторые технописы например.
т.е. ТЗ всегда составляет тот, кто больше всего в нём заинтересован. и абсолютно всем по барабану, кто это должен сделать.
ещё ТЗ на не мелком предприятии это способ отвертеться исполнителю от самодурства управленцев и недотехнологов, Объясняет такой товарищ тебе на пальцах что надо сделать или переделать, и нет смысла с ним спорить, отправляешь его писать ТЗ, согласовывать его с другими заинтересованными ( к ТБ даже отправлял) и главное, подписывать этот документ. Обычно этому товарищу некогда этим заниматься, и он перестаёт надоедать, ну а если он всётаки написал обдуманное ТЗ, значит работа действительно нужна.
Смотря что нужно заказчику. Можно на одной страничке пояснительной записки описать алгоритм работы, можно написать руководство, а если захочет, то и по 34 ГОСТу оформляем (ГОСТ 34.201
ГОСТ19.101
Требования к содержанию
Иногда проще и легче показать ответственному лицу реальный интерфейс пользователя системы, и рихтовать его просьбы-замечания, чем описывать это на бумаге. ИБО не понятно на каком языке это писать (напр. русский язык программиста и язык гл. технолога- разный).