- Обязательно представиться на русском языке кириллицей (заполнить поле "Имя").
- Фиктивные имена мы не приветствуем. Ивановых и Пупкиных здесь уже достаточно.
- Не надо писать свой вопрос в первую попавшуюся тему - всегда лучше создать новую тему.
- За поиск, предложение и обсуждение пиратского ПО и средств взлома - бан без предупреждения. Непонятно? - Читать здесь.
- Рекламу и частные объявления "куплю/продам/есть халтура" мы не размещаем ни на каких условиях.
- Перед тем как что-то написать - читать здесь, а затем здесь и здесь.
- Не надо писать в ЛС администраторам свои технические вопросы. Администраторы форума отлично знают как работает форум, а не все-все контроллеры, о которых тут пишут.
Разработка концепции АСУ ТП
Модератор: Глоб.модераторы
-
- здесь недавно
- Сообщения: 44
- Зарегистрирован: 22 фев 2010, 19:25
- Имя: Черкасский Евгений Валерьевич
- Страна: Россия
- город/регион: Москва
Разработка концепции АСУ ТП
Доброго времени суток!
Поделитесь, пожалуйста, опытом оформления документации по данной стадии проектирования АСУ ТП. По ГОСТу 34.601 она предшествует стадии "Техническое задание". Я знаю, что в реальной жизни этот концептуальный этап часто опускается, вполне достаточно предоставить ТЭО и Техническое задание, но в моем случае идет речь об учебном дипломном проекте, где должны быть представлены так или иначе все стадии создания АСУ ТП.
Собственно вопросы:
1. Как обычно выбирают базовый вариант АСУ ТП для сравнения с предлагаемой?
2. Какие схемы, диаграммы принято показывать для того, чтобы более четко подчеркнуть преимущества предлагаемого перед базовым вариантом?
Очень нужны примеры именно из практического опыта, поскольку теоретически я представляю, что нужно оценить ресурсоемкость системы до и после внедрения АСУ ТП, оценить преимущества и недостатки каждого варианта, и затем из альтернатив выбрать лучшую.
Поделитесь, пожалуйста, опытом оформления документации по данной стадии проектирования АСУ ТП. По ГОСТу 34.601 она предшествует стадии "Техническое задание". Я знаю, что в реальной жизни этот концептуальный этап часто опускается, вполне достаточно предоставить ТЭО и Техническое задание, но в моем случае идет речь об учебном дипломном проекте, где должны быть представлены так или иначе все стадии создания АСУ ТП.
Собственно вопросы:
1. Как обычно выбирают базовый вариант АСУ ТП для сравнения с предлагаемой?
2. Какие схемы, диаграммы принято показывать для того, чтобы более четко подчеркнуть преимущества предлагаемого перед базовым вариантом?
Очень нужны примеры именно из практического опыта, поскольку теоретически я представляю, что нужно оценить ресурсоемкость системы до и после внедрения АСУ ТП, оценить преимущества и недостатки каждого варианта, и затем из альтернатив выбрать лучшую.
-
- администратор
- Сообщения: 18814
- Зарегистрирован: 17 июн 2008, 16:01
- Имя: Евгений свет Брониславович
- Страна: Россия
- город/регион: Санкт-Петербург
- Благодарил (а): 983 раза
- Поблагодарили: 1867 раз
Re: Разработка концепции АСУ ТП
А Вы не путаетесь в терминологии? Не занаучиваете?
Как правило, альтернативы и рассмотрение прочих вариантов и выбор лучшего - оформлять и куда-то представлять на практике не требуется. Нужно просто описать предлагаемое и объяснить как работает, и всё. Такие сравнения естественно проводятся, но обычно они не оформляются потому что никуда не представляются - за ненадобностью. Так что ГОСТы можете не копать на этот счёт.
В Дипломе я делал сравнение и оформлял его (только в Дипломе это и понадобилось). Берёте Ваш вариант, придумываете ещё один-два варианта, поочевиднее (не надо занаучивать - чтобы принципиальная разница была на ладони), обсчитываете по критериям:
Как правило, альтернативы и рассмотрение прочих вариантов и выбор лучшего - оформлять и куда-то представлять на практике не требуется. Нужно просто описать предлагаемое и объяснить как работает, и всё. Такие сравнения естественно проводятся, но обычно они не оформляются потому что никуда не представляются - за ненадобностью. Так что ГОСТы можете не копать на этот счёт.
В Дипломе я делал сравнение и оформлял его (только в Дипломе это и понадобилось). Берёте Ваш вариант, придумываете ещё один-два варианта, поочевиднее (не надо занаучивать - чтобы принципиальная разница была на ладони), обсчитываете по критериям:
- капиталловложения при строительстве (стоимость оборудования, и примерно прикиньте будут ли отличаться строительные работы по сложности, если не будут - на них забываем);
- эксплуатаионные расходы (сколько надо запчастей заменить или докупить за год эксплуатации);
- трудоёмкость разработки (сколько времени скольки инженеров на это уйдёт, в человекочасах)
- трудоёмкость монтажа и наладки (то же самое, например в варианте 1 надо 5 гаек закрутить, в варианте 2 ни одной);
- трудоёмкость эксплуатации (то же самое, из расчета на 1 год эксплуатации, сколько чего подтянуть, поднастроить, поверить за год).
- какова будет чистая прибыль и окупаемость установки в итоге (доход от эксплуатации минус затраты по перечисленным выше пунктам, и за какой срок внедрение Вашей системы во всех вариантах окупится)
По вопросам работы Форума можно обратиться по этим контактам.
-
- здесь недавно
- Сообщения: 44
- Зарегистрирован: 22 фев 2010, 19:25
- Имя: Черкасский Евгений Валерьевич
- Страна: Россия
- город/регион: Москва
Re: Разработка концепции АСУ ТП
Ну примерно то же самое предлагается сделать и в небезысвестном справочнике Федорова.
Все выгоды и оценки по экономической эффективности будут рассчитаны в организационно-экономической части на основе технорабочего проекта (когда будет известна уже точная структура КТС, программного комплекса, персонала).
Выходит, что с этой концепцией всё задом-наперёд: "Сам придумал-сам накопал кучу недостатков" в каком-то гипотетическом базовом варианте, которого отродясь в природе не было (объект новый).
Вопрос просто заключается, как графически представить свои изыскания: то ли через диаграммы UML (например, use case), что вот дескать, тут диспетчер сам снимал показания приборов и архивировал их в амбарную книгу, а тут сервер истории появился с БД и подсистемой ведения архивов и формирования отчетов, то ли через функциональную диаграмму IDEF0...
В том-то вся и проблема, что обычно это никто не делает на практике. Тем более у меня стоит задача проектирования только ПО верхнего уровня (SCADA-проект)... Может имеет смысл сравнить между собой какие-то СКАДЫ разных производителей - по критериям, которые приводятся в разных журналах по АСУ ТП
Все выгоды и оценки по экономической эффективности будут рассчитаны в организационно-экономической части на основе технорабочего проекта (когда будет известна уже точная структура КТС, программного комплекса, персонала).
Выходит, что с этой концепцией всё задом-наперёд: "Сам придумал-сам накопал кучу недостатков" в каком-то гипотетическом базовом варианте, которого отродясь в природе не было (объект новый).
Вопрос просто заключается, как графически представить свои изыскания: то ли через диаграммы UML (например, use case), что вот дескать, тут диспетчер сам снимал показания приборов и архивировал их в амбарную книгу, а тут сервер истории появился с БД и подсистемой ведения архивов и формирования отчетов, то ли через функциональную диаграмму IDEF0...
В том-то вся и проблема, что обычно это никто не делает на практике. Тем более у меня стоит задача проектирования только ПО верхнего уровня (SCADA-проект)... Может имеет смысл сравнить между собой какие-то СКАДЫ разных производителей - по критериям, которые приводятся в разных журналах по АСУ ТП
-
- администратор
- Сообщения: 18814
- Зарегистрирован: 17 июн 2008, 16:01
- Имя: Евгений свет Брониславович
- Страна: Россия
- город/регион: Санкт-Петербург
- Благодарил (а): 983 раза
- Поблагодарили: 1867 раз
Re: Разработка концепции АСУ ТП
Это нормально, потому что это Дипломный проект. Подразумевается что студент проработает два-три проекта, полностью их обсчитает, после чего выберет лучший и покажет недостатки других. Практически на это времени нехватает (все мы были студентами ), поэтому всё делается так как Вы описали. Если есть время на троекратную работу - вперёд и всё будет честно. В конце концов, необязательно находить худший вариант, можно ведь дать просто альтернативный, мол можно было и так и эдак.Evgeny писал(а):Выходит, что с этой концепцией всё задом-наперёд: "Сам придумал-сам накопал кучу недостатков" в каком-то гипотетическом базовом варианте, которого отродясь в природе не было (объект новый).
Делает-делает. Нормальный инженер умеет оценивать пути решения задач. Просто оформлять эти изыскания не требуется. Иногда просто в таблицу сводят затраты и в итоге видна разница. Плюс с опытом появляется много субъективных критериев, которые никакими цифрами не измеряются (например удобство оператора), и их включают в оценку тоже, но в уме или на словах, а не в цифрах.Evgeny писал(а):В том-то вся и проблема, что обычно это никто не делает на практике. Тем более у меня стоит задача проектирования только ПО верхнего уровня (SCADA-проект)... Может имеет смысл сравнить между собой какие-то СКАДЫ разных производителей - по критериям, которые приводятся в разных журналах по АСУ ТП
Просто взять две разные СКАДА - бессмысленно. Если у Вас 1500 точек в/в, и вы выбираете две скады, одна из которых максимум на 2000 точек а вторая на 20000 - ясен пень что обе они будут работать одинаково, но по второй затраты выше. Сама структура сравниваемых систем должна быть разной.
В моем дипломе было несколько проще, т.к. критерии были другие. Разработал автоматизированную электростанцию из трёх агрегатов. Экономически доказывал по двум критериям:
- выбор именно трёх агрегатов, сравнил с вариантом на два агрегата и на четыре - три агрегата получились оптимальны по размещению (4 уже не вписывались по месту и по объему ЗИП - были ограничения), кап.затраты естественно больше чем станция из 2 агрегатов, но зато эксплуатационные расходы получились чуть меньше, а суммарная надёжность станции из 3-х агрегатов выше чем из двух за счет резервирования.
- для автоматизации применил устройства "всё-в-одном", т.е. по одному контроллеру на каждый агрегат, и сравнил с вариантом использования набора однофункциональных простых устройств (комплект устройств на каждый агрегат). Получил что кап.затраты в случае с "всё-в-одном" чуть больше за счет необходимости программирования, зато массогабариты меньше, гибкость при модернизации намного выше (во втором варианте придется провода крутить, а тут софт в контроллере править), ЗИПа меньше. Надежность получилась одинаковой. Ремонтопригодность у "всё-в-одном" естественно хуже (программист на вахте не сидит), но на ура прошел критерий "в наш век передовых микропроцессорных технологий..." :)
Преподавателям ведь важно, не чтобы Вы наилучший вариант выбрали, а чтобы понимали разницу и умели её чётко сформулировать - именно от формулировок и понимания, а не от техники, чаще всего зависит судьба проектов.
В Вашем проекте тоже есть своя отраслевая специфика. Выделите важные критерии - они уж точно не будут цифрами выражаться - и сделайте анализ с их применением.
А дальше, я Вам советую нарисовать структурную схему Вашей системы и опубликовать её здесь. После праздников люди подтянутся и подкинут вариантов, как ещё иначе можно построить систему. Если Вы попросите конечно. :) Вот и будет что с чем сравнить.
По вопросам работы Форума можно обратиться по этим контактам.
-
- здесь недавно
- Сообщения: 44
- Зарегистрирован: 22 фев 2010, 19:25
- Имя: Черкасский Евгений Валерьевич
- Страна: Россия
- город/регион: Москва
Re: Разработка концепции АСУ ТП
Очень интересный, и самое главное, конкретный подход у Вас в проекте был
Просто мечтаю сделать подобное логичное обоснование.
На настоящий момент остановился на следующем:
-первый вариант - автономная АСУ ТП с локальной станцией оператора котельной (блочно-модульной - собственно мой объект автоматизации);
-второй вариант (который в общем-то требуется в ТЗ Заказчика) - АСУ ТП с удаленным диспетчированием.
Априори первый вариант проигрывает просто потому что не удовлетворяет всем требованиям Заказчика - а именно удаленному сбору сигналов и контролю работы агрегатов. Тем не менее похоже, что капитальные затраты на 1 консоль оператора будут ниже гораздо, чем на удаленные АРМы операторов+коммуникационное оборудование (с резервированием линий связи).
Остаётся найти способ "опустить" первый вариант по эксплуатационным затратам (по необходимости присутствия персонала в котельной или еще по чему), чтоб уж по стандартному критерию конкурентоспособности типа "цена/качество" мой дипломный вариант вышел окончательным победителем.
Просто мечтаю сделать подобное логичное обоснование.
На настоящий момент остановился на следующем:
-первый вариант - автономная АСУ ТП с локальной станцией оператора котельной (блочно-модульной - собственно мой объект автоматизации);
-второй вариант (который в общем-то требуется в ТЗ Заказчика) - АСУ ТП с удаленным диспетчированием.
Априори первый вариант проигрывает просто потому что не удовлетворяет всем требованиям Заказчика - а именно удаленному сбору сигналов и контролю работы агрегатов. Тем не менее похоже, что капитальные затраты на 1 консоль оператора будут ниже гораздо, чем на удаленные АРМы операторов+коммуникационное оборудование (с резервированием линий связи).
Остаётся найти способ "опустить" первый вариант по эксплуатационным затратам (по необходимости присутствия персонала в котельной или еще по чему), чтоб уж по стандартному критерию конкурентоспособности типа "цена/качество" мой дипломный вариант вышел окончательным победителем.
-
- администратор
- Сообщения: 18814
- Зарегистрирован: 17 июн 2008, 16:01
- Имя: Евгений свет Брониславович
- Страна: Россия
- город/регион: Санкт-Петербург
- Благодарил (а): 983 раза
- Поблагодарили: 1867 раз
Re: Разработка концепции АСУ ТП
О, а вот тут давайте поподробнее. Я сейчас малой энергетикой занимаюсь, в большой степени как раз модульными электростанциями (агрегаты в контейнерах), есть объекты с утилизацией тепла (генератор не только электричество, но и тепло отдаёт). Автоматизация, удалённый мониторинг. Близкие вещи.
Я Вам подкину ещё третий вариант: распределённая АСУ, когда автоматика каждого агрегата работает автономно, но будучи состыкованы вместе (по интерфейсу) агрегаты обеспечивают общий алгоритм управления, при этом программно и аппаратно друг от друга по прежнему независимо. То есть единой СЛТ нет. Не знаю как исключительно в котельных, а в микроэнергетике это нормальное решение, хотя появилось относительно недавно. Думаю что и в модульной теплоэнергетике это возможно. Далее, ставим локальный сервер сбора данных. Далее - одно-два локальных операторских АРМа плюс удалённый АРМ, который отличается от локального только линией связи. Функционал удалённых АРМов иногда уменьшен (по сравнению с локальными) в силу ограничения пропускной способности линии связи. Управление (посыл команд локальным АСУ агрегатов) - только с локальных АРМов. С удалённых АРМов - только мониторинг и сбор статистических данных для экономических отчетов. На практике же, часто ставят физически один ПК, который есть одновременно и сервер и операторский АРМ, а удалённый АРМ уже к нему стучится.
Вы не забывайте, что диспетчеризация - это не управление, это только мониторинг, сбор статистических данных, и - как максимум - простейшее логическое управление (посыл команд "включить/выключить", все технологические операции выполняются локально). Так что ваш второй вариант, который требует заказчик, легко укладывается в мой и в ваш первый кстати тоже.
И учтите, что первый вариант (и мой) неоспоримо выигрывает в надежности. Отвалилась линия связи - и объект без управления? Котлы повзрываются? Или вовремя не будет запущен резервный когда тепла не хватит = люди замерзнут? И всё это из-за одного порвавшегося провода.
Кроме того, резервирование линий связи (и связанные с этим расходы) тоже ещё надо обосновать. В моем варианте можно обойтись без резервирования, а стало быть и кап.затраты и эксплуатационные расходы на линию связи снижаются. Далее, признаем линию связи с удалённым АРМом неответственным звеном в управлении (в моем варианте) - ведь от того что удалённый АРМ отвалится управление объектом не прекратится, оператор на месте, да и автоматика на месте тоже работают как и раньше - следовательно ограничиваем объём данных, передаваемых на удаленный АРМ, таким образом снижаем требования к пропускной способности линии чем ещё снижаем её стоимость. И таким образом мой вариант может оказаться в выигрыше, а возможно и Ваш первый, и это при том что требование заказчика выполняется.
Так что не всё так однозначно. :)
И, если по большому счёту, то коль у Вас объект модульный, то и АСУ должна быть модульной и локальной для каждого модуля. Это моё личное мнение. Это вывод чистой практики и прогресса (появились способы строить такие системы). Это надёжность объекта в целом - чтобы сбой в одном контроллере отразился максимум на одном модуле, а весь остальной объект остался бы работоспособен включая механизм резервирования отказавшего модуля.
Я Вам подкину ещё третий вариант: распределённая АСУ, когда автоматика каждого агрегата работает автономно, но будучи состыкованы вместе (по интерфейсу) агрегаты обеспечивают общий алгоритм управления, при этом программно и аппаратно друг от друга по прежнему независимо. То есть единой СЛТ нет. Не знаю как исключительно в котельных, а в микроэнергетике это нормальное решение, хотя появилось относительно недавно. Думаю что и в модульной теплоэнергетике это возможно. Далее, ставим локальный сервер сбора данных. Далее - одно-два локальных операторских АРМа плюс удалённый АРМ, который отличается от локального только линией связи. Функционал удалённых АРМов иногда уменьшен (по сравнению с локальными) в силу ограничения пропускной способности линии связи. Управление (посыл команд локальным АСУ агрегатов) - только с локальных АРМов. С удалённых АРМов - только мониторинг и сбор статистических данных для экономических отчетов. На практике же, часто ставят физически один ПК, который есть одновременно и сервер и операторский АРМ, а удалённый АРМ уже к нему стучится.
Вы не забывайте, что диспетчеризация - это не управление, это только мониторинг, сбор статистических данных, и - как максимум - простейшее логическое управление (посыл команд "включить/выключить", все технологические операции выполняются локально). Так что ваш второй вариант, который требует заказчик, легко укладывается в мой и в ваш первый кстати тоже.
И учтите, что первый вариант (и мой) неоспоримо выигрывает в надежности. Отвалилась линия связи - и объект без управления? Котлы повзрываются? Или вовремя не будет запущен резервный когда тепла не хватит = люди замерзнут? И всё это из-за одного порвавшегося провода.
Кроме того, резервирование линий связи (и связанные с этим расходы) тоже ещё надо обосновать. В моем варианте можно обойтись без резервирования, а стало быть и кап.затраты и эксплуатационные расходы на линию связи снижаются. Далее, признаем линию связи с удалённым АРМом неответственным звеном в управлении (в моем варианте) - ведь от того что удалённый АРМ отвалится управление объектом не прекратится, оператор на месте, да и автоматика на месте тоже работают как и раньше - следовательно ограничиваем объём данных, передаваемых на удаленный АРМ, таким образом снижаем требования к пропускной способности линии чем ещё снижаем её стоимость. И таким образом мой вариант может оказаться в выигрыше, а возможно и Ваш первый, и это при том что требование заказчика выполняется.
Так что не всё так однозначно. :)
И, если по большому счёту, то коль у Вас объект модульный, то и АСУ должна быть модульной и локальной для каждого модуля. Это моё личное мнение. Это вывод чистой практики и прогресса (появились способы строить такие системы). Это надёжность объекта в целом - чтобы сбой в одном контроллере отразился максимум на одном модуле, а весь остальной объект остался бы работоспособен включая механизм резервирования отказавшего модуля.
По вопросам работы Форума можно обратиться по этим контактам.
-
- здесь недавно
- Сообщения: 44
- Зарегистрирован: 22 фев 2010, 19:25
- Имя: Черкасский Евгений Валерьевич
- Страна: Россия
- город/регион: Москва
Re: Разработка концепции АСУ ТП
На самом деле всё так и есть, как Вы описали: сами котлоагрегаты управляются своей локальной автоматикой. Т.е. есть общекотельный щит, координирующий работу обоих агрегатов и щиты автоматики каждого котлоагрегата в отдельности. Ни одна жизненно важная функция управления не доверена программе, крутящейся на удаленном сервере - только в локальных контроллерах.
Речь идет именно об удаленном диспетчировании, что включает в себя передачу аварийной сигнализации (алармов), значений контролируемых параметров, для которых назначены уставки (и которые может менять удаленно оператор), ну и некоторые функции телеуправления. В ТЗ еще по этому поводу красуется требование "работа котельной в автоматическом режиме без постоянного присутствия персонала с выводом сигнала о неисправности в диспетчерскую".
Когда я разговаривал непосредственно с изготовителями этих котельных (через которых собственно и получил ТЗ на верхний уровень), то по поводу локальных АРМов они сказали, что установка рабочих станций (ПК) в самом производственном помещении котельной вообще-то запрещена (сослались на правила безопасности, если честно, точню не помню какие именно). Хотя получается противоречие, потому что по ТЗ идет ссылка на популярный документ Транснефти РД 153-39.4-087-01 АВТОМАТИЗАЦИЯ И ТЕЛЕМЕХАНИЗАЦИЯ МАГИСТРАЛЬНЫХ НЕФТЕПРОВОДОВ. ОСНОВНЫЕ ПОЛОЖЕНИЯ (поскольку сама котельная предназначена для отопления месторождения), согласно которому нужны и локальные, и удаленные станции. Отсюда собственно и родилась идея о двух концепциях: локальной и распределенной.
А с какой стороны ставить сервер сбора сигналов (просто промышленный ПК без панели управления), если не предусмотрен (или как мне сказали не допустим) локальный АРМ, принципиального значения, наверное, не имеет (ну если только с точки зрения потери линии связи, которая в проекте резервируется по GSM-каналу).
Речь идет именно об удаленном диспетчировании, что включает в себя передачу аварийной сигнализации (алармов), значений контролируемых параметров, для которых назначены уставки (и которые может менять удаленно оператор), ну и некоторые функции телеуправления. В ТЗ еще по этому поводу красуется требование "работа котельной в автоматическом режиме без постоянного присутствия персонала с выводом сигнала о неисправности в диспетчерскую".
Когда я разговаривал непосредственно с изготовителями этих котельных (через которых собственно и получил ТЗ на верхний уровень), то по поводу локальных АРМов они сказали, что установка рабочих станций (ПК) в самом производственном помещении котельной вообще-то запрещена (сослались на правила безопасности, если честно, точню не помню какие именно). Хотя получается противоречие, потому что по ТЗ идет ссылка на популярный документ Транснефти РД 153-39.4-087-01 АВТОМАТИЗАЦИЯ И ТЕЛЕМЕХАНИЗАЦИЯ МАГИСТРАЛЬНЫХ НЕФТЕПРОВОДОВ. ОСНОВНЫЕ ПОЛОЖЕНИЯ (поскольку сама котельная предназначена для отопления месторождения), согласно которому нужны и локальные, и удаленные станции. Отсюда собственно и родилась идея о двух концепциях: локальной и распределенной.
А с какой стороны ставить сервер сбора сигналов (просто промышленный ПК без панели управления), если не предусмотрен (или как мне сказали не допустим) локальный АРМ, принципиального значения, наверное, не имеет (ну если только с точки зрения потери линии связи, которая в проекте резервируется по GSM-каналу).
-
- администратор
- Сообщения: 18814
- Зарегистрирован: 17 июн 2008, 16:01
- Имя: Евгений свет Брониславович
- Страна: Россия
- город/регион: Санкт-Петербург
- Благодарил (а): 983 раза
- Поблагодарили: 1867 раз
Re: Разработка концепции АСУ ТП
А... Теперь я Вас понял.
Вообще-то локальная операторская всё равно есть. Как же без неё? Где-то должно быть либо в здании помещение, либо - если это вообще в чистом поле - отдельный модуль где сидит оператор. Вот в нём бы и стоять серверу и всему оборудованию для связи с внешним миром.
Тогда можете прикинуть вариант установки выделенного сервера, для которого все равно что локальный АРМ что удалённый - разница будет только в линии связи. Только для удаленого АРМа другой клиентский функционал. Второй вариант - единый аппаратно комплекс, сервер и он же локальный АРМ (как мы часто и делаем), к которому подключаются удалённые АРМы.
Кстати, в качестве GSM-канала что применяете?
Вообще-то локальная операторская всё равно есть. Как же без неё? Где-то должно быть либо в здании помещение, либо - если это вообще в чистом поле - отдельный модуль где сидит оператор. Вот в нём бы и стоять серверу и всему оборудованию для связи с внешним миром.
Тогда можете прикинуть вариант установки выделенного сервера, для которого все равно что локальный АРМ что удалённый - разница будет только в линии связи. Только для удаленого АРМа другой клиентский функционал. Второй вариант - единый аппаратно комплекс, сервер и он же локальный АРМ (как мы часто и делаем), к которому подключаются удалённые АРМы.
Кстати, в качестве GSM-канала что применяете?
По вопросам работы Форума можно обратиться по этим контактам.
-
- здесь недавно
- Сообщения: 44
- Зарегистрирован: 22 фев 2010, 19:25
- Имя: Черкасский Евгений Валерьевич
- Страна: Россия
- город/регион: Москва
Re: Разработка концепции АСУ ТП
Есть, находится на соседней пром.площадке. Поэтому как бы всё равно получается удаленная, хоть и на небольшое расстояние. Ну а где-то ("в центре всея Сибир") находится уже центральная диспетчерская, про которую я ничего не знаю...Вообще-то локальная операторская всё равно есть. Как же без неё? Где-то должно быть либо в здании помещение, либо - если это вообще в чистом поле - отдельный модуль где сидит оператор. Вот в нём бы и стоять серверу и всему оборудованию для связи с внешним миром.
Вот я вроде бы окончательно убеждаюсь, что копать нужно в направлении поиска другого варианта архитектуры. Спасибо за совет!Тогда можете прикинуть вариант установки выделенного сервера, для которого все равно что локальный АРМ что удалённый - разница будет только в линии связи. Только для удаленого АРМа другой клиентский функционал. Второй вариант - единый аппаратно комплекс, сервер и он же локальный АРМ (как мы часто и делаем), к которому подключаются удалённые АРМы.
GSM/GPRS-канал построен на двух IP-шлюзах OnCell G3110 фирмы MOXA (аппаратная версия 2, к которой можно подцеплять не только удаленные RS-232, но и сегменты Ethernet). Хабы и другое коммуникационное оборудование (кроме VDSL-модемов) также используется этой фирмы. Выбор обусловлен соответствием опросному листу Заказчика и тем, что я хорошо знаком с этим оборудованием, тк работаю в их тех.поддержке :)Кстати, в качестве GSM-канала что применяете?
-
- почётный участник форума
- Сообщения: 3974
- Зарегистрирован: 20 янв 2010, 22:23
- Имя: Никита
- Страна: РФ
- город/регион: Мурманск
- Благодарил (а): 21 раз
- Поблагодарили: 230 раз
Re: Разработка концепции АСУ ТП
Внесу свои пять копеек в дискуссию. Что касается оформления - делал подобные вещи много раз, документ назывался обычно "технико-коммерческое предложение". Рассматривается два-пять варианта построения системы (зависит от того, что делаем, на крупных объектах частенько при автоматизации электроприводов рассматривался вариант модернизации главных цепей агрегатов, это уже не Ваша тематика). Приводятся структурные схемы по каждому варианту, причем часто не по ГОСТам а веселые картинки из Visio или Worda. Далее кратко на пару листов описание каждого варианта - что делаем, что получают, плюсы и минусы, можно прикидки по окупаемости. Далее таблицы ориентировочной стоимости по каждому этапу для каждого варианта (ПИР, оборудование, СМР, ПНР, опытная) и итоговая таблица - столько-то денег для каждого варианта.
В Вашем случае можно кроме структуры, немного поиграть с самой SCADA типа "дорогая система разработки-дешевые модули рантайма-неограниченная взможность расширения" и наоборот. Кстати, не забывате про перспективы расширения и модернизации)
Дадите данные по источникам тепла - можно будет говорить о структуре построения системы.
В Вашем случае можно кроме структуры, немного поиграть с самой SCADA типа "дорогая система разработки-дешевые модули рантайма-неограниченная взможность расширения" и наоборот. Кстати, не забывате про перспективы расширения и модернизации)
Дадите данные по источникам тепла - можно будет говорить о структуре построения системы.
Опыт - это когда на смену вопросам: "Что? Где? Когда? Как? Почему?" приходит единственный вопрос: "Нахрена? "
-
- здесь недавно
- Сообщения: 44
- Зарегистрирован: 22 фев 2010, 19:25
- Имя: Черкасский Евгений Валерьевич
- Страна: Россия
- город/регион: Москва
Re: Разработка концепции АСУ ТП
Ну я чтобы хотя бы иметь право ссылаться на какую-то нотацию делал структурную схему КТС в UML -как диаграмму развертывания (обычные прямоугольники, точнее параллелепипеды, только что называется всё это deployment diagram).Приводятся структурные схемы по каждому варианту, причем часто не по ГОСТам а веселые картинки из Visio или Worda.
Вот это самое тяжелое и тёмное место, потому что плюсы и минусы, конечно, увидеть можно, а вот откуда я, студент (хоть и работающий), могу сделать "прикидку" по стоимости внедрения и уж тем более оценить эксплуатационные расходы - это вопрос на засыпку. Предположим, я могу обсчитать затраты на закупку оборудования, но сказать, что потянет за собой эксплуатация того или иного варианта - это для меня пока тёмный лес.Далее кратко на пару листов описание каждого варианта - что делаем, что получают, плюсы и минусы, можно прикидки по окупаемости. Далее таблицы ориентировочной стоимости по каждому этапу для каждого варианта (ПИР, оборудование, СМР, ПНР, опытная) и итоговая таблица - столько-то денег для каждого варианта.
В структуру самой котельной я не лезу, это не моя епархия, поскольку железная часть проектируется людьми, которые в этом компетентны по уже отработанным многократно проектам (поставщики котельных РЭМЭКС). Моя задача заключается именно в проектировании коммуникации с верхним уровнем и собственно построением самой системы верхнего уровня, для которой и варьируется архитектура.Дадите данные по источникам тепла - можно будет говорить о структуре построения системы
-
- администратор
- Сообщения: 18814
- Зарегистрирован: 17 июн 2008, 16:01
- Имя: Евгений свет Брониславович
- Страна: Россия
- город/регион: Санкт-Петербург
- Благодарил (а): 983 раза
- Поблагодарили: 1867 раз
Re: Разработка концепции АСУ ТП
Понятно. А мы используем NetBitter. Кстати, вот Вам тогда наша идея построения сети и ВУ: Ставим NetBitter (в отличие от OnCell G3110 он имеет еще порты RS-485-ModBUS и выполняет роль промежуточного OPC). Все модули станции охвачены линией RS-485 ModBUS, один модуль - один адрес. Мастером является NetBitter. Дальше к Netbitter по Ethernet подключен сервер (он же локальный АРМ). Удалённый АРМ подключается к серверу также по Ethernet. Резервный канал связи - GSM напрямую с NetBitter, то есть резервный канал не зависит от сервера. Если вылетит ещё и сервер, то удалённый АРМ лишится статистических данных, которые лежат на сервере, но данные о текущей работе объекта будут по прежнему доступны. За счёт такой организации в каждом модуле не требуется установка контроллеров с поддержкой Ethernet, а ModBUS есть в любом контроллере, следовательно удешевляется нижний уровень. Но увеличивается время опроса модулей (хотя нашем случае это вовсе не критично).Evgeny писал(а):GSM/GPRS-канал построен на двух IP-шлюзах OnCell G3110 фирмы MOXA (аппаратная версия 2, к которой можно подцеплять не только удаленные RS-232, но и сегменты Ethernet). Хабы и другое коммуникационное оборудование (кроме VDSL-модемов) также используется этой фирмы. Выбор обусловлен соответствием опросному листу Заказчика и тем, что я хорошо знаком с этим оборудованием, тк работаю в их тех.поддержке :)Кстати, в качестве GSM-канала что применяете?
По вопросам работы Форума можно обратиться по этим контактам.
-
- почётный участник форума
- Сообщения: 3974
- Зарегистрирован: 20 янв 2010, 22:23
- Имя: Никита
- Страна: РФ
- город/регион: Мурманск
- Благодарил (а): 21 раз
- Поблагодарили: 230 раз
Re: Разработка концепции АСУ ТП
Ну каждый "делает" как захочет - для профессуры может оно и правильно, для представителей заказчика, которые выделяют деньги я вообще делал подобие рекламного проспекта со структурой и фотографиями предлагаемого оборудования, весь вопрос - кто это будет читать и насколько оно ему понятно, а в случае реального проекта я бы употребил слово "привлекательно".Ну я чтобы хотя бы иметь право ссылаться на какую-то нотацию делал структурную схему КТС в UML -как диаграмму развертывания (обычные прямоугольники, точнее параллелепипеды, только что называется всё это deployment diagram).
Затраты на проект, оборудование, монтаж и ПНР можно прикинуть по Госстроевским ценникам. Кстати, в мою бытность студентом нам о их существовании даже не упоминали, а, как потом выяснилось, очень зря. Эксплуатационные расходы самой SCADA-системы - это ЗИП, аренда каналов связи, затраты на содержание обслуживающего инженера, расходы на его поездки по объектам - тут и вылезет связь со структурой - что дешевле - выезжать на объект или искать в тайге обрыв линии.Вот это самое тяжелое и тёмное место, потому что плюсы и минусы, конечно, увидеть можно, а вот откуда я, студент (хоть и работающий), могу сделать "прикидку" по стоимости внедрения и уж тем более оценить эксплуатационные расходы - это вопрос на засыпку. Предположим, я могу обсчитать затраты на закупку оборудования, но сказать, что потянет за собой эксплуатация того или иного варианта - это для меня пока тёмный лес.
Вообще, речь идет о том, чтобы разными способами достичь одного и того же результата, поэтому предлагаю ограничиться капзатратами на ввод разных вариантов системы в эксплуатацию. Превратив же их в амортизацию - можем считать эксплуатационные, это как больше нравится, суть одна - свести все в таблицу с затратами и ей ограничиться, не зная тепломеханики выгоды от АСУ Вы не посчитаете, а от диспетчеризации в чистом виде - тем более.
Опыт - это когда на смену вопросам: "Что? Где? Когда? Как? Почему?" приходит единственный вопрос: "Нахрена? "
-
- почётный участник форума
- Сообщения: 3974
- Зарегистрирован: 20 янв 2010, 22:23
- Имя: Никита
- Страна: РФ
- город/регион: Мурманск
- Благодарил (а): 21 раз
- Поблагодарили: 230 раз
Re: Разработка концепции АСУ ТП
Речь и идет о концепции, при этом о концепции оторванной от жизни скады для дипломного проекта. Рассматривать существующие на рынке SCADA-системы и делать их оценку? Немного неверный подход, как мне кажется. В конце концов выяснится что лучше всего панель оператора без всякой связи с внешним миром. Никто ж не задается вопросами стыковки с оборудованием, увязки с другими системами и пр. Вообще по соотношению цена-качество лучше всего халявное пиво, но речь не об этом. Задача сама по себе поставлена некорректно, не зная ничего о АСУТП разработать, точнее сделать вид что разработана, концепцию веселых картинок. А так как подобная задача по определению имеет множество решений - вот и приходится просто красиво лить воду, причем каждый по своему.
Опыт - это когда на смену вопросам: "Что? Где? Когда? Как? Почему?" приходит единственный вопрос: "Нахрена? "
-
- почётный участник форума
- Сообщения: 3974
- Зарегистрирован: 20 янв 2010, 22:23
- Имя: Никита
- Страна: РФ
- город/регион: Мурманск
- Благодарил (а): 21 раз
- Поблагодарили: 230 раз
Re: Разработка концепции АСУ ТП
Думаю грустнее если первое. Вряд-ли человек по собственной инициативе будет писать такие вещи просто так... А вот если больше писать не о чем и нужна просто макулатура для диплома - тогда действительно грустно. А задание преподавателя скорей всего звучало как создание АСУТП, только сил у дипломника на полноценную систему не хватит, вот и размазывают реальный объем по ГОСТу чтоб солидно было.
Опыт - это когда на смену вопросам: "Что? Где? Когда? Как? Почему?" приходит единственный вопрос: "Нахрена? "
-
- здесь недавно
- Сообщения: 44
- Зарегистрирован: 22 фев 2010, 19:25
- Имя: Черкасский Евгений Валерьевич
- Страна: Россия
- город/регион: Москва
Re: Разработка концепции АСУ ТП
Доброго времени суток и спасибо всем отозвавшимся за внимание к моему вопросу и дискуссии :-)
"В споре рождается истина". Вот и у нас в разговоре с преподом по тому, что я сделал во многом благодаря идеям genelectric , родилось какое-то ясное представление о том, как будет выглядеть концепция в моём случае. На данный день в моей работе сравниваются между собой варианты, имеющие абсолютно равные права на жизнь: с локальной и удаленной диспетчеризацией. Уверенность в правильности такого подхода подкрепила статья на сайте Московского Завода Тепловой Автоматики (статья). Я сделал прикидочную оценку по капитальным затратам. Препод в свою очередь выдал "обнаученную" (специально для профессорско-преподавательской аудитории) методику комплексного сравнения SCADA-систем: что-то типа матрицы, в итоге расчета получаются относительные оценки каждой системы, учитывающие как экономические, так и технические группы факторов (после защиты диплома обязательно поделюсь ею). :) Вдруг кому-то еще понадобится в академических целях... Что поделать, если так уж у нас повелось сравнивать между собой SCADA-системы, пусть даже в основном и в чисто рекламных целях.
"В споре рождается истина". Вот и у нас в разговоре с преподом по тому, что я сделал во многом благодаря идеям genelectric , родилось какое-то ясное представление о том, как будет выглядеть концепция в моём случае. На данный день в моей работе сравниваются между собой варианты, имеющие абсолютно равные права на жизнь: с локальной и удаленной диспетчеризацией. Уверенность в правильности такого подхода подкрепила статья на сайте Московского Завода Тепловой Автоматики (статья). Я сделал прикидочную оценку по капитальным затратам. Препод в свою очередь выдал "обнаученную" (специально для профессорско-преподавательской аудитории) методику комплексного сравнения SCADA-систем: что-то типа матрицы, в итоге расчета получаются относительные оценки каждой системы, учитывающие как экономические, так и технические группы факторов (после защиты диплома обязательно поделюсь ею). :) Вдруг кому-то еще понадобится в академических целях... Что поделать, если так уж у нас повелось сравнивать между собой SCADA-системы, пусть даже в основном и в чисто рекламных целях.
Дмитрий Милосердов писал(а):Хм..интересно - это собственные инициативы или задание преподавателя? Если последнее- то весьма грустно...
К слову о дипломе: ТЗ для него взято из реальной жизни, ничего не высосано из пальца (во-первых, Бауманка бы такого не потерпела, во-вторых, я сам мечтал делать диплом по конкретному ТЗ на АСУ ТП, а не автоматизации "вообще"). Проект привязан к реальному объекту, хотя в настоящее время работа приостановлена, т.к. Заказчик пока не профинансировал следующий этап. Поэтому речь о том, станет ли мой проект макулаторой или нет, вести рано - да и кстати я ведь и не просил беспокоиться за это, уважаемые форумчане и коллеги . Так что нечего грустить - выше нос!Никита писал(а):Думаю грустнее если первое.
Да, там действительно прописано именно это. И мне вот наоборот очень приятно. Ниеншанц-Автоматика - стабильная и солидная фирма со своими плюсами и минусами (для меня лично на данный момент больше плюсов). И пусть она и не является системным интегратором и поставщиком решений "под ключ", тем не менее действует далеко не только по принципу "купи-продай". Только я, предвидя возможное развитие дискуссии по этой теме, очень прошу - не надо фанатизма. У всех свои причины для симпатий и антипатий.Дмитрий Милосердов писал(а):Только вот в профиле Ниеншанц прописано. А вот это действительно грустна
Последний раз редактировалось Evgeny 07 мар 2010, 22:31, всего редактировалось 1 раз.
-
- почётный участник форума
- Сообщения: 3974
- Зарегистрирован: 20 янв 2010, 22:23
- Имя: Никита
- Страна: РФ
- город/регион: Мурманск
- Благодарил (а): 21 раз
- Поблагодарили: 230 раз
Re: Разработка концепции АСУ ТП
Дело-то не в макулатуре, дело в том что получим в результате. Evgeny, прошу прощения, но мы ударились в обсуждение качества работы ВУЗов по подготовке специалистов, рассматривая дипломников(и Вас в том числе) как продукцию. Ниеншанц тут вообще ни при чем, речь о том, что студент с опытом, пусть и в продажах, вместо нормальной работы по автоматизации занимается написанием реферата по SCADA-системам, практически не имея представления об объекте. Лично для меня, как работодателя, программист, умеющий лишь нарисовать мнемосхемы, особой ценности не представляет, главное в управлении -алгоритмы, а визуализация - дело десятое.К слову о дипломе: ТЗ для него взято из реальной жизни, ничего не высосано из пальца (во-первых, Бауманка бы такого не потерпела, во-вторых, я сам мечтал делать диплом по конкретному ТЗ на АСУ ТП, а не автоматизации "вообще"). Проект привязан к реальному объекту, хотя в настоящее время работа приостановлена, т.к. Заказчик пока не профинансировал следующий этап. Поэтому речь о том, станет ли мой проект мукулаторой или нет, вести рано - да и кстати я ведь и не просил беспокоиться за это, уважаемые форумчане и коллеги . Так что нечего грустить - выше нос!
Автоматика, оторванная от технологии, сама по себе не имеет смысла, а в Вашем случае от нее еще оторвано поле и ПЛК, тем самым задача превращена в чисто теоретическую. А стране нужны созидатели)
Это так, мысли вслух с высоты. С другой стороны как вспомню какую ... сами писали в дипломных работах - так за десять лет ничего не изменилось.
Так что дерзайте, будут вопросы - пишите, а если есть желание в дальнейшем что-то делать а не продавать незнамо что - надо просто интересоваться тем что делаешь.
Опыт - это когда на смену вопросам: "Что? Где? Когда? Как? Почему?" приходит единственный вопрос: "Нахрена? "
-
- здесь недавно
- Сообщения: 44
- Зарегистрирован: 22 фев 2010, 19:25
- Имя: Черкасский Евгений Валерьевич
- Страна: Россия
- город/регион: Москва
Re: Разработка концепции АСУ ТП
Во-первых, я работаю в отделе технической поддержки и не имею никакого отношения к продажам, разве что после подбора оборудования направляю заявку манагерам. Во-вторых, всё-таки за годы пребывания в университете у нас было несколько курсов, посвященных именно АСУ ТП, хоть может быть и не в том объеме, в каком хотелось бы. Но во всяком случае я слышал такую фразу, что "настоящего инженера растят около 10 лет" - это без учёта лет, проведенных в стенах ВУЗа... Так что буду расти благодаря работе, взаимодействию с Заказчиками ну и подобным форумам :) Ну а насчет того, что получится в результате диплома - хорошо, если это будет хотя бы какой-то навык, обобщение изученных ГОСТов, курсов, и т.п. - по-моему этого было бы вполне достаточно.Никита писал(а):Дело-то не в макулатуре, дело в том что получим в результате. Evgeny, прошу прощения, но мы ударились в обсуждение качества работы ВУЗов по подготовке специалистов, рассматривая дипломников(и Вас в том числе) как продукцию. Ниеншанц тут вообще ни при чем, речь о том, что студент с опытом, пусть и в продажах, вместо нормальной работы по автоматизации занимается написанием реферата по SCADA-системам, практически не имея представления об объекте. Лично для меня, как работодателя, программист, умеющий лишь нарисовать мнемосхемы, особой ценности не представляет, главное в управлении -алгоритмы, а визуализация - дело десятое.
-
- освоился
- Сообщения: 247
- Зарегистрирован: 05 мар 2010, 15:01
- Имя: Тихомиров Владимир Владимирович
- Страна: Россия
- город/регион: Кириши Ленинградской
- Поблагодарили: 1 раз
Re: Разработка концепции АСУ ТП
Как раз сейчас у мены дипломник (выпуск в июне). Тему ему дал абсолютно реальную и имеющую перспективы развития. "Оптимизация структуры диспетчерского контроля и управления цеха". Поставил ему компьютер с полным программным пакетом системы, с инженерными программами. На компе реальный пользовательский интерфейс и база данных цеха. Поставил стенд (он у меня давно собран, отрабатываю на нём реальные проблемы), с резервированным контроллером и модулями ввода/вывода аналоговыми и дискретными. То есть реальная живая схема. Рядом инженерная станция, постоянно в системе (точнее на ней 3 виртуальных машины и 3 отдельные системы).Никита писал(а):
Дело-то не в макулатуре, дело в том что получим в результате.
Далее - основные понятия и определения, классификация - книги, госты, СНиПы.
- структура цеха (технология и задачи) - технологические схемы и инструкции технологического персонала.
- постановка задачи (автоматизация процесса и цеха, в целом. Оптимизация структуры КПТС) - Исходное предложение по автоматизации, технические задания, пояснительные записки проектов.
- структура АСУ цеха на КПТС TOSDIC - Тошибовские мануалы и предложенные структуры. Реально созданная многоуровневая схема, с коммуникаторами и виланами.
- собственно оптимизация (права доступа, интерфейс, изменение интерфейса под структуру, структуризация баз данных)
Здесь уже работа с реальной базой. Инжиниринг контроллера, инжиниринг операторского интерфейса, графический редактор. В дипломе реальные скрины интерфейса, редакторов, программ - в сравнении.
- и последняя тема (основного раздела) построение системы с учётом перспективного плана автоматизации. Есть общая концепция завода, есть общий план, есть ограничения на любой КПТС.
Такой подход. Реальная тема, на реальном предприятии, с возможностью работы с реальными системами. Результат есть.
Раздел БЖД и экологии пусть пишет сам, хоть я и проверю.
-
- почётный участник форума
- Сообщения: 3974
- Зарегистрирован: 20 янв 2010, 22:23
- Имя: Никита
- Страна: РФ
- город/регион: Мурманск
- Благодарил (а): 21 раз
- Поблагодарили: 230 раз
Re: Разработка концепции АСУ ТП
Радует. Но выпускников много, один погоды не сделает. Да и наверняка его к себе заберете после выпуска?Такой подход. Реальная тема, на реальном предприятии, с возможностью работы с реальными системами. Результат есть.
Тема может быть и реальной, профессура часто оторвана от жизни и тратит время свое и студентов на разбавление диплома водой. Их тоже можно понять, у них свои задачи и свои требования, спущенные сверху и зачастую не самые умные. Вообще многое зависит от руководителя. Вспоминается история как ко мне, когда я только второй год работал на инженерной должности, прислали моего же бывшего преподавателя набираться опыта, и ее глаза когда она в первый раз увидела насколько производственная автоматика отличается от академических дисциплин и учебных стендов.
Книг в институтах много, только вот большинство студентов уже и не подозревают о существовании библиотек, тут был случай когда в параллельных ветках человек искал ответы на вопросы билетов. а ГОСТы - тоже вешь неоднозначная, их мало знать, их надо уметь применять. Вообще нам например ни разу не упоминали о том, что автоматизация имеет некоторое отношение к строительству, о том что кроме ГОСТов есть еще СНиПы и ВСН - тоже.
Реальная база - тут ситуация еще хуже, всем летом хочется в отпуск а не на практику, в результате есть дипломированные инженеры по автоматизации, которых только жизнь научила с какой стороны браться за паяльник. Реальные примеры - люди для диплома паяют схемы на операционниках по картинкам в учебниках, а когда начинают выяснять почему не работает, оказывается- а в книжках-то цепи питания операционников не нарисованы. Это уже не говоря о том, что сами операционники устарели лет ..дцать тому как..
Разделы БЖД, экологии и экономики обычно в пылу борьбы упускают вообще, а тоже очень зря, экспертиза-то требует:)
Так что образование пока от жизни оторвано, база теоретическая (академическая) у выпускников вроде есть, а вот применять ее умеют далеко не все. А прикладным знаниям приходится учиться по ходу.
Опыт - это когда на смену вопросам: "Что? Где? Когда? Как? Почему?" приходит единственный вопрос: "Нахрена? "
-
- освоился
- Сообщения: 247
- Зарегистрирован: 05 мар 2010, 15:01
- Имя: Тихомиров Владимир Владимирович
- Страна: Россия
- город/регион: Кириши Ленинградской
- Поблагодарили: 1 раз
Re: Разработка концепции АСУ ТП
Не так однозначно.Дмитрий Милосердов писал(а):Владимир, вопрос не в тему- а у вас в Киришах только диспетчеризация реализована или другой функционал уже создали? ( если мне память не изменяет- у вас зачатки MES на базе PI были?). Если есть реализация- то каких функций? (по терминам ИСА S-95 лучше, чтобы не путаться).
Во первых у нас 2 отдела (общее только сети) АСУП и АСУТП.
У АСУПа все офисные компы, в единой общезаводской сети. Управленческую часть я не знаю.
Есть там и отдельная система учёта и отчетности по пром цехам. Проект фирма "Наука" с их программным пакетом. Там собирается вся товарная информация и наработка оборудования. Я, для этого, в "своей" системе организую счётчики и программы НКО.
В этой же системе есть отдельные подсистемы учёта оборудования (программные АРМы), лично я пишу туда все обслуживания, перемещение ЗИП, записываю (по номерам до элемента) вновь поступающее оборудование, все текущие ремонты, необходимые заявки. Это программный пакет СПИК СЗМА.
В эту же структуру (через своё оборудование и ком сервера) заведена система вибромониторинга всего завода. Система фирмы АЛТ.
Руководство (и КИПовцы) имеют на своих компах полную (в реальном времени) картинку (реальные видеокадры) подконтрольных объектов. Этим занимается наш сектор IT. У них огромная сеть COM серверов с единым SQL сервером, аппаратными фаерволами. Информация вытаскивается из технологической сети, пакуется и передаётся интачем в обще заводскую сеть, а там уже кому что нужно. В "моей" системе, для связи с интачем стоит программа OPC.DA.
Более конкретно по MES:
- контроль состояния и распределения ресурсов - уже написал
- оперативное распределение - как сказал, у руководства есть реальная картинка, в реальном времени. У операторов и диспетчеров есть информация (на видеокадрах) своя и по смежникам.
- диспетчеризация - диспетчерские АРМы находятся непосредственно в системе (в управляющей сети). Видят все видеокадры системы, только им закрыто управление оборудованием.
- контроль за документами - в общей системе завода общий документооборот, с различными правами доступа, вплоть до электронных подписей. (один из примеров - выше, то, что от СПИК СЗМА и система товарного учёта "Науки")
- сбор и хранение данных. У меня, в каждой системе (их пока 3), по 10-20 операторских станций (объекты разбросаны на площади 25км.кв) и по 20-30 контроллеров. Естественно стоят выделенные сервера. Кроме того есть сервер SQL (о котором уже писал), там вообще собирается инфа по всему заводу (технологическая инфа). Что на серверах АСУП, сказать не могу.
- управление персоналом и качеством - это к АСУПу
- управление, история, анализ - на разных уровнях своё.
Есть ещё момент применения моделей. На отдельных установках внедрены адаптирующие программные модели. То есть технологическая система самообучается и адаптируется. (что то типа "терминатора")
В общем все компы и контроллеры на заводе связаны физической верёвочкой, а дальше программные и аппаратные защиты. Общая заводская сеть построена на виланах, а это жёсткая маршрутизация.
-
- освоился
- Сообщения: 247
- Зарегистрирован: 05 мар 2010, 15:01
- Имя: Тихомиров Владимир Владимирович
- Страна: Россия
- город/регион: Кириши Ленинградской
- Поблагодарили: 1 раз
Re: Разработка концепции АСУ ТП
Увы и ах. Книг много, но толку мало.Никита писал(а): Книг в институтах много, только вот большинство студентов уже и не подозревают о существовании библиотек,
Пытались меня привлечь учить студентов (филиал института) по теме АСУ, в этом полугодии (с намёком, что соглашусь и в будущем). 8 часов в неделю, по вечерам, по 200р. за час. Честно говоря оно мне нафиг (за такие деньги) было не нужно, но уж очень просили, к тому же через наш отдел подготовки кадров. Сначала согласился (предварительное согласие) потом посмотрел программу и отказался. У них предмет АСУ с точки зрения технологии (там технологов учат). По моей работе ни чего нет.
К чему это, а к тому, что поискал в инете литературу. Ни одного хорошего нового учебника. Всё 80-90х годов. Сейчас техника принципиально другая.
Ещё момент - через чур большие объёмы информации. У меня мануалов (на TOSDIC) более 10000 страниц, на английском (переведено с японского). Постоянно идут изменения, доработки, особенно по программным пакетам. Если ещё учесть мануалы (опять же на английском) на внешнее оборудование - вообще!!!
Нет сейчас универсальных профи. Настоящие профи только в своей теме.
Последний раз редактировалось T_Vlad 11 мар 2010, 13:33, всего редактировалось 1 раз.
-
- почётный участник форума
- Сообщения: 3974
- Зарегистрирован: 20 янв 2010, 22:23
- Имя: Никита
- Страна: РФ
- город/регион: Мурманск
- Благодарил (а): 21 раз
- Поблагодарили: 230 раз
Re: Разработка концепции АСУ ТП
Это как раз не проблема, это естественно. Много лет занимаясь темой становишься в ней профи.Нет сейчас универсальных профи. Настоящие профи только в своей теме.
Проблема в том, что очень большой разрыв между академическими знаниями и способностью самостоятельно работать. Уже после первого сданного объекта и освоенной техники остальное идет намного легче, техники-то хоть и множество на рынке, но она вся похожа. Есть у каждой своя специфика и подводные камни, но молодой специалист часто не может работать вообще ни с чем.
Главная беда - не умеют пользоваться знаниями, даже если они есть. Больше половины из тех, с кем беседовал, не могут, зная напор и расход, прикинуть мощность насоса, хотя эта задача из школьного курса физики для, по-моему, восьмого класса. Про то, чтобы взглянув на объект составить хотя бы представление о передаточной, я вообще молчу.
А техника - дело десятое, толковый инженер со временем с любой разберется.
Опыт - это когда на смену вопросам: "Что? Где? Когда? Как? Почему?" приходит единственный вопрос: "Нахрена? "
-
- освоился
- Сообщения: 247
- Зарегистрирован: 05 мар 2010, 15:01
- Имя: Тихомиров Владимир Владимирович
- Страна: Россия
- город/регион: Кириши Ленинградской
- Поблагодарили: 1 раз
Re: Разработка концепции АСУ ТП
Во первых знаний нет, даже базовых. У меня за год проходит парочка производственной практики и парочка преддипломников. Инженеры электроники не знают, что такое диод и транзистор. Это как? Откуда??? ГУАП и Техноложка.Никита писал(а): Главная беда - не умеют пользоваться знаниями, даже если они есть.
Во вторых их не учат главному (да ни чему не учат) - учиться. Институт должен научить учиться. Мне на всю жизнь вдолблено - "Инженер должен уметь пользоваться технической документацией". Нет необходимости держать в голове всё неюбходимую информацию (да и не реально это) нужно знать, в какой книге, на какой странице то, что тебе нужно ну и ессно понимать, что там написано.
-
- почётный участник форума
- Сообщения: 3974
- Зарегистрирован: 20 янв 2010, 22:23
- Имя: Никита
- Страна: РФ
- город/регион: Мурманск
- Благодарил (а): 21 раз
- Поблагодарили: 230 раз
Re: Разработка концепции АСУ ТП
Я не зря взял пример с насосами, эти знания есть - те с кем общался еще сдавали вступительный по физике, а не ЕГЭ. И раз сдали - значит есть. Можно не помнить формулы, для этого есть справочники, но то что такие законы в физике есть - знают точно.Во первых знаний нет, даже базовых.
Другой вопрос - преподаватели - объясняя на лекции какую-то формулу хороший лектор всегда найдет жизненный и понятный пример и приведет еще три-четыре подобных. А плохой - заставит выучить наизусть.
Те,кто не отличает диод от транзистора - это рас...и, которым плевать на все чему учат, просто нет интереса, нужен только диплом. Ну они до меня просто не доходили.
Мой преподаватель по сопромату (науке самой по себе гнусной) по этому поводу говорил так - "хороший инженер - это не тот кто много знает, а тот кто за двадцать минут найдет необходимую информацию". При этом разрешал при сдаче пользоваться всем, но задачки подкидывал такие что действительно приходилось разбираться сначала с самой конструкцией, зато потом после ее раскладки на элементы, все в пару эпюр и десяток формул решалось на раз.Мне на всю жизнь вдолблено - "Инженер должен уметь пользоваться технической документацией"
А насчет техники - не так давно общался с зам. зав. выпустившей меня кафедры, в т.ч. и на предмет "чему людей учите?" Очень неприятно был удивлен - за последние восемь лет в плане оборудования ничего не изменилось. Пожаловался на то что ГОД лежит подаренный спонсорами S7-200 и никто до сих пор не может разобраться как им пользоваться. При том что уж по сименсу-то русскоязычной документации прорва, даже книги есть. Даже желания помочь не возникло.
Людей не то что не учат учиться, даже просто думать - и то не умеют.
Опыт - это когда на смену вопросам: "Что? Где? Когда? Как? Почему?" приходит единственный вопрос: "Нахрена? "