OberonCore
https://forum.oberoncore.ru/

ОИК "Восход"
https://forum.oberoncore.ru/viewtopic.php?f=5&t=5677
Страница 1 из 10

Автор:  prospero78 [ Пятница, 22 Апрель, 2016 19:39 ]
Заголовок сообщения:  ОИК "Восход"

Активно пилю свою программулину, пока рабочее название ОИК "Восход".
Это очень громкое название, на самом деле пока речь идёт только о дорасчёте к существующему серверу.
На прицеле держу то, что бы его (действующий сервер) заместить вообще. Для этого кроме самого дорасчёта, нужно реализовать по крайней мере три протокола:
1. Modbus over TCP/IP (на python уже реализовывал частично, но в достаточном объёме)
2. IEK 870-5-104 (на python частично реализовывал уже, сбоил при поддержании сессии((впрочем, понял в чём была ошибка)), также неправильно представлял младшие разряды чисел с плавающей запятой; я проклял python за невозможность НИКАКИМ способом прочитать байты вещественного числа в памяти)
3. IEK 870-5-103 (тут ничего не делал и не знаю, что внутри ((но догадываюсь))).
4. Что-нибудь ещё поверх RS-232/485 (типа RTU Modbus но если это только кому-то, мне самому пока не надо).
Ретроспективная база данных нужна, но вообще тут не вижу никаких проблем. Есть SQLite, есть и возможность свой велосипед изобрести, но это надо хорошо посмотреть и далеко.

Но всё это пока была присказка, рассказываю сказку.
На существующем сервере телемеханики есть точка телеизмерения, в которую записывается какое-то число. В самой конфигурации сервера можно пометить что это такое и его размерность. Но это просто некий текст, ни к чему не обязывающий. И в какой-то момент у меня наступило озарение: в строке "Выражение" можно подставить ссылки на любые телеизмерения, можно с ними что-либо сделать и присвоить нужной ячейке. В какой-то момент сообразил, что в ячейку, где лежат амперы от фазы "А" можно положить сумму киловольтов фазы "Б" и мегаватт фазы "С".
И ЭТО В СЕРТИФИЦИРОВАННОЙ ПРОГРАММЕ!!!!
Вообще никак сервер АСДУ это дело не контролирует. Смотрю в интерфейс предоставляемой DLL и в упор не вижу каких-либо подобных функций для различения хотя бы типов измерений (не то, что масштаба).
Кинулся переписывать, всё что уже сделал с учётом типов измерений и размерности + с привязкой по фазам. Есть, конечно, послабления типизации, например при расчёте _суммарной_ мощности по трём фазам, или _среднего_ напряжения по трём фазам. Но, это дешёвый технический долг. Сделаю.
И в итоге вычислил мелкие потенциальные косяки в своём коде. Например, тип "Линия 110 кВ" наследуется от типа "вводная ячейка 10 кВ" (первые 11 членов типа совпадают по порядку следования в конфигурации сервера). Но! Мощность общая по линии 110 кВ и мощность вводной ячейки 10 кВ -- не совпадают по размерности!!! (МВт против кВт). Никак в толк не возьму, зачем в диспетчерском управлении такие выкрутасы с размерностями, ведь SHORTREAL, извиняюсь 3.2*10^38. А если нужно для коммерческого учёта то даже тип SHORTINTEGER 4.2 млрд Ватт (т. е. 4200 МВт -- такую мощь не всякая атомная станция выдаёт). Не говорю уже про то, что есть всякие костыли, типа разбиения INTEGER на две части и представление в формате SHORTINTEGER (или серия подряд SHORTINTEGER с умножением каждой части на 1000, на 1000000, на .... если угодно).
Я, помню, что в ячейке линии 110 кВ хранятся именно МВт, а не кВт, но программа дорасчёта на КП ничего об этом не знает и знать не должна! Только GetKWt() и хоть ты тресни. И это меня радует)
И ещё, такая наблюдалочка: я старательно закрываю прямой доступ к членам типа, максимум только чтение. Или ещё лучше -- только контролируемый доступ на чтение и запись. Это повышает контролируемость логики программы, позволяет вернуть из типа кВт -- тип МВт (tKWt.GetMWt).
И принял такое условное правило, что все нежелательные (опасные) методы начинаются с _. К примеру пока есть гадость, как _SetRaw. Думаю, комментарии тут не нужны))) Нарушает самым наглым образом безопасность типов, но это как костыль, позже избавлюсь.
Процесс идёт, выбора у меня нет, когда-нибудь закончу)))
З.Ы. Я могу согласиться с Николаем Вальтеровичем, что форма записи в виде
Код:
PROCEDURE (VAR self:mKW.tKW)GetKW(),NEW;

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

Автор:  prospero78 [ Суббота, 23 Апрель, 2016 14:38 ]
Заголовок сообщения:  Re: ОИК "Восход"

Хм. А ведь я не прав с SHORTINTEGER (16 бит). Конечно, речь шла о INTEGER и LONGINTEGER. И никто не поправил))) Сегодня перед субботником начал заменять вызовы _SetRaw на как положено. И делается это весьма приятно с помощью перехвата выполнения тела _SetRaw с заведомо невыполнимым ASSERT в теле процедуры. Не надо совсем помнить, где я этот костыль использую)
Очень удобно)
Смотрю на подход Вирта, и мне понятно почему всё именно так.
Оберон-07 вызывает у меня живой интерес, после пользования КП))))

Автор:  Илья Ермаков [ Суббота, 23 Апрель, 2016 18:56 ]
Заголовок сообщения:  Re: ОИК "Восход"

Круто.

По Modbus: Вы раньше реализовывали, опыт был?
У нас есть частичная реализация на С++ (для контроллера перекрёстков), но там нормально так абстрагировано - выделен абстрактный канал нижележащий и т.п. (у нас там RS-485).

Так что, если это пригодится, обращайтесь.

В своё время не нашли вменяемых реализаций (нам, правда, надо было "на борт" микроконтроллера выносного пульта, а не на десктоп, там существующая пара библиотек хрен помещалась).

Автор:  Info21 [ Суббота, 23 Апрель, 2016 23:42 ]
Заголовок сообщения:  Re: ОИК "Восход"

prospero78 писал(а):
Смотрю на подход Вирта, и мне понятно почему всё именно так.
Оберон-07 вызывает у меня живой интерес, после пользования КП))))

Пожалуйста, повысказывайтесь в духе мозгового штурма, т.е. когда за идеи полёт ассоциаций запрещено :)

Автор:  prospero78 [ Воскресенье, 24 Апрель, 2016 10:00 ]
Заголовок сообщения:  Re: ОИК "Восход"

Илья Ермаков писал(а):
Круто.

По Modbus: Вы раньше реализовывали, опыт был?
У нас есть частичная реализация на С++ (для контроллера перекрёстков), но там нормально так абстрагировано - выделен абстрактный канал нижележащий и т.п. (у нас там RS-485).

Так что, если это пригодится, обращайтесь. ....

Я выгреб из интернетов почти всё по Modbus, реализовал чтение отдельных битов, запись отдельных битов, чтение всех бит состояния разом. Собственно, мне хватает, но с удовольствием посмотрел бы на другие исходники. В моём случае я рассматриваю любую информацию как критически важную. Поднятый Ф.В. тезис информационной ассиметрии встаёт в полный рост)))

Автор:  prospero78 [ Воскресенье, 24 Апрель, 2016 10:19 ]
Заголовок сообщения:  Re: ОИК "Восход"

Info21 писал(а):
prospero78 писал(а):
Смотрю на подход Вирта, и мне понятно почему всё именно так.
Оберон-07 вызывает у меня живой интерес, после пользования КП))))

Пожалуйста, повысказывайтесь в духе мозгового штурма, т.е. когда за идеи полёт ассоциаций запрещено :)

Вторая часть фразы -- я что-то не понял.
1. В энергетике и смежных отраслях запрещена ситуация с потерей контроля. Любой доступ к данным должен быть явным и контролируемым. Произвольное чтение и присвоение данных без контроля метаинформации по базовым типам -- недопустимо.
2. Метаинформация вокруг базовых типов оказывается важнее. Метаинформация повышает степень управляемости и контроля над состоянием программной системы.
3. Компонентный подход превосходно подходит для описания конечных, реально-существующих устройств. Документы-отображения обращаются к своим модулям за информацией, модули-контейнеры полностью отвязаны от ГИП, что даёт а) устойчивость б) низкую связность в) независимость/гибкость в наращивании функциональности. Например: несколько модулей-контейнеров-устройств > одна форма, или другой шаблон: один модуль-контейнер > несколько документов-отображений.

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

Автор:  Info21 [ Воскресенье, 24 Апрель, 2016 10:25 ]
Заголовок сообщения:  Re: ОИК "Восход"

Спасибо, интересно.

Фраза про мозговой штурм должна была звучать так:

"... в духе мозгового штурма, т.е. когда за полёт ассоциаций бить запрещено :)
"

Автор:  prospero78 [ Воскресенье, 24 Апрель, 2016 12:51 ]
Заголовок сообщения:  Re: ОИК "Восход"

Нечаянно подумал про использованные протоколы.
Модбас делался изначально для дискретных устройств. На сколько помню, поверх RS-232 используется для контроля целостности CRC-16. Потом там прикостылили неродные средства для передачи массивов и чисел с плавающей запятой (фактически целое число). Поверх TCP/IP, по памяти, контрольной суммы нет (что логично). Таким образом в Модбасе явно смешаны сетевой и транспортный уровень. Прикладным там и не пахнет.
МЭК-103/104/105. Тут уже лучше. Присутствует и нумерация пакетов, и разделение типов данных, и контроль качества (признаки достоверности, устаревания, установки вручную, блокировка вручную). Можно даже передать массив байт как файл. В-целом, прилично. Но из всего семейства торчат уши COM-порта. МЭК-101 намертво прибит к СОМ-порту. Опять нет чёткого разделения по уровням. Непонятно, зачем нужна кодовая посылка начала и конца передачи в TCP/IP, ведь это транспорт гарантированной передачи. Соответственно, нумерация пакетов по сети тоже избыточна. Тем более, что в каждом сообщении указывается общая длина элементов.
Невольно приходишь к мысли, что забивание гвоздей микроскопом неразумно. Как наставляет паству преподобный Никлаус: каждой задаче -- свой инструмент. Попытка натягивания ежа на ужа закончится плохо для обоих и будет свидетельствовать как минимум о технической безграмотности исполнителя (если не о психических отклонениях).
И вот я смотрю на это со стороны, и не понимаю, что за архаизм, антинаучность и зоопарк в АСУ ТП?
НИ ОДНОГО научно-обоснованного непротиворечивого протокола. Думаю, что есть максимум пяток протоколов, которые можно описать через РФБН.
Вот такая сложилась неприглядная ситуация в автоматизации по сетям...
В авионике ситуация получше. Мне известно о двух протоколах, заточенных под быструю передачу и ограниченность возможных состояний оборудования (+ до пяти каналов передачи). Но там от носа до хвоста от силы 50 метров и пара сотен датчиков. Ни перед кем отчитываться не надо. В чёрном ящике буквально десяток полётных параметров+переговоры.
Это частное решение. В моём случае слишком узкое. 2600 телепараметров (с перспективной доведения до 3000), архивная глубина 2 года, 150 телепараметров уходит на уровень выше. Три протокола, 4 типа каналов передачи и около сотни блоков). Длина всех силовых и сигнализационных кабелей на объекте превышает 65 км. И мой объект далеко не самый навороченный в регионе)
Чтобы одолеть сложность необходима простота)

Автор:  Info21 [ Воскресенье, 24 Апрель, 2016 23:44 ]
Заголовок сообщения:  Re: ОИК "Восход"

Впечатляет. Следим, затаив дыхание.

Автор:  prospero78 [ Понедельник, 25 Апрель, 2016 07:49 ]
Заголовок сообщения:  Re: ОИК "Восход"

Настало утро и вот ещё одна, имхо, существенная наблюдашка: ни один промышленный/полевой протокол не знает что такое "безопасность данных". Ни авторизации, ни шифрования, не сессионного ключа. Даже поксорить поток в современных протоколах не судьба.
Исходя из этого наивное РАО "ЕЭС" требует изолированные сети передачи в благой надежде, что это спасёт положение.
Как можно предположить, примерно 70% данных передаётся по общественным сетям через VLAN. И хорошо если провайдер закрывает своим ключом поток. А то бывает совсем с этим не замарачивается)))
Шифр Вежинера простой и чуть ли не единственный, с доказанной абсолютной надёжностью. Есть проблемы с рукопожатием, но это просто мелочи по сравнению с вышеизложенным безобразием.
Вот я и подумываю, что между основным и резервным сервером я по принятым протоколам ничего передавать не буду)))

Автор:  Илья Ермаков [ Понедельник, 25 Апрель, 2016 10:28 ]
Заголовок сообщения:  Re: ОИК "Восход"

prospero78 писал(а):
Шифр Вежинера простой и чуть ли не единственный, с доказанной абсолютной надёжностью. Есть проблемы с рукопожатием, но это просто мелочи по сравнению с вышеизложенным безобразием.


Вы имеете в виду шифр "одноразового блокнота", где случайный ключ используется однократно?
Потому что то, что называется шифром Вежинера, не является криптостойким.

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

Автор:  prospero78 [ Понедельник, 25 Апрель, 2016 10:33 ]
Заголовок сообщения:  Re: ОИК "Восход"

Илья Ермаков писал(а):
prospero78 писал(а):
Шифр Вежинера простой и чуть ли не единственный, с доказанной абсолютной надёжностью. Есть проблемы с рукопожатием, но это просто мелочи по сравнению с вышеизложенным безобразием.


Вы имеете в виду шифр "одноразового блокнота", где случайный ключ используется однократно?
Потому что то, что называется шифром Вежинера, не является криптостойким.

Совершенно верно. На самом деле, я говорил про шифр Гильберта Вернама))) Фамилии похожи, старею))) (может, просто не позавтракал)
Пруф-линк: https://ru.wikipedia.org/wiki/%D0%A8%D0%B8%D1%84%D1%80_%D0%92%D0%B5%D1%80%D0%BD%D0%B0%D0%BC%D0%B0
Цитата:"В 1945 году Клод Шеннон написал работу (рассекреченную только после Второй мировой войны в 1949 г.), в которой доказал абсолютную стойкость шифра Вернама. То есть перехват шифротекста не даёт никакой информации о сообщении. С точки зрения криптографии, невозможно придумать систему безопаснее шифра Вернама[2]. "

Про ГОСТ, может быть, но там куча раундов шифрования? Тут, вопрос соотношения временных затрат/необходимая степень защиты. Стоит ли оно того?
Мне даже задачи такой никто не формулировал: программа дорасчёта, надёжная и простая передача данных между серверами.
Но есть пунктик в должностных обязанностях:
1.3.Основной задачей инженера АСДУ является:
- своевременное и правильное выполнение своих обязанностей по обслуживанию, ремонту, монтажу, наладке, эксплуатации устройств системы АСДУ - ПС 110 кВ О-55 Восточная-1.
- обеспечение надежной работы устройств системы АСДУ и их вторичных цепей;
- внедрение новой и усовершенствование эксплуатируемой системы АСДУ на подстанции ПС 110 кВ О-55 Восточная-1.
Так что я и не знаю, как тут быть. На сколько тут нужна лицензия, ведь я формально не создаю новые средства? Я работаю с существующими? Средства шифрования не на продажу, не для "внешнего" применения. Так, подстраховочка.
Экзамены в РостТехНадзоре по соответствующим разделам энергетики сдал, допуски имею. Не разработка ПО, эксплуатация электрических станций и сетей. 5 группа (до и выше 1000 В, право выдачи нарядов на проведение работ, единоличный осмотр высоковольтного оборудования)

Автор:  Илья Ермаков [ Понедельник, 25 Апрель, 2016 10:48 ]
Заголовок сообщения:  Re: ОИК "Восход"

Если для внутреннего применения, внутри РАО ЕЭС - то острота вопроса по лицензии не стоит.
Но нюансы могут оставаться.

Автор:  Илья Ермаков [ Понедельник, 25 Апрель, 2016 10:52 ]
Заголовок сообщения:  Re: ОИК "Восход"

По быстродействию: ну так между чем обмен планируется? Если между серверами, то никаких проблем с быстродействием нет. Как нет их у SSL (https). Так и у ГОСТ.

Автор:  prospero78 [ Понедельник, 25 Апрель, 2016 10:57 ]
Заголовок сообщения:  Re: ОИК "Восход"

Илья Ермаков писал(а):
Если для внутреннего применения, внутри РАО ЕЭС - то острота вопроса по лицензии не стоит.
Но нюансы могут оставаться.

Я работаю в частной организации. Я контактирую с РАО только в части передачи 150 телепараметров по протоколу, который согласован обеими сторонами и утверждён начальником с их стороны. Они точно с переходами замарачиваться не будут. У них есть свой региональный оперативно-информационный комплекс "SMART-FEP" (ОИК), плевать они хотели на разумные предложения)
Поддерживаю контакт с ответственным лицом по АСДУ с их стороны, коллеге вообще до лампочки, что у нас творится, ему главное бесперебойная работа связи. Но проврека РосТехНадзора при посещении может поинтересоваться ПО (хотя, пока вероятность такого запроса очень низкая, спецов по ПО там нет -- лицензию с ключом показали, все довольны; а что там на сервере, у которого даже монитора нет -- никому не интересно).

Обмен планируется между основным и резервным сервером. Возможно начальства внезапно захочет себе веб-морду иметь. Или, как это сейчас модно: показать народу на публичном сайте в режиме реального времени, что у нас "всё пучком". Передача должна быть как можно быстрее, чтобы метки времени телепараметров с основного сервера и резервного не отличались. Теоретически метки времени вообще должны совпадать. По-моему, резервный сервер эти метки замещает, но пока сверху претензий не было. Точно не скажу. Но, в перспективе -- это не проблема. Передать вместе с сообщением метку времени -- восемь байт.

Автор:  Илья Ермаков [ Понедельник, 25 Апрель, 2016 11:08 ]
Заголовок сообщения:  Re: ОИК "Восход"

Если речь об обмене между двумя серверами - вам шифрование ничего не замедлит. Даже не заметите.
По сравнению, например, с латентностью TCP при каждой отправке сообщения.

Автор:  prospero78 [ Понедельник, 25 Апрель, 2016 11:15 ]
Заголовок сообщения:  Re: ОИК "Восход"

Илья Ермаков писал(а):
Если речь об обмене между двумя серверами - вам шифрование ничего не замедлит. Даже не заметите.
По сравнению, например, с латентностью TCP при каждой отправке сообщения.

А если по TCP?

Кое-какие результаты после удаления _SetRaw:


Вложения:
001.jpg
001.jpg [ 73.71 КБ | Просмотров: 17061 ]

Автор:  Илья Ермаков [ Понедельник, 25 Апрель, 2016 16:57 ]
Заголовок сообщения:  Re: ОИК "Восход"

Как обещал - код модбуса:
https://bitbucket.org/Ermakov_Team/erglpclib

Это мини-библиотечка для разработки под LPC2000-контроллеры в асинхронном стиле без прерываний (задачи в духе Action, счетчик времени, асинхронный опрос сигналов без прерываний).

А также channel.h/cpp - абстракция канала битового ввода-вывода, реализация над RS-485.
И modbus.h/cpp - реализация Modbus Slave (не все вещи, просто не было нужно, но структура обработки, главное, сделана) над битовым каналом.

Там в .h-файлах есть комментарии.

Автор:  prospero78 [ Понедельник, 25 Апрель, 2016 17:36 ]
Заголовок сообщения:  Re: ОИК "Восход"

Илья Ермаков писал(а):
Как обещал - код модбуса:
https://bitbucket.org/Ermakov_Team/erglpclib

Это мини-библиотечка для разработки под LPC2000-контроллеры в асинхронном стиле без прерываний (задачи в духе Action, счетчик времени, асинхронный опрос сигналов без прерываний).

А также channel.h/cpp - абстракция канала битового ввода-вывода, реализация над RS-485.
И modbus.h/cpp - реализация Modbus Slave (не все вещи, просто не было нужно, но структура обработки, главное, сделана) над битовым каналом.

Там в .h-файлах есть комментарии.

Отлично! Спасибо)
Внимательно посмотрю и творчески искаверкаю)))

Автор:  Alexander Shiryaev [ Понедельник, 25 Апрель, 2016 19:36 ]
Заголовок сообщения:  Re: ОИК "Восход"

Илья Ермаков писал(а):
...без прерываний...

А как часто происходит вызов Channel_Uart0::Task_Body / Channel_U1_485::Task_Body? Буфера FIFO приёмника порта UART хватает?

Страница 1 из 10 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/