Технические средства для регистрации тревог

[Alex]

Уважаемые Коллеги,

есть задача разработать спецификации по оборудованию контрольного зала производства по подготовке и сжатию попутного газа. Я уже лет 5, как не занимался РСУ, в связи с этим такой вопрос:
Ранее стандартным средством регистрации тревог в системе был матричный принтер. Их можно найти и сейчас: Эпсон, Фуджитсу, Булл и т.п. их ещё производят - по крайней мере, я так думаю. Тем не менее, есть ли какие-либо альтернативные средства регистрации тревог, окромя, естественно, их записи в долговременную память АРМов РСУ? Может, за отчётный период появились новые, широко признанные средства регистрации?

Заранее благодарю за ответы.

Алексей Флилиппов
Т&Т Системы

[Elena Vnukova]

Диск 250М. например.

[Alex]

Елена Стефановна,

помнится, несколько лет назад американские авиаторы баловались, пролетая под опорами канатной дороги поблизости от итальянского курортного местечка Чермис, результат - перерубленный канат и два десятка погибших туристов. Первое, что сделали доблестные воины-интернационалисты после посадки - засветили плёнки установленных на борту телекамер. В результате их примерно наказали за несоблюдение процедур сдачи видеозаписей переводом на службу во Флориду.
А диск на 250М уронить можно. ;)
Тем не менее, спасибо за совет.

Алексей

[Jackson]

А диск на 250М уронить можно. ;)
Тем не менее, спасибо за совет.
Алексей

Потому и придуманы RAID-массивы и сервера. Ну а против лома нет приема.

[Alex]

Евгений,

могу ли я Ваш ответ интерпретировать в том смысле, что современная пракика ведения архивов тревог в нефтегазе позволяет предусматривать только электронное хранение данных, без обязательного проедоставления копий на бумажных (или иных неизменяемых) носителях? Всё упирается только в разграничение уровней доступа?

Алексей

[Jackson]

Алексей, я не работаю в нефтегазе, поэтому не могу ни подтвердить ни опровергнуть, что и где принято. Исходя из здравого смысла, при желании можно повредить абсолютно любой носитель информации: HDD, бумага, гравюра... :) Бумагу проще всего.
На одном (и единственном виденном мной) месторождении был принят электронный архив, запись в БД, на принтере операторы сами распечатывали выборки из БД событий за нужный им период, и это всех устраивало. Как это везде - не знаю. Знаю что на судах от бумаги отказываются из-за нецелесообразности - в случае (не дай RND) катастрофы бумага первой промокнет.

[Elena Vnukova]

А диск на 250М уронить можно.

То Alex: Меня терзает смутное сомненье, что мы о разных дисках говорим, ну да ладно...

[Alex]

Елена Стефановна,

это может быть... Я о нормальном жёстком диске или же о внешнем диске, но опять же магнитном форматируемом. А Вы о чём? Может, у Вас под рукой есть ссылочка?

Заранее благодарю!

Алексей

[Elena Vnukova]

Алексей, (пардон не знаю Вашего отчества)!
Я имела в виду регистратор Диск250М с бумажным носителем. В гуглях куча ссылок. Мы такую штуку использовали для регистрации температуры. Иформация хранится и в электронной БД и на бумажном носителе. Но чет мне уже кажется, что это не Ваш вариант.

А по отчеству это Вы зря, я еще маленькая. ;)

[Alex]

Елена,

Нашёл Ваши Диск250М. Хорошая штука, но в моём случае неприменима, по следующим причинам:
так как оператор обычно приравнивается к врагу народа, должно выпечатываться в точности то, что он видит на экране в качестве предупреждения, с отметкой времени. Желательно также выводить номер тревоги, соответствующий номеру в Инструкции Оператору - это чтоб он, бедолага, не мог заявить, что для него ситуация была нештатная и в документации не отражённая. Затем, архивировать надо также "События" - изменения уставок, alarm acknowledgement, переводы на ручное управление и обратно на автомат, регистрацию в системе пользователей и т.п. В виде графиков всю эту массу информации представлять неудобно, да и накладно.

Благодарю за помощь

Алексей

[Jackson]

А если такой вариант: как обычно складывать события в БД, настроить ее чтобы в строки вносились соответствующие поля (включая номера тревог, привязанные к номерам инструкции - это в текстах сообщений можно отразить при конфигурации) и всё. Журналы пишутся. И предписать скажем 1 раз за смену распечатывать список событий за смену (выборку задаст сам человек) из той же скады, пусть это делает либо тот же оператор либо кто угодно по своему желанию просто так и для отчетности. Почему нет? Думаю, любая СКАДА, нормально работющая с БД, даст такие возможности.

[Alex]

Евгений,

наверное, можно, как Вы описали. Дойдут руки до Клиента - обсудим. Пока что закладываю матричный принтер.
Спасибо за совет.

Алексей

[Jackson]

Дима, тогда просвети меня, какие принтеры у вас обычно для этого используют? Последовательные? Какие модели сейчас покупаемы?

[Alex]

Дима,

правильно излагаешь. Да ладно, мне пока что философию контроля писать - хочется, как лучше, а получится, как всегда - забью принтер в архитектуру, и все дела. Пусть Клиент комментирует. Я думал, что, может, какие-нибудь флэш-карты появились, блеснуть, так сказать, эрудицией (с вашей помощью) ;) . С поставщиком РСУ разговора серьёзного не получится - неизвестно, откуда пойдут поставки, так что лучше быть поконсервативней.

Спасибо за участие

Алексей

[Jackson]

Погодь, такие прентиры ведь не печатают построчно - они печатают постранично. А построчную печать (1 строка = 1 событие) на рулоне уже не используют?

[Alex]

Eugene,

dot matrix printers manufacturers:
http://www.fujitsu.com/emea/products/printers/
http://www.epson.ru/products/printers/dotmatrix.asp

Regards!

Alex

[Jackson]

Спасибо, буду знать что они еще реально покупаемы. :)

Я только хочу (для себя уже) выяснить, насколько широко сейчас применятся матричные рулонные принтеры для печати лога событий в реальном времени (пришло событие - мгновенно напечатана 1 строка). Или это полная экзотика в наш век электронного документооборота?

[Useful]

никогда бы не додумался для таких целей использовать матричный построчный принтер, повидимому я слишком молод ;)

-по мне так SCADA->БД->сдвоенный сервер (с ограниченным доступом) - выглядит надежнее принтера, да дороже, да сложнее, но, по-моему, куда эффективнее.

с уважением, Павел.

[zmeister]

у нас была похожая задача. любые изменения на комерческом узле учёта (алармы, переключения, старт, остановка и самое главное расход) сохранение в БД, а так же паралельно выводить на матричный принтер. со времинем заказчики начали бодаться по поводу большого расхода бумаги и вывод на пришлось отменить, кроме РАСХОДА. Т.к. после сохранения данных в БД, данные при комерции считаются "косвенными", а при прямом выводе на принтер, считаются "фискальными", т.е. "прямыми". так вот...