Рецензия на метод. рекомендации по проектированию АС

[san]

В дипломе экономический раздел тоже есть. Одна часть - это экономическое обоснования, вторая - расчет стоимости создания/модернизации, подсчитывание время окупаемости и т.д... После того как сам в свое время диплом сдал, больше туда не лез, поскольку эти разделы курируют из экономических кафедр. Но понимаю, что рано или поздно надо будет и там корректировать.
Никита, что предлагаете по поводу софта? Чему именно больше уделить внимания?
У нас в свое время создали специализацию КИСУшников "Автоматизация бизнес-процессов". Совсем неудачное название, как по мне (и не только). Так идея была в том, что оин будут заниматься MES и ERP. Ну MESом сам бог велел, но ERP - как то совсем не наше. Ну да ладно, до ERP так руки и не дошли ни у кого. Из MESа в свое время благодарая ИндаСофт (не сочтите за рекламу) у нас начали давать Plant Application (MES), iHistorian (СУБД реального времени), RTIP (клиент уровня MES). В дипломе студенты показуют этот софт со всеми вытекающими на схеме сетевых информационных потоков, делают дисплейные видеокадры. Второе как-то у них пресно и без особого понимания получается, функционалку б им туда какую-то вставить (сечас дают схемы из ), но с чего-то надо начинать. Это направление как-то вяло развивается, а у меня пока не хватает "клепки" в голове, чтоб за него браться. Если б какой-то реальный объект попался с MES, я б прочувствовал, а так пальцами размахивать ... не ловко как то. По-этому в курсовом ограничили систему только централизованным архивом и диспетчеризацией по производственной линии, куда можно вместо RTIPов обычные SCADA впихивать. Да и давать студентам надо только то, что они пощупали руками или по крайней мере прослушали в курсе. В этом году среди СКАД всего 2 - VijeoCitect/Citect и ZENON, среди ПЛК - Modicon Premium/M340, Twido, VIPA, Mitsubishi FX, Siemens S7-300.

[Никита]

Не великий я специалист по MES и ERP, мне б чего-нить что можно потрогать руками - оно проще...
По поводу софта - сложно сказать, не видя того, чему их вообще должны учить. Про алгоритмы я уже писал. А то получается что человек кроме ПИД-регулятора ничего не знает. Приносили мне тут по весне на рецензию шесть работ - через одного системы построены так, что регулятор улетит вразнос. В общем - заставить хотя бы на бумаге разрисовать то, что собираются лить в контроллер, пусть на кошках тренируются...
Да и первичная обработка сигналов тоже важна - где дребезг фильтровать, где ФНЧ нужен, где наоборот, где выход за границы ловить. Кстати, не заметил в методичке перечня уставок, ни предупредительного ни аварийного. А этот документ, однако, под роспись согласовывается...
Еще неплохо бы научить их ориентироваться в ассортименте софта - необходимых функциях, лицензиях и т.п, но как это реализовать - в рамках курсовика пока не знаю. И межпрограммный обмен кстати тоже достаточно интересен, а то получаются такие чудеса как тут в одной ветке при связке Codesys и InTouch - Codesys Gateway->DDE->OPС->DDE->InTouch... Архивы опять же в разрезе управления предприятием неплохо бы рассмотреть, а не только тренды. Мож запросы к ним какие... Впрочем это уже так, мысли вслух.
По поводу экономики - это у нас вечная тема для дискуссий с профессорами - им она в силу специфики финансирования нафиг не нужна (да и я в свое время пары по экономике предприятия часто в пивной просиживал) а в реальности потом можно поиметь большие проблемы - залезть глубоко в ... без достаточного финансирования...

[san]

Не великий я специалист по MES и ERP, мне б чего-нить что можно потрогать руками - оно проще...
По поводу софта - сложно сказать, не видя того, чему их вообще должны учить. Про алгоритмы я уже писал. А то получается что человек кроме ПИД-регулятора ничего не знает. Приносили мне тут по весне на рецензию шесть работ - через одного системы построены так, что регулятор улетит вразнос. В общем - заставить хотя бы на бумаге разрисовать то, что собираются лить в контроллер, пусть на кошках тренируются...

Курсач по проектированию - это типа подитожный по проектированию, но исключающий детали в некоторых разделах, поскольку они были затронуты в других курсовых. Так, например, есть куросовой по "контроллерам и их программному обеспечению". В инете есть выложена методичка (опять же на украинском зяыке, по этой прричине не вылаживаю тут). Там студики занимаются как хардовой так и софтовой частью ПЛК. В этом году многие взяли Modicon M340 с UNITY, имеющий встроенный симулятор, вот там они на имитационных примитивных моделях испытывают свои чудо-программы. Чесно говоря, всякие каскадные схемы с имитатционной моделью мы им редко даем в этом курсовом. В диплом эта часть тоже входит, но в курсовой по проектированию - это сильно много. По этой причине включили только хардовую часть.

Да и первичная обработка сигналов тоже важна - где дребезг фильтровать, где ФНЧ нужен, где наоборот, где выход за границы ловить. Кстати, не заметил в методичке перечня уставок, ни предупредительного ни аварийного. А этот документ, однако, под роспись согласовывается...

По поводу фильтрации и дребезгов сигналов - где это указывается в проекте? Можно бы было посилить эту часть для чистых автоматичков. Года 2-3 назад кафедра приняла решение забрать с диплома раздел моделирования с проверкой работы контуров, так как все рисовали одинкаовые графики, причем явно не в Симулинке. Руководители всё съедали, и доходило до семшного, когда в один день защиты для разных объектов были абсолютно одинаковые листы. Конечно это проблема контроля.
Сообщения и алармы входит в курсач по ЧМИ и входят в диплом. А над формой можно поработать. Есть примеры?

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

Думаю, эта тема скользкая. Разный софт - разные подходы.Да и в проекте оно как-то отображается? Можно попробовать его курсовике по ЧМИ как-то отобразить.

И межпрограммный обмен кстати тоже достаточно интересен, а то получаются такие чудеса как тут в одной ветке при связке Codesys и InTouch - Codesys Gateway->DDE->OPС->DDE->InTouch... Архивы опять же в разрезе управления предприятием неплохо бы рассмотреть, а не только тренды. Мож запросы к ним какие... Впрочем это уже так, мысли вслух.

Межпрограммное взаимодействие поакзывается в "Схеме сетевых информационных потоков". По поводу запросов - вопрос тяжелый. Как-то работу с БД им только в контексте Access дают. SQL я им только за 10 минут успеваю рассказать. Хотя на лабах в дисциплине "Промышленные сети и интеграционные технологии" есть одна лабораторка, где Citectы ложат данные в MS SQL Server, а Excel их периодически вытягивает с интервалом 1 мин за последний час. В былые времена рисковал дать это вкачестве задания (еще на TraceMode), потом посмотрел - не тянут. Написал полностью лабораторку "степ бай степ" и вроде как с горем пополам делают, но немногие понимают "что" :-) . Тут пробелов ну очень много. Понимаю, какие ж они тогда "компьютерно-иентегрированные", но потому и стараемся усовершнествовать.

По поводу экономики - это у нас вечная тема для дискуссий с профессорами - им она в силу специфики финансирования нафиг не нужна (да и я в свое время пары по экономике предприятия часто в пивной просиживал) а в реальности потом можно поиметь большие проблемы - залезть глубоко в ... без достаточного финансирования...

У нас, слава богу, профессора это понимают.

[Никита]

По поводу фильтрации и дребезгов сигналов - где это указывается в проекте? Можно бы было посилить эту часть для чистых автоматичков. Года 2-3 назад кафедра приняла решение забрать с диплома раздел моделирования с проверкой работы контуров, так как все рисовали одинкаовые графики, причем явно не в Симулинке. Руководители всё съедали, и доходило до семшного, когда в один день защиты для разных объектов были абсолютно одинаковые листы. Конечно это проблема контроля.

Еще момент - професура часто в увлечении контурами забывает про логику, а ее в реальности изрядно. Тут в параллельной ветке студент контроллер с частотником сопрягает, так судя по всему, тоже забыл что кроме задания аналогового, частотник еще пустить и остановить надо... Да вообще до анекдотов доходит - пять курсов учатся динамике типовых звеньев на операционниках, а некоторые даже после выпуска не знают что этим операционникам еще и питание подавать надо..
Тут и возникает проблема - вроде студент все, что положено, выучил, а сделать ничего не может - особенности реальной жизни не включены в учебники ТАУ. Да даже в симулинке подавляющее большинство забывает про насыщение реальных схем, отстраивают контура в отрыве от реальности. А потом получаем изделия, в прошивке которых нет ограничения на значение интегральной составляющей регулятора...
Впрочем, это все к софтовой части.
Фильтрация и дребезг - да опять кому как охота. Просто как пример - из раннего творчества, десять лет скоро этому проекту...
Блок-схемы_алгоритмов.pdf

Сообщения и алармы входит в курсач по ЧМИ и входят в диплом. А над формой можно поработать. Есть примеры?

Оттуда же Таблица_уставок.pdf

Думаю, эта тема скользкая. Разный софт - разные подходы.Да и в проекте оно как-то отображается? Можно попробовать его курсовике по ЧМИ как-то отобразить

А як же ж? Спецификации никто не отменял. Так вот с этими подходами неплохо было бы познакомить. Равно как и с методиками расчета точек в/в для лицензирования среды разработки. Естественно не подробно, а просто чтоб имели представление.

Межпрограммное взаимодействие показывается в "Схеме сетевых информационных потоков"

Так там и без сетевых потоков, на одном локальном АРМе может быть весело...

В былые времена рисковал дать это вкачестве задания (еще на TraceMode), потом посмотрел - не тянут.

Мда.. Техника усложняется, студенты упрощаются...

У нас, слава богу, профессора это понимают.

Это уже хорошо. Еще б сами умели эту экономику считать и балбесов научили - цены б им не было :)

[san]

Если все пойдет дальше в таком же темпе как началось, есть смысл постоянной коррекции методички к ТЗ и к курсовому. По этой причине выложил русский перевод ТЗ на страницу своего сайта (я его для себя сделал как открытый файл-обменник, хоть объем там всего до 100 мб).
https://sites.google.com/site/akitporta ... proekt-ukr
За перевод особо не пинайте, все делалось быстро и в двух редакциях - моей коллеги, соавтора методичики, (за что ей большое спасибо), после чего подкоректировано мной. Все ваши пожелания к переводу тоже будут учтены.
Перевод методички к курсовому - дело более хлопотное. Так что может кновому году не успеем.

[CHANt]

Приветствую Александр!
Немного накидал по ТЗ
От Стр 23
«Требования к характеристикам связи систем АСУТП и КИСУ со смежными системами. Требования к связи АСУТП ЦМП с другими подсистемами.»
Надо определить:
1) Не указана требуемая пропускная способность к каналам связи. К примеру – на какую скорость настраивать Profibus. Зависит ведь и от расстояния. Либо ее надо определить проектом, тогда надо указать.
2) Нет требований к телефонной связи - какая это связь? Оперативная диспетчерская – когда трубку снял и у оператора уже вызов идет, или это технологическая связь – по набору номера. Не указано что сделать нужно, типа - установить и проложить телефонную сеть, задействовать IP-телефония ит.п. Может быть выдать задание на разработку проекта по телефонизации?

«Требования к режимам функционирования системы»
Второй абзац. Не определены требования целевого состояния системы при переходе в автономный режим. Т.е. что система должна сделать – остаться в том же состоянии, уйти на начальное ит.п.?
В последнем абзаце приведены требования к режимам управления. Корректней будет «ручной» режим называть дистанционным управлением. Ручной, на мой взгляд, это когда оператор пошел кефир на глаз наливать))

«Требования к диагностированию системы.» (мой вариант)
Программные и технические средства системы должны обеспечивать глубокую степень диагностики и самодиагностики компонентов технических средств. Информация о работе этих средств должна формироваться с помощью:
1. Индикаторов, встроенных в технические средства 1 и 2 уровня;
2. В сводке тревог АРМ ЦМП.
С помощью средств самодиагностики должны фиксироваться, как минимум, следующие ситуации:
1. Обрыв цепи аналогового датчика с сигналом 4-20 мА и сигнала от термопары;
2. Сбой частотного преобразователя;
3. Отсутствие питания оперативных цепей управления;
4. Отказ ПЛК;
5. Отклонение сигналов за установленные диапазоны;
6. Отказ линий связи.
Все средства самодиагностики должны определять конкретный адрес неисправного устройства. Диагностические сообщения должны поступать в АРМ ЦМП и квитироваться оперативным персоналом.
4.1.3. «Требования к показателям назначения»
А про параметры для программиста ПЛК и СКАДА и не указали… С какой периодичностью обновлять данные на мнемосхеме, измерять в контроллере? Время реакции на аварийные сигналы?
10 лет? Ни один компьютер не выдержит такой срок работы. Надо конкретизировать по видам оборудования. Даже на частотниках, как минимум, надо будет вентиляторы сменить ит.п.
4.1.4 «Требования к надежности»
Надо конкретизировать! Какие параметры выбираются в качестве показателей. По каким функциям проводить анализ. Определить целевые значения показателей надежности, чтобы после расчета было с чем сравнивать.
4.1.6 «Требования к эргономике и технической эстетике»
Предложение - надо указать систему кодирования информации. Что каким цветом должно отображаться, значки каких размеров должны быть на экране ит.п. Многое ведь зависит от отрасли, а ТЗ это проработка требований данной отрасли. Вот у электриков принято нормальный цвет – красный - Оборудование под напряжением. Опасно! Отключено – зеленый. У других наоборот..Т.е. откуда берутся эти вещи студенты должны понимать. Может быть, на предприятии использоваться и система кодирования информации. Т.е. теги задаются определенным образом, у нас одно время требовали KKS.
4.1.7 «Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы»
Надо указать требования к климатическим условиям – может вентиляцию в шкафах делать надо или систему кондиционирования, или подогрев… Причем по уровням. Так как условия эксплуатации в операторных будут отличатся от цеховых. Требования к исполнению шкафов?
По эксплуатации - можно дать задание разработать в проекте инструкцию по эксплуатации системы. Ведь состав проектной документации определяет проектировщик!
4.1.12 «Требования по стандартизации и унификации» (мой вариант)
Унификация на стадии разработки АСУТП должна обеспечиваться единообразным подходом к решению однотипных задач контроля и управления (типизацией алгоритмических модулей) и созданием унифицированных компонентов информационного, лингвистического, программного и технического обеспечений.
В конструкции компонентов АСУТП должна быть сведена к минимуму номенклатура используемых модулей. Должно использоваться минимальное количество номиналов питающих напряжений. Конструктивы должны быть унифицированы.
Технологические алгоритмы должны задаваться в формализованном виде, на специализированном языке, доступном специалистам в области автоматизации.

Требования к видам обеспечения.
Интересно, вот требований к мат.обеспечению нет, а к метрологическому (хоть и формально) есть. Вот, например – сколько знаков после запятой должны иметь параметры производительности установки, ну или что-то типа этого. Это же техническое Задание.

[san]

Спасибо, CHANt.
Бегло проглянул, время появится - буду добавлять/исправлять.

[CHANt]

Мое мнение таково:
За разработку технического задания существуют расценки. За проект отдельно, за ТЗ отдельно. Значит в ТЗ должна содержаться конкретика, а не ссылки на ГОСТ - мол проектировщик прочитай и учти эти требования. Это не верно. Раз при подготовке ТЗ прорабатывается НТД государства, отрасли, предприятия, процесса - значит должно быть выдано задание уже конечное. Т.е. разработчик проекта должен руководствоваться информацией с ТЗ. а не рыться в ГОСТах. Поэтому и должны быть определены и цвет фона мнемосхем, и размер в пикселях УГО (условно-графических обозначений) и т.п. Далее, раз определяете состав документации проекта, значит все то что не выполняете должно быть отражено уже в ТЗ в каком-то объеме. К примеру: нет документа "Массив информации", значит должны указать в ТЗ какие данные процесса должны передаваться с контроллера, какие наоборот, как отображать, что архивировать...На сколько детально? Ну тут наверное определять исходя из состава проекта. Либо должно быть указание включить туда-то и туда-то.
Понятно, что в реальной жизни, что греха таить, частенько формально подходим к этому вопросы. Воды в ТЗ много. Но, надо стремиться к лучшему.
Описание тех . процесса понравилось - если б так в жизни было! :D В этом плане молодцы! И ведь ни одной ссылки на стандарт или прочее :D

[san]

Значит в ТЗ должна содержаться конкретика, а не ссылки на ГОСТ - мол проектировщик прочитай и учти эти требования. Это не верно. Раз при подготовке ТЗ прорабатывается НТД государства, отрасли, предприятия, процесса - значит должно быть выдано задание уже конечное. Т.е. разработчик проекта должен руководствоваться информацией с ТЗ. а не рыться в ГОСТах.

Смотря о чем идет речь. Если говорить о выполнении документации (п.8), создание любого из видов обеспечения, то представьте, как тогда будет выглядить ТЗ - томами. Для примера, в ТЗ не надо ж описывать правила создания схемы автоматизации или приницпиалки, входящие в состав рабочей документации, согласно требованияю к документированию. Или каким образом осуществляется заземление (4.1.5).

Поэтому и должны быть определены и цвет фона мнемосхем, и размер в пикселях УГО (условно-графических обозначений) и т.п.

Для пунктов 4.1.6 или 4.1.7, возможно Вы правы. Они в этом ТЗ просто сырые.

Далее, раз определяете состав документации проекта, значит все то что не выполняете должно быть отражено уже в ТЗ в каком-то объеме. К примеру: нет документа "Массив информации", значит должны указать в ТЗ какие данные процесса должны передаваться с контроллера, какие наоборот, как отображать, что архивировать...На сколько детально? Ну тут наверное определять исходя из состава проекта. Либо должно быть указание включить туда-то и туда-то.

Так в ТЗ таблица Т6 вроде как есть. Таблица Т9 5.1, 5.2 это не то? Если указать перечень присутствующих документов, разве нужно указывать перечень отстуствующих?

Описание тех . процесса понравилось - если б так в жизни было! :D В этом плане молодцы! И ведь ни одной ссылки на стандарт или прочее :D

[/quote]
Описание в жизни или тех-процесс? Описание тех-процесса это наверное то, что наиболее нужно стороне исполнителя, и тяжело добиться от технологов. Мы как правило трудимся на модернизации, там вроде проще с этим делом. Но модернизация АСУТП часто проходит с модернизацией технологии, и тут они часто сами не знают чего хотят.

П.С. Думаю что с таким разгоном методичка к ТЗ для студентов плавно превратится по объему в настоящее ТЗ. Я не против, обратный процесс дегромоздификация ( :-) ), попроще чем создание с нуля. По этому двигаемся в этом напрвалении.

[CHANt]

Смотря о чем идет речь. Если говорить о выполнении документации (п.8), создание любого из видов обеспечения, то представьте, как тогда будет выглядить ТЗ - томами. Для примера, в ТЗ не надо ж описывать правила создания схемы автоматизации или приницпиалки, входящие в состав рабочей документации, согласно требованияю к документированию. Или каким образом осуществляется заземление (4.1.5).

Конечно нет. Работу проектировщик должен знать. Но давать заведомо не определенные величины и при этом отсылать к ГОСТ? Тот же раздел надежность - ГОСТ 24.701-86. В ГОСТе ведь нет числовых показателей, там методика! Что Вам студенты насчитают? Ахинею! Если у меня в отрасли ПТЭ требует два показателя - Кг=99,98%, время восстановления = 4 часа, вот по ним и идет анализ. А потом выводы - достигли этих показателей одним из расчетных методов или не достигли. Все просто. Показатели надо задать в ТЗ, а не отсылать к методу анализа. Вот что его надо использовать, по идее, проектировщик должен знать сам. А если это другой документ, тогда другой вопрос.
Следующее, требование к сети электропитания привели... И что почерпнуть из этого можно?... А где -то по тексту ИБП мелькает, так категория электроприемника какая? Глядишь и уже схема подключения в общих чертах нарисовалась, да и к главному энергетику на согласование отослать надо....

Так в ТЗ таблица Т6 вроде как есть. Таблица Т9 5.1, 5.2 это не то? Если указать перечень присутствующих документов, разве нужно указывать перечень отстуствующих?

Нет, я не про то. Если часть документов не разрабатываете то тогда надо вопросы этих документов отразить в ТЗ. Скажем - нет документа "Описание программного обеспечения" значит надо написать что надо использовать к ПО ту же винду...Написали же Сайтек использовать? Написали, и MS SQL написали, а ОС? Раз документа такого нет, по идее проектировщик и не отработает этот вопрос и не отразит в спецификации, что лицензию винды купить надо. Хотя, я уже по мелочи цепляюсь, но, я пытаюсь отразить свое ви`дение содержания документа под названием ТЗ.

Описание в жизни или тех-процесс? Описание тех-процесса это наверное то, что наиболее нужно стороне исполнителя, и тяжело добиться от технологов. Мы как правило трудимся на модернизации, там вроде проще с этим делом. Но модернизация АСУТП часто проходит с модернизацией технологии, и тут они часто сами не знают чего хотят.

Техпроцесса конечно. Получить от заказчика такое описание. это все равно что подвиг. На практике - либо ничего, либо нечто косноязычное :D У меня сейчас проект в работе - переписали общее описание схемы из справочника 80-х годов, но внесли в схему существенные современные технологичные изменения, и оставили тебе решать технологию. Кучу времени придется убить на наладке, а ведь так не хочется. За это не платят.

П.С. Думаю что с таким разгоном методичка к ТЗ для студентов плавно превратится по объему в настоящее ТЗ. Я не против, обратный процесс дегромоздификация ( :-) ), попроще чем создание с нуля. По этому двигаемся в этом напрвалении.

Да и так навернули! Я как список экранов прочитал, боже - неужели успевают сделать? Или Ваши лаборанты и аспиранты шабашат? :D Можно не отвечать Шучу

Может ТЗ каких нибудь подкинуть?

[san]

ТЗ подкинуть обязательно. Чем больше тем лучше.
О безопасности, согласен. Эти вопросы сырые не только в ТЗ но и вобще, в образовании на кафедре. Тут пробелы сплошные (даже полная пустота я б так сказал) не только в ТЗ но и в моей голове (за других не отвечаю).Чтоб раздел не пустовал - честно слизал с других коз. Может для учебных целей его вобще не давать.
Наверное надо еще раз объясниться.
1. Есть дипломный проект для специалистов. На сегодняшний момент в его состав входят разделы (даю ориентировочно, на память назания не помню):
1.1. технико-экономическое обоснование
1.2. схема автоматизации+спеицифкация (выбор технических средств)
1.3. компоновка ПЛК (выбор ПЛК, подбор модулей ввода/вывода, расчет питания)
1.4. принципиальные схемы (совмещенные электр+пневм) контуров измерения, управления, регулирования, сигнализации
1.5. приниципиальные схемы питания (электрические, пневматические) - (только автоматчики)
1.6. программа для ПЛК (частичная реализация контуров или выбраной задачи)
1.7. SCADA/HMI - дисплейные мнемосхемы, таблицы тегов, тренды, алармы
1.8. чертеж общего вида для щита (только автоматчики), план пункта управления
1.9. схемы соединений и подключений внешних проводок (тольок автоматчики)
1.10 организационная структура предприятия, функциоанлаьня структура КИСУ, структурная схема КТС КИСУ (только для комп-интегрир)
1.11 принципиальная схема вычислительных сетей (только комп-интегр)
1.12 схемы сетевых информационных потоков (только комп-интегр)
1.13 построение модели объекта, снятие кривых разгона, моделирование замкнутой системы, расчет и подбор настроек регуляторов по переходным процессам
1.14 охрана труда
1.15 гражданская оборона
2. Есть курсовые практически по каждому разделу начиная с 3-го курса. Итоговый курсовой по проектированию включает все разделы кроме (1.1, 1.6, 1.7, 1.13, 1.14, 1.15). Пункт 1.13 - опциональный (я у же о нем писал), 1.11 - предлагаю заменить на схемы соединений сетевых проводок (для меня это очень спорный вопрос как по нужности самой схемы так и по ее выполнению), 1.12 - не стандартный лист (о нем тоже писал высше).
3. Идея для курсовго по проектированию и для дипломного ввести промежуточный раздел - ТЗ, наблизить курсовой и диплом к форме документации к техно-рабочему проекту.
Таким образом можно убить несколько зайцев:
- во первых, дать базовые навыки создания ТЗ (ни в какой дисциплине его не дают, самый раз давать его в проектировании)
- во вторых, разрулить курсовые и дипломные между студентами (даже тема диплома моежет совпадать по объекту, но в ТЗ поменять требования к разным видам обеспечения). По этой причине желательно привести тербования к табличному виду
- в третьих, провести студентов по основным стадиям разработки пректа и созданию документации.
4. Сейчас я думаю, что все высшесказаные замечания можно рассматривать в контексте нескольких задач:
- методичка к написанию ТЗ (полный рабочий вариант)
- методичка к написанию ТЗ (вариант к курсовому проекту)
- методичка к написанию ТЗ (вариант к дипломному проекту)

П.С. Я понимаю, что у меня сейчас очень мало времени заняться обработкой замечаний и предложений. Где-то найду полденька для подитожения того, что уже накидали. Не хочу чтоб тема умерла, так как считаю ее очень важной в образовании и самообразовании (чего греха таить). Так что, уважаемые специалисты, пожалуйста, отправляйте свои замечания, даже если я не смогу на них отвечать.

[san]

Только сейчас заметил, что появился новый раздел форума.

[CHANt]

Да, надо сюда перенести тему с разработкой связи по частотникам. Кстати, я собрал информацию по данфоссу и авв, на каникулах постараюсь сделать пару примеров. Пока вторая работа мешает :) у меня "горячий" сезон.

[san]

Попробую резюмировать замечания к курсовму проекту:

Не знаю, действует ли у вас ценник 97г, но слова "кошторис" я в методичке не увидел. А меж тем очень многие требуют именно смету на проект. С нее по идее, все должно начинаться - объем сигналов, коэффициенты на одинаковые объекты, индексы.
Подробно может и не стоит об этом писать, но пару-тройку абзацев можно уделить.

Тут еще момент - в ценнике есть договорной понижающий коэффициент на объем документов, а полного перечня документов проекта в методе тоже нет. И принципа комплектования альбомов, а за это нормоконтроль часто гоняет, да и экспертиза тоже. Нет возможности описать - хотя бы ссылки дайте, кто ищет - тому легче найти будет.

Я, собственно имел в виду именно блок-схемы алгоритмов. Рисовать их по ГОСТ 19.002-80 - муторно и незачем, частично можно конечно использовать для общего алгоритма работы. А вот те же алгоритмы регулирования - тут каждый рисует как он хочет... Было время - заказчики и трейсмодовские FBDшки принимали распечатанные.

Да и первичная обработка сигналов тоже важна - где дребезг фильтровать, где ФНЧ нужен, где наоборот, где выход за границы ловить. Кстати, не заметил в методичке перечня уставок, ни предупредительного ни аварийного. А этот документ, однако, под роспись согласовывается...
Еще неплохо бы научить их ориентироваться в ассортименте софта - необходимых функциях, лицензиях и т.п, но как это реализовать - в рамках курсовика пока не знаю.

К ТЗ пока замечания дал только CHANt, там все и так по пунктам, резюмировать нечего.

[CHANt]

Наверное надо еще раз объясниться.
1. Есть дипломный проект для специалистов. На сегодняшний момент в его состав входят разделы (даю ориентировочно, на память назания не помню):
...

Я тут тоже помощник аховый
Уже два года как в РФ действует постановление правительства №87, и изменена форма лицензирование проектных работ и СМР. Теперь надо иметь допуск СРО (Саморегулируемая организация).
По 87 постановлению есть требования выполнять проект двумя разделами:
1) ТП. Это утверждаемая часть и проходит либо госэкспертизу, либо экспертизу промбезопасности.
2) РД. Разрабатывается на основании ТП.
Все. Больше никаких там эскизов и прочего. Зато много всяких требований, к примеру, раздел автоматизации включать к каждому разделу строительства. Т.е. в раздел теплоснабжение - вставить автоматизацию. в водоснабжение и водоотведение тоже включить автоматизацию. Получается, если выполнять эти требования придется делать несколько проектов АСУТП в одном большом проекте, это тяжело взаимоувязывать - чаще всего система то одна и решает все вопросы. Выход мы пока нашли такой, пишем в ТЗ - "раздел автоматизации выполнить отдельным томом". По крайней мере для экспертизы промбезопасности это проходит.
Следующая проблема. Последние годы в моем регионе, про другие не могу сказать, принято, в качестве документации ТП и РД к системам АСУТП применять требования ГОСТ 21.408-93.
В ГОСТ 21.408-93 говорится следующее:
"Требования настоящего стандарта распространяются на рабочую документацию технического обеспечения АСУ ТП, разрабатываемую по ГОСТ 34.201.
Стандарт не распространяется на рабочую документацию систем автоматизации централизованного управления энергоснабжением."
Вот и реализуют только чертежи в качестве основной части ТП и предоставляют их на экспертизу, и это проходит вплоть до согласования с Ростехнадзором.
На мой взгляд, предоставлять заказчику только чертежи по ГОСТ 21.408-93 мало. Поэтому, когда нанимают, моя команда выпускает, в качестве РД, еще часть документов из ГОСТ 34.201. К примеру - "Описание алгоритмов", Формуляр, Паспорт, все инструкции ит.п. все зависит от сложности и категории объекта. Определяем сами, от этого зависит и стоимость выполняемых работ.
Поэтому, какой состав разделов в проекте должен быть, лично я , сказать не могу. ГОСТы 19 и 34 серии устарели и не отвечают текущим требованиям. Из приходящих ко мне на проверку проектов телемеханики и АСОДУ, на основной работе, складывается мнение - кто на что горазд, как ГИП видит решения свои. Да, какой то минимум я в типовых ТТ по энергосистеме определил, тем не менее, иногда хочется раскрытия больших вопросов.
В общем, рекомендации по составу ТРП должны наверное опираться, прежде всего на принятые НТД Украины и отраслевые стандарты, либо стандарты предприятий.
А вот содержание документов можно посмотреть ) Переводите методичку, посмотрим.

[san]

С составом документов у нас пищевиков попроще будет. Что зак захочет, то в стоставе и будет. Как правило заку готовой системы нужны только принципиалки, чтоб можно было киповцам в случае чего быстро найти неисправность. Да и буржуины оставляют кроме эксплуатационных инструкций только приниципиалки. А пречень документов вроде как с заком опредлеяется. А вот прохождение экспертизы - тут я полный профан.
Мне более важно, чтоб студики (и я вместе с ними) прошли по важным стадиям проектирования. Вданом случае КИСУ. Хотелось бы конечно, чтоб это все прошло согласно требованиям стандартов. Гипотетически, в курсовом и дипломном считается, что объект модернизируется, тоесть меняется только автоматика, по этой причине можно сослаться только на стандарты 34-й группы (поправьте меня если я не прав).
На счет отечественных стандартов, на сколько я знаю стандарты 34-й и 21-й групп у нас работают. Хотя все может уже и поменялось.
Все говорят, что стандарты 34-я группы уже устарели. Но я пока в них не встречал чего-то ограничивающего в настоящее время.
Постараюсь на новогодние праздники перевести вторую методичку. Пока поработаю над ТЗ.

[CHANt]

San, могу еще предложить, на примерах, формы еще одного документа, которого нет в составе указаний ГОСТ 34,19,21. Иногда, при крупных проектах, либо при взаимодействии сУрьезных организаций :) , приходится сталкиваться с необходимостью согласовывать перечни/формуляры взаимообмена между разными системами АСУТП. Интересует?

[san]

Конечно. Это ж те документы, которые неспоредственно к интеграции и относятся.

[CHANt]

Фильтрация и дребезг - да опять кому как охота. Просто как пример - из раннего творчества, десять лет скоро этому проекту...
Блок-схемы_алгоритмов.pdf

Сообщения и алармы входит в курсач по ЧМИ и входят в диплом. А над формой можно поработать. Есть примеры?

Оттуда же Таблица_уставок.pdf

Сижу, на выходных, делаю один проект нового Центрального теплового пункта. Как обычно, ни проектировщик раздела тепломеханики (технолог), ни заказчик, не в состоянии определить уставки технологической сигнализации и защит. Обычно, в таком случае, еду в микрорайон смотрю какие здания входят в систему отопления и провожу расчет по рекомендациям данфосса и таблице Вукалвовича. Это простенький расчет по следующим принципам:
1) рассчитать данные статического гидравлического режима с учетом невскипания теплоносителя
2) расчетдля недопущения кавитации на всасе насосов холодного водоснабжения
3) расчет для недопущения кавитации на всасе насосов горячего водоснабжения.
Для котельных немного больше - еще и по минимальному давлению газа, параметрам котлов ит.п. не важно. Потом, по этим данным составляют и утверждают таблицу уставок.
Вот и вопрос к Никите :)
Посмотрите - имеет ли такой подход к проектированию право на жизнь?

РАсчет защит по ЦТП Заря.xls

[san]

Сейчас нашел время поковыряться в методичке по ТЗ. Наткнулся на тот факт, что в требованиях к показателям назначения в разных ТЗ пишут разные вещи. Так в стандарте написано:

2.6.1.3. В требованиях к показателям назначения АС приводят значения параметров, характеризующие степень соответствия системы по назначению.
Для АСУ указывают:
- степень приспособляемости системы к изменению процессов и методов управления, к отклонениям параметров объекта управления;
- допустимые пределы модернизации и развития системы;
- вероятностно-временные характеристики, при которых сохраняется целевое назначение системы.

Я так понимаю с этих немногочисленных предложений, что нужно указать те параметры при которых система будет выполнять возложенные на нее функции а также возможность ее модернизации. Тоесть:
- время работоспособности системы, при ее постоянном обслуживании (требования к обслуживанию должно даваться в эксплуатационной документации);
- возможность измениния алгоритмов управления (модернизация на програмном уровне);
- возможность модернизации и наращивания системы (добавление новых узлов или подсистем).
Нужно ли приводить тут перечень технологических параметров объекта управления, при которых система должна обеспечивать свою работоспособность (например амплитуды и частоты колебаний технологических параметров, принимаемых как возмущение; требования к параметрам енерго/водо/воздухо/.../снабжения)?
CHANt, Вы предложили сюда указывать

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

Может стоит это все вынести в требования к функциям и задачам системы?
Можно ли в этом разделе ТЗ написать общие положения подобно первому варианту методички и сослаться на конкретный раздел требований к функциям и задачам системы?
Хотя, я четко понимаю, что многие вещи (например параметры возмущений, при которых система справится) зачастую определяются в процессе пусконаладки. По этой причине в ТЗ их вынести юудет тяжеловато. Но в любом случае минимальные гарантированные требования должны конечно же прозвучать. Можно конечно взять эти минимальные требования как за максимальные показатели....
Вобщем, какие ваши советы по этому поводу?

[san]

Примеры на
- Требования к надежности и
- Требования к безопасности
есть. Может кто б теорией снабдил. Знаю что у Фёдорова целый том есть, но думаю что за такой короткий срок неосилю. Может есть какие-то методичики или основополагающие ГОСТы. Поделитесь ссылочками плиз.

[san]

Примеры на
- Требования к надежности и
- Требования к безопасности
есть. Может кто б теорией снабдил. Знаю что у Фёдорова целый том есть, но думаю что за такой короткий срок неосилю. Может есть какие-то методичики или основополагающие ГОСТы. Поделитесь ссылочками плиз.

Уже кое-что нашёл. Нестеров "Проектирование АСУТП. ТОМ 1". Решил пока еще раз почитать этот фундаментальный труд, потом вернусь к ТЗ. А то все как-то частями и бегло, на каникулах все-же можно почитать более спокойно. Кстати, многие 2-й том ценят намного больше чем 1-ый, но как по мне - обе книги дали очень много полезной информации.

[CHANt]

Я так понимаю с этих немногочисленных предложений, что нужно указать те параметры при которых система будет выполнять возложенные на нее функции а также возможность ее модернизации. Тоесть:
- время работоспособности системы, при ее постоянном обслуживании (требования к обслуживанию должно даваться в эксплуатационной документации);
- возможность измениния алгоритмов управления (модернизация на програмном уровне);
- возможность модернизации и наращивания системы (добавление новых узлов или подсистем).
Нужно ли приводить тут перечень технологических параметров объекта управления, при которых система должна обеспечивать свою работоспособность (например амплитуды и частоты колебаний технологических параметров, принимаемых как возмущение; требования к параметрам енерго/водо/воздухо/.../снабжения)?
CHANt, Вы предложили сюда указывать

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

Может стоит это все вынести в требования к функциям и задачам системы?
Можно ли в этом разделе ТЗ написать общие положения подобно первому варианту методички и сослаться на конкретный раздел требований к функциям и задачам системы?

Одно дело когда это типовое техзадание или тех требования, другое дело когда Вы на конкретную систему даете конкретные цифры. Ведь обновление видеокадра по факту настраивается в самой СКАДе, в настройках окна. Тоже самое, если есть определенные требования к измерениям и, например, к ведению массива информации с заданной периодичностью, то самое место указать цифры. Если хотите отнести к другим разделам, тогда резонный вопрос - зачем оставлять этот? Чтоб по ГОСТу было? Это формализм. Зачем учить этому?

Хотя, я четко понимаю, что многие вещи (например параметры возмущений, при которых система справится) зачастую определяются в процессе пусконаладки. По этой причине в ТЗ их вынести юудет тяжеловато. Но в любом случае минимальные гарантированные требования должны конечно же прозвучать. Можно конечно взять эти минимальные требования как за максимальные показатели....
Вобщем, какие ваши советы по этому поводу?

Вот это точно не задача ТЗ - привод надо выбрать на этапе проектирования. Можно включить требования о необходимости разработки мат. модели и к ее параметрам. Результаты использовать для облегчения выбора привода при проектировании. Привода разные характеристики имеют.
Для наладки существует документ - "Программа и методика испытаний".

[san]

Одно дело когда это типовое техзадание или тех требования, другое дело когда Вы на конкретную систему даете конкретные цифры. Ведь обновление видеокадра по факту настраивается в самой СКАДе, в настройках окна. Тоже самое, если есть определенные требования к измерениям и, например, к ведению массива информации с заданной периодичностью, то самое место указать цифры. Если хотите отнести к другим разделам, тогда резонный вопрос - зачем оставлять этот? Чтоб по ГОСТу было? Это формализм. Зачем учить этому?

Следовательно описанию в стандарте к ТЗ - это вроде как не тот раздел, чтоб указывать периодичность обновления переменных. Это вроде как относится к функции индикации, и должно быть отображенно в требованиях к функциям системы, ИМХО. Во многих примерах, высланых Вами, периодичность обновления перемнных тоже в требованиях к функциям приведены. А этот раздел, я так понимаю нужен для определения тех границ, в каких система справляется со своей задачей. Это типа, если газа не будет - яишницу наша сковородка, оснащенная автоматикой, не приготовит; а если газ будет с очень низким давлением - то яишница не приготивится за 2 минуты, как обещано разработчиками; яишница заданого качества (с голубой корочкой сверху, не поджарена снизу) будет готовится 2 минуты только в пределах температуры в комнате -10...40 град цельсия. ИМХО

Вот это точно не задача ТЗ - привод надо выбрать на этапе проектирования. Можно включить требования о необходимости разработки мат. модели и к ее параметрам. Результаты использовать для облегчения выбора привода при проектировании. Привода разные характеристики имеют.
Для наладки существует документ - "Программа и методика испытаний".

Привод - это как пример? Я что имел ввиду - если мои понимания предназначения раздела верны, то при постановке задачи, параметры объекта определяется при описании объекта управления. Так, для примера высше (не знаю что меня на яишницу потянуло :-) ), температура в комнате определена от 20 до 30 град цельсия. В этих пределах система должна обеспечить нормальное приготовление яишницы. Но если в батареях зимой совсем не будет горячей воды, то в каких пределах температуры система справится со своей задачей.

[CHANt]

Я думаю, Вы этот ресурс видели (в т.ч. ТЗ с краткими примерами)
http://www.rugost.com/index.php?option= ... d=62#4_1_3


Вспомнилась древняя реклама Би Лайна:
Женщина: Колбаски свешайте.
Продавец: Скока?
Ж.: Ну, грамм двести-триста.
П.: Говорите точно, скоко вешать?
Ж.: Ну не знаю, сколько получится.
П.: Скока вешать в граммах?
Ж.: А к чему такая точность?
П.: Точность никогда не бывает лишней!