syoma

Не думаю, что многие знакомы с этой терминологией на данном форуме. Поэтому я пытаюсь объяснить понятным языком - есть быстрая распределенная система сбора аналоговых данных. Она собрана на Ethernet. Ну делает он это и что? На 1Гбитном канале эти вещи не вызывают никаких проблем с задержками или доставкой фреймов. Естественно, процессинговая шина отделена от остального Ethernet трафика физически, хотя с VLANaми все тоже разделяется и прекрасно работает на том же свиче. И вообще это общая проблема для всех шин с общим доступом к шине, а не только Ethernet. Максимально гарантированное 160мкс. Типовое 100мкс, но хотим уменьшить. Если у вас есть инсайдерская информация - поделитесь.

TSN вроде как организует трафик внутри сети, так что все что надо, доставляется куда надо с гарантированной максимальной задержкой. Но дальше возникает тот же вопрос - что делать с фреймами, которые пришли раньше времени? Я думаю, что что-то в свиче. Может быть особенность перевода из 100мБит в 1Гбит. Но на самом деле это не так важно, так как когда передатчиков (и фреймов) будет много, недетерминированные задержки все равно возникнут. Насколько я понимаю тут будут играть даже скорости распространения света по оптике на расстояниях 50-200м. Ну и как ниже описано, точность синхронизации +-500нс, то есть обязательно кто-то будет слать чуть раньше, а кто-то чуть позже. IEC61850-9-2 - Sampled Values. Это layer 2 protocol - голые MAC фреймы. Модель publisher-subscriber. Wireshark его легко понимает. Не знаю, но IEEE 1588 v2 PTP прекрасно справляется с такими свичами. Точнее не так. Свич-то как раз с точки зрения IEEE 1588 является "transparent clock" и поэтому компенсирует там у себя что-то. Но реально синхронизация с точностью менее 1мкс есть и работает - мы проверяли. Тут чистая внутренняя ПЛИСоводчина и синхронизированная проприетарщина. Поэтому джиттер пока там не ищем.

Ну это не странно, это IEC 61850-9-2. Уменьшает количество проводов, обеспечивает гальваническую развязку, позволяет передавать аналоговые сигналы с большой скоростью на большие расстояния от большого количества узлов в реальном времени, используя стандартное Ethernet оборудование. Возможность простого полного дублирования передающей сети. По проблеме пока нечего решать, надо сначала разобраться есть проблема или ее нет. Во первых в стандарте это не специфицировано. Там описано так, что "измерил - сразу передавай". И разнесение по времени как-то не работает с Ethernet. Я пока не понимаю почему. Вот просто берем один АЦП, цепляем его к свичу и с другой стороны ставим ПЛИС на прием. Других пакетов в сети нет. Все отключено. АЦП шлет один фрейм каждые 10.4мкс. Но почему-то на ПЛИС все равно пакеты приходят с разными задержками. Какая-то странная логика у свича - то ли он их там в буфер засовывает, то ли еще что-то. Конечно, но это отслеживается. А еще в Ethernet есть удобное решение для этого - Parallel Redundancy Protocol. До высших гармоник, то есть 2500 Гц.

Ну а что это? Пакеты от одного конкретного источника не переставляются и идут в строгом порядке. Т.е. пакет с током, измеренным в момент t, обязательно примется ранее, чем пакет с током, измеренным в момент t+10,4мкс. Наоборот точно невозможно. Просто из-за коллизий в свиче конкретный пакет может прийти раньше или позже нужного времени. Так вопрос в том - какие негативные последствия можно ожидать, если так не делать? Хоть в теории? Пока только наблюдаю, что DSP в конкретном цикле может тупо схавать слегка устаревшие данные, если новые не успевают поступить до определенного момента времени. Но чем это грозит с точки зрения алгоритма, прикинуть не могу. Может промоделировать как-то?

Привет вот такой теоретический вопрос. В общем есть аналоговый сигнал - например ток инвертора, который оцифровывается АЦП с частотой 96кГц. Далее эти семплы в виде пакетов данных передаются через общую сеть на основной вычислитель, который уже выполняет их обработку и управляет системой в реальном времени. Например, в нем крутятся алгоритмы защиты, которые должны отключить инвертор как при превышении мгновенного значения тока, так и по перегрузке, если действующее значение выше определенной величины определенное время. Таких АЦП в системе несколько - на каждой из трех фаз, на сетевых напряжениях, а вычислитель один. Вопрос в том, что передающая сеть от АЦП к вычислителю построена по типу Ethernet сети - т.е. каждый АЦП подключен к свичу через свой канал 100Мбит, а от свича к вычислителю идет один линк 1Гб или 10Гб в зависимости от необходимой общей пропускной способности. Свич вносит задержку и джиттер, так как пакеты от разных АЦП сталкиваются в свиче и затем передаются через одну общую линию связи на вычислитель. Т.е. их порядок в очереди приема может быть разный, а сами пакеты достаточно большие, чтобы коллизии имели место. Измеренная итоговая задержка любого конкретного сигнала - от 10 до 18мкс. При этом все устройства - и АЦП и вычислитель четко синхронизированы по времени и каждый семпл имеет свою метку времени и поэтому восстановить сигнал без джиттера в вычислителе можно сравнительно легко и он тогда просто будет всегда иметь максимально возможную задержку. Но тут возникает вопрос - а надо ли? Например, в случае алгоритма защиты по мгновенному току - по идее чем раньше придет этот превышающий порог семпл, тем быстрее отработает система и общая задержка будет меньше, что очень критично. Но это теоретически и в лучшем случае. Но рассчитывать - то приходится на самый худший - мы же в реальном времени управляем. То есть появляется какой-то недетерминизм - пишем максимальную задержку, а в реале система в 99% случаев реагирует быстрее. Фигня какая-то, но зато просто и именно так оно сейчас и работает. А что насчет всяких фильтрующих и DSP алгоритмов? Могут возникнуть какие-либо высокочастотные осцилляции или будет ли такой джиттер влиять на всякие преобразования Фурье? В принципе перед медленными фильтрами и алгоритмами, которые не требуют высоких частот выборок, у нас везде стоят антиалиазинговые фильтры. Они убирают джиттер или он им мешает? Наверное, самый простой вопрос, нужно ли бороться с джиттером - это 3-х фазные измерения токов, напряжений и мощности. В этом случае стоит иметь полностью синхронизированные семплы от разных фаз. Но эти измерения имеют очень низкую скорость, что похоже им тот джиттер должен быть пофиг. Да и итоговая рассинхронизация между разными АЦП никогда не превышает 1 семпл. Так надо ли? Какое ваше мнение? Может из аудио кто посоветует?

MQTT умеете?

Я как раз Вас хотел спросить, почему не занимаетесь. Вон есть товарищ, он аж 70кВтч в Лиф запихнул. 40кВтч для него уже пройденный этап, судя по другим видео. Ему бы с вами скооперироваться. Ведь почти рядом же.

Сорри, но в том же VxWorks доступа к исходникам BSP тоже нет. И оно там неуправляемо от слова вообще и управляется не Windriver, а производителем самой платы. Не понимаю, где вы тут видите разницу с RPi. И поверьте мне, как только ты пытаешься использовать тот TPM или включить Secure Boot вылазит столько багов в BSP, что производитель только и успевает их фиксить. Плата с большей пользовательской базой тут намного лучше. А что Хакеры имеют с BSP? Это разве их уровень? ПС помоему мы не заметили, как нас отделили в отдельную тему :-)

Ну вот смотрите, очередной ваш аргумент улетучивается. Исходники Azure RTOS сейчас открыты для всех https://github.com/azure-rtos/threadx. Следовательно, исследовать и найти в них уязвимости может любой хакер, также как и в опенсорс. Зачем же вы ее используете? И вообще зачем мелкомягкие выложили их в открытый доступ, если это был такой хороший proprietary и сертифицированный код?

Ну логика о том, что проприетарный софт лучше тестируется или поддерживается тоже заслуживает критики. Вы же не знаете сколько там программистов крутится и сколько незакрытых баг-репортов? А сертифицированный код - ну это вы серьезно такой используете и покупали на него лицензию или тоже теоретизируете? Но вопрос был не об этом, а о том, что с точки зрения кибербезопасности надо смотреть на риски, а не сразу констатировать - это лучше, а это хуже.

Можете обьяснить, как вы на основе этой новости делаете такой вывод?

Ну я кой-какие курсы заканчивал. И там объясняли, что за кибербезопаснотью нельзя просто следить. Это наука о минимизации рисков и их последствий, в которой в первую очередь надо смотреть на возможности для атак, оценивать риски, а потом рассказывали как минимизировать возможность их наступления, или ущерба от них или увеличивать возможность их обнаружения. Как пример, вот Вы рассказываете байки про всякие исходники, Open-Source, встраиваемый Линукс и т.д. А Cybersecurity експерт что говорит? Он говорит: "Ок, opensource использовать надо, так как без него уже невозможно сделать нормальную разработку за нормальные деньги и сроки. Но можно ли уменьшить Cybersecurity риски, если используешь Open-source? Есть ли разница между Open Source Проектом А и Open Source проектом Б с точки зрения кибер-безопасности? А она есть. Например проект А имеет 400 меинтейнеров и регулярные коммиты, а проект Б - всего 10 и коммит раз в полгода. Вопрос: в каком проекте будут быстрее находиться и устраняться уязвимости и патчи появляться быстрее? В проекте А, конечно. Ведь там код просматривается 400-ми пар глаз и шанс увидеть уязвимость многократно возрастает. А теперь вопрос 3 на засыпку - есть не-опенсоурс проект C, альтернатива A и Б, платный, но фирма не такая уж большая и не очень понятно, кто этот проект использует. Будет ли он лучше с точки зрения Cybersecurity, чем проект А? " Нет. Взял потому, что оценил риски и понял, что на данном этапе разработки ущерб от них несущественен. А потом их можно будет закрыть тем или иным способом.

Зато с ним не тр...шся - собрал панель, засунул и все дела. Это, кстати, то, что мне @FLPPotapov нарисовал, а мои умельцы собрали. Кооперация однако. И без всяких Алмаз-Антеев

Ящичек, кстати Ритталовский хороший. У меня тоже на таком тестовый стенд сделан. Только на колесиках.

Нет смысла обсуждать, что лучше а что хуже. В каждом способе есть свои недостатки и преимущества с точки зрения Cybersecurity. Важно их понимать и грамотно использовать.