syoma
-
Постов
2 476 -
Зарегистрирован
-
Посещение
-
Победитель дней
1
Сообщения, опубликованные syoma
-
-
10 hours ago, Stanislav said:
Наверно, надо уточнить: каково время принятия решения?
Я к тому, что защита вряд ли у Вас срабатывает по единичному измерению (тока), и требуется некоторое время на "обмозгование" ситуации. Проще говоря, есть фильтрация случайных/кратковременных событий.
Время принятия решения очень маленькое - скользящее среднее по двум или трем семплам, я не помню навскидку. Большая часть задержки - это время прохождения команды на блокировку инвертора. 8мкс в наших условиях - это в худшем случае +80А к измеренному току в момент отключения, соответственно под этот увеличенный ток нужно рассчитывать оборудование, чтобы его надежно разрывать/блокировать
-
3 hours ago, Hale said:
Я не понимаю, вам из принципа охота поспорить?
Нет неохота. Я просто не понимаю, зачем тянуть сюда заведомую нелепицу про "дошло бы до адресата" или про отсутствие детерминированности в Езернете. Да, есть определенный недетерминизм, с которым и думаем, что решать и нужно ли что-то решать. Пригодность/непригодность данной полевой шины в данном применении не обсуждается.
-
19 hours ago, Pengozoid said:
ТС, вы бы для понимания сути проблемы рассказали, что у вас не просто АЦП, а что-то типа 61850 MU на подстанции (?), где там ваша аппаратура стоит, process/station, может быть по делу чего посоветовали, а не спрашивали, почему нельзя напрямую АЦП подключить.
Не думаю, что многие знакомы с этой терминологией на данном форуме. Поэтому я пытаюсь объяснить понятным языком - есть быстрая распределенная система сбора аналоговых данных. Она собрана на Ethernet.
9 hours ago, Hale said:... Езернет? При задержке езернета, о каком джиттере речь. до адресата дошло-бы вовремя. Джиттер, это когда из-за 20-градусного сдвига у вас пол-моста выгорает.
свич (а не хаб) пытается составить таблицы соответствия MAC дыркам портов. Иногда он их обновляет, иногда пытается повлиять на передачу с хостов во избежание коллизий входного трафика. Также он проверяет наличие бродкастов (MAC тоже имеет механизм бродкаста, в NOVEL 90х годов это использовалось). Все это условная логика с таймерами. Ни о какой детерминированности у вас на обычном ethernet речи быть не может. Хотите избавиться от этих вещей, надо ставить хаб, или делать узел самому. А против коллизий вам нужно что-то вроде token-ring.
Ну делает он это и что? На 1Гбитном канале эти вещи не вызывают никаких проблем с задержками или доставкой фреймов. Естественно, процессинговая шина отделена от остального Ethernet трафика физически, хотя с VLANaми все тоже разделяется и прекрасно работает на том же свиче.
И вообще это общая проблема для всех шин с общим доступом к шине, а не только Ethernet.
8 hours ago, Stanislav said:Скажите, а каково характерное/максимально допустимое время срабатывания защит по мгновенному току и перегрузке? Если можно, подробнее опишите алгоритм.
Максимально гарантированное 160мкс. Типовое 100мкс, но хотим уменьшить.
8 hours ago, Stanislav said:ЗЫ. Не в тему - здесь вот "по сети" двыгун спалили. Наглухо.
Няз, словили рассинхронизацию фаз из-за задержек передачи/обработки.
Если у вас есть инсайдерская информация - поделитесь.
-
2 hours ago, blackfin said:
Значит, пора переходить на TSN. ;)
TSN вроде как организует трафик внутри сети, так что все что надо, доставляется куда надо с гарантированной максимальной задержкой. Но дальше возникает тот же вопрос - что делать с фреймами, которые пришли раньше времени?
2 hours ago, jcxz said:А вот то, что даже при наличии только одного передатчика, задержка приёма недетерминирована - с этим стоит разбираться отдельно. Может свич поменять на другой. Или в чём-то другом проблема.
Я думаю, что что-то в свиче. Может быть особенность перевода из 100мБит в 1Гбит. Но на самом деле это не так важно, так как когда передатчиков (и фреймов) будет много, недетерминированные задержки все равно возникнут. Насколько я понимаю тут будут играть даже скорости распространения света по оптике на расстояниях 50-200м. Ну и как ниже описано, точность синхронизации +-500нс, то есть обязательно кто-то будет слать чуть раньше, а кто-то чуть позже.
1 hour ago, haker_fox said:Извините, не совсем по теме. Но.. вы используете протокол TCP/IP или голые Ethernet-фреймы? Или что-нибудь индустриальное?
IEC61850-9-2 - Sampled Values. Это layer 2 protocol - голые MAC фреймы. Модель publisher-subscriber. Wireshark его легко понимает.
1 hour ago, AlexandrY said:А как вы умудряетесь с таким свичером добиться синхронизации времени с точностью 1 мкс?
Не знаю, но IEEE 1588 v2 PTP прекрасно справляется с такими свичами. Точнее не так. Свич-то как раз с точки зрения IEEE 1588 является "transparent clock" и поэтому компенсирует там у себя что-то. Но реально синхронизация с точностью менее 1мкс есть и работает - мы проверяли.
1 hour ago, AlexandrY said:Не хватает рассказа как DSP алгоритм выводит свои результаты. Небось опять через тот же свичер.
И насколько эти алгоритмы сами детерминированы.
А не окажется ли что джитер вывода гораздо больше джитера ввода.Тут чистая внутренняя ПЛИСоводчина и синхронизированная проприетарщина. Поэтому джиттер пока там не ищем.
-
2 hours ago, jcxz said:
Тут вопрос скорее в том - почему сбор данных с АЦП построен таким странным образом?
Имхо - сами себе создали проблему, теперь пытаетесь её решать.
Ну это не странно, это IEC 61850-9-2. Уменьшает количество проводов, обеспечивает гальваническую развязку, позволяет передавать аналоговые сигналы с большой скоростью на большие расстояния от большого количества узлов в реальном времени, используя стандартное Ethernet оборудование. Возможность простого полного дублирования передающей сети. По проблеме пока нечего решать, надо сначала разобраться есть проблема или ее нет.
2 hours ago, jcxz said:Так если все АЦП синхронизированы между собой, то кто мешает разнести передачи от них по времени? так чтобы они не перекрывались. Это конечно если по этой самой Ethernet не передаётся каких-то других данных, кроме АЦП-шных. Это гораздо проще (имхо) чем потом "восстановить сигнал без джиттера в вычислителе". Всегда проще не ломать, чем восстанавливать сломатое.
Во первых в стандарте это не специфицировано. Там описано так, что "измерил - сразу передавай". И разнесение по времени как-то не работает с Ethernet. Я пока не понимаю почему. Вот просто берем один АЦП, цепляем его к свичу и с другой стороны ставим ПЛИС на прием. Других пакетов в сети нет. Все отключено. АЦП шлет один фрейм каждые 10.4мкс. Но почему-то на ПЛИС все равно пакеты приходят с разными задержками. Какая-то странная логика у свича - то ли он их там в буфер засовывает, то ли еще что-то.
2 hours ago, jcxz said:А ещё он может просто не прийти (потеряться).
Конечно, но это отслеживается. А еще в Ethernet есть удобное решение для этого - Parallel Redundancy Protocol.
3 hours ago, Lmx2315 said:Уточните о какой полосе сигнала идёт речь. Если ваш полезный сигнал 48 кГц - то 10 мкс , это 180 градусов изменения фазы для него, а это порождение кучи гармоник в спектре, посмотрите фазовую модуляцию. А если полоса вашего сигнала 100 гц , то 10 мкс это менее 0.1 процента.
Это даст Динамический диапазон более 60 Дб.
До высших гармоник, то есть 2500 Гц.
-
1 hour ago, V_G said:
Как-то по другому должны называться временные искажения, связанные с перестановкой пакетов в сети передачи данных...
Ну а что это? Пакеты от одного конкретного источника не переставляются и идут в строгом порядке. Т.е. пакет с током, измеренным в момент t, обязательно примется ранее, чем пакет с током, измеренным в момент t+10,4мкс. Наоборот точно невозможно. Просто из-за коллизий в свиче конкретный пакет может прийти раньше или позже нужного времени.
2 hours ago, Lmx2315 said:для DSP собирайте по времени.
Так вопрос в том - какие негативные последствия можно ожидать, если так не делать? Хоть в теории? Пока только наблюдаю, что DSP в конкретном цикле может тупо схавать слегка устаревшие данные, если новые не успевают поступить до определенного момента времени. Но чем это грозит с точки зрения алгоритма, прикинуть не могу. Может промоделировать как-то?
-
Привет вот такой теоретический вопрос.
В общем есть аналоговый сигнал - например ток инвертора, который оцифровывается АЦП с частотой 96кГц. Далее эти семплы в виде пакетов данных передаются через общую сеть на основной вычислитель, который уже выполняет их обработку и управляет системой в реальном времени. Например, в нем крутятся алгоритмы защиты, которые должны отключить инвертор как при превышении мгновенного значения тока, так и по перегрузке, если действующее значение выше определенной величины определенное время. Таких АЦП в системе несколько - на каждой из трех фаз, на сетевых напряжениях, а вычислитель один.
Вопрос в том, что передающая сеть от АЦП к вычислителю построена по типу Ethernet сети - т.е. каждый АЦП подключен к свичу через свой канал 100Мбит, а от свича к вычислителю идет один линк 1Гб или 10Гб в зависимости от необходимой общей пропускной способности. Свич вносит задержку и джиттер, так как пакеты от разных АЦП сталкиваются в свиче и затем передаются через одну общую линию связи на вычислитель. Т.е. их порядок в очереди приема может быть разный, а сами пакеты достаточно большие, чтобы коллизии имели место. Измеренная итоговая задержка любого конкретного сигнала - от 10 до 18мкс. При этом все устройства - и АЦП и вычислитель четко синхронизированы по времени и каждый семпл имеет свою метку времени и поэтому восстановить сигнал без джиттера в вычислителе можно сравнительно легко и он тогда просто будет всегда иметь максимально возможную задержку.
Но тут возникает вопрос - а надо ли?
Например, в случае алгоритма защиты по мгновенному току - по идее чем раньше придет этот превышающий порог семпл, тем быстрее отработает система и общая задержка будет меньше, что очень критично. Но это теоретически и в лучшем случае. Но рассчитывать - то приходится на самый худший - мы же в реальном времени управляем. То есть появляется какой-то недетерминизм - пишем максимальную задержку, а в реале система в 99% случаев реагирует быстрее. Фигня какая-то, но зато просто и именно так оно сейчас и работает.
А что насчет всяких фильтрующих и DSP алгоритмов? Могут возникнуть какие-либо высокочастотные осцилляции или будет ли такой джиттер влиять на всякие преобразования Фурье? В принципе перед медленными фильтрами и алгоритмами, которые не требуют высоких частот выборок, у нас везде стоят антиалиазинговые фильтры. Они убирают джиттер или он им мешает?
Наверное, самый простой вопрос, нужно ли бороться с джиттером - это 3-х фазные измерения токов, напряжений и мощности. В этом случае стоит иметь полностью синхронизированные семплы от разных фаз. Но эти измерения имеют очень низкую скорость, что похоже им тот джиттер должен быть пофиг. Да и итоговая рассинхронизация между разными АЦП никогда не превышает 1 семпл. Так надо ли?
Какое ваше мнение? Может из аудио кто посоветует?
-
MQTT умеете?
-
1 hour ago, FLPPotapov said:
Есть спрос на переупаковку батарей на 40кВт, сейчас прорабатываем этот вопрос, в сочетании с Chademo вопрос запаса хода решается.
Я как раз Вас хотел спросить, почему не занимаетесь. Вон есть товарищ, он аж 70кВтч в Лиф запихнул. 40кВтч для него уже пройденный этап, судя по другим видео. Ему бы с вами скооперироваться. Ведь почти рядом же.
-
1 hour ago, AlexandrY said:
Но уровня BSP у них нет.
А там вся соль. Этот уровень делают производители, либо Expresslogic по заказу.
И там открыват далеко не все.Сорри, но в том же VxWorks доступа к исходникам BSP тоже нет. И оно там неуправляемо от слова вообще и управляется не Windriver, а производителем самой платы. Не понимаю, где вы тут видите разницу с RPi.
И поверьте мне, как только ты пытаешься использовать тот TPM или включить Secure Boot вылазит столько багов в BSP, что производитель только и успевает их фиксить. Плата с большей пользовательской базой тут намного лучше.
А что Хакеры имеют с BSP? Это разве их уровень?
ПС помоему мы не заметили, как нас отделили в отдельную тему :-)
-
42 minutes ago, AlexandrY said:
Тут уже многократно повторяли что Azure RTOS это ThreadX, а там тотально все сертифицировано и TUV и UL. Я думал это уже все знают.
Сейчас как раз имеем в разработке шлюз на Azure RTOS в Azure IoT Hub.Ну вот смотрите, очередной ваш аргумент улетучивается.
QuoteПотом опенсорс взломать гораздо проще чем закрытый
Исходники Azure RTOS сейчас открыты для всех https://github.com/azure-rtos/threadx. Следовательно, исследовать и найти в них уязвимости может любой хакер, также как и в опенсорс. Зачем же вы ее используете? И вообще зачем мелкомягкие выложили их в открытый доступ, если это был такой хороший proprietary и сертифицированный код?
-
12 hours ago, AlexandrY said:
Вообщем достаточно отбросить иллюзию о 400 честных и бескорыстных мантайнерах, как вся ваша логика по поводу опенсорса рушится.
Ну логика о том, что проприетарный софт лучше тестируется или поддерживается тоже заслуживает критики. Вы же не знаете сколько там программистов крутится и сколько незакрытых баг-репортов? А сертифицированный код - ну это вы серьезно такой используете и покупали на него лицензию или тоже теоретизируете?
Но вопрос был не об этом, а о том, что с точки зрения кибербезопасности надо смотреть на риски, а не сразу констатировать - это лучше, а это хуже.
-
1 hour ago, AlexandrY said:
Про это тоже была недавно новость - https://habr.com/ru/company/digital-ecosystems/blog/522364/
Т.е. все эти 400 пар глаз мало чего стоят.Можете обьяснить, как вы на основе этой новости делаете такой вывод?
-
29 minutes ago, AlexandrY said:
Забавное суждение о кибербезопасности.
Ее невозможно понимать в смысле знать, как невозможно знать все исходники и алгоритмы.
За ней можно только следить.Ну я кой-какие курсы заканчивал. И там объясняли, что за кибербезопаснотью нельзя просто следить. Это наука о минимизации рисков и их последствий, в которой в первую очередь надо смотреть на возможности для атак, оценивать риски, а потом рассказывали как минимизировать возможность их наступления, или ущерба от них или увеличивать возможность их обнаружения.
Как пример, вот Вы рассказываете байки про всякие исходники, Open-Source, встраиваемый Линукс и т.д. А Cybersecurity експерт что говорит? Он говорит: "Ок, opensource использовать надо, так как без него уже невозможно сделать нормальную разработку за нормальные деньги и сроки. Но можно ли уменьшить Cybersecurity риски, если используешь Open-source? Есть ли разница между Open Source Проектом А и Open Source проектом Б с точки зрения кибер-безопасности? А она есть. Например проект А имеет 400 меинтейнеров и регулярные коммиты, а проект Б - всего 10 и коммит раз в полгода. Вопрос: в каком проекте будут быстрее находиться и устраняться уязвимости и патчи появляться быстрее? В проекте А, конечно. Ведь там код просматривается 400-ми пар глаз и шанс увидеть уязвимость многократно возрастает. А теперь вопрос 3 на засыпку - есть не-опенсоурс проект C, альтернатива A и Б, платный, но фирма не такая уж большая и не очень понятно, кто этот проект использует. Будет ли он лучше с точки зрения Cybersecurity, чем проект А? "
29 minutes ago, AlexandrY said:Вы ж RPi взяли именно для того чтобы меньше знать что там внутри. Не так ли? Причем в ущерб всем остальным параметрам.
Где тут грамотность? Просто подняли риски ну или стоимость владения.
Нет. Взял потому, что оценил риски и понял, что на данном этапе разработки ущерб от них несущественен. А потом их можно будет закрыть тем или иным способом.
-
On 10/7/2020 at 5:14 PM, AlexandrY said:
Т.е. в моем случае уровень слепого доверия гораздо меньше чем в вашем.
Нет смысла обсуждать, что лучше а что хуже. В каждом способе есть свои недостатки и преимущества с точки зрения Cybersecurity. Важно их понимать и грамотно использовать.
-
8 hours ago, AlexandrY said:
Я беру HUAWEI E5576-320 4G и ложу его туда где лучше сигнал, а не где находится хост и продолжаю работать через WiFi.
Вы говорите о том, как все любят хакать из сети и тут же оставляете такую жирную завлекаловку в виде Wi-Fi. Класс
-
26 minutes ago, AlexandrY said:
Вот к примеру совсем недавно настала необходимость апгрейдить фирмваре в WiFi модулях.
А уязвимость была вот эта - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9502
Как видите все просто. Захватывают управление вашим WiFi модулем и привет.Ну значит WiFi пропустим и перейдем сразу к 3G/4G
. Заказал себе Huawei E3372 и буду прикручивать его к RPi для выхода в Инет. Если получится, то в скорости поставлю на объект для полевых испытаний.
Возиться с Google IoT не хочется, подключу его, наверное к какому нибудь облачному брокеру типа CloudMQTT, да начну мониторить понемножку. -
On 10/5/2020 at 11:41 AM, AlexandrY said:
А я тем временем посмотрел что из себя Zephyr представляет. Все же нет. Это слишком корявая платформа.
Она еще не скоро станет юзабельной.
Для сборки и компиляции требует строго линукса, но BSP для большинства плат ограничивается UART-ом и прочей мелкой периферией. Эт не серьезно.
Использованием аппаратного security там еще и не пахнет.Как же быстро вы опустились на землю со своего утверждения:
On 10/1/2020 at 4:31 PM, AlexandrY said:Уже сейчас на зефире можно сделать все что требуется для связи с облаками.
У меня все же сейчас другие мысли по поводу кибербезопасности: Просто паранойя по этому поводу уже заходит так далеко, что скоро придется шифровать CAN и RS485 трафик, так как очумелые ручки доморощенных IoTишников уже залазят и туда. Да что там - ведь хакнуть железяку можно даже через какой-нибудь пин, который вдруг окажется 1-wire enabled.
У меня уже сейчас спрашивают насчет шифрования реалтаймового трафика по процессинговой шине - я говорю - ну да, давайте пропишем ключи, будем все шифровать, только от перформанса там ничего не останется и отладка будет просто замечательной.
Поэтому пока у меня простая позиция: защиту от хакинга при физическом доступе к железяке делать я пока делать не буду. Пусть этим пока занимаются другие, которым надо защищаться от всяких джейлбрейков и очумелых пользователей, сующих левые прошивки в автопилоты и т.д. У меня пока защита будет только от облачного доступа.
4 hours ago, AlexandrY said:И вот как геймифицировать разработку умного дома с ПЛК?
А просто. Ставит ПЛК от Wago, а на фоновый линуксовый юзерспейс Wago накатывает Azure IoT SDK.
Получает и защищенность наследованную от железа Wago и доступ к облачным сервисам.Зачем так сложно? Harmony iPC от Шнайдера уже включает в себя Node-Red. Соединяешь кликами и подключаешься к любым облакам. И заметьте, с кибербезопасностью там тоже все ОК.
Причем необязательно сразу брать индустриальное железо - можно поиграться и отладить все на том же дешевом RPi, а потом перенести весь свой код за пару часов. А то получается, что гейминг должен быть дорогим.
-
On 10/2/2020 at 7:06 PM, AlexandrY said:
Вот подписался на Google IoT Сore. Дают сразу 300$ кредита.
Вроде все имеет для управления асетами, позволяет выделять юзерам группы управления ассетами, иерархическая схема прав доступа, раздельный биллинг и т.д.
Где вы видите там проблему требующую кучу программистов?Ну так я про такие вещи и спрашивал. Счас посмотрю, прикину, сколько ей программистов надо :-)
On 10/2/2020 at 7:06 PM, AlexandrY said:Защищенная эт где платформа имеет как минимум:
TPM к RPi прикрутить вроде можно. Насчет второго не уверен, что вообще нужно сильно заморачиваться, так как скорей всего в 80% железяк, что сейчас работают в IoT, такого нет.
-
On 9/30/2020 at 3:51 PM, yes said:
мне нужно для моделирования АЗИКа - то есть трансиверы, память и прочее на плате (кроме питания :) не нужно. наверно, по частоте/констрейнам в этот раз придется выжимать побольше, но это не жесткий параметр, а чтобы сразу софт писать похожий на боевой, а не с 1/10 железа работающий
FMC нужен, чтобы свою железку подключить, и я смотрю Интел от альтеровского интерфейса отказался и перешел на ксайлинский? или это только разъемы одинаковые?
производства своих плат с этими ПЛИС не будет
А если отказаться от железа, не пойдет облачный вариант вместо платы? Вроде и те и другие что-то такое предлагают. Дешевле платы, наверное, выйдет?
-
TE MTA Series - похоже на то, что у вас на первой картинке
Но там шаг от 2,54мм. На 1мм я таких не встречал. Мы их используем с родным инструментом. Обжимаются легко, но чувствительны к качественному проводу. Там не одновременная обжимка всех проводов и в этом их преимущество перед классическими IDC. Проводки зажимаются по одному и необязательно в определенном порядке.
Но вообще, если объемы серьезные, то надо задумываться о нормальном оборудовании. Есть машинки, которые обожмут ваши JST легко, только стоят они от 20k$. Или заказывать готовые кабели у тех, кто имеет такие машинки.
-
4 hours ago, AlexandrY said:
Опираясь на незащищенную платформу вы вдобавок ограничиваете себя в выборе.
Что значит защищенная или незащищенная платформа? На каких критериях это строится? RPi взломать проще, чем любую другую линуксоидную машину? Читаю, что 50% покупателей RPi - коммерция. И все эти вендинговые автоматы и прочие штуки внутри имеют гейтвеи на RPi и никто не жалуется.
4 hours ago, AlexandrY said:Уже сейчас на зефире можно сделать все что требуется для связи с облаками.
Уже ж обсуждали. На платформе Х (выбрать AWX, Predix, Zephir и или любую другую по желанию) можно сделать все, что угодно, если у тебя есть деньги на 10 программистов. Если нет, то выбор очень ограничен и можно только теоретизировать на форуме или тупо делать на том, что допилено и работает из коробки.
-
17 hours ago, AlexandrY said:
Вчера CODESYS прислал сообщение что их CODESYS Automation Server будет бесплатен до нового года.
Чем вам этот сервер не подходит? Он же и вузуализацию, как утверждается, показывает.
И прям родной для вашей экоситемы. Как раз позавчера запустил и попробовал.
Штука, конечно, для ПЛК отличная - и визуализация работает и удаленная отладка, но у меня на самом деле экосистема на ПЛК довольно маленькая - домашняя автоматизация, да пара тестовых стендов. Я спрашивал у Codesys сколько стоит портировать их рантайм под свой МК - от 10к$ + роялти за устройства + годовая поддержка. Для проектов, где софт очень стабилен и разрабатывается один раз, не выгодно. Поэтому для 1000+ девайсов не подойдет.
17 hours ago, AlexandrY said:Можете сколько угодно говорить о маленькой вероятности, но без навороченной защиты коммерческие перспективы нулевые.
Да и конкуренты смеяться будутПосмотрим. У конкурентов навряд-ли будет технология лучше - монстры с огромными R&D ресурсами, готовые вбахивать миллионы в этот рынок, в Украину просто не суются.
-
Quote
У меня та же самая проблема. Тоже тысячи объектов.
Общее надежное решение пока найти не удается. Представить логи как услугу для клиента очень сложно.
Расчитать выгоду от предиктивной поддержки проблематично.
Рисеч вообще никто за деятельность не считает.
Нужно иметь пилотный проект без серьезных инвестиций, но в реальном глобальном окружении.В принципе я не пытаюсь делать из этого "дойную корову" - основной заработок все-таки в управляющих изделиях. Поэтому все будет в рамках пилотных проектов и если кто-то предложит систему мониторинга получше, я с радостью от этой затеи откажусь.
15 hours ago, AlexandrY said:То что вы там пытаетесь что-то делать на RPi для массового потребителя просто не серьезно.
Где вы будете держать секретные ключи, как их будете врапить (типа уникально шифровать), как собираетесь защищать программный код, как защищать от клонирования?
Ломать то будут не конечную железку, а ваш RPi. А потом будут в даркнете продавать дырки от ваших RPi и делать из них ботнеты.Серьезные решения от облачных провайдеров предполагают установку агентов безопасности на сами конечные дивайсы. Одни только встроенные агенты могут создать гигантские логи для своих аналитических серверов. Ломать же будут и ваш шлюз в облаках, и даже наверно интенсивней всего. Его тоже надо охранять от фэйковых дивайсов.
А я не такой скептик, как вы. Если бы все было так плохо, то всякие амазоновские умные колонки, видеокамеры и прочие гаджеты для умных домов уже давно бы превратились в армии ботнетов. Но пока я вижу только единичные случаи и особого прогресса нет. Даже в условиях информационных войн и сплошных дырок в промышленных СКАДА системах, никто не спешит их взламывать, хотя там профит очень значительный. Значит большая вероятность, что мои RPi и серверы как те неуловимые Джо - нахер никому, кроме меня, не нужны.
Агенты я как раз тоже встречал именно для RPi и прочих Линуксовских платформ. Потому что разделять критический реал-тайм и облачную коммуникацию все равно надо, и легче всего это сделать отдельной физической железякой, чем мутить всякие дорогие, недопиленные и уязвимые гипервизоры. Удешевлять железо до минимума мне, слава богу, еще не нужно
Бесплатно сделаю расчёт Вашей модели в среде COMSOL Multiphysics®
в Вопросы системного уровня проектирования
Опубликовано · Пожаловаться
А можно ли в COMSOL Multiphysics моделировать движение обтекаемого объекта в водной среде?