Русский
Русский
English
Статистика
Реклама

Интернет вещей

Белогривые лошадки. Как облачные технологии меняют мир

26.04.2021 12:16:37 | Автор: admin


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

Облачный софт


Когда в октябре 2006 года корпорация Google анонсировала запуск сервиса Google Docs, а спустя пять лет к ним подтянулась Microsoft со своим Office 365 по подписке, лично я воспринял появление этих новинок с некоторым скепсисом. С одной стороны, подобная модель SAAS позволяет избавиться от необходимости устанавливать софт на свой компьютер, экономя тем самым дисковое пространство. Да и самим софтом можно пользоваться на любой, даже довольно слабой машине, с любой архитектурой и операционной системой для работы с Документами от Google вообще требуется только браузер. С другой стороны, устройство должно иметь стабильное соединение с интернетом, причем на приличной скорости, что и стало основной причиной моих сомнений. У нас тут всё-таки не Сингапур, и если в обеих столицах с доступом к сети все более-менее в порядке, то стоит отъехать от кольцевой автодороги на сотню километров В общем, вы поняли.

Однако за минувшее десятилетие широкая поступь технического прогресса добралась до весьма отдалённых уголков нашей необъятной страны. Даже в деревне, где мы с семьёй проводим лето, и где еще пару лет назад можно было проверить почту, лишь забравшись с мобильником на самую высокую березу, сейчас вполне уверенно принимается сигнал 3G. В заграничных поездках жизнь тоже стала потихоньку налаживаться: бесплатный wi-fi для постояльцев теперь можно найти даже в паршивых трех звездах, пусть только на ресепшен, но тем не менее. Да и сами сервисы активно развиваются: те же гугловские Таблицы давным-давно научились работать с формулами, и, хотя пока еще уступают по своим возможностям Excel, скоро наверняка догонят средств у разработчика для этого вполне достаточно. Скорее всего, даже опередят. Ко всему прочему, именно облачность Таблиц позволяет использовать их в качестве базы данных для интернет-магазина, бекэнда для веб-приложений, и даже в целях фишинга.

Еще один интересный проект, с которым я познакомился некоторое время назад это новая мелодия на мотив Chromium OS под названием Cloud Ready. Операционка, представляющая собой по большому счету ядро Linux с браузером, а для всего остального функционала использующая облачные сервисы, позволила изрядно взбодрить один из моих старых ноутбуков, который с трудом тянул даже Xubuntu. Быстрая загрузка, вполне современный графический интерфейс, минимально необходимый набор софта (включающий те же самые Документы Google) и довольно шустрая работа на древнем, как бивень мамонта, железе что еще нужно для просмотра котиков в интернете и работы с текстами?



Не знаю, как у вас, а лично у меня уже почти не осталось сомнений в том, что очень скоро большинство приложений и игрушек окончательно мигрируют в облака. Во-первых, это снизит расходы на железо, поскольку с облачным софтом можно довольно уверенно работать почти на любом устройстве, включая планшеты и смартфоны, под которые далеко не всегда можно подобрать адекватные офисные приложения. Во-вторых это простота переноса пользовательских данных. Меня до сих пор поражает, насколько эффективно эту проблему решила Apple в iOS, в сравнении с тем же Android, где мне приходилось изрядно помучиться, чтобы перетащить информацию со старого телефона на новый. Думаю, недалек тот момент, когда и в прочих операционках после первого запуска и входа в аккаунт все пользовательские файлы, установленные программы, драйверы, почта, фотки, сохраненные игры и переписка в мессенджерах будут подтягиваться автоматически разработчики Windows 10 уже сейчас пытаются это реализовать с помощью учетной записи Microsoft в сочетании с OneDrive. Работает, правда, пока еще кривовато, но вектор в целом понятен.

Интернет вещей


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

Выше мы говорили о модели SaaS софт как услуга, но существуют еще две категории облачных решений: платформа как услуга (PaaS), и инфраструктура как услуга (IaaS), когда клиенту предоставляется все необходимое для разработки и запуска собственных решений на разном уровне. Именно развитие подобных сервисов, думается, и позволит в не столь уж отдаленном будущем полностью перенести бекэнд IoT-приложений в облака, оставив на самом устройстве только необходимый минимум софта не требовательного к аппаратным ресурсам и способного запускаться на очень слабом дешевом железе. Примерно так, например, сейчас работают многие IP-камеры: само устройство только создает и передает по сети картинку, а все настройки девайса, да и собственно видео доступны на удаленном облачном сервере. Такой подход позволит сделать большинство IoT-приложений кроссплатформенными и практически полностью решить проблемы, связанные с поддержкой разных аппаратных конфигураций и разных протоколов, а также объединить различные устройства и датчики с универсальными мобильными приложениями то есть, строить сложные гетерогенные сети, не беспокоясь о поддержке их отдельных компонентов. Кроме того, облачные архитектуры легко масштабируемы. Примечательно, что подобные решения существуют уже сейчас, просто на данном этапе они пока еще не обрели популярность, достаточную для конкуренции с более успешными коммерческими проектами.


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

Большинство решений из мира IoT, включая пресловутый умный дом, требуют анализа больших массивов информации, в том числе, исторических данных, а также предполагают выявление закономерностей для построения сценариев поведения оборудования в будущем. С помощью облачных вычислений можно заметно разгрузить оборудование на стороне пользователя. Извлечение полезной информации из сложных потоковых данных, таких как видео, еще один пример анализа, требующего большого объема обработки. И эти объемы со временем будут только расти. Растет потребность в обработке данных из различных источников в разных сочетаниях, требуется проводить их сравнительный и эвристический анализ. Нельзя забывать, что системы IoT это системы реального времени, в которых поток информации поступает из множества источников непрерывно, и для управления этими потоками необходимы соответствующие ресурсы. Нужно оперативно отсеивать недостоверную информацию, поступающую от неисправных датчиков, поскольку такие данные могут привести в конечном итоге к повреждению оборудования или нанести вред пользователю. Кроме того, всю эту бигдату нужно где-то хранить. Облака тут являются фактически безальтернативным решением, но оно, конечно, имеет и собственный набор узких мест.

Проблемы и решения


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

Очевидным решением тут является переход от монолита к микросервисной архитектуре. Использование микросервисов гарантирует масштабируемость, гибкость, а также возможность модификации под новые задачи и обновления серверных решений без необходимости полностью останавливать процесс обработки данных. Собственно, сегодня уже мало кто сомневается, что управляемые микросервисы это перспективная технология, позволяющая справиться с наиболее сложными задачами в мире больших данных.



Второй проблемой переноса обработки данных в облако может стать, как ни странно, связанность. Какие-либо проблемы на уровне публичных или магистральных сетей способны привести к сбоям в передаче информации между конечными устройствами и облачным сервером. Еще несколько лет назад блокировки отдельных ресурсов провайдерами по требованию российских контролирующих органов приводили к периодическим проблемам при обращении к сервисам Amazon Cloud и Microsoft Azure. И застраховаться от подобных явлений, увы, очень сложно. Одно из очевидных решений резервирование каналов связи и использование сторонних NS-служб не может служить стопроцентной гарантией, что система будет работать без сбоев.

Сейчас в дополнение к облачным технологиям понемногу развивается концепция так называемых туманных вычислений (Fog Computing), которые считаются более эффективными при обработке данных в реальном времени. Это действительно очень важно, поскольку, согласно прогнозам IDC, к 2024 году количество конечных устройств в сетях IoT достигнет по всему миру 41,6 миллиарда, а совокупный объем генерируемого ими трафика составит 79,4 зеттабайт. Однако одними только вычислительными мощностями, потребными для обработки таких массивов данных, сложности облачного интернета вещей не ограничиваются.

Вопросы безопасности


Что такое Shodan, знают, наверное, все. Подобных сервисов, предназначенных для поиска подключенных к интернету умных устройств, сейчас развелось уже довольно много и хакеры активно используют их в своих интересах. Поэтому промежуточное звено между конечными устройствами интернета вещей и облачным центром обработки данных в виде публичных сетей может стать той самой ахиллесовой пятой, которая поставит под угрозу безопасность всей инфраструктуры. Шифрование тут может рассматриваться, как действенное рабочее решение, но вряд ли станет панацеей.



Хранение критических данных в облаке тоже вряд ли вызовет энтузиазм у поборников безопасности сообщения о взломах облачных сервисов мы читаем с завидной регулярностью. Как бы ни старались вендоры защитить виртуальные серверы и хранилища от различных видов атак, в любом софте рано или поздно может отыскаться критическая уязвимость, ведущая к компрометации. Да и защитить пользователя от себя самого вряд ли возможно.

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

И что потом?


Миграция сервисов в облака это неизбежный и неотвратимый процесс, но вместе с тем, не стоит рассматривать его, как конечную точку на маршруте технического прогресса. Перенос технологии в облако и переход к микросервисным архитектурам не приводит к автоматическому повышению производительности, росту общей эффективности или прибыли. Это прекрасный инструмент для оптимизации технологии, но не более того.

Если же вернуться к вопросу миграции в облака приложений, с которого я начал эту статью, то в условиях пандемии и национальных локдаунов, когда бизнес стремится к децентрализации, а рабочие места все чаще и чаще становятся удаленными, это стало актуальным, как никогда ранее. Думается, ориентация на облачные технологии во многом изменит сами подходы в разработке прикладного софта и рынок ПО в пользу модели SaaS с постепенным отходом от традиционных схем дистрибуции.

По данным crn.com, в 2021 году оборот глобального рынка облачных сервисов достиг отметки в 120 миллиардов долларов и продолжает уверенно расти. А по прогнозам аналитиков в следующем году рынок общедоступной облачной инфраструктуры расширится еще на 28 процентов. Данный сегмент технологий сейчас можно назвать одним из самых быстрорастущих, а значит, в ближайшем будущем мы сможем наблюдать переход в облака все большего и большего числа сервисов игровых, софтверных, коммуникационных и прочих. Таково наше будущее. И с этим ничего не поделать.

Подробнее..

Начинаем писать под stm8, выбираем среды разработки и стартуем

28.04.2021 12:07:29 | Автор: admin
image

На пути в программировании stm8 есть развилка, о ней сегодня и поговорим.

Определимся что речь будет идти о средах которые могут писать под си. Для начала поговорим о подходах, я выделю 2 основных.

Первый установка ST Visual Develop и выбор в качестве компилятора COSMIC Бывший платный, а ныне бесплатный, но со своими заморочками; регистрация, получение ключа, и прочие танцы с бубном.

Второй же вариант, более простой VS Code + PlatformIO и компилятор SDCC полностью свободный. И опять же не все так просто. Sdcc не умеет исключать не используемые функции. Я решил этот вопрос хоть и успешно, но не без дополнительных действий при написании кода.

Первая среда, для любителей всё делать правильно


Для начала нам нужен ST Visual Develop. Устанавливаем и ставим запуск ярлыка всегда от администратора. В придачу к нему нам дают ST Visual Programmer, полезный инструмент, особенно когда стоит защита от записи и надо разблокировать микроконтроллер, а ведь китайские blue pill всегда приходят заблокированными. Китайцы бояться что мы украдём их круто оптимизированный Blink.

Вот так выглядит STVD
image
Я так понял её создали, когда в моде были 16 битные цвета...

Дальше нужно будет получить компилятор COSMIC и его лицензионный ключ. Заполняем то что просят, получаем дистрибутив и делаем запрос ключа по электронной почте (тут рулетка кому то сразу придёт, кому то придётся подождать).

После пройденного лабиринта из форм и запросов, когда всё уже установлено, начнём
image
image
При первом запуске нужно указать расположение ключа, его лучше поместить в директорию компилятора. После создания нажимаем F7, ошибок быть не должно. Если писать на чистых регистрах, то всё готово, но я такой хардкор не люблю, поэтому продолжим и добавим SPL библиотеку.

Распакуем куда-нибудь и заходим в папку STM8S_StdPeriph_Lib\Project\STM8S_StdPeriph_Template. Тут у нас шаблон проекта stm8s_conf.h это конфигурационный файл библиотеки, через него выбирается контроллер. Зайдём в main тут сразу с первых строк #include "stm8s.h" это ссылка на основную библиотеку, а так же кусок кода отладки который начинается с #ifdef USE_FULL_ASSERT, без отладочного кода будут сыпаться ошибки.

Теперь когда мы прошлись по верхам давайте пробовать запускать библиотеку. Добавляем в проект из шаблона main и конфигурационный файл в. В include files добавляем всё из STM8S_StdPeriph_Lib\Libraries\STM8S_StdPeriph_Driver\inc.
image
Теперь всё должно собраться.

Добавим stm8s_gpio.c и соберём простецкую мигалку. У меня один из светодиодов висит на D3, конфигурация ноги на выход выглядит так:

GPIO_DeInit(GPIOD);GPIO_Init(GPIOD, GPIO_PIN_3, GPIO_MODE_OUT_PP_LOW_SLOW);

Её вписываем в main до бесконечного цикла.

А вот функция смены состояния. GPIO_WriteReverse(GPIOD, GPIO_PIN_3); вписываем её в бесконечный цикл.

Но вот незадача, в SPL нету функций задержки, скопипастим из примера GPIO в библиотеке. Там она выглядит следующим образом.

void Delay(uint16_t nCount){  /* Decrement nCount value */  while (nCount != 0)  {    nCount--;  }}

Впишем её в конец перед #ifdef USE_FULL_ASSERT. Так же впишем её прототип в начало, где под это выделено место в шаблонном main.

/* Private function prototypes -----------------------------------------------*/void Delay (uint16_t nCount);

Ну и наконец впишем функцию со значением в бесконечный цикл после функции смены состояния: Delay(0xFFFF);

Подключаем ST-Link и прошиваем, для этого нажимаем Start Debugging и Run. Светодиод моргает значит всё хорошо.

У кого не получилось вот полный main.c
/**  ******************************************************************************  * @file    Project/main.c   * @author  MCD Application Team  * @version V2.3.0  * @date    16-June-2017  * @brief   Main program body   ******************************************************************************  * @attention  *  * <h2><center> COPYRIGHT 2014 STMicroelectronics</center></h2>  *  * Licensed under MCD-ST Liberty SW License Agreement V2, (the "License");  * You may not use this file except in compliance with the License.  * You may obtain a copy of the License at:  *  *        http://www.st.com/software_license_agreement_liberty_v2  *  * Unless required by applicable law or agreed to in writing, software   * distributed under the License is distributed on an "AS IS" BASIS,   * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.  * See the License for the specific language governing permissions and  * limitations under the License.  *  ******************************************************************************  */ /* Includes ------------------------------------------------------------------*/#include "stm8s.h"/* Private defines -----------------------------------------------------------*//* Private function prototypes -----------------------------------------------*/void Delay (uint16_t nCount);/* Private functions ---------------------------------------------------------*/void main(void){GPIO_DeInit(GPIOD);GPIO_Init(GPIOD, GPIO_PIN_3, GPIO_MODE_OUT_PP_LOW_SLOW);  /* Infinite loop */  while (1)  {GPIO_WriteReverse(GPIOD, GPIO_PIN_3);    Delay(0xFFFF);  }  }void Delay(uint16_t nCount){  /* Decrement nCount value */  while (nCount != 0)  {    nCount--;  }}#ifdef USE_FULL_ASSERT/**  * @brief  Reports the name of the source file and the source line number  *   where the assert_param error has occurred.  * @param file: pointer to the source file name  * @param line: assert_param error line source number  * @retval : None  */void assert_failed(u8* file, u32 line){   /* User can add his own implementation to report the file name and line number,     ex: printf("Wrong parameters value: file %s on line %d\r\n", file, line) */  /* Infinite loop */  while (1)  {  }}#endif/************************ (C) COPYRIGHT STMicroelectronics *****END OF FILE****/


Теперь посмотрим со стороны на эту среду.

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

Вторая среда, для тех кто не любит заморачиваться.


Второй подход это свободный и обновляемый компилятор SDCC, а так же среда PlatformIO.

Для начала установим VS Code и станем рабами Microsoft, далее найдём расширение PlatformIO.

image

Ждём пока миллион ползунков пройдёт до конца и перезапускаем программу. Открываем расширение (может быть и само откроется). Создаём новый проект и выбираем ближайшую плату с stm8s (микроконтроллер можно будет изменить в конфигурационном файле). В качестве фреймворка выбираем SPL мы же не ардуинщики, нас интересует хардкор.

Не удивляйтесь, проект будет создаваться прилично долго, потому как он на ходу будет подгружать компилятор, библиотеки и тд. И вот перед нами возник девственно голый проект, закрываем его он нам больше не нужен. В меню где мы создавали проект, открываем пример spl-blink, суть в том что blink генерирует неплохой шаблон в котором можно сразу писать. Правим пример под себя и прошиваем, всё моргает.

Разберем поподробнее среду разработки. Во первых весь проект должен лежать в src, иначе среда ведёт себя неадекватно. Во вторых открываем stm8s_conf.h и видим что все библиотеки кроме GPIO закомментированы, если этого не сделать то у мк не хватит памяти что бы поместить весь SPL в микроконтроллер (помните в начале я говорил что он загружает все функции что видит в код?).

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

/* Private define ------------------------------------------------------------*/#define _GPIO_DeInit#define _GPIO_Init#define _GPIO_WriteReverse#define _CLK_DeInit#define _CLK_SYSCLKConfig#define _TIM4_DeInit#define _TIM4_ITConfig#define _TIM4_ClearITPendingBit#define _TIM4_Cmd#define _TIM4_TimeBaseInit#define _TIM4_ClearFlag#define _HAL_GPIO_WritePin#define _GPIO_WriteLow#define _GPIO_WriteHigh//#define STM8S003/* Includes ------------------------------------------------------------------*/#include "stm8s.h"/* Uncomment the line below to enable peripheral header file inclusion */#if defined(STM8S105) || defined(STM8S005) || defined(STM8S103) || defined(STM8S003) ||\    defined(STM8S001) || defined(STM8S903) || defined (STM8AF626x) || defined (STM8AF622x)// #include "stm8s_adc1.h" #endif /* (STM8S105) ||(STM8S103) || (STM8S001) || (STM8S903) || (STM8AF626x) */#if defined(STM8S208) || defined(STM8S207) || defined(STM8S007) || defined (STM8AF52Ax) ||\    defined (STM8AF62Ax)// #include "stm8s_adc2.h"


Каждую функцию я включаю через макрос, для этого у меня переписана большая часть SPL. Если вам оптимизация сильно не нужна, то такой упоротостью можете не заниматься.

Пройдёмся по преимуществам: работает почти из коробки, полностью бесплатно без попрошайничества, редакции языка обновляются и не придётся учить и переписывать код под си 80-90г. Сам интерфейс настраиваемый и намного приятнее. Для тех кто не любит win есть linux версия.

По минусам: нету полноценной отладки (над ней активно работают, но пока ничего приближённого к cosmic я не видел), в проекте небольшой хаос, раскидать по папкам пока нельзя.

Послевкусие.


Ну и на последок есть ещё среды, варианты и компиляторы, но либо это тот же SDCC вкрученный силой в Eclipse или ещё куда и работающий хуже чем в VS Code, либо это платные варианты IAR, Raisonance. Я лично пользуюсь и тем и тем, но чаще VS Code. Рекомендовать ничего не буду каждому своё, увидимся в комментариях)

Подробнее..

Интервью с менеджером проектов АСУ цифровизация, интернет вещей и умные города

19.05.2021 20:18:09 | Автор: admin

Что такое умные" города, цифровизация и интернет вещей? Какая роль в веке высоких технологий и искусственного интеллекта отведена программистам? Специально для школы Пиксель на эти вопросы и не только ответил менеджер ключевых проектов компании Schneider Electric Андрей Биневский.

Расскажи о своей работе чем ты занимаешься, связана ли твоя работа прямо или косвенно с программированием?

Я работаю менеджером ключевых проектов автоматизированных систем управления электроснабжения (АСУ) в компании Schneider Electric. Это крупный мировой вендер электрооборудования. Моя работа с программированием связана скорее косвенно, потому что я руковожу проектами программирования, я продаю проекты, в которых трудятся программисты, поскольку ни одна умная система не может быть организована без кодинга, без труда инженеров и программистов.

Что такое автоматизированные системы управления электроснабжения (АСУ)? Расскажи подробнее.

Существуют различный подход к системам энергоснабжения. Вообще, что такое энергия? Энергия это не только электричество, это еще вода, газ, тепло, пар. Для того чтобы генерировать пар нужна вода и газ, или вода и электричество, чтобы генерировать горячую воду нужна и вода, и электричество. И для каждой бытовой или технологической задачи нужно подобрать оптимальные варианты для реализации энергоресурсов. Мы не должны избыточно генерировать тепло, не должны создавать слишком много теплой воды, чтобы потом сливать ее в канализацию. Нужно найти тот симбиоз между необходимым количеством энергоресурсов и создаваемым количеством. Этот симбиоз и называет энергоэффективностью. То есть все системы должны быть энергоэффективными.

Дом с солнечными батареями на крышеДом с солнечными батареями на крыше

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

Создание этих энергоэффективных зданий и систем, управление этими энергоэффективными системами и есть основная задача, которая стоит перед строителями и инженерами 21 века. Все, что сейчас строится и создается, должно быть максимально энергоэффективно, потому что мы уже понимаем, что часть наших ресурсов является невосполнимой.

Для настройки этих систем нужны программисты?

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

Расскажи про свой первый опыт общения с компьютерами. Помнишь свою любимую компьютерную игру?

Моя первая и любимая компьютерная игра была Цивилизация. Я на тот момент был учеником начальной школы, и я столкнулся с тем, что игру можно классно организовать не только за счет своей фантазии, но и за счет возможностей самой игры. Я играл ночами, когда все ложились спать. Я побеждал Российскую империю, Индию, Ацтеков каких-нибудь, США.

Тебе захотелось потом научиться программированию?

У меня не было достаточного набора качеств для того, чтобы стать программистом. Я был слишком взбалмошным и активным, чтобы иметь возможность отключиться от внешнего мира и заниматься кодингом. Но я понимал, чем могу быть полезным этим людям, как могу стать эдаким мостом между ними и внешним миром.

Был у меня опыт по взаимодействию с аналитиками по созданию системы контроля и учета для школьников и родителей, так называемые онлайн-дневники. Был у меня опыт по кодингу в средах Паскаль, Делфи. Сейчас это мертвый и неприменимый опыт, но тогда он нужен был для того, чтобы просто понять основные положения алгоритмики и труда программистов.

Как ты считаешь программист это профессия будущего?

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

Чем дальше мы будем развиваться, тем меньше рутинной работы будут выполнять люди, тем ценнее будут специалисты, которые способны грамотно расписать задачу и перевести идею в список реализуемых дел.

Кем еще могут быть программисты, кроме того, что они могут создавать сайты и приложения? Развей мифы.

Программисты применимы везде. Они это наш проводник между нами и роботами, между тем, что может выполнять код или какой-нибудь алгоритм, и его заказчиком.

Какие города считаются умными?

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

Концепция "умного" городаКонцепция "умного" города

В России есть Иннополис в Татарстане, которые является российской Кремниевой долиной. Он построен по принципам энергоэффективности, но и там есть много нюансов. Даже сама Кремневая долина вызывает множество вопросов по расходованию энергоресурсов.

Иннополис в ТатарстанеИннополис в Татарстане

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

Что такое цифровизация?

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

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

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

И когда мы будем удивляться тому, что у нет света или воды, то это будет означать, что мы существенно шагнули вперед в цифровую эру энергоснабжения.

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

И когда мы будем знать, что мы абсолютно обеспечены энергоресурсам, что не бывает такого, что нет воды, газа, тепла, тогда и наступит цифровая эра, которую мы абсолютно не заметим.

Что такое интернет вещей? Максимально просто.

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

То есть существует какая-либо система, мы в нее добавляем новое устройство, далее можем его интегрировать в систему без колоссальной ее переработки. Условно, существует труба и в ней есть расходомеры, которые измеряют, сколько прошло по ней жидкости. Сигнал из этого расходомера мы можем перегнать по GPRS и дистанционно узнать расход жидкости в этой трубе.

Концепция "умного" домаКонцепция "умного" дома

Простой пример. У вас есть загородный дом площадью 120 квадратных метров. Летом вы туда ездите постоянно, а зимой иногда на выходные. И когда вы приезжаете туда зимой, дом остывает и требуется пару часов, чтобы его прогреть. А если бы ваш дом был построен в соответствии с философией интернета вещей, этого бы не происходило. Вы могли бы дистанционно включить обогрев хоть электрический, хоть газовый, наружное освещение перед своим приездом, и при помощи телефона открыть ворота в гараж и зайти в теплый светлый дом. Но когда вас там нет, энергоресурсы на его отопление не расходуются. Система автоматически поддерживает оптимальную температуру, например, +5, когда за окном -30. Человеку здесь будет некомфортно, но все механизмы будут работать.

То, что ты описываешь похоже на умный дом.

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

Следующий вопрос творческий. Представь, что ты министр образования любой страны. Твоя задача повысить интеллектуальный уровень дошкольников и школьников. Какие бы предметы и дисциплины ты сделал обязательными и важными, а какие и вовсе убрали.

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

Возможно я бы уменьшил часы по русскому и литературе. Не потому что мне это не нравится, а потому что наша литература так или иначе отражает нашу историю. Перечень тех книг, которые проходили в 1985 году и, например, в 2000 году, существенно разнятся, хотя здесь разница всего 1-2 поколения.

Я бы сделал упор на том, чтобы наши школьники выпускались логичными людьми, имели базовые представления о естественных науках и о тех требованиях гражданского общества, которые мы им предъявляем. И конечно, чтобы они были физически здоровыми.

У тебя есть дети, сколько им лет? Ты отдал бы их в программирование?

У меня есть дочь, ей почти 5 лет. Да отдал бы, но при условии, что она параллельно будет заниматься каким-нибудь спортом. Уходит стереотип, что программист это бледный неспортивный парень в очках. Сейчас это и парни, и девушки, которые хорошо зарабатывают, стильно одеваются, правильно питаются и могут позволить себе личного фитнес-тренера. Посмотрите на Павла Дурова.

Дети на занятиях по робототехнике в школе "Пиксель"Дети на занятиях по робототехнике в школе "Пиксель"

Как бы ты выбирал школу для обучения программированию?

Самое главное в любой школе, не только в школе программирования, это преподаватели. Я бы выбрал школу, где преподаватели любят свое дело, любят детей, и дают много практики. Обучение не должно быть похоже на заучивание, в первую очередь нужно научиться понимать. Понимание приходит через часы самостоятельной практики.

Справка. Чаще всего менеджеры АСУ вырастают из технических специальностей, таких как системные администраторы, наладчики оборудования, инженеры-электрики, инженеры-автоматчики и т.д. Зарплата специалиста чаще всего состоит из оклада и премии за выполнение плана. Средний размер оклада менеджеров АСУ в Москве по данным hh.ru от 100 тыс.руб.

Подробнее..

Топ-50 мировых лидеров Интернета вещей 2021 гаджеты, софт и сервисы

29.04.2021 00:23:42 | Автор: admin

Персональный компьютер Lenovo ThinkCentre M75n на процессоре AMD Ryzen 5 PRO

Журнал Computer Reseller News (CRN) ежегодно составляет рейтинг Internet of Things 50, выбирая полсотни самых крутых игроков индустрии на данный момент.

Свежий рейтинг 2021 года составлен по пяти категориям:


10 самых крутых производителей оборудования


По прогнозу Gartner, количество устройств IoT в мире вырастет до 5,8 млрд на конец текущего года. Очевидно, производителям сейчас нелегко в условиях глобального дефицита микросхем на всех рынках.

Здесь и далее рядом с названиями компаний приводятся примеры последних продуктов и технических достижений, за которые они удостоились чести попадания в рейтинг. Списки составлены в алфавитном порядке.

  • Advantech (Тайвань), специализированное оборудование: от киосков самообслуживания до систем машинного зрения для заводов
  • AMD, линейка встроенных процессоров Ryzen Embedded V2000
  • Cisco Systems (США), расширение функциональности AWS IoT Core
  • Dell Technologies
  • Hewlett Packard Enterprise
  • Intel, функция Intel Time Coordinated Computing в последних CPU, а также линейка процессоров Atom x6000E
  • Lenovo, компьютер ThinkCentre M75n IoT (на КДПВ), встроенные компьютеры ThinkEdge SE30 и SE50
  • Nvidia, система-на-кристалле Jetson Xavier NX
  • Qualcomm, модем Qualcomm 212 LTE для сетей NB-IoT
  • Supermicro, платформа Intelligent Retail Edge


10 самых крутых софтверных компаний


  • Akamai, сервис IoT Edge Connect на базе фирменной CDN
  • Amazon Web Services, ряд новых сервисов, в том числе управляемый сервис AWS IoT SiteWise для сбора и мониторинга данных с промышленного оборудования, а также AWS Snowcone и Amazon Monitron
  • Edgeworx, платформа ioFog для деплоя микросервисов на различные типы устройств в различных сетях (Kubernetes для IoT), а также видеокамера Darcy с машинным зрением и автоматической проверкой наличия масок на людях, среди прочих функций
  • EDJX, глобальная инфраструктура IoT в масштабе планеты
  • IOTech (Великобритания), опенсорсная платформа EdgeXpert
  • Kloudspot, корпоративная система наблюдения QuickStart (Situational Awareness and Intelligence Platform)
  • Microsoft, покупка стартапа CyberX (безопасность IoT), расширение функций Azure IoT, система Azure Digital Twins для цифрового моделирования объектов реального мира
  • Nubix, встроенные приложения с поддержкой контейнеров на устройствах под Linux с ОС реального времени
  • Pelion, дочерняя компания Arm, софт для управления инфраструктурой устройств IoT через контейнеры Kubernetes
  • Zededa, запуск легаси в VM рядом с новыми приложениями в контейнерах, оркестрация, опенсорсная операционная система EVE-OS


10 самых крутых компаний в области связи и подключения устройств


  • Aeris Communications, платформа Aeris Connectivity Platform
  • BehrTech (Канада), протокол дальней радиосвязи MIOTY
  • Celona, приватные мобильные сети LTE и 5G
  • Eseye, технология AnyNet+ SIM для незаметного переключения между мобильными сетями


  • Infiot, платформа Intelligent Edge как альтернатива VPN и SD-WAN
  • NetFoundry
  • Senet, провайдер LPWAN
  • Sierra Wireless, системный интегратор для развёртывания корпоративных сетей IoT
  • Verizon
  • Windstream


10 самых крутых компаний в промышленном секторе


  • FogHorn, инновационный стартап внедряет различные системы ИИ в промышленное производство
  • Hitachi Vantara, платформа Lumada IoT
  • KMC Controls, платформа KMC Commander IoT для сбора, визуализации и анализа информации с сенсоров и устройств, установки уведомлений и предупреждений
  • Litmus Automation, платформа Litmus Edge собирает данные с 250 типов устройств, последняя версия Litmus Edge 3.0 поддерживает аналитику, цифровые двойники объектов и алгоритмы машинного обучения
  • PTC, технологии IoT и дополненной реальности разрабатываются в альянсе с Rockwell Automation и Fujitsu
  • Radix IoT, управление производством на основе данных
  • Samsara
  • Schneider Electric (Франция), платформа EcoStruxure Power IoT
  • Siemens (Германия), огромное количество аппаратных и программных продуктов для IoT, таких как настенный тачскрин KNX Touch Control TC5 для управления умной квартирой (освещение, кондиционер, вентиляция, жалюзи), а также ряд промышленных систем
  • Software AG (Германия), новое приложение TrendMiner (в каталоге SAP) для промышленной аналитики на умных фабриках


10 самых крутых компаний в безопасности


  • Armis (Евгений Дибров), система Armis Asset Management для изучения всех устройств, подключённых к сети, и оценки рисков
  • Claroty
  • GlobalSign, платформа IoT Identity Platform обеспечивает защиту сетей IoT с поддержкой шифрования, аутентификации и авторизации. Работает на инфраструктуре публичных ключей с сертификатами от центра сертификации GlobalSign. Управление удостоверениями устройств на протяжении всего жизненного цикла, в том числе автоматическая подготовка, выпуск, продление и вывод из эксплуатации в конце срока службы


  • Karamba Security (Израиль), платформа XGuard Monitor
  • Medigate, защищённая аналитическая платформа для учреждения здравоохранения
  • Ockam, система безопасности с поддержкой криптографии и блокчейна
  • Ordr, мониторинг подключённых устройств, система Systems Control Engine с элементами машинного обучения
  • ReFirm Labs, платформа Binwalk проверяет уязвимости во всех прошивках всех устройств
  • Sepio Systems, защита сети от подозрительных устройств и нежелательных подключений извне
  • Vdoo (Израиль), поиск и устранение уязвимостей в устройствах IoT, проверка на соответствие стандартам безопасности.





Подробнее..

Программные патчи для автомобилей станут обязательными и регулярными

25.05.2021 00:13:35 | Автор: admin

Автомобиль Tesla Model 3 взломали с мультикоптера (для зрелищности), источник

Автомобили Tesla по умолчанию подключаются к любой точке WiFi с идентификатором SSID Tesla Service. Это очень удобно для взлома. Пароль указан в файле .ssq, который поставляется с автомобилем, или его можно найти в интернете (см. скриншот под катом).

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

Проблема в том, что критические уязвимости есть не только в теслах, а практически во всех современных автомобилях. Просто Tesla предлагает большие призы за информацию о багах, поэтому эта информация публикуется в СМИ. Остальные автомобили взламывают молча.

Взлом Tesla



Профиль в твиттере с паролем для вайфая Tesla Service

Последнюю хакерскую конференцию PWN2OWN 2020 отменили, поэтому авторы только сейчас опубликовали свой доклад по взлому Tesla. Они написали эксплоит Comsecuris, использующий две уязвимости в демоне ConnMan. Это стандартный менеджер подключений Linux. В частности, используется переполнение буфера в DNS-форвардере и утечка информации стека (stack infoleak) в компоненте DHCP.

В автомобиле Tesla 3 установлена последняя версия ConnMan 1.37, без уязвимости CVE-2017-12865, которую нашли в версии 1.34. Поэтому пришлось искать новые баги. Здесь повезло: возможность переполнения буфера обнаружилась в функции uncompress().

1 static char *uncompress(int16_t field_count, char *start, char *end,2 char *ptr, char *uncompressed, int uncomp_len,3 char **uncompressed_ptr)4 {5 char *uptr = *uncompressed_ptr; /* position in result buffer */67 debug("count %d ptr %p end %p uptr %p", field_count, ptr, end, uptr);89 while (field_count-- > 0 && ptr < end) {10 int dlen; /* data field length */11  int ulen; /* uncompress length */12  int pos; /* position in compressed string */13  char name[NS_MAXLABEL]; /* tmp label */14  uint16_t dns_type, dns_class;15  int comp_pos;1617  if (!convert_label(start, end, ptr, name, NS_MAXLABEL,18  &pos, &comp_pos))19  goto out;2021 /*22  * Copy the uncompressed resource record, type, class and \0 to23  * tmp buffer.24  */2526  ulen = strlen(name);27  strncpy(uptr, name, uncomp_len - (uptr - uncompressed));2829  debug("pos %d ulen %d left %d name %s", pos, ulen,30  (int)(uncomp_len - (uptr - uncompressed)), uptr);3132  uptr += ulen;33  *uptr++ = '\0';3435  ptr += pos;3637 /*38  * We copy also the fixed portion of the result (type, class,39  * ttl, address length and the address)40  */41  memcpy(uptr, ptr, NS_RRFIXEDSZ);4243  dns_type = uptr[0] << 8 | uptr[1];44  dns_class = uptr[2] << 8 | uptr[3];4546  if (dns_class != ns_c_in)47  goto out;4849  ptr += NS_RRFIXEDSZ;50  uptr += NS_RRFIXEDSZ;


В строках 27 и 41 функция memcpy копирует в буфер uptr содержимое памяти фиксированным размером 10 байт (NS_RRFIXEDSZ), не проверяя соответствие размера выходного буфера количеству копируемых байт.

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

В нашем случае достаточно отключить файрвол и отправить на компьютер нужные команды. Конечно, управление автомобилем через мультимедийную систему не получишь, но можно отпереть двери, изменить режим ускорения, рулевого управления и другие функции, доступные с панели компьютерного управления под Linux (раньше там стояла Ubuntu).

Обязательные апдейты безопасности


Автомобили Tesla обладают продвинутой компьютерной системой, а компания платит очень большие деньги (в районе $300 000) за сообщение о таких уязвимостей. На самом деле хакеры успешно взламывают автомобили и других производителей, просто об этом не всегда сообщают широкой публике.

Компания Upstream Security ежегодно публикует отчёт об автомобильных уязвимостях. Последний отчёт 2021 Global Automotive Cybersecurity Report содержит информацию о более 200 инцидентах безопасности с 2010 по 2020 годы.

Вот статистика по векторам атак за эти годы:



Дистанционные взломы сегодня составляют 80% атак, физическое проникновение 20%. Облачные сервисы главный вектор.

В июне 2020 года ООН приняла общий регламент безопасности для транспорта: UNECE WP.29 Cybersecurity. В 2021-2022 годы эти регуляции будут рассмотрены в нескольких странах, а в 2023-2024 годах ожидается более широкое принятие по всему миру. Первый регламент называется Cybersecurity and Cybersecurity Management Systems (CSMS). Последнюю версию см. здесь.

Документ CSMS содержит информацию об угрозах кибербезопасности и перечисляет большое количество уязвимостей и методов атаки. В приложении 5 десять страниц с описанием уязвимостей в нескольких категориях. В первой таблице кратко перечислены шесть типов угроз с различными типами уязвимостей (перечислено 29 штук) и примерами (67 штук).



В следующей таблице обобщены меры по смягчению угроз кибербезопасности внутри и за пределами автомобиля.



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

Облачные сервисы, бесконтактные ключи по радиопротоколу, порт OBDII, мобильные приложения для управления автомобилем, порты USB и SD, Bluetooth, Wi-Fi, встроенный модем, сенсоры, многочисленные соединения через телематические системы и облачные сервисы, которые работают в автомобиле, встроенная мультимедийная система с компьютером в салоне. Это слишком большая поверхность атаки

Вероятно, в будущем такие удобства войдут в стандартное оснащение всех автомобилей.

P. S. Компания GlobalSign уже 25 лет выдаёт сертификаты безопасности для различных отраслей. Посмотрите нашу интерактивную страничку, посвященную 25-летнему юбилею.
Подробнее..

Перевод Пять причин выбрать JavaScript для IoT-проекта

01.06.2021 14:09:01 | Автор: admin

В мире, где цифровая трансформация правит бал, Интернет вещей (IoT) играет ключевую роль в переосмыслении нашего образа жизни и бизнеса. Интернет вещей экономит наше время и повышает производительность мы можем пользоваться устройствами умного дома, работать в едином виртуальном пространстве и взаимодействовать с коллегами, которые далеко от нас.

Согласно исследованию тенденций в области IoT, проведенному по инициативе корпорации Майкрософт, 85% респондентов в настоящее время активно внедряют IoT-технологии и три четверти планируют их внедрение. Примерно 88% респондентов считают, что Интернет вещей критически важен для развития их бизнеса.

Для тех, кто занимается разработкой IoT-технологий, выбрать язык программирования так же сложно, как выбрать тип датчиков или других устройств.

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

И здесь нам не обойтись без JavaScript!

JavaScript для разработки ПО

На современном этапе разработка программного обеспечения без JavaScript кажется немыслимой. Согласно опросу разработчиков, проведенному Stack Overflow в 2019году, JavaScript вот уже 7лет остается самым популярным языком разработки. Немаловажно и то, что на 95% всех сайтов JavaScript используется как язык программирования на стороне клиента.

С помощью JavaScript на стороне клиента можно писать пользовательские сценарии, создавая динамичные и интерактивные веб-страницы. Вместе с тем можно использовать кросс-платформенные среды выполнения наподобие Node.js для написания серверного кода на JavaScript.

Выбираем JavaScript для IoT

JavaScript это не только веб-приложения. Если вы умеете программировать на JavaScript, вы можете заняться разработкой приложений для Интернета вещей.

Есть несколько вариантов использования JavaScript для разработки IoT-приложений.

Метод клиент сервер

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

Встроенный JavaScript

Код JavaScript можно запускать с помощью оптимизированных под малые объемы памяти движков прямо на IoT-устройствах. На устройствах могут использоваться такие фреймворки, как JerryScript.

JavaScript на одноплатных компьютерах

Исполнение кода JavaScript или Node.js на одноплатных компьютерах не вызовет никаких проблем.

JavaScript прекрасно подходит для разработки IoT-решений, поскольку он может реагировать на события и исполнять код асинхронно. Также этот язык отлично подходит для быстрой разработки прототипов.

К тому же большинство организаций хотят либо сотрудничать с компанией-разработчиком IoT-решений, либо нанять IoT-разработчиков, которые смогут создать на JavaScript единый интерфейс для различных устройств.

Что ж, теперь рассмотрим основные причины выбрать JavaScript для IoT-проекта.

Пять основных причин выбрать JavaScript для IoT-проекта

  1. Node.js

  2. Управление памятью

  3. Событийно-ориентированное программирование

  4. Простота внедрения

  5. Библиотеки и фреймворки JavaScript

Node.js

Это кросс-платформенная среда выполнения JavaScript с открытым кодом, позволяющая создавать решения для обработки данных в реальном времени.

В сфере IoT она пригодится для обработки большого количества запросов, генерируемых различными датчиками, маячками, передатчиками и электродвигателями. Node.js позволяет отладить операции запрос ответ и выполнять их быстрее.

К тому же в Node.js используются сокеты и протокол MQTT (MQ Telemetry Transport), которые обеспечивают непрерывную передачу данных в IoT-приложениях.

В состав Node.js входит менеджер пакетов NPM, который включает более 80 пакетов для одноплатных IoT-совместимых компьютеров, таких как Arduino, BeagleBone Black, Raspberry Pi и Intel IoT Edison. Таким образом, службы разработки на Node.js позволяют быстро создавать надежные IoT-приложения.

Управление памятью

Работая с такими языками, как C, программистам приходится вручную выделять и освобождать память с помощью методов malloc(), calloc(), realloc() и free(). У программистов JavaScript в этом нет необходимости.

В JavaScript используется сборщик мусора, который автоматически выделят память по мере создания объектов, строк и т.д. и освобождает ее, если они больше не используются.

Благодаря функции сборки мусора IoT-разработчики могут полностью сосредоточиться на проекте, не отвлекаясь на управление памятью. В определенной степени автоматическое освобождение неиспользуемой памяти обеспечивает стабильную работу IoT-решения, так как сборщик мусора исключает утечки памяти.

Событийно-ориентированное программирование

В приложениях с управлением по событиям каждое устройство реагирует на события определенным поведением. JavaScript отлично подходит для разработки таких приложений.

Циклы событий в JavaScript позволяют выполнять несколько задач одновременно. Благодаря этому возможно реагирование в режиме реального времени, при этом на одно и то же событие могут реагировать несколько устройств.

Поддержка событийно-ориентированного кода в JavaScript позволяет существенно продлить время работы от батареи.

Простота внедрения

JavaScript, в отличие от C++, Ruby и Python, прост в изучении и внедрении. Это один из самых распространенных языков программирования, с которым внедрение IoT-решений не составит труда. Он эффективен в разных средах, в том числе на шлюзах и в облаке.

Библиотеки и фреймворки JavaScript

В последнее время JavaScript все чаще используется для разработки приложений, и число библиотек и фреймворков JavaScript тоже растет.

JerryScript

Это легкий движок JavaScript, который используется на устройствах с очень ограниченными ресурсами, например на микроконтроллерах. JerryScript поддерживает локальную компиляцию и исполнение и предоставляет доступ к периферийным устройствам через JavaScript.

Cylon.js

Cylon.js это фреймворк JavaScript для робототехники, аппаратных вычислений и IoT. Это простое и эффективное решение для разработки приложений, которые работают одновременно на нескольких разнородных устройствах. Кроме того, Cylon.js поддерживает более 50 платформ, а также интерфейс ввода/вывода общего назначения через общий набор драйверов, включенных в модуль cylon-gpio (тоесть модуль Cylon для интерфейса ввода/вывода общего назначения [GPIO]).

Johnny-Five

Johnny-Five это фреймворк JavaScript, который используется для контроля компонентов оборудования на основе различных микропроцессоров и однокристальных систем. Он подойдет для всех, кто собирается разрабатывать решения для робототехники на JavaScript.

IoT.js

IoT.js это межоперационная сервисная платформа для Интернета вещей, в основе которой лежат веб-технологии. Она может использоваться на устройствах с ограниченными ресурсами, которые потребляют всего несколько килобайт оперативной памяти. Поэтому она поддерживает широкий спектр вещей.

Резюме

Безусловно, JavaScript популярный язык программирования веб-решений. Поэтому вполне разумно использовать его для программирования устройств, которые уже являются частью Интернета. Кроме того, в пользу JavaScript для IoT говорят такие преимущества этого языка, как Node.js, управление памятью, событийно-ориентированное программирование, простота внедрения и большое количество библиотек и фреймворков.


Перевод материала подготовлен в рамках курса "JavaScript Developer. Basic".

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

Подробнее..

О чем спорят строители Умных Домов, Бань, Дач и Гаражей

29.04.2021 08:22:29 | Автор: admin

Я Community Manager и у меня есть зависимость. Ну хорошо, не зависимость, но хобби: я увлекаюсь автоматизацией собственной квартиры с помощью того, что принято теперь называть Умным Домом. Начинал я пару-тройку лет назад с чистого Apple HomeKit, затем расширил его возможности с помощью Homebridge и далее полностью погрузился в дебри HomeAssistant.

Но поскольку я Community Mananger, мне интересна та часть моего хобби, которая касается вопроса коммуникации сообщества людей, имеющих такое же увлечение, как и моё.

О чем спорят в этом сообществе, что обсуждают особенно горячо, какие темы сейчас наиболее актуальны и мой личный взгляд на эти вопросы я постараюсь описать в этой статье.

Статья также о том, как я попал в секту строителей Умных домов и что я о ней узнал. Для начальной ориентации новичков, в общем.

Предыстория

Предупреждая все возможные разговоры о целесообразности Умного Дома, скажу сразу: в настоящее время, в домашних любительских условиях, автоматизация собственного жилища действительно, всего лишь хобби для большинства участников сообщества. Причем весьма дорогостоящее хобби, которое не приносит никаких материальных выгод. Говорить об экономии расходов на тепло, электричество и воду, при использовании весьма дорогостоящих комплектующих для этой экономии, совершенно не приходится. Все это лишь ради собственного удовольствия и для создания некоторых удобств существования в личном пространстве. Новичкам, вступающим на этот путь, нужно четко себе это понимать и быть готовым к существенным расходам.

Мой путь начался с того, что в один прекрасный момент я внезапно осознал, что имеющийся в хозяйстве AppleTV 4K может служить шлюзом для построения Умного Дома на базе Apple HomeKit. Было приобретено и успешно подключено несколько HomeKit ready устройств. Все было прекрасно, стабильно, но дорого. Хотелось дальнейшего расширения, но за меньшие деньги.

И тут я сделал открытие, что существует, оказывается, множество сообществ людей, подобных мне. И что многие устройства можно делать самому и при этом ничуть не хуже, а главное, дешевле. И что вездесущая Xiaomi, со своими инкарнациями вроде Aqara и прочих, делает устройства для Умного Дома значительно менее затратные для моего кошелька.

Так, с помощью внимательного чтения и вопросов к коллективному разуму я влился в обширное и очень эффективное русскоязычное сообщество строителей Умных Домов, Бань, Дач и прочих Гаражей. Мир DIY и OpenSource решений захлестнул меня и, нужно заметить, я был к этому подготовлен. Я уверенно обращался с паяльником и имел очень долгий опыт работы с Linux. Мне было легко и приятно быть среди единомышленников.

С каждой новой итерацией своего продвижения по этому пути все новые и новые ресурсы открывались мне, с великими Гуру можно было спокойно общаться в телеграм группах практически на одном языке и порой даже осмеливаться их критиковать. Я узнал, что большинство самых ценных сообществ живет в профильных телеграм каналах, что сообщество на форуме 4PDA живет какой-то своей жизнью, что известный всем русскоговорящим умнодомщикам Спрут портал раскинул свои щупальца настолько широко, что даже проник на территорию подкастов и инстаграма, что адепты св.Квазиса повсюду и что AlexxIT, Jager, Илья Киров и Иван Бессарабов настолько же доброжелательны и приветливы в общении, насколько круты в своем профессионализме. А для владеющих английским открываются поистине бездонные кладези знаний на Reddit, YouTube и, например, официальном форуме HomeAssistant.

Опыт накапливался быстро и вместе с ним пришло понимание тем и вопросов, вызывающих наиболее горячие и часто повторяющиеся дискуссии. Опыт так же сформировал собственное мнение по этим вопросам. Давайте же их рассмотрим и обсудим.

OpenSource против готовых решений

Xiaomi MiHome стал уже символом консьюмерской системы Умного ДомаXiaomi MiHome стал уже символом консьюмерской системы Умного Дома

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

На чем строить свой Умный Дом? На готовых решениях от Miija, Sonoff, Tuya, Apple, Aqara, Rubetek, Yandex, Google и прочих и прочих? Или же построить его самому на базе OpenSource решений типа HomeAssistant, NodeRed, OpenHub, IOBroker и так далее?

NodeRed очень популярное OpenSource решение для Умного ДомаNodeRed очень популярное OpenSource решение для Умного Дома

Тем, кто стоит перед таким выбором приходят на помощь авторитетные прожженные линуксоиды и начинают говорить о непревзойденной гибкости автоматизаций и отвязки от коварных "китайских облаков" в OpenSource решениях. Они будут говорить о том, что все будет контролироваться только лично тобой и что ты сможешь использовать почти весь доступный на рынке зоопарк устройств Умного Дома, да еще и DIY устройства. Стоит лишь купить "малинку", установить на нее Linux, потом поколдовать в командной строке, чтобы установить этот самый альтернативный Умный Дом, а потом еще потратить месяцы на настройку и понимание что вообще тут к чему.

И вот новичок, который про Linux только на уроках информатики слышал, а командную строку видел только в голливудских блокбастерах про геройских хакеров, обалдев от такого объема информации, мало ему понятной, принимает решение переплатить, но сделать свой Умный Дом легко и просто на базе существующих на рынке готовых решений. Или вообще ничего не делать. И правильно сделает, кстати.

Консьюмерские решения имеют полное право на существование, и принижать их адептов не стоит в сообществах ни в коем случае. Люди принимают решение, основываясь на собственном опыте, знаниях, ресурсах, и тащить их силком в OpenSource не нужно. Мучения таких людей, вставших на путь, на который их убедили вступить, их обескураживающие и порой наивные вопросы очень хорошо заметны, а попытки профессионалов им помочь выглядят удручающе. Но вызывают неподдельное уважение те, кто начинает с такого уровня вхождения в тему и успешно преодолевает его.

Поэтому отсюда мое наблюдение: не стоит тащить и убеждать не готовых людей. Пусть каждый будет в комфортных для него условиях его личного выбора. И выбор этот нужно уважать.

Малинка против Intel NUC, Gigabyte BRIX и прочих x86

Та самая знаменитая "Малинка" Raspberry Pi 4 Та самая знаменитая "Малинка" Raspberry Pi 4

Итак, новоявленного строителя Умного Дома затащили на темную сторону OpenSouce и перед ним встает первый из ключевых вопросов: а на что мне все это хозяйство устанавливать?

Популярность использования платформы Rapberry Pi для сервера Умного Дома я могу объяснить лишь пресловутыми "исторически сложившимися причинами", а так же, не в последнюю очередь, мощью авторитета Алекса Квазиса и его YouTube канала.

При всех своих недостатках, "малинка" остается самой популярной платформой и поныне. А недостатки у нее серьезные:

  1. Использование в качестве накопителя медленной и очень ненадежной SD карты

  2. Необходимость в хорошем охлаждении

  3. Склонность к троттлингу при недостаточно качественно обеспеченном питании

  4. Слабый встроенный Bluetooth

  5. Довольно слабая производительность ARM процессора, которой, впрочем, в большинстве случаев достаточен для систем Умного Дома

  6. Важная для многих необходимость в приличном корпусе

Для устранения части этих недостатков потребуется покупка SSD или eMMC накопителя, мощного корпуса-радиатора, внешнего Bluetooth донгла, корпуса вроде Argon One. Все эти дополнительные покупки приводят к значительному удорожанию вашего сервера Умного Дома на базе "малинки".

И тут на авансцену выходят опытные члены сообщества с вполне резонным вопросом: А почему бы вам сразу не купить компактное, бесшумное и быстрое решение на базе гораздо более производительных процессоров x86 с встроенным SSD диском, расширяемой памятью? Ну, например, что-нибудь подходящее по цене из обширного семейства миниатюрных компьютеров Intel NUC или Gigabyte BRIX?

Очень популярный Intel NUCОчень популярный Intel NUC

В действительности цены на подобные новые минисерверы довольно высоки и далеко не каждый будет готов потратится. Но на просторах интернет барахолок, вроде Avito, вполне можно найти приличные варианты за вменяемые деньги. Я, например, купил там немного устаревшую модель Gigabyte BRIX с процессором Celeron N3000, 4GB RAM, 120GB SSD и пассивным охлаждением всего за 5 тысяч рублей. И машинка эта прекрасно работает в круглосуточном режиме с HomeAssistant на борту вот уже больше года. Некоторые домовладельцы покупают на Авито даже подержанные HP Microserver Gen8 под свой домашний сервер, на котором, кроме системы Умного Дома, работает еще и медиасервер, торрент-качалка, NAS и что-нибудь еще. Многие используют в качестве сервера Умного Дома уже имеющиеся в хозяйстве NAS от Synology или реже Qnap с поддержкой Docker. Но в этом варианте много подводных камней, которые вызывают множество вопросов и дискуссий. Этот вариант сервера, на мой взгляд, подходит только уверенным пользователям Linux с достаточно глубокими знаниями Docker.

На мой взгляд, если говорить о сервере только для Умного Дома, наиболее целесообразным вариантом сейчас является использование миникомпьютеров на базе процессоров x86 (не Atom!). Это могут быть не обязательно Intel NUC или Gigabyte BRIX, а любой подходящий на базе Celeron и выше, и желательно с пассивным охлаждением, особенно для тех, кто строит Умный Дом в городской квартире и для кого уровень шума сервера является критическим параметром. Наличие именно SSD диска не обязательно, но крайне желательно для общего быстродействия. Памяти в большинстве случаев достаточно 2-4Gb. Подключать к сети такой сервер рекомендую по более надежному Ethernet, но и по WiFi 5Ггц у многих работает вполне стабильно.

Zigbee против WiFi (BLE mesh, Zwave, Thread пока не в счет)

Теперь, когда система успешно установлена на сервер, выполнена первоначальная настройка, приходит время покупать и подключать конечные устройства Умного Дома: всевозможные датчики и исполнительные устройства.

У всех дома есть WiFi роутер и, как правило, Умный Дом начинает разрастаться за счет недорогих WiFi устройств от производителей вроде Sonoff, Yeelight, DIY устройств на базе ESP8266 и прочих. Действительно, WiFi прост, есть у всех, дополнительно что-то приобретать и настраивать не нужно. Отсюда в сообществе происходят иногда не то чтобы споры, но оживленные дискусси с основным посылом - зачем мне вообще этот ваш "зигбее" (варианты написания бывают порой очень забавными, "zig been" как-то попадался), мне и на WiFi хорошо и все отлично работает. Мне кажется это мнение происходит от недостаточно хорошего представления о преимуществах протокола Zigbee новичками. Давайте их перечислим:

  • Низкое энергопотребление конечных устройств (где вы найдете WiFi датчик двери или, например, датчик движения, датчик протечки, который работал бы от батарейки годами?)

  • Самоорганизующаяся Mesh сеть, в отличие от звездообразной WiFi сети, где роутер является центром звезды. Например, так выглядит моя домашняя Zigbee сеть, где хорошо видно, как устройства-роутеры (синие) являются точками подключения физически далеко расположенных устройств:

  • Наличие класса конечных устройств-роутеров с постоянным питанием позволяет строить сеть на очень большой территории. Да, WiFi тоже умеет строить Mesh сети, но не с помощью исполнительных устройств-роутеров, а с помощью дополнительных WiFi роутеров подключенных в mesh сеть.

  • Огромный выбор доступных устройств на рынке. На данный момент Zigbee Alliance насчитывает сотни членов, а на рынке существует тысячи разнообразных решений с заявленной поддержкой Zigbee.

  • Безопасность. С 128-битным алгоритмом AES, используемым для шифрования данных и аутентификации, и тремя типами ключей, используемых для управления безопасностью, конечным пользователям не стоит беспокоиться об опасности взлома.

  • Относительно низкие цены на устройства.

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

Лично для меня преимущества Zigbee очевидны и я строю свой Умный Дом почти полностью на этой технологии. Конечно, у меня еще есть несколько WiFi устройств, например, кондиционер управляемый WiFi USB стиком на ESP8266, датчик потребления фильтрованной воды на Wemos D1 mini, настольная лампа Yeelight. Среди активных сторонников Zigbee такой неоспоримый авторитет в сообществе, как Алекс Квазис, который в подкасте Спрута однозначно высказывался о преимуществах Zigbee перед Wifi. Кстати, кто не слышал подкаст, то рекомендую:

Если говорить о Zigbee дальше, то всплывает еще одна горячая тема: USB Zigbee стик, шлюз Xiaomi Gateway 3 (возможно перепрошитый Sonoff шлюз) или SLS использовать в качестве координатора сети Zigbee. Или еще одна, касающаяся пользователей HomeAssistant: что лучше, Zigbee2mqtt или ZHA? Это настолько объемные темы, что заслуживают отдельной статьи. Скажу лишь за себя - я за использование Zigbee USB стика в союзе с Zigbee2mqtt. В двух словах почему: стабильность, количество поддерживаемого оборудования, независимость от прихотей производителей шлюзов или SLS, при необходимости возможность самостоятельно обеспечить поддержку неподдерживаемого устройства с помощью zigbee2mqtt external converter. Но если вы уже имеете Xiaomi Gateway 3 шлюз и хотите использовать его в качестве координатора вашей Zigbee сети, а также, возможно и для BLE mesh сети, то очень рекомендую вам послушать подкаст с AlexxIT, авторитетнейшим участником сообщества и автором интеграции этого шлюза в HomeAssistant, чтобы узнать все нюансы из первых рук:

Говорить о распространенности других протоколов для Умного Дома можно, но на мой взгляд, пока рано. Отличный протокол Zwave живет своей жизнью уже очень давно, но из-за дороговизны устройств и географического разделения рабочих частот протокола мало распространен в русскоговорящем сообществе. Хотя есть пользователи очень давних реализаций Умных Домов на Vera или Homey, у которых осталось Zwave оборудование, например от Fibaro, и которые в рамках HomeAssistant, где поддержка этого протокола очень развита, успешно используют эти устройства и поныне.

Протокол BLE mesh выглядит очень многообещающим и поддерживается последними версиями шлюзов Xiaomi. Кроме того, явно заметно разделение направлений, если устройства для Умного Дома от Aqara практически все выпускаются для протокола Zigbee, то последние новинки от Xiaomi выпускаются почти исключительно для BLE mesh. И уже сейчас вполне реально активно использовать этот протокол, покупая доступные на рынке устройства.

Что касается протокола Thread, то его в последнее время стали продвигать в Apple, включив его поддержку в HomePod Mini и новой версии AppleTV. Солидные производители вроде Eve или Nanoleaf тоже стали включать поддержку Thread в своих новых устройствах. Я думаю, маркетинговая мощь Apple может продвинуть популярность этого протокола достаточно далеко и стоит не упускать из вида этот очевидный тренд.

Но пока протокол Zigbee в Умных Домах безусловно доминирует. И меня это устраивает. Я за Zigbee, как самое сбалансированное решение на рынке на данный момент.

Красивый GUI против текстовых конфигов и чистых автоматизаций

Это очень обширная тема со множеством ответвлений и нюансов. Постараюсь быть кратким и замечу, что в моем изложении она больше относится к HomeAssistant, как к системе Умного Дома, которую я использую. В целом, эта горячая тема подразделяется на следующие два больших направления:

  • Как настраивать систему и писать автоматизации - через предоставленные возможности GUI или редактированием текстовых файлов конфигураций?

  • Зачем заморачиваться с красивым и удобным интерфейсом, делая его похожим на пульт управления космолета? Ведь настоящий Умный Дом тот, в интерфейс которого вообще не нужно заходить - все работает через точно и тонко настроенные многочисленные автоматизации.

Начнем с первого. В последних версиях HomeAssistant тренд на уход от правки yaml конфигурационных файлов в сторону настройки всего и вся через GUI был настолько очевиден, что многие старожилы сообщества загрустили о старых добрых временах, когда все настраивалось вручную. Кроме того, в свое время весомый вклад в популяризацию правки yaml конфигов внес не раз уже упомянутый Алекс Квазис со своими видео уроками по настройке HomeAssistant. Но его продвижение этого метода дало и обратный результат. Вместо того, чтобы вникать в код его примеров и пытаться в нем разобраться, начинающие, неопытные пользователи стали просто бездумно копипастить код из его уроков и слепо следовать его рекомендациям, как истине в последней инстанции. Я уверен, что Алекс не подразумевал изначально такого эффекта, но теперь в сообществе сложился устойчивый мем "так было у Квазиса в его уроке" или "я делал все по урокам Квазиса". Опытные участники сообщества лишь саркастически ухмыляются, отсылая вопрошающих с их проблемами к чтению документации и к пониманию того, что и как они делают.

Многие не любят HomeAssistant именно из-за его формата конфигураций yaml. Жесткая требовательность к форматированию, отступам многих раздражает. Написать вручную, к примеру, такую автоматизацию света на кухне с учетом датчиков движения, датчика освещенности и времени суток с множеством условий, без серьезной подготовки и опыта очень сложно:

alias: Kitchen Lighttrigger:  - platform: state    entity_id: binary_sensor.kitchen_motion_group    to: 'on'  - platform: state    entity_id: binary_sensor.kitchen_motion_group    to: 'off'    for: '00:02:03'condition: []action:  - choose:      - conditions:          - condition: template            value_template: '{{ trigger.to_state.state == "on" }}'          - condition: time            after: '09:20'            before: '23:00'          - condition: numeric_state            entity_id: sensor.lux_kitchen_illuminance_lux            below: '23'        sequence:          - service: switch.turn_on            target:              entity_id:                - switch.relay_switch_l1                - switch.relay_switch_l2                - switch.switch_kitchen_switch_center          - service: light.turn_on            data:              transition: 4              color_name: crimson            target:              entity_id: light.led_strip      - conditions:          - condition: template            value_template: '{{ trigger.to_state.state == "off" }}'          - condition: time            before: '23:40'            after: '09:20'        sequence:          - service: switch.turn_off            target:              entity_id:                - switch.relay_switch_l1                - switch.relay_switch_l2                - switch.switch_kitchen_switch_center                - switch.switch_kitchen_switch_right                - switch.switch_kitchen_switch_left          - service: light.turn_off            target:              entity_id: light.led_strip      - conditions:          - condition: template            value_template: '{{ trigger.to_state.state == "on" }}'          - condition: time            after: '01:00'            before: '05:30'        sequence:          - service: switch.turn_on            target:              entity_id: switch.relay_switch_l2      - conditions:          - condition: template            value_template: '{{ trigger.to_state.state == "off" }}'          - condition: time            after: '01:00'            before: '05:30'        sequence:          - service: switch.turn_off            target:              entity_id: switch.relay_switch_l2    default: []mode: single

Но с другой стороны, эту же автоматизацию можно собрать в GUI автоматизаций HomeAssistant. А в последних версиях еще и появилась возможность визуального дебага автоматизаций в GUI:

Дебаг автоматизаций в HomeAssistantДебаг автоматизаций в HomeAssistant

Таким образом, по этому пункту, я бы посоветовал начинающим следующее. Попробуйте совмещать оба способа при написании автоматизаций, благо интерфейс теперь это позволяет. Пробуйте составить ее через GUI, потом переключитесь в текстовый режим и поправьте что нужно в нем. Или наоборот, скопипастите готовый yaml код автоматизации и затем переключившись в режим GUI попробуйте понять логику его работы, подставьте свои нужные сущности. На мой взгляд, сочетание обоих режимов при создании автоматизаций сейчас наиболее эффективный и оптимальный подход. Также не следует забывать об очень интересной недавней фиче в автоматизациях HomeAssistant: Blueprints, или готовых шаблонах автоматизаций.

Второй пункт нашего списка касается опять HomeAssistant и настройке его интерфейса Lovelace. Да, сейчас его можно настраивать исключительно средствами интерфейса, предоставленного HomeAssistant и не думать о правке вручную файла ui-lovelace.yaml в режиме Lovelace "yaml", как было в уроках Квазиса. Но лично я предпочитаю ручную полировку интерфейса. Весь интерфейс моих дашбордов как для десктопа, так и для мобильных устройств полностью написаны вручную. Сделать два разных дашборда очень просто, достаточно в configuration.yaml прописать что-то вроде:

lovelace:  mode: yaml  resources:  - url: /hacsfiles/mini-graph-card/mini-graph-card-bundle.js    type: module  - url: /hacsfiles/mini-media-player/mini-media-player-bundle.js    type: module  - url: /hacsfiles/ha-yandex-icons/yandex-icons.js    type: module  - url: /hacsfiles/lovelace-card-mod/card-mod.js    type: module  - url: /hacsfiles/lovelace-auto-entities/auto-entities.js    type: module  - url: /hacsfiles/button-card/button-card.js    type: module  - url: /hacsfiles/vertical-stack-in-card/vertical-stack-in-card.js?v=0.4.0    type: module  - url: /hacsfiles/simple-thermostat/simple-thermostat.js    type: module  - url: /hacsfiles/simple-weather-card/simple-weather-card-bundle.js    type: module  - url: /hacsfiles/text-element/text-element.js    type: module  dashboards:    lovelace-generated: # Needs to contain a hyphen (-)      mode: yaml      filename: mobile-ui.yaml      title: Mobile UI      icon: mdi:cellphone-text      show_in_sidebar: true      require_admin: true

и уже в файле mobile-ui.yaml конфигурировать ваш отдельный Lovelace для мобилок. Для десктопа мой интерфейс сейчас выглядит примерно вот так:

Версия для десктопаВерсия для десктопа

Для мобильных устройств примерно так:

Версия для мобильного телефонаВерсия для мобильного телефона

Ну и наконец, резонный вопрос - зачем этот пульт управления космическим кораблем, если настоящий идеальный Умный Дом не должен подразумевать ручного вмешательства, управления и контроля, а все должно работать как надо автоматически?

Скажу честно, у меня нет аргументированного ответа на этот вопрос и более того, я совершенно согласен с таким пониманием идеального Умного Дома. Но я люблю интерфейсы в который не только все удобно, но и красиво, и это для меня вопрос эстетики и эргономики. Как деревенские мастера украшают совершенно утилитарные вещи вроде ставен на окнах домов изысканной резьбой, так же и мне доставляет эстетическое и эргонометрическое удовольствие оптимизация вручную интерфейса моего Умного Дома. Кроме того, я достаточно регулярно пользуюсь мобильным приложением HomeAssistant, где мой удобный и оптимизированный мобильный дашборд весьма кстати.

Тут у меня не будет никаких выводов и рекомендаций. Все очень просто - выбирайте тот вариант, который вам ближе. Тут любые варианты правильные.

HomeAssistant против Node Red. Или вместе с ним.

Эта тема характерна для споров между уже опытными и продвинутыми строителями Умных Домов, Бань, Дач и Сараек. Она не так остра и популярна, но написать о ней мне все же хочется. Хочется, потому, что когда-то этой теме было посвящено немало споров в уютном лампово-теплом сообществе телеграм чата Homever.

Примерный вид обычного Node RedПримерный вид обычного Node Red

Скажу сразу, я попробовал Node Red и он мне не зашел. Визуальное создание автоматизаций перетаскиванием и связыванием каких-то прямоугольников различного назначения лично мне не показалось удобным и интуитивным. Мне гораздо проще и понятнее описывать автоматизации текстом, в yaml, в HomeAssistant. В общем, опыт с Node Red у меня небольшой, судить о нем авторитетно я не могу. Я запустил и отладил несколько флоу, но не более того.

Логотип HomeAssistantЛоготип HomeAssistant

Но тем не менее, я могу поговорить о чем спорят и говорят на эту тему в сообществе. А говорят следующее. Node Red может быть совершенно самостоятельной системой Умного Дома, с интеграцией устройств, собственным дашбордом, ну и конечно, собственными мощными автоматизациями. Также Node Red может работать в тесной связке с HomeAssistant выступая системой автоматизации для него. То есть вы подключаете устройства через HomeAssistant, который позволяет это сделать намного эффективнее, чем Node Red, и поддерживает гораздо больше интеграций для подключения огромного количества всевозможных устройств, но все автоматизации для этих подключенных устройств и сущностей вы создаете средствами подключенного Node Red.

Почему-то принято считать, что возможности и гибкость автоматизаций в Node Red значительно превосходят таковые в HomeAssistant с чем я совершенно не согласен. Я не знаю ни одного сценария автоматизации, который можно было бы реализовать в Node Red и нельзя было повторить средствами автоматизаций HomeAssistant. На этот неоднократно заданный адептам Node Red вопрос я так ни разу и не получил убедительного примера такого сценария.

Таким образом, целесообразность такой связки двух систем мне кажется избыточной и нерациональной хотя бы с точки зрения стабильности. Каждая из этих двух систем вполне самодостаточна, разве что в Node Red нет такого красивого интерфейса, как в HomeAssistant. Но это важно далеко не всем. Ну и возможности подключения огромного разнообразия устройств у Node Red значительно скромнее. Для чего нужен конгломерат двух серьезных и мощных систем, мне непонятно. Знаю пользователей таких симбиозов, которые используют подключения устройств и там и там, да еще и автоматизации создают средствами обоих систем. Представляете, какая каша из сущностей и связей там образуется? Надежность и стабильность такой связки двух систем вызывает у меня большие сомнения.

Мое мнение: максимально глубоко изучите возможности Node Red или HomeAssistant и используйте что-то одно. Каждая из этих систем в отдельности способна полностью удовлетворить все ваши требования к Умному Дому. Хотя, с другой стороны, я могу понять тех, кто имеет устройства, которые не поддерживаются в Node Red, но подключаются в HomeAssistant и он используется в качестве некоей прослойки для проброса подобных устройств в Node Red, а также, возможно, для красивых дашбордов для настенных панелей в виде вмонтированного планшета, например.

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

Заключение

На самом деле я затронул лишь малую часть горячих тем в сообществах строителей Умных Домов. Их гораздо больше по самому широкому кругу вопросов. Например, есть популярная тема о том, что лучше и надежнее - проводное или беспроводное подключение устройств? Или тема о том, каким воспользоваться способом для настройки подключения SSL сертификатов и проброса HomeAssistant наружу в интернет.

Если вас интересует тема Умных Домов и вы готовы погрузиться в нее с головой, подписывайтесь на профильные телеграм чаты по HomeAssistant, этот, или этот. На чат обо всем, касающемся темы Zigbee. На персональный канал большого авторитета Ивана Бессарабова, где найдете кладезь полезной информации. Ну и на упомянутый выше ламповый чат сообщества Homever

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

Подробнее..

Рожденные в карантине беспроводной датчик и все-все-все. Битва роботов в конце

26.04.2021 12:16:37 | Автор: admin
image
Рабочая неделя сокращена и теперь ты мой
Твоя прокрастинация. Апрель 2020.


imageВ этой статье я c удовольствием хочу поделится с Вами универсальной платой, которую легко можно использовать для:
  • метеостанции, беспроводного датчика температуры\влажности на солнечной батарее или без нее;
  • автоматического полива цветов на солнечной батарее;
  • безопасным пускателем фейерверков;
а также
  • управлением открывание/закрывая форточки в парнике или механический кнопконажиматель;
  • модуль охранной сигнализации или контактный датчик;
  • управление светодиодной лентой или небольшим вентилятором;
  • умный уличный фонарь на солнечных батареях;
  • наручными/настенными часами или кухонным таймером;
  • и даже электрическая мышеловка или кормилка для животных.


Устройство представляет собой микроконтроллер с приемопередатчиком nrf24l01 и выходами до 3А стоимостью всего от 2*. Заинтересовались и хотите попробовать сами? Последние 10 плат вышлю по Германии абсолютно бесплатно.
* по ценам на 07.2020

Что в черном ящике?

Требования к устройству


Необходимость разработки, как ни странно, пришла от желания установить банальный беспроводной датчик температуры. Я знаю, на Хабре и в Интернете представлено огромное количество температурных датчиков на любой вкус. Но у большинства готовых работ есть серьезный недостаток цена. Платить по 10-15 за штуку, на фоне текущего дефицита и подорожания микросхем, это не серьезно, особенно когда тебе надо больше 10 штук.
Почему так много?
Когда температура в доме опускается ниже 19C, возникает дискомфорт и желание включать отопление. Двери в комнатах закрываются и там образуется свой микроклимат. Слишком высокая температура плохо скажется на счетах и выбросах СО2, а низкая температура будет способствовать избыточной влажности и появлению плесени.
Для помещений рекомендуется соблюдать следующие температуры: гостиная +22C, спальня +20C, ванная +25C, детская +23C, коридор +18C, подвал > +1C, гараж > 0C.
Вторым недостатком увиденных мною датчиков является радиус действия. WiFi с трудом пробивает междуэтажные перекрытия, а что уже говорить о подвале. Можно протянуть WiFi в подвал, для любимой мышки, но она перегрызет провода, испугавшись излучения. Поэтому, датчик должен уметь ретранслировать сообщения от других датчиков.

Третье требование автономность. Для 10 датчиков нужно более 10 батареек и, конечно, хотелось бы заряжать батарейки не чаще 2-3 раз в год. А лучше вообще забыть про зарядку. Например, датчик расположенный на улице может заряжаться от солнечной батареи, а датчик в кладовке может работать от таблетки, просыпаясь 1 раз в час.

Четвертое требование универсальность. Хочется иметь класс устройств, которые будут долго спать, отправлять 5-8 байт в сеть, а при наступлении события включать что-нибудь маломощное, до 2-3А.

Выбор компонентов


В качестве приемопередатчика был выбран NRF24L01, известный не только благодаря своей низкой цене, но и богатым выбором готовых SMD модулей со встроенным усилителем и разъемом внешней антенны.

Датчик температуры/влажности должен иметь цифровой интерфейс и точность выше 1 градуса и опять же приемлемую цену. Выбор пал на SHTC3.

Дисплей должен быть дешевым и информативным. В качестве дисплея было выбрано семейство больших и малых SSD1306 дисплеев. Кончено, я задумывался и над E-paper и для него зарезервировано место, но он плохо ведет себя на морозе и все еще дорого стоит.

Основной дисплей является не энергоэкономичным, поэтому надо определять необходимость его включения. Датчик движения SR602 понравился из-за его размеров. Также можно включить сенсорную кнопку или ИК-приемопередатчик.

Аккумуляторы были выбраны 2 типов: NiMH, как безопасное и дешевое решение для домашних и уличных нужд, если постоянная отрицательная температура длится меньше 1-2 недель и LiFePo4 для уличных нужд при сильных отрицательных температурах.

Контроллер заряда аккумуляторов был выбран CN3085 для NiMh и CN3058e для LiFePo4. Они имеют схожую цоколевку, за исключением вывода DONE, без которого можно обойтись. NiMH также можно заряжать через токоограничительный резистор.

Так и сложились требования к микроконтроллеру: SPI, I2C, RTC с alarm, PWM, ADC, 5 свободных gpio, малое потребление, рабочую температуру -40C..+85C, диапазон напряжений аналогичный NRF24L01, также, имеет значение цена, комфортный для пайки корпус и большой lifetime.
Взвесив все за и против выбор пал на STM8L051. Некоторые могут обвинить меня в предвзятости к STMicroelectronics и будут правы, но на самом деле
были рассмотрены и отброшены следующие варианты:
ESP32-S2FH4 дешево, но WiFi энергозатратен и придется возиться с отладкой высокочастотных схем;
STM32L0XX + NRF24L01 очень хорош, но хотелось бы дешевле;
PIC16Fxx + NRF24L01 также понравился, но нет RTC;
nRF52810 хорош в своем классе, но будет дороже, чем NRF24L01 + дешевый микроконтроллер;
и некоторые китайские производители были отброшены по причине плохой поддержки.

Таким образом определился следующий список компонентов:
Наименование компонента Цена*, Минимум Обычный Обычный с экраном Метеостанция Внешняя метеостанция
STM8L051 0.4 x x x х х
NRF24L01+ 0.6 x x x х х
PCB 0.2 x x x х х
Кварц. резонатор 1TJF090DP1AI075 0.2 x x х х
Датчик температуры SHTC3 0.8 x x х х
Датчик движения SR602 0.4 x х х
Аккумулятор NiMh 1 x x х х
Зарядка аккумулятора CN3085 и стабилизатор напряжения AP2210K-3.3 0.3 x х х
Дисплей SSD1306 0.91 1.1 x
Дисплей большой SSD1306 2.4 10 х х
Солнечная панель 2 х
Итого, 1.2 3.2 5 13.9 15.9

* по состоянию на 07.2020, текущая цена может отличаться в 2-10 раз. Будем надеяться, что это скоро пройдет.

Схема принципиальная.


Я не настоящий электротехник, поэтому в схеме могут быть допущены ошибки, влияющие на работу устройства в долгосрочной перспективе.
Разработка принципиальной схемы и платы выполнялась в KiCAD.

Основные узлы


Питание


Ключик для датчиков и внешних устройств, 2 шт



и многочисленные разъемы



Схема разрабатывалась универсальная и необходимость пайки элементов зависит от конфигурации устройства. Пайка всех элементов сделает устройство нерабочим.
Например, в схеме предусмотрены 3 варианта зарядки батарей через зарядные контроллеры, с подключением внешнего блока питания и через токоограничительный резистор для подключения солнечной панельки.
Также невозможно одновременно использовать датчик движения и диод D2, как индикатор MCU.
Цоколевки для SMD модулей NRF24L01 и NRF24L01 Long Range разные и можно подключить только один из них.

С целью снижения энергопотребления, был установлен отдельный ключ Q1-VT1, который прерывает питание дисплея, приемопередатчика и датчика температуры. В режиме сна основными потребителями являются микроконтроллер, 100К подтяжки на VT1,VT2 и датчик движения, при его установке. I2C шина также была подтянута на отключаемое питание датчиков, дабы избежать утечки драгоценного заряда в режиме сна.

Для подключения внешних устройств, таких как водная помпа, сервопривод, аналоговые датчики или кнопки управления, предусмотрен разъем J4 с управляемым питанием Q2-VT2. Этот выход может иметь раздельное питание с основной платой J3. Максимальное напряжение зависит от подобранных транзисторов и здравого смысла.

Печатная плата.


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

Нижний слой


SMD компоненты выбраны размером 0804, для комфортного разглядывания номиналов резисторов и ручной пайки. Знаю, что многие из вас способны запаять 0204 с закрытыми глазами 60Вт паяльником, так вот это схема и для тех кто этого не может. Для самого мелкого компонента температурного датчика SHTC3 нанесена разметка для его точного позиционирования. Посадочное место для ключей управления устройством, к которому можно подработать транзистор с переключением до 6А при 8V, что больше возможностей дорожек.

Датчик температуры\влажности разместился рядом с контроллером в надежде, что большую часть времени контроллер будет спать и не будет нагревать датчик. По этой причине, силовые элементы унесены на противоположные концы платы, но это не помогает и в режиме зарядки температура увеличивается на 4-5 градусов. NRF24L01 припаивается отдельным модулем, для экономии времени и возможности выбора типа приемопередатчика. Проект данной платы вы найдете на GitHub.

Если схема зарядки аккумулятора не требуется, то можно ее отломать бокорезами, сделав кусь по линии отверстий(берегите глаза).

Плата распаивалась с помощью паяльной пасты и утюжных технологий. Запекать 2 мин. при температуре Лён:

Смотрится вполне сносно:


Корпус


Размер платы удачно совпадает с размерами 2 батареек ААА, что делает доступными все корпуса с батарейками 2xААА или 2xАА. Также подойдут некоторые корпуса для 1x18650 при диагональном размещении платы. Вид у этих коробочек соответствует цене, но мы их спрячем и замаскируем.
Для устройств находящихся на видном месте спешу поделится технологией быстрого и дешевого изготовления красивых корпусов.
Покупаем или печатаем пластиковый корпус и фанеру толщиной 1-2мм из благородных пород дерева. С помощью цианокрилата(берегите глаза и нос) клеем фанеру на пластик и отрезаем все лишнее. Если у вас такие же кривые руки, то необходимо запастись шпатлевкой по дереву и замазать сделанные щели и сколы. Затем, надо дать просохнуть клею и шпатлевке, затереть всё наждачной бумагой и покрыть маслом или лаком.
Таким образом, из
серой пластиковой коробочки


получается теплый деревянный корпус.


Тестирование


Платы были успешно протестированы при температурах от +40С до -14С в конфигурации с дисплеем и датчиком движения. Для плат, которые будут использоваться на улицы в качестве защитного покрытия был использован специальный лак.

Измеренный ток в спящем режиме ~1.5мкА при 2.6В. При включенном режиме потребление зависит от количества подключенных устройств, яркости дисплея, количестве включенных пикселей и режимах приемопередатчика, в среднем получилось 40мА.
Ниже приведено расчетное время работы в зависимости от используемой батареи.
АКБ Заряд, mAh Номинальное напряжение, V Период передачи данных, c Расчетное время работы на 70% заряде, дней
AAx2 2500 2.4 300 217
AAAx2 900 2.4 300 77
AAx3 2500 3.6 120 174
AAAx3 900 3.6 120 62
CR2025 150 3 3600 189
AAx6 5000 3.6 120 350

На сегодняшний день я не могу подтвердить достоверность расчетных данных, испытания продолжаются.

Программное обеспечение.


STM8L051 является 8 битным MCU, имеет 1Кб RAM и 8 Кб ПЗУ. Это значит, что в 8 Кб необходимо уместить максимальную комплектацию:
поддержка интерфейсов i2c, spi;
поддержка устройств: датчик, NRF, дисплей, часы;
протокол передачи данных SMESH;
шрифт (цифры, знаки, буквы);
график вывоза мусора.
И здесь придется бороться за каждый байт. Программный код был написан на языке С для компилятора sdcc. Из допущенных ограничений стоит отметить, что шрифт уместился только от пробела до заглавной Z, а годовой график вывоза мусора пришлось упаковать в 1 байт на событие. Для дисплея размером 128*32 пикселя требуется RAM буфер 512 байт, что приемлемо для микроконтроллера, а вот для экрана 128*64 требуется уже 1Кб, что в RAM уже не помещается. Поэтому, для большого экрана, его буфер пришлось делить на 2 части верхние 3 строки текста и нижние 3 строки текста.

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

SMESH (Simular MESH)


Да, уместить полноценный MESH в 8Кб не получилось, но по крайней мере он умеет ретранслировать сообщения. Для управления необходим контроллер, который будет синхронизировать устройства, принимать показания датчиков, передавать время и другие данные. Каждое устройство имеет уникальный ID(4 байта) и динамический однобайтовый адрес. Одна сеть поддерживает до 126 узлов, с максимальным диаметром 22 узла. Кроме этого, каждый узел может ретранслировать данные с устройств не участвующих в сети.

Подразумевается, что контроллер сети постоянно включен и передает данные устройствам. Устройства же спят большую часть времени, просыпаясь согласно расписанию. Расписание имеет установленный период и всегда кратно одному часу. Таким образом, зная точное время и период цикла можно вычислить следующий сеанс связи. С началом периода устройства должны проснуться, передать свои данные и уснуть до следующего сеанса.
Если устройство не будет просыпаться каждый сеанс связи, то оно должно быть исключено из цепочки ретрансляторов данных.

Основа функционирования сети точное время. Поэтому сообщения с точным временем от контроллера сети передаются регулярно. Это помогает скорректировать время на устройствах и быстро подключить новое устройство.

Как мы знаем в аббревиатуре IoT буква S означает seсurity. Нарушать эти традиции у меня не хватило памяти. Но можно быть уверенным, в случае атаки злоумышленник будет находится в радиусе 100 метров от крайнего узла, и при обнаружении невероятных значений температуры вам следует выпустить ваших собак.

На данный момент полноценного тестирования сети проведено не было, но в первом приближении это работает.

Контроллер сети


Изначально контроллер сети планировалось сделать также на базе микроконтроллера, в виде шлюза NRF24L01 WiFi. Но, посчитав соотношение цена\функциональность\время разработки, выбор пал на полноценный PC Raspberry PI Zero(20) c 6'' HDMI дисплеем+touchscreen(30). Несмотря на свою одноядерность и 1Гб RAM RPi Zero справился со своей задачей отображения сенсоров и почасового прогноза погоды на остаток дня.
В качестве ОС был развернут минимальный образ OC *Linux* и установлен Kivy, который поддерживает egl, умеет работать с framebuffer и не нуждается в Xwindows. Следуя заветам Unix, было написано несколько программ, каждая из которых вносит небольшой вклад в отображение информации. Основной является программа управления сетью, которая также принимает данные с устройств, распределяет динамические адреса и передает точное время, погоду и другую информацию. Программа написана на языке С и может быть портирована на любой микроконтроллер. Также работают несколько небольших Python-скриптов: однин из них прекрасно генерирует картинку первого этажа дома, второй для второго этажа, еще один для генерации погоды от OpenWeatherMap на следующие 12 часов, отправки данных на сервер и телеграмм, и наконец, программа, которая показывает сгенерированные картинки по кругу, с возможностью swipe и обеспечивает интерфейс с пользователем.



Чтобы монитор не светился постоянно, к RPI был приделан все тот же датчик движения, по сигналу с которого или с touchpad подается команда к включению монитора. Через 30 секунд монитор выключится, если сигналы не поступят опять.

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



Автоматический полив цветов на солнечной батареи


Скоро лето, время когда люди уезжают в отпуска, оставляя свои комнатные растения без воды под жаркими лучами палящего солнца. Я знаю, на Хабре и в Интернете представлено огромное количество систем полива для цветов. Большая их часть требует питания 220В или емких LiPo АКБ.

Для модификации нашей платы в автоматическую поливку цветов нам потребуется маломощная водяная помпа до 3А и напряжением 3-4В. Помпу необходимо поместить в емкую канистру от 5л. Желательно, чтобы канистра находилась на одном уровне с цветком, иначе мощности помпы может быть недостаточно для подъема воды более, чем на 30см. Если канистра с водой будет выше цветка, то необходимо поставить обратный клапан, который будет предотвращать самотек воды, запуская в трубопровод воздух. Помпа подключается к разъему J4.

В простейшем случае, длительность включения насоса можно настроить экспериментально. Например, установить включение на 3 минуты 2 раза в день. Для ручной регулировки цикла подачи воды можно подключить дисплей и 2-3 кнопки к разъему J7. В качестве обратной связи можно использовать ADC канал или поместить датчик влажности ближе к поверхности земли. А источник питания лучше использовать 3-6 аккумуляторов АА и солнечную батарею(блок батарей) площадью от 0.4 кв.м., которую необходимо подключить к разъему J8 и приклеить(прислонить) к окну.

Данная схема уже была реализована и, возможно, работает и по сей день, но на другом микроконтроллере.

Безопасный пускатель фейерверков


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

Для этого понадобится 2 таких устройства: одно для запуска, с нитью накаливания, а второе для управления. В качестве нити накала можно использовать никелевую нить малого сечения, намотанную на разъем и подключенную к J4. Для нагрева нити достаточно 3-4 аккумулятора АА и соответствующий току и напряжению транзистор в ключе VT2. Длину нити следует подобрать так, чтобы она светилась ярко-желтым светом, но при этом не перегорала мгновенно.

Перед надеванием нити накаливания на фитиль фейерверка, фитиль следует загнуть. Для пульта управления следует использовать второе устройство, подключить кнопку запуска к разъему J12. Соблюдайте осторожность при включении устройства!
Демонстрацию устройства, к сожалению, провести не удалось из-за отмены фейерверков в этом году из-за COVID.

Бонус. Битва роботов.



Их схватка будет легендарна

В качестве побочного продукта(своего рода вложенная прокрастинация) сопряжения STM8L0xx+NRF24L01 были изготовлены роботы для игры всей семьей. Схему печатной платы, ПО и модели деталек для 3D печати можно найти на GitHub.

Идея была в создании дешевой игрушки на радиоуправлении с возможностью расширения. В качестве основы корпуса была взята печатная плата, на которую крепятся моторы N20 с редуктором на 150об/мин и батарейный отсек с поворотным колесом.
Для добавления зрелищности борьбе был предусмотрен крюк с сервоприводом, но в схватке реальной пользы от него почти нет. С помощью крюка робот может самостоятельно переворачиваться и впиваться в ногу. На плате есть возможность подключения излучателя для стрельбы фотонами и фотодиода с операционным усилителем, а также внешней платы управления на базе esp32 c внешней камерой. К сожалению, все это так и не было протестировано.

В проекте также используются NiMH аккумуляторы, терпимые к замыканию и ударам, особенно, в руках детей. Cледует обратить внимание на максимальный ток NiMH аккумуляторов, дешевые аккумуляторы не способны выдать ток, необходимый для работы сервопривода под нагрузкой и просаживают напряжение, сбрасывая микроконтроллер.

Было придумано множество вариантов игр, роботы могут устраивать гонки, драться, играть в футбол. Один из вариантов игры можно увидеть в этом коротком видео:

За все время эксплуатации сломалось 6 больших колес, 2 кнопки пульта управления, 2 сервопривода и 1 мотор. Запасайтесь колесами!
Подробнее..

Сетевой интерфейс для программируемого реле с поддержкой Telegram Bot и HomeKit

07.05.2021 14:19:42 | Автор: admin

Как я реализовал удаленное управление и мониторинг, для программируемого реле ПР200, используя разные сервисы (Telegram Bot, HomeKit) и протоколы (Modbus RTU, Modbus TCP, mqtt) и ESP32.

Год назад была статья про управление освещением на ПР, где я на примере показал наиболее часто используемые алгоритмы. Пример демонстрировал работу с клавишными выключателями, подключенными к дискретным входам. В эпоху, когда даже у чайника есть облачный сервис или другой режим удаленного доступа, было бы странно не развить данное направление и для программируемого реле.

Долгое время я использовал сетевой интерфейс на основе модуля esp8266, на сегодня более перспективным вижу использование модуля esp32, долгое время я не рассматривал его из-за размеров, но впоследствии, проработав разные варианты, удалось не только вместить все на одной плате, но и сделать решение более универсальным и удобным.

Первая версия платы на основе ESP32

Во второй версии добавлен usb порт, что позволяет загрузить прошивку без использования дополнительных проводов и преобразователей. Базовая реализация изначально задумывалась с возможностью обновления прошивки по воздуху через ОТА, а для экспериментов проще использовать microUSB.

В обновленном варианте добавил ещё и кнопки сброса и загрузки при прошивке, а так же добавил поддержку модулей ESP32-WROVER с PSRAM, это позволит использовать больше памяти и расширит возможности.

В общем, структура взаимодействия сетевой платы с программируемым реле основана на протоколе modbus rtu, а с внешним миром варианты могут быть самые разнообразные от bluetooth до TelegramBot.

TelegramBot

Именно с поддержки бота я и начал опыты, на раннем этапе получилось вот такая реализация:

Для использования бота достаточно получить токен и ввести его в поле ввода и сохранить, значение сохраняется в энергонезависимой памяти, после перезагрузки бот запустится автоматически.

Для универсальности взаимодействие бота с алгоритмом в приборе, использован режим чтения/записи сетевых регистров Modbus а разных форматах представления:

/R- целое 16 битное значение

/I-целое число занимающее 2 регистра

/F- число в формате float тоже 2 регистра.

После символа адрес в диапазоне 512-576, эти регистры можно читать и записывать, формат для записи /Xzzz=nnnn, для чтения достаточно отправить номер регистра в требуемом формате.

Для представления состояний регистра в битовых полях, можно отправить адрес в формате /Bzzz, ответ будет в виде 16 значения в булевом формате.

Apple HomeKit

Следующим этапом был сервис Apple HomeKit и приложение дом, как раз для управления освещением и другими точечными нагрузками он подходит лучше всего, я начал с 16 каналов, по количеству бит в регистре модбас.

После выхода обзора по такому применению,

многие задавали вопрос о раздельной привязке выключателей по разным комнатам. Сейчас это решено, после добавления аксессуара в системе появляется 16 независимых выключателей.

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

Для быстрого добавления платы в приложение Дом, на web страницу добавлен QR код, второй вариант ввести код настройки, индивидуальный для каждой платы. Постарался упростить и минимизировать все настройки для быстрого старта.

Так же протестировал mqtt, идея задания топиков взята из версии платы для esp8266. Проверил поддержку датчиков 1-wire ds18b20, для их подключения к плате предусмотрены посадочные места под разъем, и сигнальные линии с резисторами, такой-же использовался в плате prsd на esp8266.

4 пина, два из которых +3.3v и gnd, позволяют задействовать 2 порта в качестве интерфейса 1-wire или i2c. I2C позволяет подключать всякую экзотику, которую практически невозможно состыковать в базовой поставке прибора. Например, датчик влажности/давления с I2C или RFID ридер.

Для быстрого просмотра значений регистров используется протокол Modbus TCP, запустив Modbus Poll на ПК или Virtuino/Kascada и другие приложения на Android, можно быстро организовать доступ и управление устройством с помощью телефона или планшета.

Остальные настройки WEB интерфейса представлены ниже:

WEB настройки

Для смены прошивки платы, когда она уже установлена в устройство, предусмотрен режим обновления по воздуху (OTA), для этого достаточно выбрать bin файл, после загрузки прошивки устройство перезагрузится и запустится обновленная версия. Так же можно перезагрузить плату в ручном режиме через web кнопку.

При первом старте, когда устройство не имеет настроек точки доступа и пароля и не может подключиться к сети wi-fi, плата включает режим точки доступа для подключения и ввода ssid и pass, после сохранения значений и перезагрузки если подключение к сети успешно, точка доступа выключается. Если токен Telegram bot введен, то после подключения и выхода в интернет, узнать IP адрес платы можно введя команду. Через бот можно получить и другую информацию.

Основные моменты по работе представлены в видео.

На данный момент прошивка находится в режиме доработки, демонстрационные версии будут доступны позже.

Для экономии ресурсов ESP32 в перспективе думаю разделить на версии с поддержкой того или иного функционала, памяти в esp32 хоть и больше в сравнении с esp8266, но одновременная работа всех сервисов может снизить ресурсы до критического уровня.

В процессе тестирования нескольких подключенных устройств одновременно, заметил особенность.

В меню бота есть возможность смотреть время бесперебойной работы в секундах, текущий и минимальный объем доступной Heap памяти, используя один и тот же токен для TelegramBot, можно читать параметры сразу с нескольких устройств, аналогично и на запись параметров. Т.е. любая команда, отправленная с телефона боту, отправляется всем устройствам с токеном, это происходит не всегда, иногда отвечает только часть устройств, и приходится делать запросы повторно. Сейчас все они не имеют привязки к имени, думаю сделать уникальные имена для отличия при запросах/ответах.

Используя несложный сетевой интерфейс с чипом ESP32, можно значительно расширить функционал программируемого реле ПР200 и в перспективе ПР103, куда можно установить сетевой интерфейс, другие модели ПР100/ПР102 потребуют внешний драйвер RS-485 для подключения снаружи, так как сетевые интерфейсы в них не съемные.

Наличие программатора на борту платы, позволяет создать собственные алгоритмы с быстрой загрузкой в устройство, необходимо лишь обеспечить обмен по протоколу Modbus на стандартных выводах UART esp32.

Подробнее..

Использование LoRa для интеграции кота в IoT

09.05.2021 16:23:04 | Автор: admin
Duivendrecht, вид на ферму и церковьDuivendrecht, вид на ферму и церковь

Я всегда мечтал жить в деревне - чтобы зелень и птички щебетали летом - но недалеко от города и выбора удобств. И наконец мечта сбылась - я поселился в доме с садом, в местечке Дёйвендрехт, тихой деревне, которая ближе к центру Амстердама чем половина собственных его районов.

А в дом с садом просто необходимы коты.

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

Поэтому через некоторое время у нас появился Барсик, по паспорту Эскобар.

Эскобар - британский голубой кот, который своё имя оправдывает полностью. Способен находить лазейки и убегать практически из любых ситуаций.Эскобар - британский голубой кот, который своё имя оправдывает полностью. Способен находить лазейки и убегать практически из любых ситуаций.

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

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

Было решено исследовать рынок кото-трекеров. Кейс простой - хочу знать где гуляет кот в данный момент, и если он вдруг потерялся, не может найти дорогу домой, или же куда-то направился, где много и часто ездят машины - знать, куда направлять спасательную группу.

Протестированы были устройства Invoxia, Findster, Tractive и некоторые другие. Invoxia это сеть SigFox, Tractive и прочие - GPRS с симкой, Findster - собственное радио.

  • Симочные все требуют денег, минимум 5 евро в месяц абонемент. При этом видимо используются какие-то дешёвые IoT симки с 2G connectivity. Задержки сигналов 1-2 минуты.

  • На SigFox возлагались надежды - но сеть теряет сигналы как-то уж очень часто, локации приходят в перемешанном порядке. Качество фикса позиции ужасное.

  • Findster - хороший фикс и реалтайм отслеживание. Производитель рекламирует радиус 900 метров в городе, реально 100+ метров - трекинг теряется. Его я использовал дольше всего - пока Барсик вокруг дома уже всё не изучил, ему не стало скучно и он отправился в более дальние экспедиции.

  • Жизнь батарейки - реалтайм GNSS трекинг выжирает часа за 2-3 батарейку у всех трекеров.

LoRa и The Things Network

Трекеру в общем-то не очень нужна симка, надо передавать десятки байт раз в минуту или несколько минут. Погуглив туда и сюда, выяснил, что есть радиостандарт LoRa, который гораздо лучше подходит под мой кейс чем всё вот это вот.

  • LoRa использует EU 868MHz нелицензированные частоты, которые доступны и в РФ.

  • LoRa использует chirp модуляцию, изначально придуманную для военных целей, которая позволяет энерго-эффективную радио коммуникацию в отсутствии прямой видимости.

  • LoRa поддерживает различные сети - можно делать частную сеть со своей базовой станцией, или пользоваться сетью провайдера. KPN предоставляет покрытие по всем Нидерландам.

  • Устройства LoRa не стоят индустриальных денег

Стандартных решений для трекеров с LoRa сетью на рынке не было - и нет - но почему бы и не сделать собственное?

Gateway и антенна


Нидерландская компания The Things Network предлагает TTN Indoor gateway за 70 евро. Установка и конфигурация (gateway передаёт через wifi на сеть TTN всё, что ловит на радио сам) была завершена за 10 минут.

TTN консоль сделана с любовью, всё понятно и удобно.TTN консоль сделана с любовью, всё понятно и удобно.

Единственная проблема - gateway содержит внутреннюю напечатанную антенну, которая не обеспечивает связи вне дома.

Решение проблемы - подключить внешнюю антенну. Благо дом свой, можно лезть на крышу и ставить что угодно.

Aurel GP 868 антенна на крышеAurel GP 868 антенна на крыше

Решение по частям

  • заказать внешнюю антенну с ground plane диаграммой (например Aurel GP 868, EUR 40,-)

  • заказать IPEX кабель-адаптер (для Aurel был нужен IPEX-to-BNC-female, EUR 3,-)

  • вскрыть корпус gateway, отсоединить IPEX кабель от печатной планы и воткнуть свой кабель внешней антенны

Наверное можно было сделать аккуратнее, но и так работает.Наверное можно было сделать аккуратнее, но и так работает.

После такого хака я увидел на гейтвее трафик с нескольких LoRa устройств поблизости. Это колхозный принцип организации TTN - каждый любитель, типа меня, с гейтвеем ловит и передаёт трафик от всех устройств, активированных в TTN. В сутки где-то 100 тысяч сообщений, но каждое меньше 100 байт, поэтому +10 мегабайт в сутки на фоне всего остального незаметно, от слова вообще.

В результате получается бесплатная (и без SLA) колхозная сеть. Покрытие не 100% и даже не близко, но сам факт, почему бы и нет?

Бесплатное покрытие TTN в АмстердамеБесплатное покрытие TTN в Амстердаме

С антенной как есть - покрытие порядка 1 км радиус, планирую поднять антенну на 6 метров, посмотрю насколько увеличится радиус. Фанаты устанавливают рекорды LoRa связи в несколько сотен километров.

На рынке LoRa трекеров есть несколько устройств, но единственное устройство можно было использовать в качестве кото-трекера. Это BroWAN Object Locator, которые делает тайваньская фирма Browan. Кроме этих сенсоров, они делают ещё десятки других LoRa устройств, от CO2 до протечек воды. Очень милые ребята, хорошая техническая поддержка.

Другие сенсоры были либо слишком тяжёлые (для авто или мотоциклов), либо с батарейкой, которая не перезаряжается, либо не позволяли сконфигурировать себя под TTN.

BroWAN tabBroWAN tab

Вес 28 граммов, батарейка 540mAh, которой хватает на передачу позиции раз в минуту в течение 8 часов, или дольше, если реже.

Но если бы я был котом, мне бы с такой блямбой на шее бегать было бы неудобно. К тому же кот носил Findster и теперь носит два BroWAN tab - TTN с моей антенной и KPN, который тестируется.

Поэтому я купил шлейку для прогулок котов, отрезал всё лишнее и пришил как умел два кармашка, получился такой типа жилетик-разгрузка.

Пришлось ещё удлинить лямку вокруг шеи, чтобы не затягивать сильно, но и не расстёгивалось.

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

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

Чтобы сместить баланс жизни и смерти в пользу птичек, я ещё пришил звякающий шарик сверху. Теперь Эскобар может выполнять функцию верхнего хищника просто гоняя птичек, чтобы не жирели, но не убивая их. Или же, если некая птица не способна заметить кота с колокольчиком в ярком жилетики и свалить восвояси, кот может рассчитывать на применение по отношению к ней законов Дарвина, а не человеческой этики.

Ещё Барсик таскает в одном из кармашков маленькую круглую таблетку Tile- она не умеет в GNSS и из радио всего лишь Bluetooth. Но зато она умеет громко пиликать, когда ты от неё в 10 метрах или ближе (в рекламе 30-40, но с 10 точно берёт). Это позволяло мне находить жилетик в 6 случаях, когда кот его сбрасывал и гулял дальше голый.

Эскобар в боевом облаченииЭскобар в боевом облачении

Программное обеспечение

Пока что было всё про железки, теперь про софт немного. Архитектура решения выглядит примерно так:

Кот начинает гулять, трекер активируется акселерометром и начинает посылать позиции раз в минуту. Пакеты ловятся каким-то gateway (иногда несколькими) и пересылаются в сеть TTN.

Каждый пакет это примерно 50 байт, содержит заголовки, метаданные, локация и напряжение батарейки.

Приложение в консоли TTNПриложение в консоли TTN

Gateway добавляет свою информацию, в частности отношение сигнал/шум и посылает всё в сеть TTN. В консоли TTN каждое устройство (device) конфигурируется как честь приложения (application) - группа устройств, парсер входящих пакетов + дальнейшие интеграции - MQTT, HTTP и прочие.

Конфигурация устройстваКонфигурация устройства

В TTN application можно добавить функцию-парсер для преобразования байтов из устройства в структуру типа JSON. Для BroWAN трекеров код выглядит так:

function Decoder(bytes, port) {    var params = {        "bytes": bytes    };    bytes = bytes.slice(bytes.length-11);      if ((bytes[0] & 0x8) === 0) {        params.gnss_fix = true;      } else {        params.gnss_fix = false;      }      // Mask off enf of temp byte, RFU      temp = bytes[2] & 0x7f;      acc = bytes[10] >> 5;      acc = Math.pow(2, parseInt(acc) + 2);      // Mask off end of accuracy byte, so lon doesn't get affected      bytes[10] &= 0x1f;      if ((bytes[10] & (1 << 4)) !== 0) {        bytes[10] |= 0xe0;      }      // Mask off end of lat byte, RFU      bytes[6] &= 0x0f;      lat = bytes[6] << 24 | bytes[5] << 16 | bytes[4] << 8  | bytes[3];      lon = bytes[10] << 24 | bytes[9] << 16 | bytes[8] << 8  | bytes[7];      battery = bytes[1];      capacity = battery >> 4;      voltage = battery & 0x0f;      params.latitude = lat/1000000;      params.longitude = lon/1000000;      params.accuracy = acc;      params.temperature = temp - 32;      params.capacity = (capacity / 15) * 100;      params.voltage = (25 + voltage)/10;      params.port=port;      return params;}view rawttn-browan hosted with  by GitHub

В TTN добавлена интеграция HTTP, чтобы посылать события в приложение catracker, которое сохраняет позиции в базу и посылает их подключенным клиентам по вебсокетам.

Приложение состоит из Scala/Akka сервиса, фронтенда на голом TypeScript, Azure DevOps CI и Kubernetes дескриптора.

Полный код доступен в https://github.com/jacum/catracker.

Сегодня был дождь и Барсик не ходил далекоСегодня был дождь и Барсик не ходил далеко

Интерфейс минималистичный но вполне MVP - показывает проценты батарейки, позицию кота и время с апдейта последней позиции, если прошло больше двух минут. Скриншот сделан после 1 часа и 53 того, как кот пришёл домой - трекер не посылает событий, если акселерометр не показывает движения.

Большое спасибо TTN за надёжное и недорогое оборудование, и добротную консоль, и BroWAN за лучшие LoRa трекеты.

И конечно же коту Барсику за ежедневные усилия по тестированию решения.

Мяу!Мяу!

Оригинал (моей же) статьи

Подробнее..

Рождение Гуся как создаётся умный стрелковый тренажёр

18.05.2021 00:13:00 | Автор: admin

Гусь домашний тренировочно-игровой стрелковый стенд с лазерными мишенями и интеллектуальным сопровождением для отработки меткости и техники стрельбы, а также для развлечения всех любителей пострелять!

Тренажер представляет собой несколько умных устройств, которые должны работать в связке автономно, а при online включении становиться частью глобальной облачной инфраструктуры. Системы рейтингов, редакторы и магазины сценариев игр и программ тренировок то, над чем еще предстоит пофантазировать и во что должен эволюционировать Гусь.

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


Одной прекрасной ночью, накануне сдачи экзамена по безопасному владению оружием, мне приснился сон - я был в тире и стрелял по световым мишеням. Сначала показалось, что я очутился в Counter Strike и отрабатываю AIM (меткость), но вскоре дошло это тренировка! Я не просто стрелял по произвольным мишеням, холостил, отрабатывал чёткость и плавность движений. Тир как будто был наделён интеллектом, контролировал каждое моё движение и корректировал программу занятий. Оказалось, нас много, все стрелки тренируются и соревнуются, каждый у себя дома.

Это было чертовски увлекательно!

Экзамен был сдан с первого раза. Я рассказал об этой идее другу, и с этого момента у нас появилось неуёмное желание сделать умный тренажёр, чтобы каждый мог похолостить перед охотой и походом в тир или скоротать время, стреляя по лазерным мишеням.

Идея была объединить игру, тренировку и современные технологии.

Гусиные пёрышки

Гусь каждому придётся по вкусу, он прост и ненавязчив. Умён и хитёр. Его лазерные мишени не так просто подстрелить, когда с ним соревнуешься. А когда тренируешься он мягок и покладист, только держи на мушке. Благодаря своему зоркому глазу Гусь всё видит, а электронному уму ещё и точно знает, когда и куда стреляли.

У Гуся есть компаньон. На оружие или муляж устанавливается насадка-контроллер с универсальным оптическим датчиком спуска и лазерной имитацией дробового пятна. С напарником Гусь обретает чуткий слух и осязание. Гусь запомнит удачные и плавные выстрелы, обратит внимание на резкие движения и неудачный выход на цель, а стрелок получит статистику и рекомендации.

Гусиные навыки

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

В качестве мишени в первой версии Гуся выбран маломощный лазер, отражающийся на стенах в виде красной точки и установленный на вращающейся платформе. В перспективе на место лазера напрашивается лазерный проектор, проецирующий цели с анимацией и разной формы. Пока же разнообразие целей обеспечивается несколькими программами движений с разными настраиваемыми характеристиками, которые объединяются в сценарии. Предполагается, что сценарии могут быть созданы как разработчиками, так и пользователями и проигрываются с SD карты устройства.

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

Программное окружение и облачная инфраструктура в перспективе позволит объединить все устройства в локальную или глобальную сеть с библиотекой сценариев и программами тренировок. Показания с датчиков устройств сохраняются в процессе тренировки и могут быть загружены в мобильное приложение или облако для анализа результативности тренировок и разработки новых упражнений, нацеленных на отработку конкретных навыков. Наша фантазия по применению таких данных не знает границ, так как много лет занимаемся разработкой инфраструктуры для крупных систем анализа информации, на Хабре были опубликованы статьи про Социальный монитор и Cubisio.

Собирая статистику промахов и попаданий, показания с гироскопа и акселерометра, путем нехитрых вычислений и машинного обучения, можно получить множество полезных показателей. Сравнивая эти данные с результатами разных программ тренировок становится возможным выявление наиболее эффективных. Это с одной стороны. С другой развитие в сторону коллаборации пользователей и объединение в своего рода социальную сеть с тренерами и стрелками, программами упражнений, игровыми уровнями, соревнованиями и рейтингами. Гусь в таком представлении выполняет роль терминального устройства для взаимодействия пользователей удалённо.

Arduino, STM32, ESP32 - о железяках...

Техническая глава для тех, кто любит возиться с устройствами или во всех подробностях разбирать по косточкам.

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

Будучи опытными программистами, но новичками в электронике, мы двинулись в неизвестность как обычно, от простого к сложному, преодолевая трудности и неизбежно натыкаясь на непредвиденные неприятные сюрпризы.

Первая же попытка собрать прототип на отладочной плате и написать программу не увенчалась успехом. Скудный объем оперативной и Flash памяти контроллера Arduino не позволил даже запрограммировать движок проигрывания сценариев, не говоря уже о подключении сенсорного экрана, беспроводных датчиков и видео модуля с распознаванием.

Обсудив с коллегой, мы решили закончить войну с ардуинкой за ресурсы и попробовать микроконтроллер STM32. Взвесив все за и против, решено было для начала взять также отладочную плату, но сразу помощнее, так как наши амбиции росли, а планируемый функционал расширялся. Популярная BluePill на STM32F103 на фоне возросших амбиций уже тоже смотрелась слабовато. Поэтому пока мы остановились на плате WeAct на STM32f411 c 512Kb Flash и 128Kb оперативной памяти.

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

Шина питания и автономность

По задумке устройство однозначно должно быть автономным с запасом питания минимум на час-два активной тренировки. При этом по схемотехнике шина питания должна включать как минимум две линии линия стабильного напряжения 3.3В и линия ~5-6В для питания сервоприводов.

Первая идея была простой взять за основу вариант с последовательным 2S подключением пары аккумуляторов 18650. Имея до 9В на выходе, ставим понижающий импульсный преобразователь, формирующий стабильные 5-6 В шины сервоприводов, и к ней же в свою очередь подключаем отладочные платы микроконтроллеров (у них на бору вариант стабилизатора AMS1117).

Вариант оказался абсолютно не из той оперы... Во-первых, сервоприводы при движении создают помехи, которые сгладить не просто, конденсаторы тут не помогали. Во вторых, сложности с зарядкой. Требовалось дополнительно ставить модуль балансировки заряда и подбирать подходящий блок питания. А хотелось-то сделать "как у всех" поддержать стандартную зарядку USB Type-C.

Взвесив за и против, мы выбрали путь повышения напряжений и схему параллельного подключения аккумуляторов 2P. Тем более, что под руками оказалась замечательная плата TP4056 в варианте с USB Type-C, с ней проблема контроля заряда и разряда аккумулятора оказалась закрыта.

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

На выручку пришли старые добрые линейные стабилизаторы серии LM780x. Со стабилизатором LM7805 и парой конденсаторов линии питания наконец стали ровными, не зависимо от работы сервоприводов.

Но и это решение не обошлось без компромиссов. Оказалось, что иногда попадаются сервоприводы (мы выбрали MG995), которые не работают от 5В принципиально при нижнем пороге по даташиту в 4.8В. При этом попытка поднять напряжение и заменить линейный стабилизатор на LM7806 делало схему нестабильной (в некоторых случаях потребляемые токи превышали какой-то предел, после которого возникали скачки или падение напряжения в линии питания с уже известными последствиями).

Голова целеуказателя и видео-модуль

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

В качестве первого и пока устоявшегося варианта на эту роль отлично подошла плата ESP32-CAM. Одновременно на этот же модуль была возложена вся коммуникация, Bluetooth (BLE) для взаимодействия с насадкой-контроллером и датчиком спуска на оружии, а WiFi для интеграции с облаком и обновлений.

Взаимодействие основного микроконтроллера и видео-модуля внутри Гуся осуществляется по проводам через последовательный интерфейс SPI, а также для удобства из головы в основной корпус была выведена дополнительная шина для отладки и прошивки видео-модуля без разбора.

Насадка-контроллер и датчик спуска

В качестве начинки для насадки-контроллера сразу решено было использовать знакомый ESP32, но на этот раз ESP32-WROOM-32 без отладочной платы. Bluetooth (BLE) для связи насадки с базой, а сам микроконтроллер для обработки показаний с датчиков гироскопа/акселерометра и распознавания голосовых команд с микрофона.

Датчик спуска (курка) решено было реализовать в виде внешнего модуля на трех проводах с подключением через разъем наушников MiniJack. В идеале датчик спуска должен крепиться на спусковую скобу, не мешая производить выстрелы, и фиксировать пересечение спусковым крючком луча оптопары.

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

Питание в навесном устройстве также оказалось задачей не с самым очевидным решением.

Время автономной работы должно быть сравнимо с базой, при этом достаточно иметь одну шину питания со стабильными 3.3В. С учетом наличия мощного зеленого лазера и прожорливого при беспроводной работе ESP32, стабилизатор должен выдавать ток хотя бы до 750мА.

Здесь напрашивается несколько вариантов. Первый и самый простой использовать стабилизатор на 3.3В (тот же AMS1117) и работать с аккумулятором в верхней половине заряда. Другими словами, заведомо использовать более мощный аккумулятор, но разряжать его не ниже допустимого для стабилизатора минимального напряжения. Второй вариант использовать buck&boost преобразователь, способный выдавать стабильные 3.3В как при большем, так и меньшем входном напряжении классно и удобно. Но на практике этот вариант оказался дорогим в реализации, такие чипы сложно найти в наличии и они бьют по цене устройства. И третье решение в лоб использовать дешевый повышающий преобразователь на 5В и после него понижающий стабилизатор на 3.3В.

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

Включение и выключение устройств

Следующим моментом, непосредственно влияющим на автономность устройства, оказалось управление питанием, а именно, как будет реализовано включение, выключение и спящий режим.

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

В базе Гуся выключение было решено реализовать максимально просто добавлением тумблера в разрыв проводника между самодостаточным модулем зарядки TP4056 и повышающим преобразователем на материнской плате устройства. В результате тумблер отключает от батареи всю внешнюю нагрузку вместе с основным питанием микроконтроллера, который имеет RTC модуль с подключенной часовой батарейкой на плате.

В насадке-контроллере Гуся подобный тумблер применять было бы не эстетично. Здесь напрашивается всего одна тактовая кнопка и для управления питанием, и для управления устройством во время работы. Было решено спроектировать схему на транзисторе, которая будет одновременно выполнять несколько функций:

  • удерживание кнопки при выключенном устройстве включает;

  • включенный микроконтроллер состоянием пина управляет ключевым режимом транзистора на линии питания;

  • кнопка при включенном устройстве работает как тактовая, подключенная к входному пину микроконтроллера;

  • длительное удерживание кнопки при включении устройства вводит прошивку в режим обновления;

  • нажатие на дополнительную копку принудительно отключает питание, переводя транзистор в закрытый режим.

Данная схема реализована пока только в теории, хотя и проверена на симуляторе, но планируется ее применить в следующей версии платы насадки-контроллера. Возможно, сообщество Хабра подкинет хорошие идеи или поможет обнаружить незамеченные косяки.

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

Калибровка лазера

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

В результате пары дискуссий и нескольких визуальных умозаключений был найден, как в таких случаях чаще всего бывает, самый простой и одновременно самый подходящий вариант. Механизм включает всего одну петлю из тонкой пружинной проволоки для давления по двум осям и пару регулирующих винтов со втулками, скрыто вмонтированными в корпус. Устойчивость и стабильность конструкции достигается мягкой опорой, полученной литьём силикона в форму.

Лабораторная птица

Гусь амбициозен, но молод и скромен. Многому ещё Гусю нужно научиться и набраться опыта, сменить оперение и вырасти на потеху всем охотникам и стрелкам. На волю Гусю хочется, но пока в лаборатории ему теплее и комфортнее.

Таких Гусей будет мало, самые первые самые ценные, уникальные. Понаблюдаем за ними, потренируем, и в тираж полетит птица вольная. А пока ограничимся главным.

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

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

На текущем этапе мы реализовали все основные технические решения, некоторые из которых еще стоит доработать. Полностью разработали дизайн корпусов, подготовили модели для 3D печати и литья. Мы подобрали комплектующие и воспроизвели почти весь цикл производства устройства своими силами в условиях "гаража", собрали первый рабочий экземпляр, вместе с которым вскоре шагнём на следующий этап выход на рынок. Но в этом нам потребуется помощь, заинтересованность потенциальных пользователей и вовлечённость специалистов.

Гусь в Facebook, VK, Intagram, Telegram.

Подробнее..

Русские программисты не сдаются-2

25.04.2021 08:16:54 | Автор: admin
image

Главное в следственных действиях
это не выйти на самих себя.
Генеральный прокурор СССР


Часть 2-я:

Учитывая тупиковую ситуацию, решили написать о своей проблеме в администрацию Президента РФ, авось помогут. В своём обращении мы ссылались на жёсткие действия американской компании Apple не только в отношении российских программистов, но и российской компании, в течение ряда лет инвестировавшей деньги в отечественные разработки. В письме мы попросили вмешаться и по возможности дать указание соответствующим службам разобраться, придав разрешению проблемы ускорение. Ровно через 3 дня на почту пришло письмо-указание: в Минцифру, в ФАС и ответ заявителю.

Из-за того, что в формулировке нашего письма к Президенту РФ было указано доминирование на мировом рынке в области , нашим вопросом занялись в ФАС. Была некая надежда, что суровые российские органы призовут американцев сообщить очевидные причины отзыва лицензий, и мы хотя бы докопаемся до истинны.

Когда я решил уточнить статус обращения, ответственный специалист ФАС по телефону резонно отметил: А где гарантия, что вы сами не несёте всякую пургу на уважаемую компанию? Покажите оригинальные письма от Apple, докажите, что именно ваш аккаунт был заблокирован на основании официального решения Apple и желательно, чтобы мы видели, что письма от Apple пришли именно на ваш аккаунт действительно с аккаунта Apple и т.д. К тому времени мой аккаунт в Apple был полгода надёжно заблокирован уважаемой компанией, и внутренняя переписка не велась. В тот момент мне захотелось разразиться запретным восклицанием.

И вот однажды случайность навела меня на идею. Общаясь с нотариусом по своим рутинным делам, я припомнил, что не могу подтвердить электронную переписку с компанией Apple. Ведь эта компания без объяснения причин, точнее без фактов, предъявленных нам, под неизвестным предлогом занесла нашу компанию в разряд мошенником и плагиаторов лишив тем самым лицензий разработчика ПО, пускай и на её собственной платформе iOS. Нотариус дал хороший совет. Оказывается, в России разработано специализированное ПО для нотариата, благодаря которому возможно нотариально, пошагово зафиксировать в результате специальной процедуры, всю или почти всю переписку в сетях Интернет между конкурентными абонентами.

На следующий день я лечу в рекомендованную нотариальную контору, где есть специалист по кибернотариату. Не буду вдаваться в детали процесса, опишу его так. Мы с нотариусом открываем на компьютере нотариальной конторы исследуемый почтовый аккаунт и отслеживаем последовательную цепочку файлов переписки, из чего в последствии складывается однозначная запротоколированная и юридически оформленная процедура осмотра в виде Протокола осмотра, заверенная подписью и печатью Государственного нотариуса. Далее оформляется апостиль англоязычной переписки (дабы в ФАС прочитали переписку на русском) форма официального подтверждения документов для надлежащего признания их юридической силы во всех странах, присоединившихся к Гаагской конвенции от 5 октября 1961 года.

В итоге, для ФАС была собрана солидная папка файлов, в которой находились: нотариальные документы, заверенные копии наших патентов на изобретения в России и в США. Патенты на полезные модели, на товарные знаки, свидетельства о регистрации программных кодов для ЭВМ и ещё куча других необходимых бумажных носителей. Эти документы должны были дезавуировать якобы нарушения чьих-то авторских прав, а также опровергнуть вопрос спама и мошенничества с нашей стороны. Тот факт, что иконки пользовательских приложений, хотя и имели в нашем случае определенное сходство с логотипом DO-RA, были наделены специальными префиксами, выполняющими, по мнению Apple функцию спама. На самом деле, клиентское ПО было произведено для разных типов гаджетов. А именно: с аудио, цифровыми, BLE протоколами обмена данных гаджета и смартфона или иного девайса. Ведь также Apple маркирует свой модельный ряд смартфонов префиксами 3G, 3GS и своего ПО 7.0 14.4.2 и т.д.

В итоге, собранный пакет документов от компании Интерсофт Евразия был отправлен в ФАС для ознакомления по нашему делу. На основании предоставленных документов ФАС в ноябре 2020 г. сделал запрос в Apple. На ответ в ФАС американская компания попросила 3 месяца. После чего в феврале 2021 года пришло общение от Apple с комментариями причин, по которым был впервые лишён девелоперской лицензии разработчика на платформе iOS/Apple наш ведущий программист Вадим Башуров, более известный в среде Habr под ником PapaBubaDiop. Так на рутинное выяснение причин, явившихся спусковым крючком для последовательного лишения всей команды проекта DO-RA лицензий с блокировкой аккаунтов включая саму компанию intersofteurasia.ru, ушло 2 года!

Причины блокировки аккаунта и отзыв лицензии Apple нашего коллеги привожу дословно, это крайне важно для объективного установления первичных причин, а также для рассеивания возможных заблуждений в собственной невинности. Могу лишь заметить, что позиция Apple нас отрезвила и заставила серьёзно задуматься над проведением дополнительного собственного внутреннего расследования.

Из письма Applе ФАС: Согласно пояснениям Apple Inc., приложение DO-RA.Pro было удалено из App Store после прекращения аккаунта его разработчика Вадима Башурова 17 июня 2019 г. Аккаунт В. Башурова bashurov@mail.ru был заблокирован, поскольку с него было направлено пяти другим аккаунтам пять приложений, которые изменяли свой функционал с обычных игр на незаконные азартные игры. Это изменение происходило после того, как эти игровые приложения прошли проверку App Review (приложения Jaws-2, Clicasso Bugs, Half of Clash, 16s, Match Tri, которые были переданы В. Башуровым на другие аккаунты в январе-апреле 2019 г.). Данные действия противоречат кодексу поведения и руководств App Store, в частности, пунктов 3.2(f), 11.2(f) лицензионного соглашения Apple с разработчиками.

Наконец мы узнали, где собака зарыта, и попросив кодера восстановить до мельчайших подробностей причины, которые могли бы привести его к первой чёрной метке от Apple. Получив от Вадима Башурова подробные пояснения, мы поняли, почему остальные владельцы лицензий были лишены привилегий разработчика ПО на мобильной платформе Apple. С другой стороны, из пояснений нашего кодера следовало что факты, на основе которых он был лишён лицензии Apple в некотором смысле сравнимы с предъявлениями претензий к бывшему владельцу автомобиля со стороны ГБДД. Бывает так, что ГБДД выставляет штрафы за правонарушения совершённые уже после продажи автомобиля новым физическим лицом, бывшему владельцу авто. Однако Apple это далеко не ГБДД.

Далее из письма Applе ФАС следовало и другое пояснение-вывод: Из пояснений Apple Inc. также следует, что приложение DORA.Pro было удалено из App Store после прекращения аккаунта его разработчика В. Елина elin.vladimi@gmail.com 18 мая 2020 г. в связи с нарушением пункта 3.2(f) лицензионного соглашения Apple с разработчиками. В июле 2019 г., Apple Inc. был намерен прекратить аккаунт В. Елина в связи с тем, что этот разработчик имел несколько похожих приложений в аккаунте, таким образом осуществлял спам пользователей App Store, а также получил приложение с другого аккаунта (В.Башурова), который был ранее заблокирован. Apple Inc. направил В. Елину предупреждение о его возможном исключении и о возможности подать апелляцию.

В. Елин данную апелляцию подал, после рассмотрения которой Apple Inc. согласился не блокировать аккаунт В. Елина и дать ему возможность исправить нарушения. В частности, В. Елину было необходимо предпринять ряд действий, с тем чтобы обеспечить соблюдение правил App Store: удалить дублирующиеся приложения из своего аккаунта и удалить приложение, которое было получено из заблокированного аккаунта В. Башурова. В. Елину также было указано, что будущие нарушения правил App Store могут привести к удалению аккаунта. Впоследствии, когда Apple Inc. обнаружил, что В. Елин продолжает нарушать лицензионное соглашение Apple с разработчиками, это привело к прекращению его аккаунта в мае 2020 г.

Далее, согласно сведениям Apple Inc., приложение DORA.Plus было удалено из App Store в связи с блокировкой 4 декабря 2020 г. аккаунта компании АО Интерсофт Евразия, с которого это приложение было размещено в App Store. Аккаунт был закрыт из-за наличия связей с ранее заблокированными аккаунтами В. Башурова и В. Елина. Было установлено, что приложение DORA.Plus является единственным приложением, которое было подано с данного аккаунта АОИнтерсофт Евразия, имеет сходные файлы с приложениями DO-RA.Pro и DORA.Pro В. Башурова и В. Елина и почти полностью идентично им. Таким образом, приложение DORA.Plus было удалено, а аккаунт разработчика заблокирован в соответствии с пунктом 11.2(f) лицензионного соглашения Apple с разработчиками, из-за прямой связи аккаунта с другими аккаунтами, которые были прекращены за нарушение правил Apple Inc.


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

Хотя если разбираться по сути, то от нашего кодера ко мне в аккаунт перекочевали рабочие приложения: Do-Ra; DO-RA.Uni; DO-RA.Pro и DORA.Plus, разрабатываемые нашей командой с 2011 год и многократно проверенные службой App Store для разных гаджетов линии DO-RA. А ведь мы писали ПО с различными протоколами передачи данных, когда ещё были живы мобильные платформы такие, как: WP7, JavaME, BlackBerry, Symbian, Bada и др.
В следующей статье будет подробное пояснение, почему мы с высокой степень вероятности не виновны, и что именно могло привести к ошибке, в связи с чем Искусственный интеллект выкинул нам таки чёрную метку.

Продолжение следует
22 апреля 2021г.
Подробнее..

Простой Telegram-бот для получения информации через MQTT

04.05.2021 06:11:43 | Автор: admin

Этот бот был разработан для просмотра информации, находящейся на mqtt сервере внутри локальной сети. Он может работать на одном компьютере с mqtt сервером (в том числе на Raspberry PI или подобном) или отдельно. Задача удалённого управления не ставилась, только предоставление доступа к данным.

Протокол MQTT предназначен специально для использования в различных устройствах автоматики, на нём очень легко организовать телеметрию и сбор данных. Этот протокол поддерживают как "умные" бытовые устройства, так и многие промышленные контроллеры. Также есть множество проектов на ESP8266, ESP32 или подобных платформах.

На mqtt сервере публикуются данные телеметрии с различных датчиков - допустим, это метеостанция и термометры в теплицах. Для их просмотра на десктопе я раньше делал виджет, веб-страницу, потом захотелось иметь эти данные всегда под рукой. Конечно, можно было пробросить доступ к серверу наружу или разместить его в облаке, но тут возникает ещё целый ряд проблем. Тема использования бота в мессенджере для меня не новая - ещё пятнадцать лет назад я использовал ICQ клиента на мобильном телефоне, чтобы с помощью ICQRemote и скрипта на AutoIt переключать треки в Winamp на десктопе. Сейчас средний телефон гораздо мощнее того десктопа и имеет почти столько же постоянной памяти, но проблема внешнего подключения к устройству в локальной сети по-прежнему существует. И боты всё так же отлично справляются с решением этой проблемы. В общем, было решено делать Телеграм-бота, который просто предоставляет по запросу необходимую информацию.

Я не буду рассказывать про регистрацию имени бота и получение токена, так как это всё уже есть в каждой предыдущей статье про телеграм-ботов. Перейду сразу к программе на Python. Она разрабатывалась под Windows, но я не вижу препятствий для её запуска под другими системами - используемые библиотеки python-telegram-bot и paho-mqtt это позволяют.

Настройки программы хранятся в ini файле. В секции TELEGRAM прописывается токен для бота, в секции MQTT адрес и логин/пароль mqtt сервера, а также топик для получения данных (если несколько - через запятую, без пробелов). При запуске бот подключается к mqtt серверу и подписывается на необходимые топики. Глубина вложенности уровней может быть любой. Поступающие данные попадают в словарь alldata, ключом является полный топик:

{'greenhouse/1/temp': '24.76','greenhouse/1/upd': '22.04 18:20:30','greenhouse/2/temp': '22.95','greenhouse/3/temp': '28.91','air/outdoor/1/temp': '17.32','air/outdoor/1/upd': '22.04 18:21:25','air/outdoor/1/pressure': '739','air/outdoor/1/humidity': '58.3'}

При необходимости чтения из этого словаря формируется разбитый на уровни вложенный словарь tree - дерево данных. Это преобразование выполняет функция maketree.

def maketree(group, items, path):    def sep(s):        return s.split('/', 1)    head = [i for i in items if len(sep(i)) == 2]    tail = [i for i in items if len(sep(i)) == 1]    if len(tail) == 1:        return group, tail[0]    gv = groupby(sorted(head), lambda i: sep(i)[0])    return group, dict([(i, path) for i in tail] + [maketree(g, [sep(i)[1] for i in v], '') for g, v in gv])

В результате получается такая структура:

{    "air": {        "outdoor": {            "1": {                "humidity": "58.3",                "pressure": "739",                "temp": "17.32",                "upd": "22.04 18:21:25"            }        }    },    "greenhouse": {        "1": {            "temp": "24.76",            "upd": "22.04 18:20:30"        },        "2": {            "temp": "22.95"        },        "3": {            "temp": "28.91"        }    }}

Из такого словаря очень легко получить нужные данные. Например, температура в 1 теплице находится по адресу tree[greenhouse][1][temp]. Так как данные обновляются намного чаще, чем запрашиваются, преобразование в момент запроса достаточно эффективно. При более частых запросах лучше будет формировать и обновлять такое дерево сразу при поступлении данных.

Затем идёт подключение к серверу Телеграм. Бот предназначен для работы в локальной сети без возможности пробросить необходимый для веб-хука порт, поэтому для подключения он использует Long Polling запросы. Используется библиотека python-telegram-bot версии 12.8, так как в 13 версии разработчики что-то поломали. Установить её можно командой pip3 install python-telegram-bot==12.8

Для упрощения работы с ботом не используются команды: в ответ на знакомое слово он отсылает информацию, на незнакомое выдаёт кнопки выбора. В моём случае кнопок две, они прописаны в функции get_keyb:

def get_keyb():    return [[InlineKeyboardButton('Погода', callback_data='1'),            InlineKeyboardButton('Теплицы', callback_data='2')]] 

А также в словаре, строчными буквами для удобства сравнения:

keys = {'погода': '1', 'теплицы': '2', 'приборы': '3'}

Ключ "приборы" добавлен для отладки, на него ответ всегда "40"

Вариант диалогаВариант диалога

Кнопки можно многократно использовать для обновления информации.

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

Подробнее..

Samsung превратит устаревшие смартфоны пользователей в устройства для управления умным домом

22.04.2021 18:21:21 | Автор: admin

Компания Samsung Electronics Co., Ltd. запускает официальную программу утилизации смартфонов Galaxy. В рамках этой программы корейский гигант предлагает владельцам устаревших физически и морально гаджетов перепрофилировать их, дав новую жизнь.

В новой жизни смартфоны станут элементами систем умного дома. Доступ к сервису получат пользователи из США, Кореи и Великобритании. Программа будет реализована в рамках инициативы Galaxy Upcycling at Home. Сейчас проект вошел в стадию бета-тестирования.

В чем заключается инициатива


Получившие своеобразный апгрейд устройства будут работать через приложение SmartThings. Приложение получит два новых режима: звуковой и световой задействующий датчики телефонов.

Во что превратят устаревшие модели телефонов серии Galaxy:

1. Инструмент присмотра за маленькими детьми со звуковым сенсором как радионяня.


2. Решение по присмотру за домашними питомцами со световым сенсором.


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

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

Чтобы девайсы могли длительное время работать в режиме обнаружения света и звука, Samsung оснастила устройства решениями по оптимизации энергопотребления.

В итоге все устройства будут легко взаимодействовать с широким спектром IoT-систем.

Что еще


По словам вице-президента и руководителя группы SmartThings в Samsung Джайен Джанг (Jaeyeon Jung) интерес пользователей к умным домашним устройствам активно растет, поэтому неиспользуемые устройства Galaxy могут помочь превратить каждый дом в умный.

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

Кроме того, было бы в целом здорово, если бы компания разблокировала загрузчики. Так даже пользователи, не имеющие навыков рутования, смогли бы удалить старые, неиспользуемые приложения и ОС, устанавливая новое и подходящее ПО.

Подробнее..

Recovery mode Русские программисты не сдаются-3

03.05.2021 14:08:04 | Автор: admin
image

О, сколько нам открытий чудных
Готовят просвещенья дух,
И опыт, сын ошибок трудных,
И гений, парадоксов друг,
И случай, бог изобретатель.

А. С. Пушкин


Часть 3-я

После повторного прочтения пояснений Apple я попросил своего коллегу, программиста Вадима Башурова написать мне подробную пояснительную записку по фактам, полученным нами через ФАС. В данной записке наше объективное пояснение возникшей ситуации вокруг девелоперских лицензий от компании Apple. Переведя текст на язык партнёров, мы попытались связаться со службами Apple для пояснений голосом нашей трактовки происшедшего. На основании новых пояснений в службе поддержки Apple нам посоветовали заполнить другую форму восстановление корпоративной лицензии разработчика ПО, куда в дальнейшем вошли наши текстовые файлы.

Пояснительная записка в Apple


1. Башуров Вадим с магазином App Store и компанией Apple работает с 2009 года. За 10 лет им опубликовано, после проверки и одобрения соответствующими службами Apple, более 200 игровых пользовательских приложений и несколько бизнес-приложений. Некоторые из раннее разработанных, но морально устаревших приложений не приносили Башурову В. дохода. По этой причине Башуров В. не обновлял версии этих приложений, а поддерживал только дюжину пользовательских приложений популярных среди пользователей авторских игр.

2. Весной 2019 года Башуров Вадим получил письмо от ранее неизвестного разработчика Я+++й Татьяны, её реквизиты: tanya.+++.ptrvn@gmail.com WhatsApp: +79290499+++, с предложением продать ей несколько приложений для платформы iOS, разработанных В. Башуровым, таких как: Jaws-2, Clicasso Bugs, Half of Clash, 16s, Match Tri, которые он создал и разместил в App Store в период с 2011 по 2014 гг.

3. В магазине Apple: App Store предусмотрена официальная процедура передачи пользовательских приложений transfer app, фактически это передача в первую очередь самого имени приложения и сопутствующих кодов. При этом в оболочке продаваемого приложения, или названия приложения программный код может быть старым родным или вообще отсутствовать. В тот период Башуров В. официально, через магазин App Store Apple, передал эти вышеописанные имена ранее им разработанных приложений покупателю, после чего тогда же согласно правилам Apple, Башуров В. полностью потерял права на эти приложения и их имена.

4. С момента передачи прав и одобрения этой процедуры со стороны Apple, Башуров В. уже не является владельцем этих игр и программных приложений, соответственно, и не имеет прав на любые действия, связанные с ними, и в частности, права менять их исходный код или добавлять в приложения изменения без нового собственника. Это правило и техническая процедура чётко описана компанией Apple в лицензионном соглашении.

5. С момента покупки приложений новый владелец имеет полное право выкладывать свои собственные проекты под этими именами и является единственным законным владельцем данных приложений и соответственно обладает всеми правами на изменения кодов купленного приложения. Только Apple через собственные службы может проверять новые версии игр или приложений, выложенных с этих новых аккаунтов, к которым Башуров В. с официального момента их передачи не имеет никакого отношения. Поэтому процедура передачи имен приложений: Jaws-2, Clicasso Bugs, Half of Clash, 16s, Match Tri была абсолютно законная и официальная и была одобрена Apple. Никакого злого умысла со стороны Башурова В. в передаче этих старых приложений не было. Apple прекрасно знает, что переданные имена и/или приложения принадлежат новому владельцу и никакого отношения к прежнему хозяину, то есть к Башурову В. после момента их передачи эти приложения де-юре и де-факто уже не имеют.

6. Если злоумышленники в 2019 г. каким-то образом ввели в заблуждение или обманули компанию Apple или её службы через магазин App Store, то это безусловно, проблема в безопасности магазина Apple, и последующие меры в отношении данных нарушений полностью лежат на компании Apple и не имеют отношения к предыдущим владельцам или разработчикам. При этом, считаем абсолютно недопустимым подвергать аккаунты Башурова В. и его шефа Владимира Елина и компанию Интерсофт Евразия блокировке, а также лишать их лицензий разработчиков Apple.

7. Замечания по приложению DO-RA/ДО-РА и его версиям, что они якобы являются спамом, также недостоверны и не обоснованны. Пользовательское приложение DO-RA впервые было разработано и выпущено в ноябре 2011 году в App Store и в течении 10 лет распространялась бесплатно по всему миру. Приложения были загружены с платформ iOS и Android более 300.000 раз. Основная задача программы DO-RA/ДО-РА отображать значение радиационного фона в месте нахождения владельца ПО и устройства DO-RA, и соответственно данных, которые поступают в смартфон или телефон от специального устройства DO-RA/ДО-РА через аудио-разъём гарнитуры по аудио или цифровому протоколу. За прошедшие 10 лет было выпущено несколько типов устройств DO-RA/ДО-РА в разных промышленных партиях.

8. Первое устройство DO-RA.Classic передавало информацию при помощи аналогового (аудио) сигнала (протокола). Затем элементная база прибора DO-RA/ДО-РА усовершенствовалась, и появились устройства с аналого-цифровым протоколом, затем с чисто цифровым протоколом передачи данных и наконец, устройство с передачей данных по каналу Bluetooth. Это объясняет наличие одноименных приложений в App Store помеченных префиксами к основному имени DO-RA Uni, -Pro, -Light, -Plus.

9. Пользовательские приложения были разработаны и опубликованы под каждый выпускаемый девайс DO-RA/ДО-РА. В качестве подтверждения факта разработки новых версий программного обеспечения, у компании Интерсофт Евразия есть 14 Свидетельств на программные коды ключевых платформ для устройств DO-RA/ДО-РА, зарегистрированные в Роспатенте (ФИПС). Электронные копии этих Свидетельств также размещены в открытом доступе на официальном сайте компании-разработчика ПО под мобильные платформы iOS и Android: intersofteurasia.ru/o-proekte/liczenzii/svidetelstvo1.html. Сайт компании поддерживается на русском и английском языках.

10. Разумеется, к каждому устройству и соответствующему протоколу ранее выпускалось новое пользовательское приложение DO-RA/ДО-РА, и в частности, для мобильной платформы iOS. При этом, старые версии приложений оставались доступными в магазине App Store, чтобы пользователи старых версий гаджетов DO-RA/ДО-РА могли пользоваться своими устройствами, купленными за деньги. Все эти программы объединены под общим товарным знаком DO-RA/ДО-РА, имеют различные иконки, выполненные в единой цветовой гамме и дизайне. Патент на товарный знак DO-RA защищён в России, Китае и в США: intersofteurasia.ru/o-proekte/liczenzii/patent1.html. Названия приложений хотя и похожи, но различаются по типу протокола-устройства DO-RA, DO-RA.Uni, DO-RA.Pro, DORA.Pro, DORA.Plus, DO-RA.Light.

11. Учитывая вышеизложенное, ни о каком спаме и плагиате, а тем более мошенничестве в отношении пользовательских приложений линии DO-RA или дублировании приложений с различными дизайнерским и программными решениями не может быть и речи. Так за 10 лет разработок у Интерсофт Евразия накопилось с десяток типов устройств DO-RA/ДО-РА, а также соответствующих им пользовательских приложений, объединенных под единым брендом линии DO-RA/ДО-РА.

На наши пояснения и аргументы, а также просьбу о восстановлении девелоперской лицензии под мобильную платформу iOS для Интерсофт Евразия служба Apple ответила отказом. Напомнив, что разработчики в рамках компании Интерсофт Евразия лишены права заниматься разработками платформе Apple сроком на 1 год.

Нашего Президента и его администрацию мы более тревожить не стали, а написали письмо свыше приведёнными пояснениями в Министерство цифрового развития, связи и массовых коммуникаций Российской Федерации. Через неделю наше обращением было передано опять в ФАС для дальнейшего рассмотрения.

Найдя нашего исполнителя в ФАС по телефону, я ещё раз прокомментировал нашу ситуацию с лишением девелоперских лицензий от Apple, оправку письма Минцифру на основе пояснений в Apple и в связи с вновь выявленными обстоятельствами. Чиновник спросил моего разрешения прикрепить эти пояснения к письму Apple и ещё раз набраться терпения. Тем не менее, на основании выше изложенного, мы пришли к собственным предварительным выводам:

Выводы


1. С высокой степенью вероятности, ведущий программист Интерсофт Евразия Вадим Башуров не виновен в предъявленных ему нарушениях регламента и положений лицензионного соглашения прилагаемого к девелоперской лицензии на мобильной платформе iOS/Apple.

2. Highly likely сотрудники, а равно как ИИ компании Apple могли ошибиться в ситуации с передачей через App Store приложений Вадима Башурова новому владельцу. В итоге от имени нового владельца пользовательских приложений: Jaws-2, Clicasso Bugs, Half of Clash, 16s, Match Tri, были совершены правонарушения регламента и положений лицензионного соглашения Apple, которые были несправедливо отнесены к бывшему владельцу приложений В. Башурову. В результате алгоритмической ошибки В. Башурова и записали в мошенники, плагиаторы и т.д.

3. На основании ложных выводов сотрудников или недоработанных алгоритмов ИИ компании Apple был активирован процесс лишения лицензий Руководителя и инвестора проекта ДО-РА/DO-RA Елина Владимира, а также компании-разработчика Интерсоф Евразия. Выше описанные события привел к замиранию проекта на 2 слишним года, потере международных рынков, утрате имиджа и капитализации компании, до сих пор находящейся в реестре Dow Jones для венчурных капиталистов.

P.S. Есть надежда, что после внятных пояснений со стороны Интерсофт Евразия и её программистов, с учётом требований ФАС для Российского рынка, компания Apple более внимательно отнесётся к нашей ситуации. Ведь в результате наших мытарств мы наткнулись в системе Apple на юридическую, программную и алгоритмическую брешь, за что стоит поблагодарить компанию Интерсофт Евразия, её специалистов и восстановить их права на лицензии в полном объёме.


Продолжение следует
3 мая 2021г.
Подробнее..

Алгоритм оценки стиля вождения водителя грузового (коммерческого) автомобиля

15.05.2021 20:20:44 | Автор: admin

2021 год. IoT окружил нас с Вами со всех сторон. GPS/GLONASS трэкерами и всевозможными облачными платформами слежения нас зазывают со всех сторон. Казалось бы, с чего вдруг я решил, что данный пост имеет актуальность?! Но не все так однозначно - давайте разбираться!

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

Логистические компании выстраивают более оптимальные логистические маршруты и казалось бы все движется только вверх и вперед и с каждым годом расходы транспортной компании на топливо должны уменьшаться! Но в жизни получается не так. Несомненно, если сравнивать 1990,2000 и 2010 года, то по мере обновления моделей грузовых автомобилей, расход топлива стремительно сокращался. К примеру для грузовиков 1990 года выпуска при перевозке 20 тонн груза расход топлива 45л/100км считался нормальным. Моделям 2000-х годов удавалось выйти из 40л/100км расхода топлива, а грузовики 2010 годов выпуска уже могли хвастаться расходом 30-35 л/100км пути. Но что происходит сейчас, в 2021году? Современные модели грузовиков заявляют о паспортных расходах в 21....23...25л/100км, но в реальных условиях транспортные компании получают средний расход автомобилей в районе 30-31л/100км. Встает резонный вопрос?

Получается что автопроизводители лгут и их автомобили не стали более экономичными и это всего лишь маркетинговые ходы? На самом деле нет - проблема кроется в другом.

Автопроизводители, как и производители электроники, очень сильно шагнули вперед и автомобили обогнали в своем развитии людей, которые их эксплуатируют. Ситуация стала такова, что люди, управляющие современными грузовыми автомобилями, не могут раскрыть полный потенциал автомобиля с точки зрения расхода топлива.

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

Но, казалось бы, с этим у нас тоже должно быть все в порядке. Практически все навигационные системы и GPS/Glonass трэкеры имеют опцию ECO DRIVING которая должна оценивать водителя. Но вот тут как раз таки маркетинг чистой воды!) Опция вроде бы есть, а вот толку от нее нет!

Проанализировав большую часть предложенных решений на рынке, оказалось, что разработчики не стали заморачиваться над проблемой и взяли в основу довольно примитивную методику оценки:

Алгоритмы ECO DrivingАлгоритмы ECO Driving

Хотел было я дать комментарий к каждому параметру, в чем его + и -, но текста получилось на 3 страницы) В общем, если подвести жирную черту ИТОГО, то эти критерии оценки стиля вождения водителя настолько сильно обобщенные, что более половины ситуаций не анализируются данными критериями, а если и рассматриваются - то без обоснованно штрафуют водителей за ситуации, на которые они не влияют. К примеру критерий Остановки - за рейс Москва - Париж - Москва, автомобиль сделал 157 остановок, из них 54 остановки - это пробки, 82 остановки - это прохождение очередей на границах. 13 остановок - это загрузки/выгрузки/растаможки, и всего 8 остановок были инициированы водителем. А по данной системе оценится он по всем 157 остановкам...) Системы оценки стиля вождения, основанные на схожих алгоритмах больше игрушка, нежели инструмент оптимизации и управления.

Что же, начнем строить свои алгоритмы!

За исходные данные мы берем седельный тягач, с расширенным CAN протоколом, цифровой ДУТ, вариации с количеством ступеней неизнашивающихся тормозных систем и наличие встроенных электронных помощников (круиз контроль, система аварийного торможение, система слежения за разметкой, система учета рельефа местности и пр.) без привязки к марке грузовика. МКПП и АКПП. Электронная педаль газа и наличием системы EBS не старше 2006г.ПО верхнего уровня Wialon. Выбор обусловлен всеядностью платформы с точки зрения телематического оборудования.GPS трэкер с интерфейсами RS,1-wire, BT, CAN BUS. Дополнительные модули RFID, выносной модуль вибраций (удара). И конечно же нам понадобится гибкая логика, что то вроде Easy Logic от Galileosky.

Итак, начнем, пожалуй, с самого энергозатратного с точки зрения автомобиля параметра.

Превентивная езда/ Режим разгона

Данный критерий характеризует способность водителя к предусмотрительному вождению, т.е. умению водителя прогнозировать и предусматривать дорожную обстановку и принимать управляющее воздействие на автомобиль во время разгона до события, а не по факту. Основная задача избегать РЕЗКИХ управляющих воздействий

Пример: водитель начинает движение и динамично разгоняется до ограничителя скорости в 83 км/ч, но тут же быстренько упирается в идущий автомобиль с меньшей скоростью 75 км/ч, а совершить обгон возможности нет и ему приходится тормозить до скорости данного транспортного средства, а затем снова разгоняться и пытаться его обгонять.

Способ реализации алгоритма: после промежутка разгона автомобиля на >=10км/ч, должен следовать равномерный участок графика скорости в диапазоне +-2км/ч.
Система выставления баллов:
22 секунды прямолинейного движения - 10 баллов,
18 секунд - 9 баллов,
15 секунд - 8 баллов
// 22 секунды взяты из расчета 500 метров прямой видимости на дороге

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

Превентивная езда/ Режим торможения

Здесь все аналогично Режиму разгона.

Равномерная скорость движения

Энергия, необходимая для достижения более высоких скоростей, должна поддерживаться как можно дольше, чтобы постоянно поддерживать скорость движения. Лучшая оценка в этом разделе достигается за счет плавания в транспортном потоке и недопущения слишком частых и интенсивных процессов ускорения и замедления.

Анти пример: данный параметр нам нужен для борьбы вот с таким вот графиком скорости автомобиля.

  1. Способ реализации алгоритма: Считается количество циклов изменения вектора скорости. Идеальная езда - один цикл от троганья с места до полной остановки.

    Система выставления баллов:
    10 циклов - 9,0 баллов
    20 циклов - 8,0 баллов

    !. Изменением вектора считается изменение скорости на величину от 2 км/ч до 10 км/ч. Колебания скорости до 2км/ч обусловлено гистерезисом круиз контроля, а изменение скорости на 10 км/ч и более рассматриваем за дорожную обстановку.

Использование педали газа

Когда водитель орудует педалью газа, система управления двигателем отрабатывает нажатие на педаль газа в процентном значение и даже небольшое кратковременное дерганье педалью приводит к подачам порций топлива для отработки желаемого ускорения, но так как автопоезд с массой 40 тонн слишком инерционен, то такие управляющие воздействия не заметны водителю, но приводят к пустой трате топлива. Ошибочно мнение, что автомобиль сглаживает волнения педали для экономии топлива.

Анти пример: Режим движения водителя по проселочной дороге за впереди идущем авто. Он едет примерно с одной скоростью но постоянно мучает педаль газа туда/сюда пытаясь держаться на одинаковом расстоянии до впереди идущего авто.

Способ реализации алгоритма: Считается количество колебаний процентов нажатия педали газа. Идеальная езда - один цикл от троганья с места до полной остановки.
1 цикл - 10,0 баллов
10 циклов - 9,0 баллов
20 циклов - 8,0 баллов
!. Циклом считается изменение нажатия педали газа на величину от 2 до 30% вниз затем вверх. Аналогия как с равномерной скоростью, только анализируем график нажатия педали газа в %.

Разгон

Процесс разгона должен происходить в зеленом секторе оборотов двигателя. Если водитель разгоняется слишком медленно - то АКПП сбрасывает повышенную передачу на 850-900 об/мин, а зеленый сектор работы турбины начинается с 1040об/мин. Если же разгонять автомобиль слишком сильно - то АКПП переключает передачи в диапазоне 1300-1650 об/мин, а это уже выходит за пределы зеленого сектора.

Способ реализации алгоритма:Считаем количество раз превышения двигателем оборотов свыше 1600 и ниже 1050 при затребованной мощности.
! Если в момент превышения мощности не было затребовано, значит это режим наката или торможения моторного тормоза.
10 раз - 10 баллов
20 раз - 9 баллов
30 раз - 8 баллов

Торможение

Тут все сложно...Важно правильно тормозить! Не только важна сила нажатие педали тормоза, но и алгоритм торможения/Замедления автомобиля, поскольку постоянное и длительное очень легкое торможение палит и перегревает колодки, и его можно заменить использованием не изнашиваемых тормозных систем (торможение оборотами двигателя/ретардер/претардер/моторный тормоз/горный тормоз) . Идеальный алгоритм торможения:
1 этап торможения это накат - 10 сек длительность использования
2 этап торможения это Моторный тормоз ступень 1 - 9 сек
3 этап торможения это Моторный тормоз ступень 2 - 8 сек
4 этап торможения это Моторный тормоз ступень 3 - 7 сек
5 этап торможения это Ретардер ступень 1 - 6 сек
6 этап торможения это Ретардер ступень 2 - 5 сек и только после этого жмем на педаль)))
7 этап торможения это Рабочий тормоз 1-30% - 4 сек
8 этап торможения это Рабочий тормоз 30-50% - 3 сек
9 этап торможения это Рабочий тормоз 50-70% - 2 сек
10 этап торможения это Рабочий тормоз 70-100% - 1 сек

!! На разных авто разное количество ступеней моторного тормоза и ретардера.

Балл за одно торможение зависит от количества ступеней, которые водитель выполнил правильно.
1-10 выполнены, то балл 10,00
2-10 выполнены, то балл 9,00
5-10 выполнены, то балл 8,00
7-10 выполнены, то балл 7,00

Остановки

Поскольку трогание с места является одним из наиболее затратных по топливу процессов (около 700 грамм топлива на разгон сцепки полной массы) при движении, количество остановок, которых можно избежать, следует по возможности сократить до минимума. Тут очень важно понимать что общее количество остановок слишком неинформативный критерий! Есть пробки, особенно их много в Европе. Есть очереди на границах, есть погрузки и выгрузки на которые водители не влияют

Способ реализации алгоритма:Считаем количество остановок после 3 км пути. Т.е. остановки через каждые 10 метров игнорируем, это пробки/очереди/загрузки/выгрузки.
5 остановок - 10 баллов
10 остановок - 9 баллов
15 остановок - 8 баллов

Сложность трассы

Не все маршруты одинаковы и количество и процент нажатия педали тормоза при поездке в Азербайджан и в Германию очень отличается и в этом нет влияния водителя поэтому сложность трассы тоже необходимо учитывать
"Средний уклон"
"Средний вес"
"Количество положительных остановок (очереди и пробки)"

Способ реализации алгоритма:
А. Средний уклон - акселерометр
Б. Средний вес - CAN
В. Количество остановок = общее количество остановок за вычетом количество ненужных остановок из п.6

Оценка = (а+б+в)/3

Накат

С этим параметром попроще его уже все хорошо считают. Из практики - хороший накат за рейс плавает в размере 14-16% от общего пути.

Неиспользование помощников автомобиля

В современных автомобилях много очень полезных помощников, которые водители так и норовят выключить в пути, мол мне лучше знать как ехать! К примеру рельеф местности загружен практически в каждый современный автомобиль. В Мерседесе данная система называется PPC, и автомобиль выбирает скоростной режим прохождения гор и поворотов учитывая рельеф. К примеру если после высокой горы будет сразу следовать спуск, то в конце подъема на гору машина перестанет поддерживать заданную скорость и закатится на горку на скорости 50км/ч и начнет потихоньку перекатываться горку а затем разгоняться накатом, но не всем водителям такое по душе. А еще машины теперь любят сами заранее тормозить перед поворотом)

Система РРС сама заранее сбросит скорость перед перекрестком.Система РРС сама заранее сбросит скорость перед перекрестком.

Оцениваем процент пути с включенными системами
А. Режим AUTO ВКЛ (в сравнении с Manual)
Б. РРС ВКЛ
В. Слежение за разметкой ВКЛ
Г. аварийное торможение ВКЛ
Д. Режим ECONOMY вкл (в сравнении с AUTO)
Е. круиз контроль/ограничитель скорости ВКЛ (круиз + ограничитель)
Ё. Усталость водителя ВКЛ
Ж. Слежение за дорожными знаками ВКЛ

Оценка = (А+Б+0,25*В+0,25*Г+Д+Е + 0,25*Ё + 0,25 * Ж)/6

Мощностная диаграмма пути

При движении водителю необходимо избегать диапазонов высоких оборотов при низких нагрузках и диапазонов низких оборотов при высоких нагрузках . Поэтому будем контролить режимы:

Считаем секунда вне селеного диапазона и штрафуем голубчика))) Кстати, зачастую водители чтобы сымитировать повышенный расход топлива, к примеру после установки ДУТ, кидает автомобиль на 10 передачу вместо 12 и едет весь день на 1600 оборотах при малой нагрузке. А тут мы его и подловим) А также здесь будут видны обгоны на скорости.

Вибрация от внешнего датчика вибрации на раме

Этим параметром мы будим приучать водителей бережно относиться к авто и тормозить на лежачих полицейских и ямах в колено.

Способ реализации алгоритма: Устанавливаем внешний датчик вибрации на раме и проезжаем спящий на 20 км/ч, и удар в средненькую яму на скорости 60км/ч. Смотрим показания датчика, определяемся с какой-то критической величиной и все последующие колебания свыше этого значения штрафуем

10,0 0 ударов за рейс
9,00 2 удара за рейс
8,00 4 удара за рейс

Внутренний акселерометр в данном случае не подойдет, т.к. спящие на скорости 60 км/ч пневмоподвеска рама+кабина глотает. А вот колеса становятся квадратными!

P.S.. В заключении нужно сказать, что, анализируя и влияя на водителей в рамках этих критериев возможно максимально минимизировать негативное влияние водителя на расход топлива. Однако не стоит забывать, что помимо стиля вождения на расход также влияет и техническое состояние транспортного средства, и в борьбе за экономию топлива необходимо должное влияние уделять также и техническому состоянию ТС.

Приведу небольшой пример: при закоревании направляющих тормозного суппорта одного из колес на ведущей оси, расход топлива за рейс Минск, РБ-Вольфсбург, Германия Минск, РБ вырос с 24,9 до 29,2 л/100км. Наш менее опытный водитель даже не заметил ничего неладного в пути, т.к. ступица ведущей оси рассеивает тепло через бортовую и масло моста, и колесо грелось сильнее остальных, но не критично больше, а опытный водитель в следующем рейсе жаловался на слабый накат автопоезда и легкий запах паленых колодок после длительного вождения. И стоит отметить, что используемая смазка в направляющих, имеет срок службы 36 месяц, после чего она высыхает и теряет свои свойства.

Но как видим не каждый водитель способен увидеть данные тонкие проблемы, и, следовательно, человеческий фактор необходимо по максимум исключать в нашей работе!)

P.S.

Самый главный вопрос почему стоит прислушиваться к нашему мнению?

  1. Наша компания заняла 1 место в Mercedes-Benz FleetBoard Drivers League среди стран СНГ.

  2. Среднегодовой расход по автопарку за 2020 год 24,6 л/100 км (14 машин, 130-140 т.км пробега на каждый грузовик, 27 водителей)

Подробнее..

Открытый курс молодого бойца по Интернету вещей

31.05.2021 12:16:05 | Автор: admin

Всем привет!

Некоторое время назад мы с партнерами IT Академии Samsung запустили открытый онлайн-лекторий Samsung Innovation Campus по Интернету вещей. В видеолекциях для студентов и новичков мы решили дать правильное, с нашей точки зрения, представление об этой сфере. И это не про обывательское представление о том, что Интернет вещей - это умные чайники и говорящие холодильники и не про пафос цифровизации и мировых перспектив Индустрии 4.0 (тут без нас много сказано). Это про то, что Интернет вещей - это серьезная промышленная область с по-настоящему сложными, масштабными задачами.

О чем были прошедшие еженедельные лекции (записи доступны в YouTube), и о чем еще хотим рассказать в рамках этого небольшого открытого образовательного проекта, читайте под катом.

Интернет вещей в России - область молодая, и университеты еще не успели создать учебный материал для нее. Чтобы работать в IoT, требуются знания нескольких инженерных дисциплин. Но спустя несколько лет эксплуатации IoT-систем, на растущем рынке появилось понимание, почему важно учить кадры, и как усилия архитектора экономят огромные деньги на масштабах даже в сотни устройств.

Не всё гладко с методическими материалами и в целом взглядом на Интернет вещей. Это неудивительно, ведь тема обширная, и авторы пишут о ней в частном контексте своих компетенций и интересов. Например, популярен подход, при котором Интернет вещей рассматривается исключительно как отрасль телекома.

Нам более близка позиция организаторов конференции InoThings++, которая проходила в течение двух лет в 2018-2019 годах (записи выступлений спикеров здесь в свободном доступе на YouTube): каждый доклад раскрывал бизнес-, либо технологическую сторону Интернета вещей в России, а иногда и то, и другое вместе. Спикеры тщательно отбирались и были с конкретным опытом: сами участвовали в разработке и внедрении решений. Однако эти материалы сложны для новичков. Они рассчитаны на подготовленную аудиторию, которая не просто владеет терминологией, но и имеет представление о затрагиваемых технологиях. А есть ли что-то более простого уровня?

Samsung с 2017 года реализует образовательный проект IT Академия, в котором есть трек по Интернету вещей. Это годовой практико-ориентированный курс для студентов вузов-партнеров проекта, который состоит в основном из учебных кейсов и лабораторных работ. На данный момент среди партнеров - 22 вуза по всей России. Однако нам то и дело задают вопрос: как принять участие в проекте, если я - не студент вуза-партнера?

Концепция лектория

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

1. По компонентам системы,

2. По навыкам: железо, софт, обработка данных,

3. По проектной работе и сферам, которые must-have, но они надпроектные (например, безопасность, дизайн, стандартизация).

Основной труд по разработке программы лектория взяла на себя Ксения Сизова - менеджер проектов компании RedBees. Именно практический опыт Ксении был для нас очень важен, она прекрасно знакома с этим бизнесом и его спецификой в России. Кроме того, у нее есть и методический опыт: уже второй год она курирует обучающую программу IoT AM - проект для студентов вузов Санкт-Петербурга, нацеленный на подготовку стартапов и бизнес-ориентированных команд.

Мы решили охватить примерно такой круг тем в следующем порядке:

  1. Общий обзор систем IoT

  2. Оконечные устройства

  3. Транспортные сети

  4. Программная часть

  5. Облачные технологии

  6. Жизненный цикл проекта

  7. Безопасность

  8. Дизайн и UX

  9. Data Science

  10. Стандартизация

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

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

Курс лекций

Все лекции доступны для просмотра в плейлисте Samsung Innovation Campus IoT Lectorium.

Лекция 1. Архитектура и типология систем IoT. Антон Куропятник (Woodenshark), Ксения Сизова (Red Bees)

Первую лекцию учебного курса вели Антон Куропятник, старший продукт-менеджер в компании Woodenshark (IoT R&D), и Ксения Сизова, руководитель проектов в компании Red Bees (IoT R&D).

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

Лекция 2. Как выбрать технологию IoT, чтобы выжать максимум от достоинств и не страдать от минусов. Антон Куропятник (Woodenshark), Ксения Сизова (Red Bees), Юрий Сизов (RedBees)

Во второй лекции к Антону и Ксении присоединился Юрий Сизов, генеральный директор компании Red Bees.

Наши лекторы остановились на первых двух компонентах сети IoT оконечные устройства и каналы передачи данных до базовой станции/граничного роутера. Кратко произвели обзор технологий и протоколов, применяемых в IoT, рассказали подробнее об их характеристиках, плюсах и минусах, а также основных трендах использования.

Лекция 3. Инфраструктура транспортных сетей. Роман Андреев (СПбГУТ).

Изучив первые два уровня IoT-системы, мы стали двигаться дальше, и одно занятие прицельно уделили телекоммуникациям. На этой лекции у нас был специальный гость: Роман Андреев, начальник Научно-образовательного центра Беспроводные инфотелекоммуникационные сети СПБГуТ им. проф. М.А. Бонч-Бруевича - одного из немногих отраслевых телеком-вузов в стране.

В ходе лекции были рассмотрены топологии 2G/3G/4G-сетей, основные производители оборудования и функциональные блоки сети, прохождение аутентификации и вызовов в сетях связи, ядро сети и радиочасть с учетом распределения частотных ресурсов. Если вы всегда мечтали узнать, как устроена антенна изнутри, то эта лекция для вас.

Лекция 4. Программная часть IoT: о чем нужно знать помимо железа. Дмитрий Чудинов (Red Bees)

Здесь мы провели эксперимент и устроили боевое крещение для студента. А почему бы и нет? Глядишь, других этот пример вдохновит. Свой дебют в нашем лектории совершил Дмитрий Чудинов, студент 4 курса, инженер-стажер в компании Red Bees (IoT R&D), выпускник платформы IoT AM. Дмитрий продемонстрировал широкое знание существующих платформ Интернета вещей и наличие опыта работы с ними.

В своей лекции Дмитрий рассказал об архитектуре программной части IoT, о том, как построить и собрать свою платформу, а также, какой джентльменский набор необходим разработчику софта для IoT решений, и с чего лично он рекомендует начать новичкам.

Лекция 5. Облачные технологии в решениях IoT. Кирилл Святов (УлГТУ)

Развивая тему облачных технологий, в лектории выступил Кирилл Святов, декан Факультета информационных систем и технологий УлГТУ (Ульяновск) - нашего вуза-партнера. На своей лекции Кирилл Валерьевич рассмотрел типовые архитектуры программных решений по работе с данными в IoT, технологии граничных и облачных вычислений на примере IBM Cloud. Вторая часть занятия представляла собой практикум: был реализован вариант построения службы по сбору, анализу и визуализации данных, получаемых от устройств интернета вещей с использованием code-less подхода на основе Node-RED в облачной среде IBM Cloud.

Очень полезное и очень насыщенное занятие с примером устройства - посудомоечной машины, отправляющей данные. Было объяснено многое - основы работы с IBM Cloud на примере сэмпла IBM Quickstart, продемонстрирована NoSQL база данных Cloudant с кратким комментарием о том, а в чем вообще суть этого подхода и в чем отличие от стандартных реляционных БД применительно к задачам IoT, и наконец, показан доступ к системе машинного обучения IBM Watson и работа в Jupyter Notebook. То есть проложен мостик и к другим направлениям Computer Science - у нас в IT Академии Samsung как раз есть учебный трек по AI.

Бонус: лекции о предметных областях

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

"Интеллектуальные транспортные системы Умного города", Игорь Ежков (Softline)

С концепцией Умного города нас знакомил Игорь Ежков - руководитель направления Интеллектуальных транспортных систем компании Softline. Мы давно знакомы с Игорем Геннадьевичем, однажды вместе проводили с ним хакатон по NB-IoT на радиофаке УрФУ.

Что такое Умный город? Это умные перекрестки, светофоры, видеокамеры наблюдения, но и нечто большее: технологичный подход к урбанистике, который просто невозможно реализовать как набор разрозненных сервисов. Всё это дает эффект только в комплексе, когда данные собираются и визуализируются на единой платформе. Основной тезис, высказанный спикером, как раз в том и состоял - не нужно изобретать велосипед, изучайте зарубежный опыт в этой области, смотрите, какие готовые платформы есть.

Бонус: лекции-практикумы о технологиях

Другой вариант - лекция о конкретной технологии, будь то протокол связи, платформа или аппаратное устройство. Это очень классный формат, особенно если он сопровождается практикумом.

"Взаимодействие устройств по Bluetooth Low Energy", Олег Пехов (ТУСУР)

В Томском государственном университете систем управления и радиоэлектроники (ТУСУР) наша программа реализуется на факультете безопасности. Поэтому и неудивительно, что на лекции про BLE в рамках практикума был рассмотрен сниффер пакетов. Помимо этого, в лекции были рассмотрены принципы и особенности технологии Bluetooth Low Energy, ее отличие от классического Bluetooth, разновидности устройств и способы их подключения. Лекцию вел Олег Пехов, старший преподаватель кафедры комплексной информационной безопасности электронно-вычислительных систем.

"Платформа SmartThings для Умного дома", Татьяна Волкова (Исследовательский центр Samsung)

Автор этого текста тоже приняла участие в лектории. Я решила показать в стриме, как интегрировать ваше собственное устройство в платформу умного дома Samsung SmartThings. Устройство очень простое - умный светильник на базе ESP8266, подключаемый к платформе по WiFi. Звучит несложно, но занимает вся эта работа около 40 минут - нужно зарегистрировать ваше устройство внутри платформы, скомпилировать и загрузить прошивку, настроить схему авторизации устройства, сделать обмен ключами. Тут получился целый триллер. Не всё сработало с первого раза, но всё-таки заработало.

Дальнейшие планы

На данный момент наш лекторий находится примерно посередине. Какие лекции еще мы запланировали:

  1. Экономика IoT-системы по состоянию на 2021

  2. Жизненный цикл IoT-проекта

  3. Кибербезопасность в IoT: примеры эксплоитов

  4. Как известно, в аббревиатуре IoT буква S обозначает безопасность

  5. Дизайн и UX в IoT-решениях

  6. Краш-тест вашего IoT-проекта: оцениваем идею на жизнеспособность

  7. Есть ли жизнь после релиза? Обслуживание IoT-системы

  8. Data Science в IoT

  9. Сертификация в IoT: стандарты, регуляторика и прочее

Вести их будут разные спикеры, в том числе, не побоимся этого слова, один монстр современного IoT-образования, но не будем пока раскрывать интригу: по завершении лектория, напишем еще один пост-апдейт.

Какие еще важные темы мы не затронули? Чего не хватает в этом тематическом плане? Пишите в комментариях ваши предложения - как бы вы составили идеальную программу лектория по Интернету вещей для начинающих?

Смотрите лекции в рамках стримов на YouTube-канале IT Академии Samsung и смотрите архив в плейлисте Samsung Innovation Campus IoT Lectorium. Задавайте вопросы нашим лекторам, пишите свои комментарии. А может быть, вы сами хотели бы выступить с лекцией по своей теме, которая пока не озвучена - мы готовы предоставить вам слово!

Татьяна Волкова, куратор трека по Интернету вещей социально-образовательной программы для вузов IT Академия Samsung

Подробнее..

Промышленные VS офисные сети построение, защита, подвохи, и как надежно отделить первые от вторых

07.06.2021 18:08:54 | Автор: admin
Привет, Хабр! Этим постом я хотел бы начать серию публикаций по промышленным решениям, которые мы сейчас активно тестируем в нашей КРОК-лаборатории. Для начала попробую разобрать основные вопросы проводных промышленных сетей и показать, чем их построение отличается от классических офисных. В качестве подопытного кролика возьму наиболее востребованное на рынке оборудование и софт от Cisco и разберу их особенности.



Как организовать Ethernet-подключения в промышленных зонах?


Первый и, казалось бы, очевидный вариант, который приходит в голову поставить Ethernet-коммутаторы, соединить их, по возможности, оптикой, и дотянуть от них до подключаемых устройств витую пару.

Здесь возникает первая сложность и первое же отличие промышленных сетей от офисных: большая часть коммутаторов устанавливается не в серверные, а в монтажные шкафы, разбросанные по цехам или по территории объекта. Тянуть от каждого монтажного шкафа по две оптические линии по разным путям дорого и сложно, из-за этого становится сложнее организовать привычную и надёжную звездообразную топологию. Приходится использовать кольца. Каждый, кто погружался в построение Ethernet-сетей, помнит, что кольца из коммутаторов зло. В случае со Spanning-Tree это действительно так. Этот протокол в кольцевой топологии может отрабатывать до 30 секунд, что часто неприемлемо для сетей, обслуживающих производственные процессы. Хуже того, скорость сходимости STP падает с увеличением количества хопов от корневого коммутатора до крайних коммутаторов, и как правило, рекомендуется не превышать расстояние в 7 хопов. Это значит, в кольце должно быть не больше 14 коммутаторов.

Что с этим можно сделать? В случае с коммутаторами Cisco, самое простое решение использовать вместо STP Resilient Ethernet Protocol REP и его модификацию REP Fast. Данный протокол специально предназначен для кольцевых топологий и обеспечивает сходимость сети максимум за 50-100мс при любых типах неисправностей и размерах колец до 50 коммутаторов. Причём 50 коммутаторов в кольце это не предел для такого протокола. Время сходимости при росте кольца конечно будет увеличиваться, но тот же Spanning-Tree на кольцах такого размера не сойдётся вообще никогда. REP поддерживается не только в промышленных коммутаторах, но и в офисных, в частности в серии Catalyst 9000, которые могут служить в качестве коммутаторов агрегации.

Протокол очень прост в настройке, вот пример:



Для более сложных случаев доступны протоколы PRP и HSR. Они предполагают полную дупликацию трафика по двум путям в сети. При отказе одного из путей потерь в передаче данных не возникает вообще. Однако и стоимость реализации такой устойчивости выше протокол поддерживается только в старших моделях и только промышленных Ethernet-коммутаторов (IE3400, IE4000, IE4010, IE5000). Впрочем, требования к надёжности и сходимости промышленной сети, как правило жёстко определяются характером производственного процесса, который эта сеть будет обслуживать. Один простой даже в 50 миллисекунд порой может стоить дороже, чем хорошее сетевое оборудование.

Как обеспечить требуемую надёжность работы?


Как правило требования по надёжности и отказоустойчивости к промышленному сегменту сети выше, чем к офисному. Промышленное сетевое оборудование делается и тестируется так, чтобы отвечать этим требованиям. В случае с коммутаторами Cisco, промышленное исполнение означает:

монтаж в компактные шкафы на DIN-рейку, питание от постоянного тока;
защита микросхем и портов от электростатических разрядов до 4000 кВ;
отсутствие вентиляторов высокоэффективное охлаждение конвекцией, несмотря на малый размер устройств;
способность выдерживать скачки напряжения электропитания согласно требованиям сертификаций IEC 61000-4-11, IEC 61850 коммутаторы Cisco продолжают работать при пропадании электропитания на промежуток времени до 50 мс, а при отключении отправляют сигнал Dying Gasp;
высокоточные внутренние часы;
возможность быстро заменить неисправный коммутатор, просто переставив SD-карту в новый (при этом новый коммутатор поднимется не только с тем же конфигом, что и старый, но и с тем же образом IOS);
быстрая загрузка (в пределах 80 секунд);
тщательное тестирование на соответствие промышленным сертификациям.


Рисунок 1. Симуляция процесса охлаждения коммутатора конвекцией


Рисунок 2. Тестирование коммутатора на устойчивость к электромагнитным воздействиям


Рисунок 3. Тесты с воздействием водой на коммутатор с уровнем защиты IP67

Часто так бывает, что промышленные коммутаторы подключаются к обычным офисным, как к коммутаторам агрегации и при отказе последних промышленный сегмент перестаёт работать. Чтобы такого не допустить, необходимо обеспечивать агрегацию промышленных коммутаторов, расположенных в цехах или по территории промышленного предприятия, на специальных промышленных коммутаторах агрегации. Cisco для этой цели предлагает коммутаторы серии Cisco IE5000:



Они монтируются в 19-дюймовый шкаф, могут питаться и от постоянного и от переменного тока, обеспечивают высокую плотность портов, высокую производительность, но при этом промышленную надёжность и поддержку промышленных протоколов, например PTP, PRP, HSR, PROFINET MRP. Как и другие коммутаторы промышленной линейки, Cisco IE5000 умеют принимать сигналы тревоги от устройств автоматики, например, устройств контроля климата или датчика открытия двери в помещение, и отдавать их например для включения сирены и светового оповещения, помимо, конечно же, SNMP и Syslog-сообщений о состоянии коммутатора, отсылаемых в системы мониторинга. Кроме того, эти коммутаторы поддерживают стекирование через 10G-порты. Вот пример построения сети с использованием REP-колец и коммутаторов IE5000 в качестве агрегирующих:



Поддержка промышленных протоколов


В промышленных Ethernet-сетях используются Ethernet-версии различных промышленных протоколов: PROFINET, CCLINK, CIP и т.п. При этом, как правило, от сетевого оборудования требуется поддержка таких протоколов в том или ином виде. К примеру, при использовании PROFINET, требуется управлять с помощью этого протокола не только контроллерами, сенсорами или исполнительными устройствами, но и самими коммутаторами, образующими сеть. Для этого в моделях промышленных коммутаторов Cisco начиная с IE3000 реализована поддержка работы по PROFINET в качестве устройства ввода-вывода. Кроме того, некоторыми моделями коммутаторов Cisco можно управлять с помощью портала Siemens TIA.

Ещё один пример промышленного стандарта, поддержка которого часто требуется Time-Sensitive Networking (TSN). Это набор стандартов Ethernet, позволяющий обеспечить доставку Ethernet-фреймов с предсказуемой и не меняющейся во времени задержкой. Привычный Ethernet, напомню, работает асинхронно и фреймы в нём доходят до адресата настолько быстро, насколько получается. Функционал TSN протокол поддерживается в коммутаторах Cisco IE3400, IE4000, IE4010 и IE5000.

Как защитить промышленную сеть?


Многие стандарты и рекомендации построения промышленных сетей предусматривают реализацию демилитаризованной зоны ДМЗ между офисной и промышленной сетями. В этой зоне могут располагаться рабочие станции для удалённого доступа к промышленным компонентам. Есть целый ряд рекомендаций по построению такой ДМЗ, например:

трафик не должен проходить между офисной и промышленной сетями насквозь;
любой протокол, разрешённый между ДМЗ и промышленным сегментом должен быть в явном виде запрещён между ДМЗ и офисным сегментом;
в промышленный сегмент сети не должно быть доступа из интернета, даже через межсетевой экран;
И конечно никаких Any в полях для IP-адресов, портов и протоколов в политиках межсетевого экрана.

В идеале ДМЗ должна быть устроена так что если её физически отключить от сети, промышленный сегмент продолжит работать.

Промышленный, офисный и ДМЗ-сегменты отделяются друг от друга межсетевыми экранами. Здесь у Cisco явное преимущество на её продуктах можно построить защищённую сеть от и до.
Межсетевые экраны Cisco умеют распознавать не только промышленные сетевые протоколы:







но и промышленные устройства, подключённые к сети:



А также обнаруживать, разрешать или запрещать конкретные действия в рамках данных протоколов:



Это позволяет выстраивать политики межсетевого экранирования не только на базе IP-адресов и TCP/UDP-портов, но и на базе наименований конкретных моделей устройств и протоколов взаимодействия между ними. Для большинства ситуаций в межсетевом экране есть преднастроенные правила, которые можно использовать с собственными параметрами. Такими правилами можно защищаться не только от преднамеренных атак, но и от дурака ошибочно подаваемых на промышленные устройства команд.

Межсетевые экраны обеспечивают так называемую макросегментацию сети разделение на крупные участки, трафик между которыми либо запрещён, либо фильтруется через правила межсетевого экранирования. Таким образом отделяются друг от друга не только ДМЗ, промышленный и офисный сегменты сети, но и, например, разные цеха и производственные линии в промышленном сегменте. Для последней задачи может пригодиться межсетевой экран Cisco Industrial Security Appliance (ISA) полноценный фаерволл в промышленном исполнении.



Как правильно обеспечить удалённый доступ?


Как правило, в промышленных сетях требуется обеспечивать удалённый доступ для организаций, обслуживающих оборудование АСУТП. При этом, важно хорошо контролировать кому и куда такой доступ предоставляется и защититься от доступа несанкционированного. Удалённый доступ осуществляется через описанную выше ДМЗ.

Здесь, помимо межсетевых экранов Cisco Firepower, огромную помощь может оказать решение Cisco Identity Services Engine. Межсетевые экраны обеспечивают подключение с помощью AnyConnect VPN или проксирование трафика удалённого рабочего стола, а ISE позволяет максимально чётко идентифицировать и человека, получающего доступ и объект в сети, к которому этот доступ предоставляется, а также определить политики такого доступа в виде своего рода матрицы:



Кроме того, система предотвращения вторжений межсетевых экранов Cisco позволяет выявлять и блокировать атаки, связанные с промышленными протоколами. Речь здесь не только о ситуации, когда специалист производителя осуществляет какие-то злонамеренные действия в сети заказчика, но и о том, что компьютер специалиста производителя и сервер удалённого доступа, которым он пользуется, могут оказаться заражены вирусом, который пытается открывать несанкционированный доступ третьим лицам-злоумышленникам.





Как выполнить требования регуляторов?


Стандарты международных организаций и дизайн-документы Cisco Validated Design только дают рекомендации как лучше. Но кроме рекомендаций есть ещё и требования регулирующих органов, которые необходимо выполнять при построении промышленных сетей. В России к таким относится приказ 239 ФСТЭК Об утверждении требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации. Он содержит перечень архитектурных решений функционала, которые должны быть реализованы.

Часть требований приказа, такие как наличие межсетевого экрана и обновляемого IPS на периметре промышленного сегмента, сегментация сети, организация ДМЗ закрываются межсетевыми экранами Cisco Firepower, описанными выше. Требования по аутентификации и авторизации Cisco ISE. Далее, целый набор требований, связанных с мониторингом промышленной сети закрывается решением Cisco CyberVision.

Решение Cisco CyberVision может собрать данные с промышленной сети в виде SPAN-трафика или со специальных сенсоров в сетевых устройствах и представить картинку происходящего администратору, а также отправить необходимую информацию в системы управления конфигурациями и SIEM. Администратор сети может получить полный список устройств, подключённых к промышленному сегменту сети (не только Ethernet-коммутаторов, но и устройств промышленной автоматики), проверить их на известные уязвимости и отследить их поведение.


Рисунок 4. Пример отображения известных уязвимостей для промышленных устройств

Еще детальнее тему проводных промышленных сетей будем разбирать на вебинаре 22 июня, если хотите записаться, можно зарегистрироваться здесь
Подробнее..

Контроль сонливости водителя и кресла с учётом женской анатомии что нового в автомобильных технологиях безопасности?

09.06.2021 14:20:05 | Автор: admin

В 1959 году компания Volvo стала оснащать свои автомобили трёхточечным ремнём безопасности, а затем поделилась этой технологией со всеми производителями. Спустя десятилетие появились подушки безопасности, которые после тестов внедрили в серийные автомобили. От ремней до контроля поведения водителя, от пассивной до активной безопасности: какие технологии создали в последнее время и какие из них считаются одними из эффективных, рассказываем в этом материале.

Active safety и ADAS

Автомобили оснащаются электроникой, датчиками, сенсорами, радарами, которые позволяют чувствовать себя на дороге чуть более спокойными. Одна из них технология active safety это различные стабилизационные системы, которые берут на себя управление автомобилем в критических ситуациях.

ADAS (Advanced driver-assistance systems) включает ряд функций, таких как адаптивный круиз-контроль, стабилизационные системы, автоматическое экстренное торможение, обнаружение слепых зон, предупреждение о столкновении, предупреждение о перекрёстном движении и система удержания полосы. Автомобили могут определить, покинули ли вы свою полосу движения, упустили ли из виду пешехода или животное на дороге, помогут с парковкой в неудобных ситуациях.

Эксперты считают, что автомобили, оснащённые ADAS, снизили количество аварий и спасли жизни. Согласно исследованию LexisNexis Risk Solutions, владельцы автомобилей с системой ADAS на 27% реже обращались по поводу телесных повреждений и на 19% реже обращались по поводу повреждения имущества.

Возможное снижение количества несчастных случаев по мере роста внедрения ADAS.

Данные страхового института дорожной безопасности (IIHS) и производителей CCC Information Services, показывают, что автомобили, оснащённые ADAS, сокращают количество аварий на 20-50%. Институт прогнозирует резкое снижение аварийности в ближайшие 30 лет благодаря ADAS.

Automatic Emergency Braking

Одним из самых популярных и эффективных ADAS-решений для владельцев машин является автоматическое экстренное торможение (Automatic Emergency Braking). Американский страховой институт дорожной безопасности (IIHS) считает, что системы AEB предотвратят 28000 аварий к 2025 году.

Эта система использует датчики и камеры для обнаружения потенциального лобового столкновения и измерения расстояния до любого транспортного средства, а затем автоматически включает тормоза. Сокращая время реакции человека на торможение, система AEB может снизить вероятность аварии или, по крайней мере, уменьшить тяжесть удара.

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

20 автопроизводителей согласились включить в свои автомобили автоматическое экстренное торможение как стандартную опцию к 2022 году. По данным страхового института дорожной безопасности, некоторые компании выполнили обещание, хоть и не идеально. Среди них Audi, Mercedes-Benz, Volvo and Tesla, а также BMW, Hyundai, Mazda, Subaru, Toyota and Volkswagen. Некоммерческая организация Consumer Reports считает, что внедрение технологий для спасения жизней должно быть не добровольным, а обязательным. Они призывают внести в федеральный закон США необходимость оснащения уже созданными технологиями всех новых моделей автомобилей, поступающих на рынок. Компания указывает, что автопроизводители должны сменить вектор и перестать продавать safety technologies как очередную дорогостоящую надстройку, как люк на крыше или модные стереосистемы.

Какие ещё есть системы и приложения?

Помимо экстренного торможения существуют технологии, помогающие наблюдать за происходящим внутри и снаружи. Среди них:

Адаптивное освещение

Ограниченная видимость может затруднить движение в ночное время, особенно по извилистым дорогам. Адаптивные фары улучшают ночное видение за счёт регулировки направления в зависимости от дороги впереди. AFS (Adaptive Front-Lighting System) использует датчики для измерения действий рулевого управления, затем система регулирует наклон и поворот фар, чтобы лучше видеть, куда вы собираетесь. Поэтому, когда водитель поворачивает, у него будет больше шансов понять, куда он направляется, вместо того, чтобы освещать обочину дороги. Кроме того, такая система позволяет избегать попадания прямых лучей на встречные автомобили.

Камера в салоне

К примеру, проект Honda CabinWatch, где используют камеру, чтобы помочь водителям минивэнов внимательно следить за детьми на заднем сиденье. Другие компании и сервисы экспериментируют с программным обеспечением для распознавания лица, чтобы разблокировать автомобиль или определить, когда водитель устаёт или отвлекается. К примеру, так делает Яндекс.Такси с их камерой Yandex Signal Q1, которая анализирует 68 точек на лице человека с помощью технологий компьютерного зрения и нейросети. Она фиксирует различные параметры, например, частоту и длительность моргания.

Мониторинг сонливости

У Jaguar разработана система контроля степени усталости водителя (Driver Condition Monitor), которая определяет признаки сонливости и предупреждает об этом. Она анализирует широкий ряд показателей: отклик системы электроусилителя руля, нажатие на педали газа и тормоза и общее поведение во время управления автомобилем. Алгоритмы изучают полученные данные, чтобы определить момент, когда водитель устаёт. Распознав признаки сонливости, система предлагает остановиться и отдохнуть.

Проекционный дисплей

Heads Up Display позволяет не спускать глаз с дороги, проецируя важную информацию на лобовое стекло автомобиля. Во время движения водитель видит скорость транспорта и GPS-навигацию на приборной панели. Такие дисплеи, например, есть у BMW.

Что может быть не так?

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

Ещё один момент стоимость обслуживания автомобилей с ADAS. Ремонт датчиков, сенсоров, радаров дорог, и иногда только производитель может им заняться.

Пассивная безопасность

Помимо ремней и подушек, к пассивной безопасности можно отнести зоны деформации, поглощающие энергию столкновения. Для введения этих технологий были организованы краш-тесты, которые проводились на телах умерших людей, животных, живых испытателях и манекенах. Помимо самих автопроизводителей, краш-тесты проводят такие ассоциации, как европейская Euro NCAP, Национальное управление безопасностью движения на трассах США (NHTSA) и страховой институт дорожной безопасности IIHS, и похожие ассоциации в Германии, Австралии, Китае и Японии. В разных странах они отвечают за рейтинг безопасности и вывод на рынок новых моделей автомобилей. Тесты проводятся с помощью манекенов и компьютерного моделирования.

Женские манекены

Как раз о манекенах мы и упомянем. В 2019 году статья Guardian Смертельная правда о мире, построенном для мужчин из жилетов к автомобильным авариям вызвала бурное обсуждение. Оказалось, что когда женщина попадает в ДТП, у неё на 47% больше шансов получить серьёзные травмы и на 71% больше шансов получить травмы средней степени тяжести. А всё потому, что в экспериментах никогда должным образом не использовали женский манекен. Он существует, но его тестируют чаще на месте пассажира, а не водителя. И это просто уменьшенная версия мужского манекена, которая не учитывает размеры и состояние грудной клетки, шейного отдела, вес, рост и возможность быть беременной.

Что изменилось за это время?

Шведские исследования показали, что современные сиденья слишком прочные, чтобы защитить женщин от хлыстовых травм: они выбрасывают женщин вперёд быстрее, чем мужчин. Закономерно, что в авангарде решений находится компания Volvo. Они создали инициативу EVA и согласно накопленным данным подготовили систему защиты от хлыстовой травмы WHIPS. Она сочетает прочный подголовник с продуманной конструкцией сиденья для защиты головы и позвоночника. По мнению Volvo, сейчас отсутствует разница в риске травмы между мужчинами и женщинами. Помимо этого, есть инновация SIPS (система защиты от боковых ударов) которая вместе с подушкой безопасности при боковом ударе снижает риск серьезных травм грудной клетки более чем на 50% для всех пассажиров. И не последнее решение от шведов они разработали первый в мире манекен среднего размера для краш-тестов для беременных. Это компьютерная модель, которая позволяет изучить, как движется пассажир, и как ремень безопасности и подушка безопасности влияют, среди прочего, на женщину и плод.

Новая линейка манекенов для краш-тестов под названием THOR доступна давно, но ещё не была официально принята системами оценки безопасности NHTSA или IIHS. По форме они больше соответствуют мужскому и женскому телу и имеют на 100 датчиков больше для сбора данных, чем семейство Hybrid III стандартных манекенов. Женская версия имеет тазовую кость и грудь женской формы.

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

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

Что нас ждёт?

Появляется всё больше решений для более безопасного вождения или сокращения ДТП. Из последних новостей: в Кембридже разработали голографический дисплей для автомобиля. Голограммы появляются в поле зрения водителя в соответствии с их фактическим положением, создавая дополненную реальность по мнению авторов, это может быть менее отвлекающим решением, чем проекционный дисплей.

Никакого алкоголя

Ожидается внедрение технологии, предотвращающей вождение водителями с опьянением Driver Alcohol Detection System for Safety (DADSS) это единственная технология, разрабатываемая для измерения или количественного определения точной концентрации алкоголя в крови. Это решение не позволит водителю, находящемуся в подвыпившем состоянии, завести двигатель автомобиля и управлять им в нетрезвом виде.

География авторынка

Решения будут зависеть и от географии авторынка. Так, Volvo запланирована современные технологии предупреждения о скользкой дороге и аварийной остановке для Северной Америки.

Кибербезопасность

Из-за увеличения количества программного обеспечения в автомобиле игроки рынка автомобилестроения должны обратить внимание на кибербезопасность. Она становится новой гранью качества для транспорта. В скором времени планируется ввод обновленных стандартов и регуляций, касающихся обновления программного обеспечения автомобиля по беспроводным сетям.

Источники материала:

  1. https://www.forbes.com/sites/christopherelliott/2020/10/03/your-car-knows-best-these-new-auto-safety-features-will-surprise-you/

  2. https://www.erieinsurance.com/blog/best-car-technology-features-2020

  3. https://www.volvocars.com/mm/why-volvo/human-innovation/future-of-driving/safety/cars-safe-for-all

  4. https://www.theguardian.com/lifeandstyle/2019/feb/23/truth-world-built-for-men-car-crashes

  5. https://humanetics.humaneticsgroup.com/products/anthropomorphic-test-devices/frontal-impact/thor-5f

  6. https://www.mckinsey.com/industries/automotive-and-assembly/our-insights/cybersecurity-in-automotive-mastering-the-challenge#

  7. https://cccis.com/wp-content/uploads/2020/12/CCC-Crash-Course-2020.pdf

Если вы разбираетесь в теме технологий и вам нравится сфера автомотив, у нас открыты интересные вакансии. Мы ищем С/С++ разработчиков, QA автоматизаторов, архитекторов и других специалистов. Все вакансии в автомотив практике в Luxoft по ссылке

Подробнее..

4G-камера с детекцией человека

18.06.2021 22:18:25 | Автор: admin
Эта камера не требует Wi-Fi или кабельного интернета: в неё вставляется симкарта.
Она позволяет просматривать на смартфоне из любой точки мира живое видео, а также записи, сделанные при появлении человека в кадре.




Это одна из самых дешёвых 4G-камер на Aliexpress. Сейчас она стоит $58, на распродажах цена может падать до $52.

Камера работает только через мобильный интернет. Она не поддерживает Wi-Fi и не раздаёт его, разъём RJ-45 на кабеле никуда не подключён.

В комплекте блок питания 12V 2A. Камера потребляет около 210 мА в дневном режиме и около 345 мА в ночном режиме, когда работает ИК-подсветка.



Подсветка сделана на двух мощных ИК-светодиодах.



Снизу герметичный лючок, под которым есть слоты для NanoSIM и MicroSD. На лючке микрофон и динамик.



Корпус металлический, всепогодный. Передняя панель пластиковая. Недостаток такой конструкции в том, что камеру невозможно сдвигать влево-вправо относительно площадки крепления. Только вверх-вниз и вращать вокруг оси.

Мне не удалось разобрать камеру: нужно снимать переднюю панель, которая скорее всего приклеена.

Камера работает с приложением CamHI. Добавляется камера очень просто: нужно в приложении отсканировать QR-код с наклейки на боку камеры.

Настройки и режимы такие же, как у камеры (Zilink), но есть одно важное отличие: у этой камеры есть детекция человека в кадре, а значит запись по движению не будет срабатывать от колышашихся на ветру веток и пролетающих птиц.



Когда камера видит человека, в окне просмотра появляется рамка вокруг него.



Матрица в камере стоит китайская и на честные FullHD 1920x1080 можно не рассчитывать, но для того, чтобы следить, всё ли в порядке на объекте, качества вполне достаточно.



Пример записи по детекции человека. Я вышел из-за угла, камера начала запись примерно через секунду. Для проверки записи звука я спрашиваю, слышно ли меня. :)


www.youtube.com/watch?v=yxZC6YG_0D4.

Камера потребляет менее 64 КБ трафика в час, когда приложение не запущено. Неторопливый просмотр текущей картинки и трёх роликов, записанных по движению, потребовал 23 МБ. Если использовать камеру, ежедневно запуская просмотр, потребуется около 1 ГБ трафика в месяц, при еженедельном просмотре будет достаточно и 200 МБ. Я использовал камеру с симкартой Билайн с тарифом Связь Z, который наиболее выгоден для использования в камере.

Камеру можно сделать полностью автономной, если оснастить её аккумулятором и солнечной батареей.

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

2021, Алексей Надёжин
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru