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:
|
Автор: | Илья Ермаков [ Понедельник, 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/ |