Timeweb

Приветствую, коллеги! Меня зовут ProstoKirReal, и сегодня я хочу обсудить с вами физический уровень (L1) модели OSI. Понимание этого уровня является основополагающим для всех, кто только начинает свой путь в сетевых технологиях.

❯ Что такое физический уровень?

Физический уровень (Physical Layer) — это первый и самый низкий уровень модели OSI. Он отвечает за передачу необработанных битов данных по физическим средствам связи, таким как кабели и радиоволны. Этот уровень определяет электрические, механические, процедурные и функциональные характеристики для активации, поддержания и деактивации физических соединений между конечными системами.

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

Бит и байт — это две основные единицы измерения информации в компьютерных системах. Разница между ними заключается в следующем:

❯ Бит

• Определение: бит (bit) является наименьшей единицей информации в компьютерных системах.

• Значение: может принимать одно из двух значений: 0 или 1. Эти значения часто интерпретируются как «включено» или «выключено», «истина» или «ложь».

• Использование: используется для представления двоичной информации и операций на уровне аппаратного обеспечения.
  

❯ Байт

• Определение: байт (byte) состоит из 8 битов.

• Значение: может представлять 256 различных значений (от 0 до 255 в десятичной системе или от 00 до FF в шестнадцатеричной системе).

• Использование: широко используется для представления данных, таких как символы в текстовых файлах. Например, каждый символ в стандарте ASCII кодируется одним байтом.

  
  Примерное сравнение:

• Бит: 0 или 1

• Байт: 8 битов (например, 01101010)

  
  Для запоминания есть старая шутка:
  

Штирлиц поругался с посетителем бара и вышел с ним 1 на 1. На выходе он увидел 8 человек с битами. «Один байт равно 8 бит», — подумал Штирлиц

Выше я писал о двоичной и шестнадцатеричной системе. А для чего они?

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

К примеру предложение «Hello, world!» выглядит как 01001000 01100101 01101100 01101100 01101111 00101100 00100000 01110111 01101111 01110010 01101100 01100100 00100001.
Для повышения читаемости таких массивов данных используют шестнадцатеричную систему. К примеру, предложение «Hello, world!» выглядит как 48 65 6C 6C 6F 2C 20 77 6F 72 6C 64 21.
Уже читабельнее?

То есть 1 бит – 0, 1 байт – 01001000, в 16-ричной 1 байт – 48.

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

❯ Преимущества шестнадцатеричной системы

1. Удобство преобразования: простое преобразование между шестнадцатеричной и двоичной системами.

2. Краткость записи: значительно более короткие записи по сравнению с двоичной системой.

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

4. Принятость в стандартах: широко используется в сетевых и компьютерных стандартах.

Сложно? Еще немного и доберемся до L1.
Еще одно понятие, которое нам будет необходимо для понимания.

❯ Пакет данных

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

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

Итак, про L1 уровень.

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

❯ Основные функции физического уровня

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

Медные кабели передают информацию с помощью электрических сигналов, бывают 1G и 10G медные кабели, типа витая пара. Я был удивлен о наличии 10G меди.

Оптоволоконные кабели передают информацию с помощью световых сигналов.

Беспроводные соответственно передают информацию без проводов, по средством радиоволн.

Модуляция и демодуляция: Преобразование цифровых данных в аналоговые сигналы и обратно.

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

❯ Модуляция (Modulation)

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

❯ Демодуляция (Demodulation)

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

❯ Важность модуляции и демодуляции

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

• Совместимость: благодаря модуляции цифровые системы могут быть совместимы с существующей аналоговой инфраструктурой.

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

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

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

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

Напряжение определяет разницу потенциалов между двумя точками сети. В сетях передачи данных, например, в Ethernet, используются различные уровни напряжения для кодирования цифровых данных. Низкое напряжение может быть интерпретировано как бит «0», а высокое — как бит «1».

• Ток — это поток заряженных частиц через проводник. В сетях передачи данных, таких как Ethernet, ток используется для переноса информации. Изменения в токе могут интерпретироваться как изменения битовых значений данных. Потребляемый ток также определяется сопротивлением проводников и устройств, через которые проходят данные.

• Частота определяет скорость, с которой данные передаются через сеть. В сетях Ethernet и других сетях передачи данных частота определяет скорость передачи данных, измеряемую в битах в секунду (бит/с). Например, Ethernet может иметь частоту 100 МГц или 1 ГГц, что определяет максимальную скорость передачи данных по сети.

  
  Механические характеристики: определение физического соединения, разъемов и кабелей.
  
  Физическое соединение (Physical Connection): — это способ, которым устройства в сети физически соединяются друг с другом. Физическое соединение может включать в себя различные типы кабелей, разъемов и портов. Например, в локальных сетях (LAN) устройства часто соединяются с помощью кабелей Ethernet.
  
  Разъемы (Connectors): — это физические интерфейсы, которые позволяют подключать кабели к сетевым устройствам. Существует множество типов разъемов, каждый из которых предназначен для определенных типов кабелей и протоколов. Например:
  

• RJ45: используется для подключения витой пары Ethernet.

• LC/SC: используются в оптоволоконных сетях.

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

Кабели (Cables): — это физические носители, по которым передаются данные. Тип кабеля определяет скорость передачи данных, расстояние, на которое данные могут быть переданы, и среду, в которой кабель может использоваться. Основные типы кабелей включают:

• Витая пара (Twisted Pair): наиболее распространенный тип кабеля для локальных сетей. Включает неэкранированную витую пару (UTP) и экранированную витую пару (STP).

• Оптоволоконный кабель (Fiber Optic Cable): используется для высокоскоростных соединений на большие расстояния. Передает данные с помощью световых импульсов.

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

❯ Примеры механических характеристик в сети Ethernet

• Разъем RJ45: используется для подключения кабелей Ethernet к сетевым устройствам, таким как маршрутизаторы, коммутаторы и сетевые карты.

• Оптоволокно с разъемами LC/SC: используется как для высокоскоростных магистральных соединений и соединений на большие расстояния, так и на небольшие расстояния (как разъемы RJ).
  

❯ Почему это важно

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

• Совместимость: использование стандартизированных разъемов и кабелей гарантирует, что устройства могут быть подключены и будут работать вместе.

• Производительность: тип и качество кабелей и разъемов могут влиять на скорость передачи данных и стабильность соединения.

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

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

• Физическая топология: определение расположения и соединения сетевых устройств.

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

Давайте рассмотрим основные типы физической топологии и их характеристики.

❯ Основные типы физической топологии

1. Шинная топология (Bus Topology)

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

Преимущества:

• Простота установки и низкая стоимость.

• Легкость добавления новых устройств.

Недостатки:

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

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

• Низкая производительность при большом количестве устройств.
  

2. Звездообразная топология (Star Topology)

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

Преимущества:

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

• Простота управления и обнаружения неисправностей.

• Поломка одного устройства или кабеля не влияет на работу всей сети.

Недостатки:

• Зависимость от центрального узла: если он выходит из строя, вся сеть перестает работать.

• Более высокая стоимость из-за необходимости в центральном узле и большем количестве кабелей.
  

3. Кольцевая топология (Ring Topology)

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

Преимущества:

• Равномерное распределение нагрузки между узлами.

• Отсутствие коллизий при передаче данных.

Недостатки:

• Поломка одного устройства или кабеля нарушает работу всей сети.

• Сложность добавления новых устройств.
  

4. Ячеистая топология или сетчатая (Mesh Topology)

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

Преимущества:

• Высокая надежность: сбой одного устройства или кабеля не влияет на работу всей сети.

• Высокая производительность и минимальная задержка.

Недостатки:

• Высокая стоимость и сложность установки.

• Сложность управления и обслуживания.
  

5. Древовидная топология (Tree Topology)

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

Преимущества:

• Иерархическая структура упрощает управление.

• Легкость масштабирования сети.

Недостатки:

• Зависимость от центральных узлов.

• Более сложная установка по сравнению с простой звездной топологией.
  

❯ Почему физическая топология важна?

• Производительность: различные топологии предлагают разные уровни производительности и могут справляться с разными объемами трафика.

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

• Масштабируемость: разные топологии по-разному справляются с добавлением новых устройств и расширением сети.

• Управляемость: некоторые топологии проще в управлении и диагностике неисправностей.

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

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

Основные технологии

• Кабели и разъемы: RJ45, оптоволоконные кабели, коаксиальные кабели.

• Электрические характеристики: RS-232, V.35, 100BASE-TX, 10BASE-T.

• Беспроводные стандарты: 802.11 (Wi-Fi), Bluetooth.

Основные стандарты

• RS-232: стандарт для последовательного обмена данными. (это не разъем как обычно считают, DE-9 это разъем, а RS-232 это стандарт)

• V.34: стандарт для модемов, который определяет методы модуляции для передачи данных по телефонным линиям со скоростью до 33.6 Кбит/с.

• 100BASE-TX: стандарт для передачи данных по витой паре на скорости 100 Мбит/с.

• 802.11: набор стандартов для беспроводных сетей.

Применение физического уровня на практике

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

❯ А что будет с данными если отключить кабель?

Отключение сетевого кабеля и его влияние на уровни сетевой модели

Когда сетевой кабель выдергивается, это затрагивает только физический уровень сетевой модели OSI, но как это влияет на работу протоколов TCP/IP?

Физический уровень (Physical Layer)

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

Канальный уровень (Data Link Layer) (подробнее о данном уровне в следующей статье)

Канальный уровень взаимодействует непосредственно с физическим и управляет доступом к среде передачи данных, обнаружением ошибок и управлением потоком. При отключении кабеля сетевой интерфейс, например, Ethernet, сигнализирует об ошибке, такой как «link down». Это событие фиксируется на этом уровне, но не обязательно передается выше.

TCP/IP и вышележащие протоколы

Протоколы стека TCP/IP (такие как TCP, UDP, IP) работают на более высоких уровнях и не имеют прямого доступа к информации о физическом состоянии соединения. Они оперируют виртуальными представлениями сети, предоставляемыми нижележащими уровнями. Поэтому, когда кабель отключается, TCP/IP не узнает об этом напрямую, если информация о разрыве соединения не передается с более низких уровней.

Механизмы обнаружения обрыва соединения

Для того чтобы протоколы верхнего уровня, такие как TCP, могли узнать о разрыве соединения, используются специальные механизмы:

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

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

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

❯ Заключение

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

В следующей статье мы рассмотрим канальный уровень (L2) и его роль в сетевом взаимодействии.

Спасибо за внимание, и до встречи в следующей статье!

Написано специально для Timeweb Cloud и читателей Пикабу. Больше интересных статей и новостей в нашем блоге на Хабре и телеграм-канале.

Хочешь стать автором (или уже состоявшийся автор) и есть, чем интересным поделиться в рамках наших блогов — пиши сюда.

Облачные сервисы Timeweb Cloud — это реферальная ссылка, которая может помочь поддержать авторские проекты.

📚 Читайте также:

• Будущее хранения данных. Где и на чем будем хранить данные в будущем;

• Как подготовиться к собеседованию начинающему сетевому инженеру? Базовые знания;

• Тимоти Джон Бернерс-Ли – человек, который почти создал интернет.

Сегодня я начинаю небольшой цикл статей, посвященных операционной системе Microsoft — Azure Stack HCI. Да, именно посвященных ОС, а не решениям Azure, рассматривать я буду именно серверную ОС на базе ядра Windows Server с названием издания Azure Stack HCI, которая вот уже пять лет как ежегодно выходит по программе ежегодного (не долгосрочного) цикла выхода серверных ОС. На данный момент мой план таков:

1) В первой (этой) статье я опишу своё видение того, что такое Azure Stack HCI, чем он отличается от ОС Windows Server Datacenter Azure Edition (Core), что отличает Azure Stack HCI от сервисов Azure Stack, самое главное, для чего вам такая странная ОС в вашем датацентре;

2) Во второй статье я буду рассказывать о том, что такое Hot Patching, — процедура установки обновлений безопасности Microsoft без перезагрузки, какие требования к ОС имеются, — и самое главное, как обойти обязательность наличия подписки Azure, то есть как пользоваться Hot Patching в вашем датацентре без каких-либо Azure Benefits, как создавать виртуальные машины на базе ОС Windows Server и любых её ролей так, чтобы обновления ОС внутри ВМ не требовали их перезагрузки (как вы прекрасно понимаете, обновление хост ОС не требует перезагрузки ВМ в виду живой миграции между узлами кластера). Это весомый аргумент в пользу виртуализации Windows сервисов именно на базе Hyper-V;

3) В третьей статье я расскажу о том, как превратить ОС AzureStackHCI, которая поставляется исключительно в режиме Server Core в ОС с полным рабочим столом, чтобы у вас была возможность полноценно её администрировать. Причем сделать это таким образом, чтобы на ОС все так же продолжали приходить обновления с Windows Update.

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

Итак, что же такое Azure Stack HCI в 2024 году.

На Хабре есть неплохие статьи об Azure Stack (статья Azure Stack: Немного теории / Хабр (habr.com) от 2017 года) и Azure Stack HCI (статья Что такое Azure Stack HCI и как это работает / Хабр (habr.com) от 2020 года), которые в целом дают понимание о том, что такое службы Azure, в том числе и on-premises. За несколько лет, прошедших с тех публикаций основное отличие заключается в том, что AzureStackHCI теперь это издание ОС на Windows Server, выходящее раз в год, предназначенное для создания гиперконвергентной инфраструктуры на вашем оборудовании. Я очень рекомендую для начала тем, кто совсем не в курсе решения Azure Stack HCI прочитать вышеупомянутую статью корпоративного блога Microsoft, ибо я вообще не буду рассматривать ни аппаратные требования, ни процессы создания кластеров и управления имя, я буду говорить сегодня чисто об операционной системе.

Microsoft говорит, что "AzureStackHCI, — это решение гиперконвергентной инфраструктуры (HCI), в котором размещаются виртуальные машины Windows и Linux или контейнерные рабочие нагрузки и их хранилище. Это гибридный продукт, который подключает локальную систему к Azure для облачных служб, мониторинга и управления." Как и любое другое издание Windows Server, вы можете загрузить Azure Stack HCI с сайта Microsoft. Обращу внимание на то, что сейчас там предлагается загрузить версию 23H2, тогда как уже существует и 24H2, доступная на UUP, о которой я и буду вести речь в этом цикле статей. Версия 24H2 основана на базе ядра germanium, того же, что используется в Windows Server 2025 и Windows 11 24H2. Соответственно, и компоненты и обновления у данных ОС общие.

Обычно, отпугивающим фактором для начинающих администраторов является то, что Azure Stack HCI это всегда Server Core. То есть нет кнопки Пуск, Параметров и иже, нет ни MMC ни панели управления, при старте доступен sconfig, дальнейшее управление локально из командной строки или PowerShell или удаленное средствами Azure Arc и Windows Admin Center:

В Azure Stack HCI 24H2 входят лишь те роли, которые требуются для создания гиперконвергентной инфраструктуры, в первую очередь, Hyper-V и файловый сервер (включая Storage Spaces Direct), а также другие компоненты, такие как поддержка высокой доступности средствами Failover Clustering.

Как вы видите, список ролей невелик (точнее список велик, но это в основном Features). Основных ролей, имеющихся в Server Datacenter Core (обычном или Azure Edition) - таких как ADDS, ADCS, ADFS, DHCP, DNS и далее в нем нет. Но в них нет нужды на узле виртуализации, тем более Core. Вы установите полные версии Windows Server в виртуальных машинах, особенно если будет работать Hot Patching и обновления без перезагрузок.

Azure Stack HCI как ОС купить нельзя, она не лицензируется по узлам или процессорам, в отличии от традиционных решений, предполагается, что вы являетесь подписчиком Azure и будете управлять кластером при помощи Azure Arc или других средств, таким образом монетизируя затраты Microsoft. Раз ОС не лицензируется, то и активации, как класса в ней нет, ничего с ней делать не требуется:

Заводите ОС в домен, подключайтесь удалёнными средствами управления, создавайте кластер, хранилище Storage Spaces Direct, виртуальные машины Hyper-V и используйте без покупки серверных лицензий вообще, если внутри гостевых виртуальных машин у вас ОС Linux или клиентские ОС (например ферма Windows Virtual Desktop). Для лицензирования серверных ОС Microsoft внутри виртуальной среды следует как и ранее покупать лицензии Datacenter по ядрам процессоров ваших узлов виртуализации или устанавливать издания с подпиской (доступно только для Azure Stack HCI). Если потребуется, вы можете использовать встроенную в Hyper-V возможность Automatic Virtual Machine Activation (AVMA) и с AzureStack, для этого потребуется Windows Admin Center и ручная привязка ключей Windows Server Datacenter к узлам Azure Stack HCI. Если ваш AVMA ключ имеет Software Assurance или Subscription, то AVMA сможет активировать и виртуальные машины с Windows Server Azure Edition (те самые, в которых работает Hot Patching).

Не путайте Azure Stack HCI (издание ОС Windows Server) с решением Azure Stack (связка ОС Windows Server, OEM железа от какого-либо вендора-партнера и сервисов). Azure Stack это готовое решение, не всегда на базе Azure Stack HCI (чаще на базе Windows Server Datacenter), которое продаётся предустановленным в виде стойки с серверами, хранилищем, коммутаторами. Azure Stack идёт уже настроенным и готовым, - дорого, менее гибко, сложно обновлять. Azure Stack

Отдельно замечу, для виртуальных машин, работающих в Azure Stack HCI бесплатна доставка расширенных обновлений (ESU). То есть, если у вас в виртуальной машине установлен Windows Server 2012/R2 и SQL Server 2012, вы будете получать Extended Security Updates, которых не получат ОС, установленные на железе или любой другой виртуализации (в том числе и Hyper-V на базе Windows Server Datacenter).

Следующей статьей я расскажу о самой интересной возможности Azure Stack HCI — Hot Patching и поделюсь информацией, как установить данный функционал без покупки подписок Azure (в нашей стране их ведь купить невозможно? :)

А после поговорим о том, как довести до ума Azure Stack HCI, добавив ей полноценный рабочий стол, чтобы было комфортно администрировать, — таким образом можно будет использовать Azure Stack HCI как решение для виртуализации в небольшом офисе, где нет других серверов, нет подписок Azure и знатоков управления Server Core, с возможностью использовать Hot Patching.

Подписывайтесь, ставьте лайк, пишите комментарии, чего отдельно хотели бы увидеть в следующих статьях по Azure Stack и другим поделкам Microsoft!

Написано специально для Timeweb Cloud и читателей Пикабу. Больше интересных статей и новостей в нашем блоге на Хабре и телеграм-канале.

Хочешь стать автором (или уже состоявшийся автор) и есть, чем интересным поделиться в рамках наших блогов — пиши сюда.

Облачные сервисы Timeweb Cloud — это реферальная ссылка, которая может помочь поддержать авторские проекты.

📚 Читайте также:

• Как Kodak у Polaroid патенты украл;

• ХрюХрюКар: как перестать беспокоиться, начать создавать сервисы и обзавестись друзьями;

• Предательские фото: две истории о том, как ЦРУ по шакалистым фотографиям раскрывало ядерные секреты СССР.

Однажды компания Kodak украла у Polaroid патенты. Это случилось в 1976 году, когда Kodak представила свою первую мгновенную камеру. Конечно, у конфликта есть предыстория, но Kodak хотели обставить ситуацию не как воровство, а как здоровую конкуренцию. Обе компании – лидеры рынка, а их конкуренция и последующий суд превратились в крупнейший скандал. Суд длился 14 лет!

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

❯ Краткая история Kodak

Компания Kodak создала рынок фотографии, когда Джордж Истман в конце XIX-начале XX веков внедрил гибкую фотопленку – именно он придумал делать фотоаппараты не из дерева и латуни, а из картона и кожзама. Фотоаппараты Kodak стали доступны простому человеку за счет снижения цены камеры. В 1900 году самая примитивная камера в мире Kodak Brownie I стоила 1 доллар (около 40 долларов в современных деньгах). В конце XIX века большой фотоаппарат стоил в тысячи раз дороже. Существовавшая в те времена бизнес-модель Kodak сохранилась на весь XX век: фотоаппараты продавались в убыток, чтобы стимулировать продажу пленки. Кстати, пленка Kodak, в отличие от камер, вполне подходит профессиональным фотографам. Другие источники доходов мы тут рассматривать не будем.

Главное, что надо знать о компании Kodak, – это огромная международная корпорация: около 150 тысяч сотрудников и десятки заводов по всему миру. Она была главным мировым поставщиком в области фототехники (исключая только секторы профессиональных и узкоспециализированных фототоваров). Кроме того, компания Kodak производила кинопленку для Голливуда, разные (простые, в основном) кинокамеры, проекторы и даже товары общего потребления. Именно Kodak приучила американцев, что лучший подарок на Рождество – это фотоаппарат.

❯ Краткая история Polaroid

Компания Polaroid появилась в 1937 году и первые 43 года работала под управлением основателя Эдвина Лэнда. Этот энергичный изобретатель задал компании импульс с технологией поляризации, а в 1947 году он представил миру фотоаппарат, способный сделать фотографию за 1 минуту. Технология работала не без нареканий, но широкую публику поразила в самое сердце. Продажи были успешными. В 1963 году появилась цветная мгновенная фотография. Эдвин Лэнд стал звездой в Америке, а компания Polaroid обрела настоящий успех и приносила выручку в 500 миллионов в год.

Эдвин Лэнд, основатель компании Polaroid, любил проводить презентации на сцене, загадочно зазывая журналистов. Стив Джобс делал также – и теперь вы знаете, у кого он подсмотрел подачу. Эдвин Лэнд был настоящим визионером. Этот человек еще в 1960-х предсказал смартфон!

С 1947 по 1975 года компания прошла эволюцию в технологиях, поколениях камер и покорении умов. Первые два поколения продавались хорошо, на уровне необычного гаджета. Kodak не видели угрозы, ведь тогдашний успех Polaroid – это доля рынка на уровне статистической погрешности (0,5-1,5%). Но когда покупатели привыкли к технологии и вышло третье поколение камер, Polaroid стала международной, узнаваемой наравне с Kodak, а Эдвина знал весь мир наравне с Элвисом, рост Polaroid испугал Kodak.

❯ Начало конфликта: зависть или дальновидность?

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

Можно ли было представить в 1970-м году, что весь рынок фотографии перейдет на технологию моментальной фотографии? Это такой же сложный вопрос, как и вопросы вроде – кто в 1980-м году в IBM мог подумать, что микрокомпьютеры могут быть популярны и станут важнее мейнфреймов? Кто мог предсказать, что цифровая фотография уничтожит рынок аналоговой в 1990-м году? А кто в 2005-м мог бы предположить, что смартфоны отберут долю рынка у цифровых фотоаппаратов? Кто в 2010-м верил, что электрические автомобили займут крупную долю рынка в развитых странах через 20 лет?

Обратите внимание на эту иллюстрацию. Повезло найти качественный скан рекламы. Дело в том, что Kodak еще в начале XX века придумали публиковать в рекламе комиксы о простоте использования камер. Polaroid пошли похожим путем в 1950-х. Без комикса или чтения инструкции тут, действительно, не разобраться.

В 1950-60-х Kodak производил для Polaroid запчасти и химию. Очевидно, Kodak видели всю технологию, знали подробности механики и, без сомнений, могли все скопировать. Предвидя такие риски, Эдвин Лэнд хорошо подготовился и получил патенты на все компоненты и идеи, заложенные в Polaroid. Эдвин, кстати, войдет в мировую историю как один из самых плодовитых на патенты изобретателей. Знаете, чем он занимался в 1945-1947 годах? Он старательно и последовательно патентовал все свои разработки, так как потом пришел с ними в тот же Kodak с предложением купить весь проект за огромные (неизвестные нам сегодня) деньги. И тогда Kodak ему отказали.

Итак, в компании Kodak решили, что пора бы сделать и собственную мгновенную камеру. Полагаем, что такое решение приняли в середине 1960-х. Несколько лет ушло на разработку в условиях, конечно, полной секретности. Были отлажены все процессы, и Kodak уже готовила продукт для выхода на рынок. И вдруг как гром среди ясного неба в 1972 году компания Polaroid выпустила новый тип расходных материалов, что заставило Kodak отложить старт и начать копировать уже обновленную технологию.

Kodak Instamatic 104 – одна из самых массовых камер 1960-1970-х. Простая, компактная, потом такие в русскоязычном мире называли мыльницы, а в англоговорящем – point-and-shoot camera. Знаете, чем еще примечательна серия Instamatic? Именно в ее честь названо приложение Instagram.

❯ Выход камеры Polaroid SX-70

Выход камеры Polaroid SX-70 важен по двум причинам. Во-первых, она обрела культовый статус из-за невероятного дизайна – она раскладывалась, что поражает до сих пор. Во-вторых, в SX-70 использовался новый тип пленки. Об этом чуть ниже.

Эта модель стала настоящим прорывом. Удачная конструкция, отличные характеристики, рекордные продажи. Любой фанат марки начинает коллекцию с этих 4 моделей: Polaroid 95, Polaroid (складная) 200-420, Polaroid SX-70 и Polaroid Spectra.

Если посмотреть количество проданных камер, долю рынка и выручку, то Polaroid показывал очень хорошую динамику между 1950 и 1980 годами. Каждый год – плюс 10-20% к выручке, акции тоже росли, но это не столь важно. Важно, что каждая следующая камера приближала Polaroid к Kodak по объемам выручке и доле рынка. Когда в 1965 году вышла камера Polaroid Swinger за 20 долларов, Polaroid стал еще на на шаг ближе к цели. Такие камеры, хоть и выглядели нелепо, (см. рекламный ролик Polaroid Swinger), но стоили очень дешево и продавались отлично.

Сначала мгновенная техника Polaroid занимала 1-2% фоторынка в США. В начале 1960-х уже до 5-7%. Kodak забеспокоился. А вот после трех прорывных событий и бурного периода роста Polaroid, Kodak уже начали нервничать: 1963-1975 годы – выход цветной мгновенной фотографии сильно простимулировал продажи и котировки Polaroid. Тогда же вышли кассеты для снимков и легендарная SX-70. Кроме того, техника Polaroid получила распространение в госструктурах. Оказалось, что при изготовлении пропусков, удостоверений и полицейских магшотов мгновенная фотография – разумный выбор. В итоге Polaroid даже выпустили специальную камеру для документов.

Крупный американский художник Энди Уорхол был большим фанатом марки Polaroid. Он не только везде таскал их камеру с собой, он как бы был неофициальным лицом марки. У Kodak не было ничего похожего: ни амбассадора, ни лица, ни легенды. Точнее лица в рекламе Kodak менялись часто, основатель Kodak, Джордж Истман, остался в истории.

Так, к 1972 году доля Polaroid на рынке США в целом достигала уже 17-20%. Выручка компании в 1960-х превышала 500 миллионов долларов в год, затем рост чуть замедлился и резко ускорился. К 1976 году выручка уже составляла 1 миллиард и неумолимо приближалась к отметке в полтора миллиарда. Так Kodak и осознали, что Polaroid – это уже не средняя фирма с необычным «продуктом», а компания, которая чисто теоретически может вообще поставить крест на старомодной фотопленке.

❯ Типы фотоматериалов у Polaroid

Но в технологии Polaroid существовало и слабое место – это расходные материалы. Надо уточнить, что было 3 этапа и, соответственно, 3 подхода к передаче изображения на негатив-позитив. Они все по-разному работали, их объединяло только то, что через 30-120 секунд у вас в руках была полностью готовая фотография.

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

ROLL

Тип 1: многослойная пленка, которая расклеивалась после ожидания, и через пару минут получалась фотография. Пример на видео – Polaroid 95.

PACK

Тип 2: пачка снимков, химии и батарейка в упаковке, которые загружались в камеру. Продаваться начал в 1963 году. После спуска затвора снимок можно было вытащить из камеры или он подавался мотором за 30-60 секунд. Это экономило время, а главное – процесс смены картриджей был гораздо проще.

INTEGRAL

Тип 3: картридж нового поколения, все то же самое (пачка снимков, химия, батарейка). Начало продаж – 1972 год. Но скорость всех этапов значительно возросла. Именно в таком виде и с характерным узнаваемым звуком камеры Polaroid вошли в 1990-е годы.

❯ Kodak выходит на рынок моментальной фотографии

Итак, Kodak выпустили моментальную фотографию – технология, фотокамеры и расходники. Рекламная кампания была беспрецедентной. Они предложили конечному потребителю фотокамеры по той же цене, что и Polaroid, но вот снимки были немного дешевле. Кроме того, у Kodak сеть продающих партнеров была куда обширнее, чем у Polaroid. Kodak могли потратить на маркетинг в 5, 10 и даже 20 раз больше денег.

Камера Kodamatic в первой версии не имела моторчика, готовый кадр надо “выжимать”, покрутив ручку (см. рекламный ролик). Обратите внимание, Kodak сделали совершенно иной тип корпуса, чтобы не было претензий по патентам в механике и оптике, поэтому у Polaroid готовый снимок почти всегда спереди, у Kodak – сзади. На фото камера ColorBurst, а кассета пленки тут только для масштаба (лучше, чем пачка сигарет).

Первая камера носила название Kodak EK4, или Kodamatic. Моторчика на ней не было, чтобы получить снимок, нужно было крутить ручку. Кстати, камеры мгновенной фотографии всегда были и остаются относительно крупными. Они весили до 5 кг, в разы крупнее обычных камер, поэтому у Polaroid и у Kodak на многие модели устанавливалась крупная рукоятка (что, кстати, было характерно и для 1920-х, когда камера со вспышкой была очень очень громоздкой). Одна из моментальных камер Kodak даже носила имя Handle.

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

Активная реклама от Kodak в прессе. Самая яркая была, конечно, на ТВ (пример, видео).

В компании Kodak считали, что они не нарушают патенты Polaroid, так как они «разрабатывали всю химию и механизмы с нуля». Просто поставили цель – готовая фотография за 30-60 секунд. У Polaroid снимок выезжал впереди, у Kodak – сзади. Нет, это, конечно, не главное, это следствие того, что Kodak постарались сделать все не так, как у Polaroid: ориентация линз и механизмов иная, размеры, принцип и последовательность событий. Химические процессы они также изменили, как последовательность и количество слоев в фотобумаге. Kodak уверенно заявляли: у нас камеры работают не так, как у Polaroid.

❯ Новый участник истории: Fujifilm

Fuji занимала доминирующую позицию в Японии и копировала бизнес-модель Kodak. В 1970-х она вышла на рынок США, и началась настоящая война. С одной стороны, Kodak испытали давление и по цене, и по присутствию на рынке, с другой стороны, в 80-х им было даже выгодно, что на рынке есть конкуренты, иначе они казались бы (и являлись по факту) монополистами.

В 1984 году прошли Олимпийские игры в Лос-Анджелесе. Kodak впервые за 50 лет отказался выступить спонсором национальной сборной (в США государство не помогает спорту, как было принято в некоторых странах, например, в СССР) и возникла забавная коллизия: японская компания Fuji финансировала американскую сборную. В общем, противостояние было жестким, до судов доходило не единожды.

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

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

Успехи Fuji в сделке с Kodak можно описать так: они выпустили свою версию фотоаппарата на основе технологии и химии от Kodak. Только в Японии. Их позиции усиливались с каждым годом. Но оставалась проблема: как можно продавать что-то, имея лицензию на продукт, по которому прямо сейчас идет судебный процесс?

❯ Кризис в Polaroid

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

В конце 1960-х Polaroid ставила рекорды роста котировок акций, до 125 долларов за 1 акцию в 1969 году. Следующий рекорд был поставлен в 1980-м году: выручка достигла 1,451 миллиарда. В том же году выручка в расчете на 1 акцию – 2,6 доллара. за 40 лет Polaroid произвел 7,5 миллионов фотокамер марки Polaroid Land Camera.

А вот следующие 5 лет будут крайне тяжелыми. Продажи Kodak росли, а у Polaroid падали. С одной стороны, общественное мнение находилось на стороне Polaroid, и Kodak с выходом на рынок инста-фото выглядели как пираты. Но вместе с тем Kodak – в 50 раз крупнее Polaroid. Многие боялись покупать камеры Polaroid, справедливо предполагая, что им осталось недолго, и Kodak в итоге победит.

Polaroid в те же годы потерпели крах и с другим проектом – провалилась технология Polavision. На нее тратили все свободные деньги более 5 лет, но детище Эдвина Лэнда так и не взлетело.

Ну и последнее. К 1980 году всем стало понятно, что Kodak выигрывают по цене и качеству фотографий. Судебный процесс шел медленно, начавшись 4 года назад, и Kodak тянули время. Как известно, крупным компаниям выгодно затягивать суды, чтобы измотать противника. Все это привело к падению выручки Polaroid в 81-85 годах на 30%.
На фоне кризиса, который стал очевиден и для сотрудников, и для прессы, генеральный директор Эдвин Лэнд покинул свой пост. Ему было 72 года, и он владел 533 патентами в сфере оптики, химии и механики.

Важный момент: Эдвин Лэнд потерял пост из-за проекта Polavision, а не из-за конкуренции с Kodak. Конечно, он ошибся с этой технологией, однако он был визионером, сформировавшим Стива Джобса и предсказавшим появление смартфонов.

❯ Первое решение суда в 1986 году

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

Судебный процесс шел с 1976 года. Сторона истца – Polaroid – декларировала нарушение 12 патентов и заявила упущенную прибыль, ущерб репутации и суммарные требования на 12 миллиардов долларов. Сумма, где есть число 12 и 9 нулей – это шокирующие претензии. Мировой рекорд. Как вариант, можно трактовать так: претензия на 1 миллиард – это мировой рекорд, а вот претензии на 12 миллиардов – это буквально сообщение “Мы хотим вашей смерти”!

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

❯ Окончательное решение суда

Прошло еще пять лет. Наконец вышло окончательное решение суда: компания Kodak должна выплатить 909 000 000 долларов за нарушение 2 патентов. А также 16 миллионов долларов штрафа, проценты за период суда (скрытая плата за затягивание процесса). Все камеры Kodak могли остаться у покупателей или по соглашению выкупались компанией Kodak.

В 1990-х главной массовой и довольно успешной камерой стала Polaroid Spectra и Polaroid серии 600, они определили то, как воспринималась марка. Кстати, камеры Polaroid серии 600 производилась по лицензии в СССР!

Сумма выплат в $ 925 000 000 – это мировой рекорд. Даже рекордная выплата по суду между Apple и Samsung не дотягивает до рекорда (там было 1.049 миллионов, надо делать поправку на инфляцию, это +30-40% к 925 млн).

Акции и валовая выручка обеих компаний изменились по результатам суда, но не катастрофически. Polaroid с 1986 года вышла из кризиса, тем более, в начале 1990-х они выпустили ряд новых камер. А акции Kodak упали в 1991 году приблизительно на 25%, что тоже нельзя назвать катастрофой.

❯ А что же компания Fuji?

Компания Fuji по логике должна была получить какие-то претензии от Polaroid, ведь они использовали некоторые патенты по соглашению с Kodak. В Polaroid знали, что смогут прижать Fuji и по соглашению провели обмен: Polaroid получили от Fuji технологии и права на продажу нескольких товарных групп в секторе магнитных носителей. Прежде всего, это видеокассеты типа VHS и дискеты 3,5 дюйма. То было крайне удачное решение для Polaroid, ведь в 1990-х дискеты и видеокассеты приносили заметную часть выручки на американском рынке.

Компания Fuji успешнее всех вышла из кризиса цифровой революции. Они, в отличие от Polaroid и Kodak, позакрывали фабрики еще в середине 2000-х и куда более решительно вкладывались в новые рынки. Сегодня, спустя 25 лет совершенствования технологии, компания очень успешно продает камеры с принтером серии Fuji Instax. Более того, классические пленки и картриджи для Polaroid компания также до сих пор выпускает именно Fuji!

❯ Чему нас научила война Polaroid и Kodak?

Суд стал самым крупным в истории противостояний крупных компаний. Формально, конечно, самый большой суд – это Apple vs Samsung, но без поправки на инфляцию.

Когда пыль рассеялась, выяснилось, что пока длились судебные распри между Polaroid и Kodak, началась цифровая революция. Мир изменился. Вместо того, чтобы искать новые рынки и технологии, развивать уже готовые идеи, они искали развитие через войну. Обе компании не сильно поумнели впоследствии и ушли в банкротство в XXI веке. Меньше всех пострадала компания Fuji, она умела договариваться, а значит, смогла найти решение в истории с авторскими правами, а в XXI веке активно диверсифицировала бизнес (например, начали косметический проект).

Также обращаю внимание на то обстоятельство, что обе компании совершили по одной очень большой ошибке, помимо неспособности увидеть цифровое будущее. В Kodak в 1982 году запустили проект Kodak Disc Film, который был красиво подан, разрекламирован и выведен на рынок. И по очевидным причинам провалился. А про проект Polavision, который был создан Эдвином Лэндом, я уже написал выше. Эти истории показывают, как крупные и, казалось бы, сильные компании способны допускать одну фатальную ошибку за другой.

Написано специально для Timeweb Cloud и читателей Пикабу. Больше интересных статей и новостей в нашем блоге на Хабре и телеграм-канале.

Хочешь стать автором (или уже состоявшийся автор) и есть, чем интересным поделиться в рамках наших блогов — пиши сюда.

Облачные сервисы Timeweb Cloud — это реферальная ссылка, которая может помочь поддержать авторские проекты.

📚 Читайте также:

• История планшетных компьютеров. От древних времен до конца двадцатого века;

• ХрюХрюКар: как перестать беспокоиться, начать создавать сервисы и обзавестись друзьями;

• Предательские фото: две истории о том, как ЦРУ по шакалистым фотографиям раскрывало ядерные секреты СССР.

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

❯ Чему мы хотели научиться

Я два года работаю в IT (Fullstack: Django, Go, Vue) и по работе мне приходилось сталкиваться с разными технологиями, но я ни разу не писал сервисы полностью, всегда уже были готовые проекты, в которых нужно было что-то дорабатывать. Также у меня есть брат, который вообще не имел опыта в IT, но хотел научиться программировать (с уклоном в Django).

Чтобы приобрести больше уверенности в вопросах создания сервисов, мы решили сделать проект с нуля. Брату хотелось понять как создавать backend на Django, работать с базами данных, а также разбираться с асинхронными задачами, ну а мне было интересно создать PWA на Vue3, научиться работать с картами, набить шишек на DevOps и в целом разработать сервис полностью.

❯ Как выбирали проект

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

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

В то время все закончилось на том, что мы фотографировали нарушения на OpenCamera, после чего я загружал снимки в QGIS и скриптом извлекал данные из EXIF-тегов, осуществлял обратное геокодирование, заполняя слой. Оставалось разобраться с распознаванием автомобильных номеров и разработать функционал формирования документов (запросов/протоколов/писем), но в связи со сменой места работы, работа над проектом была остановлена.

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

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

Чтобы привлечь нарушителя к ответственности, вам необходимо:

1. Зафиксировать факт нарушения, время и место его совершения;

2. Понять кто уполномочен принимать заявления по конкретному типу нарушений на данной территории;

3. Составить заявление с учетом всех юридических тонкостей;

4. Отправить заявление в уполномоченный орган и дождаться ответа.

Вроде бы для гражданина все просто, но на практике все оказалось сложнее. Многие считают что все нарушения правил парковки относятся к полномочиям МВД (ГИБДД/ГАИ), но на самом деле это не так.

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

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

Обращение в МВД (ГИБДД/ГАИ) — это вообще отдельная история. При разработке их формы обращения, программисты сделали все для того, чтобы граждане вообще не обращались к ним. Например, в форме обращения, «для борьбы со спамом», отключена возможность использования буфера обмена, а максимальный размер вложений в 30Мб является по сути запретом на отправку видео.

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

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

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

Мы решили создать сервис, который позволит горожанам «в один клик» фиксировать факт правонарушения, а все остальные аспекты взять на себя.

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

❯ Какую задачу решает проект

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

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

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

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

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

На данный момент мы обзвонили не все стоянки, но результат уже достоин внимания: из 17 стоянок по которым мы уже получили данные, только на одной стоянке нет мест, а на остальных — 40-60% свободно! С гаражами ситуация примерно такая же: по данным председателей кооперативов, 30-40% гаражей в городе — брошены и практически не используются.

Причины, которые нам видятся основными:

• во дворе ставить «выгодней» (от предупреждения до 5000 руб. штрафа раз в 1-2 года против 1200-1600 рублей в месяц за стоянку);

• до стоянки или гаража нужно ходить, а «мы привыкли от двери до двери на авто, это же удобно, 21-й век!»;

• низкий шанс получения наказания: за 2023 год, согласно отчетам, на весь город ~300 админ. протоколов (и это не только по парковке);

• нет общественного порицания: люди либо считают это нормой, либо просто молчат;

• нехватка кадров в муниципалитете, чтобы фиксировать большое количество нарушений по всему городу. В Балаково это 27 человек, уполномоченных составлять протоколы (помимо основных обязанностей) на тысячи нарушений;

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

В рамках проекта «ХрюХрюКар» мы постарались охватить все описанные выше проблемы.

Посмотреть 12 примеров того, с чем борется ХХК можно ниже:

❯ Что получилось в результате

Карта нарушений:

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

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

Фиксация нарушений:

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

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

Модерация и отправка заявлений:

Пользователю с правами модератора (членство в группе Moderator), а также суперюзеру доступна консоль модерации. Модераторы не получают в очередь модерации фотографии, авторами которых они являются. Суперюзеры — могут модерировать любые материалы.

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

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

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

Для удобства модератора, в консоли мы связали карту с Google Street View, чтобы было проще геолоцировать фото.

Если с модератором связан заявитель, то у него доступен последний шаг степпера — генерация и отправка заявления.

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

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

Рендеринг заявлений производится с использованием встроенного в Django шаблонизатора.

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

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

По состоянию на 05/01/2024 у нас реализована автоматическая отправка только по электронной почте, что покрывает ~90% всех нарушений, которые нам присылают через ХрюХрюКар. Отправка в ГИБДД ведется почти в ручном режиме.

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

Также мы пробовали осуществлять отправку заявлений через ПОС Госуслуг и нас удивили их методы по «борьбе со спамом». Разработчик из непонятных соображений также запретил использование буфера обмена для пользователя и установил следующие ограничения на количество обращений, направляемых через ПОС: не более одного обращения в час и не более двух в сутки.

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

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

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

Почему именно расширение?

Чисто технически, реализовать отправку заявлений напрямую с сервера ХХК, используя эндпоинты уполномоченных органов возможно. Но нам показалось это неправильным с юридической точки зрения. Заявитель все же должен взаимодействовать с формой напрямую, через фронтэнд уполномоченных органов, а мы только можем помочь в её заполнении.

❯ Общие результаты в моменте

За 4,5 месяца мы направили 742 заявления, 28 материалов находится на модерации. Сейчас мы получаем в среднем по 10-20 материалов в день и стараемся около 20-и заявлений в день направлять.

Примерно 90% материалов — нарушения, выражающиеся в размещении автомобиля на зелёной зоне (направляются в администрацию БМР), около 9% — стоянка на тротуаре в нарушение ПДД (полномочия отдела ГИБДД МУ МВД «Балаковское»), 1% делят стоянка на месте для инвалидов, автобусных остановках и пешеходных переходах.

За это время на сайте авторизовалось 277 пользователей, из которых:

• 62 присылали одно и более нарушений, в том числе;

• 17 присылали более десяти нарушений, в том числе;

• 9 присылали более двадцати нарушений, в том числе;

• 6 присылали более пятидесяти нарушений, в том числе;

• 4 присылали более ста нарушений.

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

На примере некоторых пользователей мы поняли что один человек может зафиксировать сотню нарушений за пару часов прогулки, а мы их можем обработать за 1,5-2 часа. Но мы понимаем, что направление большого количества заявлений в уполномоченный орган по сути является DoS-атакой и вызовет отказ в обслуживании из-за банальной нехватки кадров.

За все время работы к нам зашли 5027 уникальных посетителей ~21000 раз. Основные пики посещаемости после таких вот постов (1, 2) в местной группе автомобильной направленности. Люди находят сайт в Яндексе или нашу группу в ВК и уже от туда приходят на сайт, где ищут свои машины.

Мы оперативно получаем положительные ответы от администрации и не очень оперативно — от МВД. Все ответы стараемся выкладывать в группе, но по мере появления свободного времени. Сейчас на почте ждут обработки 53 ответа от администрации и 3 от ГИБДД, это ~250-350 административных производств (администрация в одном ответе отвечает сразу на несколько наших заявлений).

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

Из дополнительных источников метрик следует отметить официальные публикации администрации: 1, 2, 3, 4, 5, 6.

Также нами проводится работа с органами власти всех уровней с целью внедрения в Балаково официального приложения на базе ПАК «Помощник Москвы». Это программное решение имеет статус средства, работающего в автоматическом режиме, что позволяет исключить бюрократию в виде административных производств (штрафы будут приходить через несколько дней прямиком на Госуслуги).

Процесс не быстрый, но мы будем стараться добиться такого внедрения у нас, благо куратор проекта в лице ЦОДД Москвы оказался очень адекватным и на первое же наше письмо ответил приглашением на ВКС, где нам изложили все детали и дали рекомендации для внедрения ПАК ПМ в регионах.

❯ Какие технологии мы использовали

Более подробно о технологиях можно почитать тут.

Облачные вычисления и сервисы:

1. TimeWeb Cloud — для всех вычислений (сервер БД, сервер бэкенда, сервер фронтенда, сервер почты).

2. Yandex.Cloud — S3-хранилище для фотографий, заявлений и иллюстраций к типам нарушений.

3. Google Street View API — для просмотра точного местоположения фотографии на панорамах при модерации.

4. OSM — для обратного геокодирования.

5. Yandex.Forms — для форм обратной связи: 1, 2, 3, 4.

Деплоим все это скриптами (1, 2, 3). Хотелось бы прикрутить Kubernetes и GitLab CI/CD, но пока не хватает времени и опыта.

❯ Что требует доработки

1. Камера. На некоторых устройствах (например, на iPhone Pro Max 11) камера не работает. Также наблюдаются проблемы с камерой в следующих браузерах: Яндекс, Samsung Internet, MIUI. Мы понимаем что проблема в некорректном коде компонента камеры, но у нас пока не хватило опыта её исправить. Исправляем работу камеры на одном типе устройств — все ломается на другом. Если есть опыт работы с камерой,будем благодарны за помощь.

2. Несвободная лицензия MDB Vue в редакции Pro. Из-за отсутствия в команде дизайнера, нам пришлось подбирать UI-библиотеку. На этом этапе была допущена ошибка и из-за невнимательности при ознакомлении с лицензией мы не заметили тот факт, что лицензия MDB Vue Pro запрещает распространять под открытой лицензией проект с исходным кодом самой библиотеки MDB Vue Pro. Поэтому мы опубликовали варианты выхода из этой ситуации. Если вкратце, то можно написать несколько компонентов самостоятельно, удалить ненужные несвободные компоненты или вовсе использовать ХХК без фронтенда (например для написания ТГ-бота такой же направленности, как и ХХК).

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

4. DevOps. На данный момент у нас нет CI/CD, Kubernetes, да и в целом есть масса замечаний по деплою. Например, у нас для каждой реплики бэкенда, поднимается свой контейнер с Celery в связке с Redis, что не очень хорошо. Также у нас нет автоматического масштабирования, что в перспективе может привести к проблемам с производительностью. Ну и есть масса замечаний к порядку развертывания. Например, при сборке для staging/production, статика фронта собирается в таком порядке:

   1. Скрипт готовит папки на хосте перед запуском сборки;

   2. Запускается контейнер для сборки статики Django;

   3. Запускается контейнер для сборки статики фронта ХХК и фронта карты стоянок;

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

      По-хорошему, нужно производить сборку backend, frontend, parkings_frontend, а потом уже при сборке Nginx копировать нужные директории/файлы из полученных образов.

      Если есть опыт работы с Kubernetes и GitLab CI/CD, будем рады помощи.

5. Консоль модератора. Необходимы доработки в консоли модератора, а именно: фильтрация, сортировка, поиск.

6. Local-first. На данный момент у нас нет возможности работать при плохом канале связи на стороне клиента. Необходимо реализовать возможность работы с ХХК в режиме, близком к offline. Для этого необходимо переработать часть стора, чтобы он работал с IndexedDB, а также реализовать синхронизацию данных с сервером, не забывая про контроль за временем создания снимков (временем на устройстве), чтобы избежать подлогов (нужен «камертон», работающий через веб-сокеты).

7. Отправка заявлений от имени пользователей без доступа к их данным. На данный момент заявления отправляются от имени нескольких модераторов, что является одним из самых узких мест в проекте. Необходимо реализовать отправку заявлений от имени пользователей, но без доступа к их данным. Тут вариантов масса, но нам кажется идеальным следующее решение: мобильное приложение, которое помогает заполнять формы уполномоченных органов (если отправка ведется через формы), либо готовит черновик письма для отправки на почту уполномоченного органа через стандартный почтовый клиент.

8. Исправление логики импорта исходных данных. Сейчас все территории и базовые типы нарушений/полномочия и т.д. у нас импортируются в миграции, это неправильно. Во-первых, не всем нужны эти данные, а во-вторых, после импорта территорий производится их привязка друг к другу, которая из-за не оптимизированного кода и большого объема данных, требует для выполнения минимум 8Гб оперативной памяти и ~10 минут времени. Этот код писался на самом раннем этапе и мы тогда еще не знали про фикстуры и management-команды. Надо будет всю эту логику перенести в management-команду, чтобы она загружала из фикстур заранее подготовленные данные и импортировала их в базу, при необходимости загружая нужные картинки в S3-бакет.

9. Журналирование. Сейчас журналы пишутся в stdout контейнеров и, по сути, хранятся в огромном JSON-файле в одной из директорий docker-compose.Также мы настроили конфиги так, чтобы Nginx и Django их сохраняли еще и в папки, смонтированные на хост.

10. Мониторинг. Сейчас у нас помимо обычного хелсчека, на который стучится Traefik, чтобы определить жив ли контейнер при проксировании запросов,в файле с хелсчеками лежат представления, которые по сути не являются хелсчеками. На эти представления изредка заходит Uptime Kuma, чтобы мы в Телеграмме получали алерты если ресурсы хоста на исходе или что-то не так с бизнес-процессами (не уходит почта, выходят сроки модерации материалов, пользователь или модератор производят много отклоненных материалов). Все это по сути является метриками и необходимо это все, скажем, с использованием Prometheus, передавать на некие дашборды и от туда уже слать алерты.

11. Автоматизация бэкапов. Сейчас у нас все сервера бэкапятся средствами хостера + мы периодически выгружаем эти бэкапы себе в облака. S3 вовсе не бэкапится нами... Необходимо наладить нормальное резервное копирование и сохранять все добро в какой-нибудь сторонний ледяной S3.

12. Stateless. Сейчас у нас Stateful-архитектура. В частности, когда пользователь присылает фотографию нарушения, мы ее помимо S3, кладем в папку, примонтированную к хосту. После того как запрос успешно выполнился, запускаются фоновые задачи в контейнерах Celery. Одна из таких задач подбирает этот файл из той же папки, делает сжатую копию и стучится в Nomeroff, чтобы распознать номера. Контейнер Nomeroff ходит в ту же папку. В самом конце задачи, файл удаляется. Все это нам уже не очень нравится с архитектурной точки зрения.

13. Тестирование. Сейчас в проекте ровно 0 тестов. По-хорошему нужны не только юнит-тесты, но и нормальные интеграционные тесты.Также мы пока не научились производить нагрузочное тестирование, поэтому на все вычисления (на все серверы) у нас в сумме задействовано 10vCPU и 18Гб памяти, что требует ~7000 рублей в месяц. Нагрузочное тестирование позволит оптимизировать использование ресурсов и сократить затраты.

❯ Планы на будущее

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

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

Исключение административных производств (и ХХК, как следствие)

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

1. Мы направляем заявление.

2. Это заявление регистрируют в отделе обращения граждан и относят главе в почту (о да, на бумаге!);

3. С учетом структуры аппарата, письмо «спускается» до исполнителя за 2-4 дня, т.к. каждый разбирает почту и «отписывает» (поручает) подчиненному в рамках возложенных полномочий;

4. Исполнитель готовит запросы в МВД (в ГИБДД и ФМС);

5. Эти запросы перед отправкой проходят ту же самую цепочку согласований, но уже «вверх», что также занимает 2-4 дня;

6. Запросы достаточно долго обрабатываются у адресатов (а бывает и теряются);

7. Приходит ответ на запросы и также «спускается» 2-4 дня. В идеальном случае в ответах есть контакты собственника авто;

8. Если контактов нет, то по адресу регистрации необходимо направить письмо (по тому же пути) касаемо административного протокола. Если контакт есть,то собственника приглашают на составление протокола (что тоже достаточно трудно и затратно по времени).

9. Когда протокол составлен, назначается административная комиссия, состоящая из уполномоченных лиц из разных ведомств. Как правило, комиссии проходили пару раз в месяц и на них приглашалось 20-30 нарушителей. Сейчас периодичность и «наполняемость», естественно, иные.

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

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

Выход из этой ситуации — внедрение официального федерального приложения на базе ПАК «Помощник Москвы». Когда у нас получится добиться такого внедрения, потребность в ХХК отпадет и большая часть нарушений правил парковки будет проходить через эту систему в автоматическом режиме, что позволит комиссии заниматься другими делами, коих у них в достатке (свалка мусора, граффити, незаконная торговля, и т.д.).

Информационная работа

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

Бэкенд используется тот же, только добавили отельные модели (1, 2, 3, 4) и сделали простейший эндпоинт.

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

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

❯ Как помочь проекту

Код и компетенции

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

Финансовая поддержка

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

Информационная поддержка

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

❯ Ссылки

1. Сайт: xxkap.app и хрюхрюкар.рф;

2. Репозиторий;

3. Группа в ВК;

4. Канал в Telegram;

5. Почта брата — его зовут Игорь и он за время работы над ХХК неплохо вырос как бэкенд-разработчик, ~90% кода backend — его работа. Если кому-то в проект нужен молодой и перспективный backend developer (Django/Flask), напишите ему, пожалуйста.

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

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

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

Спасибо за ваше время!

Новости, обзоры продуктов и конкурсы от команды Timeweb.Cloud — в нашем Telegram-канале ↩

Как вы думаете, какой планшет был первым? Apple iPad? Может «интернет-планшеты» от Nokia? Мечтали и фантазировали люди о подобном устройстве с конца 19-го века. В середине века 20-го писатели фантасты всё чаще рассуждали о них в своих произведениях. Но фактическая история планшетных компьютеров началась в 80-е с разработкой первых реальных прототипов, а коммерчески успешным стал GRiDPad 89-го года, от американской компании GRiD, известной также по изобретению современного подобия ноутбука. В этой статье я постараюсь глубоко не погружаться в технические характеристики и принципы работы планшетных компьютеров, но попробую по полочкам разложить основные вехи этой истории и рассказать о самых интересных представителях семейства.

❯ Ранние годы

Всего до начала 50-х годов прошлого века в Америке было выдано несколько патентов, связанных с электронным вводом рукописной информации. Самый первый датируется 1888 и был получен Элишей Греем за описание электрического устройства, использующего стилус. Называлось оно Telautograph и использовалось для передачи рукописей и рисунков на расстояния.

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

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

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

В том же 1942 году Ханна Муди, одна из будущих разработчиков цветного телевидения, изобретает систему «сенсорного» ввода рукописного текста на основе резистивных (реагирующих на изменение сопротивления) плёнок и источника переменного тока.

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

❯ Stylator

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

Первой частью было устройство ввода. В 1957 году Том Даймонд представил свое изобретение в подробной статье под названием «Устройства для чтения рукописных символов». Stylator — это сокращение от стилуса и переводчика (translator), что должно четко указывать на то, что мы рассматриваем: графический планшет со стилусом.

Базовая концепция Stylator не так уж сильно отличается от «Контроллера» Голдберга. Однако она содержит несколько улучшений, наиболее важным из которых является то, что вместо соединения точек выводов проводящими чернилами для создания цепи, вы используете стилус для рисования по пластиковой поверхности со встроенными в нее медными проводниками. Провода расположены таким образом, что всего тремя линиями, состоящими из семи проводов, можно распознать все цифровые символы. Иллюстрация ниже из статьи Даймонда говорит сама за себя.

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

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

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

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

Можно сделать вывод, что «Стайлатор», несмотря на огромный скачок вперед по сравнению с предыдущими системами, все еще был довольно ограничен в возможностях. Чтобы распознавание действительно стало эффективным методом ввода, нам нужно нечто большее. Давайте сделаем еще один шаг вперед и создадим систему, состоящую из графического планшета, ЭЛТ-дисплея, программного обеспечения для распознавания и пользовательского интерфейса — по сути, Palm Pilot размером с комнату.

❯ «Грааль»

В течение 1960-х годов над таким проектом трудилась корпорация RAND. Он назывался GRAIL, сокращенно от Graphical Input Language Project («Язык графического ввода»). Описание проекта простое: «Человек, используя планшет/стилус RAND и электронно-лучевой дисплей, может создавать и редактировать компьютерную программу с помощью блок-схем, а затем выполнять ее. Система обеспечивает соответствующую обратную связь на дисплее». Весь проект подробно описан в заключительном отчете, состоящем из трех частей, и был спонсирован Агентством перспективных исследовательских проектов Министерства обороны США.

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

Планшет состоит из листа майлара с печатными схемами на каждой из двух его сторон; верхняя схема содержит линии, обозначающие позицию x, в то время как нижняя схема содержит линии, обозначающие позицию y. Эти линии генерируют отрицательные и положительные импульсы, которые улавливаются стилусом с высоким входным сопротивлением. Каждая позиция x и y состоит из определенной последовательности отрицательных и положительных импульсов; отрицательные импульсы — это нули, а положительные импульсы — единицы, которые при объединении дают код Грея для каждой позиции x, y. Затем они могут быть введены в компьютер, где происходит дальнейшее волшебство.

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

Целью проекта GRAIL было создание «общей рабочей поверхности» как для человека, так и для компьютера — электронно-лучевого дисплея. Они пришли к выводу, что гибкость выходных данных (ЭЛТ-дисплея) должна соответствовать гибкости входных данных, чтобы было возможно прямое и естественное отображение на двумерной поверхности, и, очевидно, именно здесь планшет RAND снова вступает в игру. Перед проектом стояли четыре задачи проектирования:

1. Использовать только ЭЛТ и планшет для интерпретации движений стилуса в режиме реального времени;

2. Сделать операции наглядными;

3. Повысить отзывчивость системы;

4. Сделать продукт завершенным средством решения задач.

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

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

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

Благодаря чудесам Интернета и YouTube мы можем увидеть GRAIL в действии и послушать рассказ Алана Кея. В видео Кей даже утверждает, что одно из элементов управления окнами Mac было «буквально» заимствовано из GRAIL. В проекте GRAIL также появилось несколько жестов, которые сохранятся и будут использоваться на протяжении десятилетий. Жест курсора использовался для вставки текста, жест очистки — для удаления чего-либо и так далее. Эти жесты позже появятся в системах, использующих парадигму пользовательского интерфейса ноутбука, таких как PenPoint OS и Newton OS.

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

Проект GRAIL был запущен на IBM System/360 с двумя жесткими дисками  в качестве дополнительного хранилища. ЭЛТ-дисплей и базовая операционная система были созданы с нуля специально для GRAIL. Несмотря на локальных характер проекта и низкую распространенность мейнфреймов, исследователи отмечают, что система была перегружена в условиях пиковых нагрузок, что свидетельствует о том, что проект, возможно, немного опередил свое время. Я был удивлен, обнаружив, насколько продвинутой была система распознавания — она вышла за рамки простого распознавания рукописных символов и позволяла использовать различные жесты для редактирования текста, а также автоматический синтаксический анализ для обеспечения корректности строк (в конце концов, это среда программирования).

❯ GRiDPad

Ближе к 80-м, благодаря распространению микрочипов, компьютеры в целом начали проникать в дома обычных людей. Они больше не представляли из себя целые шкафы, а скорее небольшой ящик или даже компактный корпус с клавиатурой «всё в одном». Первой компаний, которая скрестила готовую концепцию «планшета» и относительную миниатюрность вычислительной техники, стала Pencept. В 1982 году они запустили производство компьютерного терминала общего назначения, использующего планшет и функцию распознавания рукописного ввода вместо клавиатуры и мыши.

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

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

И всё же первым устройством, которое можно отнести к планшетным компьютерам, стал Letterbug, разработанный стартапом Hindsight из Коннектикута. Устройство предназначалось для сферы образования, в частности, для обучения письму детей с дислексией.

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

Не считая других концептов от Pencept, Linus Technologies и Acorn, первый коммерчески успешный планшет появился спустя 3 года, в 1989. Им стал GRiDPad 1900, выпущенный одноименной компанией GRiD, уже успевшей стать известной благодаря изобретению прообраза ноутбука. Он весил 4,5 фунта и имел резистивный экран с проводным стилусом. Система распознавания рукописного ввода была создана Джеффом Хокинсом, который руководил разработкой GRiDPad, а позже создал PalmPilot. Его программное обеспечение GRiDPen работало под управлением MS-DOS и позже было лицензировано как PenRight.

GRiDPad 1900 - это, по сути, чрезвычайно портативный IBM PC-XT. Он оснащался монохромным сенсорным CGA-дисплеем с разрешением 640x400, 2 МБ системной памяти и  2,5-дюймовым IDE-диском объемом 20 МБ. Имелась возможность подключения внешней клавиатуры, модема и устройств с последовательным портом RS-232. Также для устройства существовала док-станция, добавляющая разъемы под внешний дисковод и принтер. Информацию также можно было переносить через карты памяти стандарта PCMCIA тип 1. На корпусе расположены кнопки с F1 по F5, кнопка перехода в режим ожидания, а также переключатель питания.

Имеется 6-контактный интерфейс клавиатуры micro-DIN XT. Аудиосигнал ограничен поддержкой обычных динамиков ПК. На устройстве имеется один последовательный порт и расширение для модема с частотой 2400 и 9600 бит / с. На устройстве есть два слота ATA-FLASH, которые используются исключительно для хранения данных. В нижней части системы также имеется разъем шины расширения, который включает в себя, по крайней мере, разъем для клавиатуры, параллельный порт и шину гибких дисков

Это устройство использовалось в основном для инвентаризации и тому подобного. По-видимому, оно использовалось Chrysler и армией Соединенных Штатов. Военные требовали от корпуса большей жесткости и долговечности, чем от гражданской версии, и поэтому GRiD изготовила корпус из магния. Магниевые «гриды» никогда не продавались широкой публике.

Кроме оригинальной модели, внимания заслуживают, пожалуй PalmPad и GRiDPad Convertible. Первый появился в марте 1992 года и представлял из себя ещё более миниатюрное устройство с дисплеем 6.5 дюйма против 10. Кроме того он был в полтора раза легче. В минусы можно записать отсутствие подсветки, как на модели 1910 и меньшее количество портов для подключения устройств и расширений.

GRiDPad Convertible же представлял из себя более продвинутое устройство, в первую очередь отличавшееся наличием встроенной клавиатуры. Он оснащался процессором Intel 80386 или 486, имел до 20 МБ оперативной памяти и до 120 — дискового пространства.

Важное отличие от предыдущих моделей — операционная система. Да, в основе здесь всё ещё MS-DOS, но на Convertible также могла устанавливаться специальная редакция Windows 3.1 for Pen Computers. К Windows на планшетных компьютерах мы ещё вернемся, но это была одна из первых попыток.

К сожалению, уже в 1993 году GRiD Systems ждало банкротство. Трансформеры ещё какое-то время продавались под именем AST PenExec, но в 1994 году их поддержка прекратилась.

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

❯ Apple Newton

За пару лет до выхода «Грида» Apple Computer начала разработку своего устройства с сенсорным экраном и распознаванием рукописного ввода. В 1987 году был представлен концепт Knowledge Navigator. Он описывает не только планшет, но целую новую систему взаимодействия человека с компьютером. Пользователи буквально могли путешествовать через «миры знаний».

Так описывает проект Джон Скалли, генеральный директор компании на тот момент: «Это Macintosh будущего поколения, который должен появиться в начале двадцать первого века, вполне может быть замечательной фантастической машиной под названием Knowledge Navigator, первооткрывателем миров, инструментом, столь же прорывным, как печатный станок. Люди могли бы использовать его для навигации по библиотекам, музеям, базам данных или архивам. Этот инструмент не просто приведет вас к этим огромным ресурсам, как это делают сейчас сложные компьютеры; он пригласит вас глубоко проникнуть в его секреты, интерпретируя и объясняя — преобразуя огромные объемы информации в персонализированные и понятные знания».

Видеоролик Apple Knowledge Navigator иллюстрирует использование ряда технологий, включая:

• Планшетный компьютер;

• Гибкий дисплей;

• Сенсорный интерфейс;

• Карты памяти;

• Университетские исследовательские сети;

• Гипертекст в распределенных базах данных;

• Программное обеспечение для моделирования, для разработки и экспериментов;

• Видеоконференции;

• Интеллектуальные агенты с распознаванием и синтезом голоса.

Всего за год было выпущено 5 видео-демонстраций, охватывающих период с 1992 по 2008 год. Они показывали различные  возможности планшетного компьютера, включая отличную систему преобразования текста в речь без «роботизированости», интерфейс на основе жестов, позже использованный на iPhone, и не менее мощную систему понимания речи, позволяющую пользователю общаться с системой через анимированного «дворецкого» в качестве программного агента.

Проект Newton изначально был нацелен на создание «персонального цифрового помощника» (personal digital assistant, PDA). Этот термин был внедрён самим Джоном Скалли на достаточно поздних стадиях проекта. Newton должен был соответствовать концепту «Навигатора», стать новым видом персонального компьютера. Довольно продолжительное время Newton разрабатывался как компьютер с экраном большого формата, большой внутренней памятью и полноценным объектно-ориентированным графическим ядром. Одним из оригинальных сценариев, повлиявших на разработку, был «сценарий работы Архитектора»: архитектор, занимающийся проектами жилых домов, обсуждает с клиентом новый дом, используя двумерный план этажа — делает набросок и вносит изменения непосредственно в ходе разговора.

Разработкой программного обеспечения распознавания рукописного текста для первого Apple Newton занималось российское предприятие ParaGraph.

Готовый продукт появился в августе 1993 года. Официальное название устройства — MessagePad, название Newton было закреплено за операционной системой и было дано ей в честь Исаака Ньютона.

80-90-е года прошлого века были временем быстрого развития компьютерной техники, казалось бы только вчера появившийся графический интерфейс уже становился чем-то обыденным и не поражал воображение. Компьютер всё ещё оставался в лучшем случае домашним, первые портативные «лептопы» были неудобны, да и управление с клавиатуры, можно сказать, не менялось десятилетиями. Неужели принципы взаимодействия человека и машины всегда должны оставаться такими? Newton и был первым ответом на этот вопрос. В Newton были новые метафоры и абстракции, во многом опережающие Mac. Сегодня мы считаем само собой разумеющимся, что во многих приложениях (включая сетевые) не нужно явно сохранять изменения или, допустим, выбирать уникальное имя и задавать папку для любого нового созданного объекта. В Newton это было уже в 1993 году в масштабах всей системы. Даже от названия Newton веяло чем-то великим. Он уступал Mac в производительности и программных возможностях (все Newton были черно-белыми), однако на пике ньютономании (была и такая), которая лишь усилилась в период неудач Mac, всем казалось, что в будущем интерфейсные парадигмы Newton лягут в основу флагманских компьютеров Apple — а со временем и всех остальных. Парадигмы того Newton, каким он вполне мог стать.

Наряду с основной серией MessagePad, ориентированной на рукописный ввод, Newton OS был оснащён eMate 300 — единственный КПК Apple со встроенной клавиатурой.

Современные авторы находят Newton инновационным, восхитительным устройством. Но к сожалению, история этого компактного компьютера тоже заканчивается трагично. MessagePad был дорог, а качество распознавания текста оставляла желать лучшего. Ходят слухи, что Apple сильно упростила изначальное ПО «ПараГрафа», но возможно оно изначально было несовершенным. В любом случае, как кажется лично мне, устройство просто опередило своё время, его амбиции оказались сильнее возможности технологий. Уже упомянутый Palm Pilot несколькими годами позже использовал куда более простую систему, был лёгким и дешевым. На самом деле простого ответа на вопрос «Почему Newton быстро сняли с производства» нет. Его проблемы и недостатки были многомерными, это была сложная совокупность разных факторов. В итоге, когда на капитанский мостик Apple вернулся Стив Джобс, он отправил всю продуктовую линию Newton в утиль. В каком-то смысле Newton — это квинтэссенция переходного периода Apple со всеми ее плюсами и минусами. Так что вполне вероятно, что при Джобсе у Newton не было шансов. Как у Apple IIGS и «бежевых» макинтошей. Некоторые преданные поклонники Newton усматривали в поступке Джобса личные мотивы: у него был зуб на Джона Скалли, уволившего его в 1985 году.

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

Написано специально для Timeweb Cloud и читателей Пикабу. Больше интересных статей и новостей в нашем блоге на Хабре и телеграм-канале.

Хочешь стать автором (или уже состоявшийся автор) и есть, чем интересным поделиться в рамках наших блогов — пиши сюда.

Облачные сервисы Timeweb Cloud — это реферальная ссылка, которая может помочь поддержать авторские проекты.

📚 Читайте также:

• Гэри Килдалл — изобретатель, предприниматель, легенда;

• Предательские фото: две истории о том, как ЦРУ по шакалистым фотографиям раскрывало ядерные секреты СССР;

• Будущее хранения данных. Где и на чем будем хранить данные в будущем.

Привет, Пикабу!

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

❯ Небольшая предыстория

На тот момент я не имел счетчиков учета воды со смарт функциями, поэтому, для интеграции в свою систему умного дома, использовал проект AI on the edge device, который реализован на базе модуля ESP32 CAM и для распознания значения расхода использует алгоритмы машинного обучения (платформа Tensorflow lite) на базе компьютерного зрения.

Ниже фото установленного модуля для считывания показаний на базе ESP32 CAM:

Но в процессе эксплуатации у данного решения было выявлено несколько недостатков, а именно:

• Точность распознания — очень часто передавались ошибочные показания;

• Большое потребление, что затрудняет использование в местах с отсутствием доступа к сети питания;

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

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

Установка новых счетчиков ITELMA в техническом отсеке:

❯ Разработка аппаратного устройства

Итак, счетчики установлены, концы выведены, можно сказать, что половина дела сделана :) Далее нам предстоит немного интеллектуального труда, а именно — разработать принципиальную схему устройства, исходя их наших «хотелок» (назовем их «техническим заданием»). В итоге у меня сформировалось следующее ТЗ:

• Устройство должно быть реализовано на элементной базе, которая у меня имеется в наличии;

• Устройство должно иметь возможность работы от встроенного источника питания, соответственно, иметь низкое энергопотребление;

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

С коммуникацией ясно, как и в прошлой статье, будем использовать микроконтроллерESP8266от компании Espressif Systems. Но для снижения потребления энергии нам придется перенести функцию подсчета импульсов на более энергоэффективный и маломощный микроконтроллер, так как ESP8266 в активном режиме потребляет много энергии (даже с отключенным радиомодулем), если рассматривать его в контексте автономного питания. К счастью, у меня есть под рукой кандидат, который справится с этой задачей — это проверенный временем микроконтроллер от компании Microchip TechnologyATtiny 2313A. В результате у нас «вырисовывается» следующая принципиальная схема устройства.

Принципиальная схема устройства:

Для достижения максимальной энергоэффективности ATtiny 2313A, согласно технической документации, необходимо обеспечить уровень питающего напряжения в 1,8 В. Ниже приведена техническая информация возможностей данного микроконтроллера:

Возможности ATtiny 2313A-SU:

Features

• High Performance, Low Power AVR® 8-Bit Microcontroller • Advanced RISC Architecture

– 120 Powerful Instructions – Most Single Clock Cycle Execution – 32 x 8 General Purpose Working Registers

– Fully Static Operation

– Up to 20 MIPS Throughput at 20 MHz

• Data and Non-volatile Program and Data Memories

– 2/4K Bytes of In-System Self Programmable Flash

• Endurance 10,000 Write/Erase Cycles

– 128/256 Bytes In-System Programmable EEPROM

• Endurance: 100,000 Write/Erase Cycles

– 128/256 Bytes Internal SRAM

– Programming Lock for Flash Program and EEPROM Data Security

• Peripheral Features

– One 8-bit Timer/Counter with Separate Prescaler and Compare Mode

– One 16-bit Timer/Counter with Separate Prescaler, Compare and Capture Modes – Four PWM Channels

– On-chip Analog Comparator

– Programmable Watchdog Timer with On-chip Oscillator

– USI – Universal Serial Interface

– Full Duplex USART

• Special Microcontroller Features

– debugWIRE On-chip Debugging

– In-System Programmable via SPI Port

– External and Internal Interrupt Sources

– Low-power Idle, Power-down, and Standby Modes – Enhanced Power-on Reset Circuit

– Programmable Brown-out Detection Circuit

– Internal Calibrated Oscillator

• I/O and Packages

– 18 Programmable I/O Lines

– 20-pin PDIP, 20-pin SOIC, 20-pad MLF/VQFN

• Operating Voltage – 1.8 – 5.5V

• Speed Grades

– 0–4MHz@1.8–5.5V – 0–10MHz@2.7–5.5V – 0–20MHz@4.5–5.5V

• Industrial Temperature Range: -40°C to +85°C • Low Power Consumption

– Active Mode

• 190 μA at 1.8V and 1MHz

– Idle Mode

• 24 μA at 1.8V and 1MHz

– Power-down Mode

• 0.1 μA at 1.8V and +25°C

Чтобы обеспечить данный уровень питающего напряжения, в схеме предусмотрен линейный регулятор LP2985-18DBVR с низким падением напряжения и имеющий ток собственного потребления 850 мкА при максимальном загрузочном токе в 150 мА.

Моя реализация подразумевает использование в качестве источника питания li-ion аккумулятор форм фактора 18650, но также в схеме предусмотрена возможность питания от элементов АА с напряжением 1,5 В.

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

Ниже приведена визуализация проекта печатной платы.

Трассировка и габаритные размеры платы:

Рендер трехмерной модели платы:

❯ Изготовление печатной платы

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

Видео процесса:

Процесс активации паяльной маски лазером:

Плата после монтажа радиокомпонентов:

❯ Корпус устройства

Здесь всё просто, по классике DIY, модель корпуса была спроектирована воFreeCADи напечатана на моем любимом и проверенным временем принтереFlyingbear Ghost 5.

Рендер модели корпуса:

Корпус после печати:

❯ Сборка устройства

Установка системы питания в корпус:

Как можно видеть на изображении, в качестве контроллера зарядки применен модуль на базе TP4056, а в качестве разъема питания — USB Type-C. И для улучшения качества связи, применена внешняя Wi-fi антенна с разъемом SMA. А в качестве световода, для отображения индикации заряда, был применен прозрачный термоклей. Я считаю что DIY без термоклея — это не DIY.

Установка платы в корпус. Для фиксации платы в корпусе предусмотрены специальные прорези.

Пример с моделью платы:

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

Устройство в собранном виде:

Порт зарядки и выключатель:

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

❯ Прошивка, интеграция в «Умный дом» интерфейс устройства

Прошивка устройства

Микро ПО устройства реализовано на моей «базовой» прошивке для умных устройств. Здесь я опишу несколько важных моментов, в остальном коде вы можете «поковыряться» на моем GitHub. Для простоты реализации, используется среда разработки Arduino IDE, а для программирования ATtiny 2313 — библиотека ATtiny Сore.

Так как в устройстве применяется два микроконтроллера: ESP8266 в качестве ведущего, а ATtiny2313 в качестве ведомого, то я хотел бы описать метод коммуникации между устройствами. Ниже представлен полный код прошивки ATtiny 2313:

Исходный код прошивки ATtiny 2313:

#include <Wire.h>

int32_t counter0 = 0;

int32_t counter1 = 0;

uint16_t data = 0;

uint16_t data_t;

void setup() {

pinMode(4, INPUT_PULLUP); // Пин счетчика 1

pinMode(5, INPUT_PULLUP); // Пин счетчика 2

attachInterrupt(0, countPulses0, FALLING); // Прерывание на INT0 при падении сигнала

attachInterrupt(1, countPulses1, FALLING); // Прерывание на INT1 при падении сигнала

Wire.begin(18); // Устанавливаем адрес устройства I2C

//PB5: SDA (Serial Data) - 12

//PB7: SCL (Serial Clock) - 14

Wire.onRequest(sendCounters); // Устанавливаем функцию обработки запроса на передачу данных

}

void loop() {

sender(); // Это пустая функция в точке входа, чтобы контроллер работал, иначе не работает

}

void countPulses0() {

counter0++;

}

void countPulses1() {

counter1++;

}

void sender(){

if((millis() - data_t) > data*3600000 && data >= 1 ){ // Событие которое не сработает никогда

data_t = millis();

digitalWrite(10, HIGH);

while((data_t + 1000) > millis()){}

digitalWrite(10, LOW);

}

}

void sendCounters() {

byte byteData[8]; // массив для хранения байтов

byteData[0] = (counter0 >> 24) & 0xFF; // старший байт счетчика 0

byteData[1] = (counter0 >> 16) & 0xFF;

byteData[2] = (counter0 >> 8) & 0xFF;

byteData[3] = counter0 & 0xFF; // младший байт счетчика 0

byteData[4] = (counter1 >> 24) & 0xFF; // старший байт счетчика 1

byteData[5] = (counter1 >> 16) & 0xFF;

byteData[6] = (counter1 >> 8) & 0xFF;

byteData[7] = counter1 & 0xFF; // младший байт счетчика 1

Wire.write(byteData, 8); // Отправляем данные по шине I2C

}

Как можно видеть, код довольно простой. И как вы уже, наверное, могли догадаться, связь между контроллерами обеспечивается по I2C шине. Функция обмена по шине реализована с помощью библиотеки <Wire.h>, где используются методы:

• Wire.begin(18) — назначает адрес устройства;

• Wire.onRequest(sendCounters) — установка функции обработки запроса на передачу данных;

• Wire.write(byteData, 8) — метод для отправки данных;

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

attachInterrupt(0, countPulses0, FALLING); // Прерывание на INT0 при падении сигнала
attachInterrupt(1, countPulses1, FALLING); // Прерывание на INT1 при падении сигнала

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

– Active Mode
• 190 μA at 1.8V and 1MHz

Данный параметр устанавливается в среде программирования:

Запрос со стороны ведущего ESP8266:

void read_count(){

Wire.requestFrom(SLAVE_ADDRESS, 9); // Запрос данных у ведомого устройства

while (Wire.available() < 9) {} // Ожидание доставки всех данных

receiveData(); // Получение данных счетчиков

}

void receiveData() {

byte byteData[8]; // Массив для хранения принятых байтов

Wire.readBytes(byteData, 9); // Чтение данных из шины I2C

uint32_t receivedCounter0 = ((uint32_t)byteData[0] << 24) | ((uint32_t)byteData[1] << 16) | ((uint32_t)byteData[2] << 8) | byteData[3]; // Собираем данные счетчика 0

uint32_t receivedCounter1 = ((uint32_t)byteData[4] << 24) | ((uint32_t)byteData[5] << 16) | ((uint32_t)byteData[6] << 8) | byteData[7]; // Собираем данные счетчика 1

uint32_t c0 = receivedCounter0 - receivedCounter0_storage;

uint32_t c1 = receivedCounter1 - receivedCounter1_storage;

if(receivedCounter1 != 4294967295 && receivedCounter0 != 4294967295){

if(c0 > 429496652 && c1 > 429496652){

L_1 = 0;

L_2 = 0;

}else{

L_1 = c0;

L_2 = c1;

}

receivedCounter0_storage = receivedCounter0;

receivedCounter1_storage = receivedCounter1;

ESP.rtcUserMemoryWrite(0, &receivedCounter0_storage, sizeof(receivedCounter0_storage));

ESP.rtcUserMemoryWrite(sizeof(receivedCounter0_storage), &receivedCounter1_storage, sizeof(receivedCounter1_storage));

if(!config_st){

MQTT_send_data("json", JSON_DATA());

}

}

}

Интеграция в Home Assistant и интерфейс устройства

Конфигурация устройства выполняется через web интерфейс. При первоначальном подключении, устройство создает точку доступаCYBEREX-COUNTс беспарольным доступом. После подключения к точке доступа, у пользователя автоматически откроется страница авторизации, где необходимо будет ввести пароль по умолчанию «admin». После входа необходимо выполнить конфигурацию устройства. Интерфейс простой и интуитивно понятный. Ниже представлены скриншоты интерфейса.

Главная страница:

Конфигурация веса импульса:

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

Настройка MQTT протокола и периодичности отправки данных:

В данном устройстве реализован механизм MQTT Auto Discovery, позволяющий в автоматическом режиме добавлять объекты счетчика в Home Assistant.

Скриншот энергомониторинга:

И для возможности интеграции в Энергомониторинг Home Assistant, в MQTT запросе реализована передача параметра:

"state_class": "total"

При необходимости, Вы можете «собрать» карточку объектов для отображения данных нашего устройства.

Пример карточки объектов:

Для перехода в режим конфигурации необходимо выполнить следующие действия:

• Зажать кнопку 1 и не отпуская, кратковременно нажать кнопку 2;

• Не отпуская кнопку 1, дождаться постоянного мигания светодиода (примерно 10 секунд);

• Отжать кнопку 1 и перейти в web интерфейс для конфигурации устройства.

❯ Итоги

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

• Ток потребления устройства в обычном режиме: 540 мкА; (ESP8266 (DeepSleep) — 25 мкА + ATtiny2313A (Active mode) — 190 мкА + Остальное — линейные регуляторы напряжения и подтягивающие резисторы );

• Ток потребления в режиме передачи данных: 74 мА (зависит от уровня сигнала сети в точке установки).

Бюджет проекта, если рассматривать стоимость «железа», составляет не более $ 5,66.

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

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

Ссылки к статье:

• GitHub с исходным проекта;

• Модель корпуса для печати (STL).

Написано специально для Timeweb Cloud и читателей Пикабу. Больше интересных статей и новостей в нашем блоге на Хабре и телеграм-канале.

Хочешь стать автором (или уже состоявшийся автор) и есть, чем интересным поделиться в рамках наших блогов — пиши сюда.

Облачные сервисы Timeweb Cloud — это реферальная ссылка, которая может помочь поддержать авторские проекты.