Что должен знать инженер-программист АСУТП

[Romcheg]

2san: :D Опишите Ваши требования к такой скаде, возможно вам смогут ее показать.
В качестве примера приведу свою разработку - у меня и архивы и журналы событий в скаде пишутся в СУБД MySQL. Однако при конфигурировании проекта разработчик нигде, вообще нигде не должен даже знать SQL-синтаксиса:
- таблицы для архивных параметров и журналов событий в СУБД система генерит сама по кнопочке в интерфейса, знай только тип данных таблицы выбирай
- указание системе что параметр надо архивировать или вести по нему журнал событий выполняется всего лишь указанием имени таблицы из списка (куда) и галочкой (что включен режим архивации)
- все выборки из архивов или журнала в математику выполняются штатными функциями скады, при этом разработчик получает уже готовые массивы параметров, ни строчки SQL-запросов ему писать не надо
- отображение журналов в табличном виде и отображение кривых на архивном тредне конфигурируется, снова ни строчки запросов на SQL не нужно
- более того - разработчик нигде даже свзяь с СУБД не конфигурирует: он только указывает в настройках IP-адрес где СУБД стоит, задает имя БД, с которой он будет работать и задает логин пароль доступа... все... Снова никаких заморочек по типу источников-ODBC...

:)

Если грамотно подходить к вопросам организации функционала системы, то большинство деталей его реализации остаются за кадром и не требуют пристального к себе внимания. Разработчику (конечному пользователю) остается только задача правильно задать конфигурацию механизма или функции, но никак не задача создать эту функцию с нуля самому.

Что касается списка - я уже привел этот список, как свое ИМХО, взяв за основу ваш и дополнив его некоторыми моментами.

[san]

2san: :D Опишите Ваши требования к такой скаде, возможно вам смогут ее показать.
В качестве примера приведу свою разработку - у меня и архивы и журналы событий в скаде пишутся в СУБД MySQL. Однако при конфигурировании проекта разработчик нигде, вообще нигде не должен даже знать SQL-синтаксиса:
- таблицы для архивных параметров и журналов событий в СУБД система генерит сама по кнопочке в интерфейса, знай только тип данных таблицы выбирай
- указание системе что параметр надо архивировать или вести по нему журнал событий выполняется всего лишь указанием имени таблицы из списка (куда) и галочкой (что включен режим архивации)
- все выборки из архивов или журнала в математику выполняются штатными функциями скады, при этом разработчик получает уже готовые массивы параметров, ни строчки SQL-запросов ему писать не надо
- отображение журналов в табличном виде и отображение кривых на архивном тредне конфигурируется, снова ни строчки запросов на SQL не нужно
- более того - разработчик нигде даже свзяь с СУБД не конфигурирует: он только указывает в настройках IP-адрес где СУБД стоит, задает имя БД, с которой он будет работать и задает логин пароль доступа... все... Снова никаких заморочек по типу источников-ODBC...

Это большинство SCADA умеет. А как у Вас организована выборка для отчетов? Ну скажем нужно сделать отчет о количестве переработаного за смену сырья, среднее, максимальное и минимальное значения параметров. Как это делается в Вашей разработке?
А не стояла ли у Вас задача получить данные с других источников БД, со своим форматом таблиц? Тут без SQL или какого-то программного интерфейса (всякие там ActiveX эллементов) во многих случаях никак. Хотя встечал случаи, где в SQL-драйвере для SCADA много чего можно сконфигурить, без написания строчки кода.
А требования к СКАДАм у меня много, в хороших СКДАх все в мелочах проявляется. Но иногда, сдается что эти мелочи вроде как можно было б и сделать.

[Romcheg]

С штатными отчетами у меня пока никак... Только прорабатываю решение, чтобы как раз увести разработчика из дебрей программирования, а дать ему именно визуальный редактор отчета с возможностью конфигурирования нужных запросов с их обработкой в разных режимах. В принципе почти все современные ReportBuilder'ы это как раз и делают - во многих из них знаний SQL не требуется, чтобы создать связку "Отчет по данным из СУБД".

Если вдаваться в конкретику по вашей задаче (количество чего-то за период времени с выделением: максимума, минимума и среднего) - то это легко решается штатным функционалом, опять таки без синтаксиса SQL. Результат выборки из СУБД - есть массив данных за определенный период времени, а уже обработку этого массива можно вести штатными средствами разработки алгоритмов, в моей системе понятие типа данных "динамический массив" - такое же обычное как и float и integer.

[san]

Возможно Ваша СКАДа, вернее ТМ с Вашими доработками станет бест оф зе бест.
Конкретно по моей задаче, вот что мне нужно:

1. собирать данные через ОРС с удаленных девайсов, надеюсь обходить ОРС не придеться
2. архивировать данные в БД, для последующего просмотра в трендах
3. если связь потеряна с девайсами, данные в них накапливаются, после наладки связи надо их оттуда вытащить и записать в БД вместо "никаких"
4. Доступ операторам предоставить через ВЕБ-интерфейс, с возможность просмотра с любой точки страны (это требование заказчика, не я так придумал)

Меня очень смущает пункт 3-й. Пункт 4-й доступен во многих СКАДА, но всюду есть свои ограничения. Ну и конечно цена вопроса важна. Так вот, Romcheg, как с этими пунктами обстоит дело в ТМ + Ваши дополнения? И сколько будут стоить Ваши дополнения?
Количество точек ввода/вывода - 1024. Количество одновременных клиентов - 2.

[Romcheg]

2san: Начнем с того, что моя скада - это не дополнение к ТМ, а совершенно самостоятельная скада, вообще не зависящая от ТМ, и не имеющая к нему отношений. То что она сделана похожей на ТМ еще не значит, что они одно целое, не путайте, пожалуйста. :D

Из перечисленных Вами задач, применительно к своей системе могу прокомментировать пункты так:
1) Данные собирать по ОРС моя скада уже умеет.
2) Архивация у меня в MySQL, архивный тренд имеется (правда пока только аналоговый, дискретные параметры только прописываю).
3) Как уже сказал: в моей скаде "динамический массив" - это штатный тип данных системы. На его основе можно делать локальные архивы в узлах (контроллеров или операторских станций) и можно их поднимать по сети с сохранением в общий архив.
4) Доступа через Вэб нет, еще не занимался таким функционалом. :( Временно его может конечно заменить рантайм для АРМов, ведь он все равно по TCP/IP может и через Интернет подключаться, но тогда на клиентские места надо будет заранее его переписать, что не есть красивое решение. Заказчик, я понимаю желает видеть именно в вэб-браузере.

Вообще - по 4-му пункту у меня пока только в планах на базе Сильверлайт сделать клиентов. Проект в моей скаде хранится полностью в формате XML, графический движок полностью на .Net технологии написан на С#, так что портировать это все добро в Silverlight под браузеры не составит особого труда. Зато будет шикарный бонус такого решения - интерфейсы операторов и в АРМах и в браузере будут один в один и по внешнему виду и по функционалу как в АРМах, потому как код практически без изменений должен перейти.

[san]

Тогда вот эту фразу я неправильно интерпритировал

Все бы хорошо, но в последнее время уже начали напрягать некоторые особенности системы, поэтому многие вещи пришлось делать самому в виде дополнений и "заплаток" к системе (по этому поводу даже сайт начал вести: http://www.tracemode6.ru). И вот, год назад, этих наработок накопилось уже столько, что я решил их собрать все вместе и просто сделать свой собственный ТМ6...

Вы свою систему в читсом виде уже кому-нить внедряли?

[Romcheg]

Нет, реальных внедрений еще нет, в мае один из заказчиков должен был уже выдать мне ТЗ на систему, которую он хочет видеть на моей скаде, потому как на ТМ6 он уже ничего вообще видеть не хочет. Однако все лето вот сижу и жду от него это ТЗ :) Сами понимаете, в срок что-либо делается очень редко... Вообще - по требованиям его проекта моя скада уже была готова под его задачи еще в мае.

А пока делаю свои текущие проекты в своей скаде для того, чтобы реально погонять ее и понять, что не так и чего не хватает. Поэтому сама система в процессе разработки. Весь этот месяц занимался разработкой и запуском сайта, форума и он-лайн справочной системы на базе движка Википедии. Параллельно со мной несколько пользователей ради интереса брали систему на "пощупать". Одним из результатов такого "щупания" стало то, что теперь у меня штатно поддерживается протокол ADS для работы с оборудованием от Beckhoff. Даже погоняли на реальных железках обмен. Включил ModBus RTU (до этого пока был только TCP/IP). Появился архивный тренд. Попутно сейчас закопался в дебри сетевого обмена между узлами проекта. В общем процесс идет... Там еще много чего предстоит сделать. :) Но как только дам доступ к интернет-ресурсу по системе, наверное уже больше народу будет с системой работать и принимать участие в ее развитии.