Активно пилю свою программулину, пока рабочее название ОИК "Восход".
Это очень громкое название, на самом деле пока речь идёт только о дорасчёте к существующему серверу.
На прицеле держу то, что бы его (действующий сервер) заместить вообще. Для этого кроме самого дорасчёта, нужно реализовать по крайней мере три протокола:
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;
вполне могла обойтись и функциональным видом. Единственное преимущество: чуть более наглядная форма записи вызова метода. Но, имхо, это особо не принципиально.