Промышленное программирование *

Предлагаю вашему вниманию запись вебинара "Особенности разработки встроенного ПО по требованиям ФБ". Слайды презентаций.

Вместе с экспертами из "ФанкСэйфети" разбирались с такими сущностями, как ГОСТ Р МЭК 61508, уровнями SIL, стандартом MISRA C, сертификацией по функциональной безопасности и т. д.

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

Примечание 1. Говоря про безопасные и сертифицированные компиляторы, стоит отметить, что в 2024 году появился ГОСТ Р 71206-2024: "Разработка безопасного программного обеспечения. Безопасный компилятор языков С/С++. Общие требования". Также см. пост из цикла разбора РБПО: Процесс 12 — Использование безопасной системы сборки программного обеспечения и вебинар на эту тему.

Примечание 2. Инструменты SAST и DAST не обязаны быть сертифицированы. Из методической рекомендация ФСТЭК № 2025-07-011 | Уровень критичности: 3:

Область: Инструментальный анализ

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

Описание: В настоящий момент ФСТЭК России не предъявляет требования наличия сертификата соответствия к большинству типов инструментов анализа кода и архитектуры. При этом к инструментам предъявляются следующие требования: ...

См. также выдержку из эфира AM Live "Разработка безопасного программного обеспечения (РБПО)". Анализатор PVS-Studio участвует в инициативе ФСТЭК по испытаниям статических анализаторов кода, но это другая история.

Примечание 3. Был вопрос, связанный с объединением требований ФБ и ИБ в одном стандарте. Некоторые усилия в этом направлении предпринимаются, см. примеры ГОСТов ниже:

ГОСТ Р 59506-2021/IEC TR 63074:2019. Безопасность машин. Вопросы защиты информации в системах управления, связанных с обеспечением функциональной безопасности.

ГОСТ Р 71452-2024/IEC/PAS 63325:2020. Требования к функциональной безопасности и защите системы контроля промышленной автоматизации (IACS) на протяжении жизненного цикла.

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

Автоматизация discovery: от идеи до интерфейса за один день

Мы у себя провели эксперимент и пришли к ряду выводов

Зачем

Классический discovery: недели согласований, уточнений, макетов, пока команда не дойдёт до первого прототипа. Мы проверили гипотезу: можно ли сократить весь цикл от идеи до интерфейса до 24 часов — без потери управляемости и качества.

Что сделали

Собрали полуавтоматический pipeline, который превращает любые вводные (голос, текст, фото) в CJM, прототип и UML. Нижняя граница — один день. Обычно 2-3 дня. Пайплайн выстроен вокруг генеративных инструментов:

1. ChatGPT — генерирует эпики, сценарии, модели данных, UI-интерфейсы и документацию

2. Bolt.new — визуализирует CJM и собирает первый прототип

3. GitHub + Codex — превращают интерфейсы в код и валидируют логику (не удалось внедрить из-за ограниченного контекстного окна)

4. tldv; — записывает и логгирует встречи со стейкхолдерами и командой

В итоге discovery превращается из цепочки встреч в цикл общения с GPT

Результат

• Цикл discovery сократился до 2-3 дней, иногда — 1

• Трудозатраты продуктов и дизайнеров снизились в разы, иногда — без дизайна

• Стоимость на команду — около 190 $/мес (tldv + bolt.new + chatgpt)

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

• Возможность полного отказа от дизайна в ряде кейсов (Bolt)

Что не заработало

• Bolt ограничен по объёму токенов, не подходит для сложных интерфейсов

• Вводные без контекста ломают качество генерации

• Для больших проектов пока не хватает контекстного окна и нужно предварительное упрощение проекта

• Часть сценариев по-прежнему требует ручной доводки.

Бизнес-эффект

• Time-to-Market резко снижается

• Высвобождение продуктовых и дизайнерских ресурсов

• Формализованный discovery-процесс, готовый к стандартизации

Автоматизация discovery жизнеспособна. Большая часть процесса может быть выполнена GPT с минимальным участием людей. Проект завершился на ручном приводе — но подтвердил, что конвейер от идеи до интерфейса за сутки реален. Дальше — вопрос масштаба и доверия к машине.

ИТ-завод запущен успешно: пора забирать призы

Пришло время подвести итоги и наградить победителей ИТ-пинбола!

Напомним, что участникам предстояло активировать 5 цехов виртуального ИТ-завода и запустить его. «Мастеров шара» оказалось немало, но лишь несколько добрались до вершины рейтинга. Они получат фирменный мерч с логотипом «Северстали».

Теперь к призам.

Стильные рюкзаки теперь будут носить: 
@RAZEX0LOL
@marrainfue
@Vedun824

Греться в худи с логотипом «Северстали» смогут:
@Adhmor
@Ruhinger
@OCTAGRAM.

Слушать музыку в AirPods 4 будет @Zzingy

Крутые наушники Sony послужат занявшему @Artem_Dolgii

И, наконец, новенькие AirPods Max достаются покорителю пинбола — @zkingfinn

Это ещё не всё! Хабравчане, активировавшие в игре все 5 цехов ИТ-завода, скоро полюбуются ачивкой «Я — стальной» в своих блогах.

Поздравляем победителя и призёров! Мы уже написали вам в личку все детали)

Не грустите, что наш конкурс завершился. Кто знает, вдруг вам совсем скоро снова пригодятся полученные скилы? : )

Готовы запустить ИТ-завод? На кону — крутые призы и награда на Хабре!

«Северсталь» запустила совместный проект с Хабром, игру в пинбол. В ней можно проверить свою ловкость, а также узнать интересные факты об ИТ-проектах в промышленности. Цель проста: набрать максимум очков, активируя цеха и открывая карточки с фактами.

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

Участие в ИТ-пинболе — это отличная возможность больше узнать об информационных технологиях «Северстали». Переходите по ссылке, играйте, соревнуйтесь и активируйте собственный ИТ-завод!

Разбираюсь с бюджетными преобразователями USB CAN. В качестве параметра для классификации удобно использовать тип применяемого протокола, по которому данные передаются на ПК.

slcan - текстовый протокол который применяется еще и с интерфейсом RS2232, с оборудованием фирм LAWICEL и VScom, переросшим в связку USB-UART-CAN, с виртуальным последовательным портом, а затем - в USB CAN на единственном микроконтроллере, а затем и вообще TCP. C которым можно работать из обычной терминальной программы, без особого софта.
Существует множество реализаций и расширений этого протокола, на разных микроконтроллерах, в том числе STM32, включая поддержку CAN-FD (на STM32G431, STM32G01) в основном в виде проектов на GitHub.
Проект canable (VID:PID AD50:60C4 либо 0x0403:0x6015) (и еще ранний вариант под названием cantact), прошивается в доступные платки на базе контроллеров STM32F042 и STM32F072 (на Ali похоже уже только на F072 продают). Получил развитие в виде canable v2 (STM32G431, 0x16D0:0x117E).
Вариация USB2CANFDV1 от WeAct studio (STM32G01, 0x0483:0x5740) - зашифрованная прошивка без исходников.
Помимо этого: stm32-slcan (STM32L433, 0x0483:0x5740, протокол урезан), UCCBEmbedded (STM32F042, 0x0483:0x5740), CFDC_embedded-slcan (STM32G431, 0x0483:0x5741), CAN2USB (STM32F105, 0x0483:0x5740), CANsniffer (STM32F042, 0x0483:0x5740).
Проект USBtin (PIC18, 0x04D8:0x000A) представляет собой скорее исторический интерес, в его состав входят макросы для поддержки протокола slcan в легендарной HyperTerminal. Не менее историческая разработка - у Michael Wolf, которая как то связана с программой CanHacker.
Проект ESP32RET использует текстовый протокол LAWICEL в качестве подмножества команд для двоичного протокола GVRET как через USB так и WiFi (TCP). Проект WiCAN реализует поддержку протокола slcan через USB, WiFi, BLE, а так же протокола для программы RealDash. Так же эти прошивки знают известный протокол ELM327 для автодиагностики, это тестовый протокол со множеством реализаций, однако при его помощи "сырой" CAN захватить либо трудно либо нельзя.

gs_usb более известный как candleLight (0x1D50:0x606F) по названию платы (разработка Linux Automation GmbH, так же фигурирует наименование USB2CAN by Geschwister Schneider Technologie-, Entwicklungs- und Vertriebs UG). Это уже двоичный протокол. Который рассчитан в первую очередь на контроллеры STM32F042/STM32F072, поддержка контроллера STM32G01 и CAN-FD на текущий момент только создается.
Однако есть проект bugetcan - прошивка для "most STM32 devices", есть готовые пресеты для STM32F042, STM32G01, STM32G431, STM32G473, STM32H743, STM32H745 и тоже работает с этим протоколом

uCAN_FD - упомянутый ранее CFDC_embedded (uCAN CanFD USB Converter(CFUC)) также предлагают свой собственный протокол, но он, похоже, работает только в софте из этого проекта.

pcan и kvaser по названию соответствующих фирм. Реализованы не только для фирменного оборудования, но и для тех же дешевых платок canable/cantact на STM32F042 (0x0bfd:0x0120 и 0x0483:0x000C), что дает возможность использовать софт рассчитанные именно на эти платы.

usb_8dev для 8 devices USB2CAN, реализован в открытом проекте CANalyze (STM32F042, 0x0483:0x1234), который, похоже, больше не развивается

Разные программы для мониторинга CAN обращаются с протоколами по разному. Например мощная программа BUSMASTER умеет работать с оборудованием VScom (в том числе и через TCP) и PEAK, а значит можно попробовать использовать ее с дешевыми платами перепрошитыми на поддержку такого протокола. SavvyCAN и CANgaroo умеют работать с LAWICEL/slcan, протокол candleLight - через драйвер для Windows. RealDash умеет работать с огромным числом протоколов. Ну а в linux (с относительно свежим ядром) некоторые перечисленные протоколы уже встроены в виде драйверов сетевых (устройств) SocketCAN, что тоже поддержано большим количеством софта.

Пошаговые инструкции сборки — больше не ад для техписов

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

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

На данный момент мы собрали из исходников документы для 647 конфигураций серверов. Даже при таком сравнительно небольшом количестве инструкций мы простым делением получаем затраты на один документ в размере 2 человеко-часов. Это в 12,5 раз дешевле, чем писать отдельные инструкции вручную — выше мы оценивали затраты такого подхода. В итоге с документацией справляются шесть человек — а если бы мы делали инструкции вручную, потребовалось бы не меньше 13 сотрудников. После внедрения конструктора мы оценили дальнейшие трудозатраты, продолжили работу с динамической документацией, и уже через несколько месяцев система начала окупаться.

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

Какую информацию содержит FRU EEPROM и как с ней работать

Набор возможных данных, хранимых во FRU EEPROM, определяется спецификацией Intel IPMI FRU Information Storage. Вся информация разделена на пять областей, присутствие каждой из которых не обязательно и определяется информацией в общем заголовке FRU EEPROM, где размещены указатели на данные каждой из них в следующем порядке:

1. Область для внутреннего использования (Internal Use Area) — ее
содержимое не описано спецификацией. Предполагается, что эта часть EEPROM может использоваться программным обеспечением BMC или другого контроллера на плате для хранения какой-то служебной информации (например, внутренних состояний).

2. Область информации о шасси (Chassis Information Area) — здесь содержится базовая информация о «корпусе» или «шасси» устройства, описываемого этим FRU EEPROM. Основным параметром тут является «тип шасси», который представляет собой целое число, выбираемое согласно спецификации SMBIOS (см. DMTF DSP0134, Table 17). Например, значение 0x17 соответствует типу «Rack Mount Chassis». Также в этой области может содержаться информация о серийном номере шасси и его артикуле (part number).

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

Какие еще есть области во FRU EEPROM, и как утилита frugen и библиотека libfru помогают с ними работать — читайте в статье Александра Амелькина, технического эксперта департамента разработки BIOS и BMC в компании YADRO, а также автора и мейнтейнера проекта frugen / libfru.

Интересно, до какой скорости можно разогнать 6502-е ядро с современными технологиями?

Допустим, у нас есть чиплет «6502 + 64К SRAM», выполненный в максимально быстром исполнении, вплоть до экзотики типа арсенида галлия (ядро проектировали не дураки и уложились в три с половиной тысячи транзисторов, что тогда было немало для кремния, а сейчас — для арсенида галлия тоже, насколько я знаю, очень до фига).

…и есть несколько кремниевых чиплетов с умножителем, DRAM и прочей веселухой. Или даже один кремниевый чиплет с этим всем, плюс с бутлоадером, который прогружает наши 64К с некоего SPI и после этого снимает с 6502-го ресет.

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

Команды 6502-го выполняются фиксированное время, причём довольно небольшое (в тактах. А арсенид галлия этих тактов нам даёт не просто много, а очень много). Пульнул той же DDR указание, занимается своими делами, через некоторое время прочитал от неё ответ. Мы с точностью до команды знаем, когда за ним лезть в порт.

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

Ну то есть в камментах я такое уже высказывал, но тут мне именно сама архитектура больно шибко зашла. Там даже система команд просто кричит — «сделайте на мне движок микрокода!!!»

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

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

НАБОЛЕЛО!!!!

Что бы вы не сделали, диванным критикам просто до одного места! Даже диван на котором он лежит это тоже Г-но потому, что болит левая пятка.

Семь лет назад нам нужен был промышленный компьютер (1000 штук), который бы собрал данные через промышленные протоколы и отправил их в облачную платформу с бюджетом до 15к (400 баксов) рублей на то время.

По какой то причине мы не заметили контроллер Wirenboard 6 (на процессоре NXP который покрывал все наши задачи) и начали разработку своего устройства AntexGate на базе Raspberry cm3 (теперь уже на Raspberry CM4 )

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

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

Имея таких конкурентов как Wirenboard, ОВЕН, RealLab, Siemens .... мы нашли своих клиентов и продаем в год более 700 компьютеров.

Мы заморозили свое прибор до -65 (легко запустился на таком морозе), нагрели до +101 (на 102гр выключился).
Все равно получаем каждый день отзывы: "Вы просто засунули малину в свое коробку!"
Нет не просто! Мы угрохали более 5 лет жизни небольшой команды на то, чтобы это все работало - "Так как должно!" Перебрали рефенсные схемы самых именитых Европейских производителей под свои реалии.

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

Я желаю пройти каждому разработчику правильный путь и по возможности сделать свое решение на сколько можно.
Я надеюсь, что оттепель настанет в нашей стране и появятся действительно Росcийские процессоры и другая элементная база, а пока увы Broadcom, Raspberry, NXP да на худой конец RockChip главное что-то делать и с голоду не умереть.

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

Учебник по Программированию Микроконтроллеров.

Господа,

Я сочинил книгу для библиотеки.

Предлагаю Вашему вниманию мой авторский учебник по программированию микроконтроллеров.

Всё утро его писал.

Называется
Практические Аспекты Программирования Микроконтроллеров

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

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

Скачать учебник можно по ссылке на git hub. Распространение приветствуется.

Есть две версии учебника: censored и unleashed.
Версию UnLeashed я буду высылать только под NDA в ответ на сообщение.

Учебник постоянно и непрерывно улучшается, исправляются опечатки, добавляются новые главы. Поэтому последняя версия лежит на git hub.

https://github.com/aabzel/Artifacts/tree/main/mcu_book

клонируйте репозиторий https://github.com/aabzel/Artifacts.git

git clone https://github.com/aabzel/Artifacts.git

И *.pdf окажется в папке mcu_book

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

Итоги хакатона: ML, ГОСТ, металлургия

Привет! Вот и мы с итогами!

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

В хакатоне приняло участие около 30 человек. Мы протестировали все решения и выбрали три лучших:

3 место занял Андрей Леонов. Его решение основано на создании базы вопросов и ответов. Система ищет пару вопрос-ответ с помощью специального метода без использования ИИ. Мы присудили третье место за оригинальный подход.

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

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

Планируем как можно скорее внедрить и проверить решение победителя в деле! Хакатон зашел на ура, так что точно будем проводить такие штуки еще! Следите за анонсами!

В Оксфордшире расположен крупнейший экспериментальный термоядерный реактор проекта JET (Объединенный европейский токамак). С 1984 года JET выполнил серию полезных экспериментов, а в 2024 поставил рекорд в генерации термоядерной энергии, но почти сразу после этого установку решили остановить. 

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

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

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

Больше IT-новостей бизнеса и бизнес-новостей IT — в нашем канале

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

Но можно гораздо проще. У нас есть значения A (B, C - свои тех. переменные) и 1 (1,1 те же уникальные тех. переменные из определнных в количестве 10) и 0 (00). Всего 9. 10 последнее испольуем как условную функцию равенства. Теперь аппаратным программированием строим тринарную матрицу 3х3 с 9 возможными значениями для строки. Это по часовой стрелке (A=B=C=(A)?(1)?(0), BCA, CAB или 3 строки). Программируем для столбца, - против. Далее описываем все возможные варианты значений квадратной матрицы третьего порядка. Индекс строки, индекс столбца, матричное значение выражаем линейно распределенными равенствами (предварительно выделив оперативное пространство в параллельной логике: I + ∑I+ ∑∑II + ∑∑∑I,II + ∑∑∑∑II,I + ∑∑∑∑∑III повторяем копированием полностью каждый раз предшествующую запись ∑ и запоминаем вновь образованные входные переменные, банальным равенством f=(₃3³), удов-им О.О.Ф. или 10ой тех-ой переменной из 13 битов) и обрабатываем запросы элеткронно-вычислительной машины, создав таблицы истинности, логические операторы и, конечно, перепроверку USB устройством 3 из 5 каждого посланного и принятого в такте битов (5 тактов для обработки 1 бита). Либо Y - 3 матр. значения, Y - 3 индекса матрицы, Y - вход., вых. приравнивания, переменная.

Важна ли вам защищенность промышленного интернета вещей?

Мы активно разрабатываем технологии для безопасности industrial internet of things (IIoT). За счет быстрого распространения IoT-технологий риск взлома таких устройств и систем постоянно растет.

Если в вашей компании используется IIoT, ➡️ поделитесь мыслями и наблюдениями в опросе.

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

Давайте работать сообща в области исследования угроз, объектов защиты и методов обеспечения безопасности инфраструктуры IIoT🔒

Всем привет. Возможно, вы помните меня по статьям об изменениях в C++ и о фреймворке 🐙 userver, поэтому сразу к делу. 27 июля я выступаю на конференции C++ Zero Cost Conf, которая пройдёт в Москве и Ереване. Там я поделюсь новостями со встречи Международного комитета по стандартизации языка в Сент-Луисе и расскажу о наших планах на C++26 и C++29. А ещё отвечу на ваши вопросы. Приходите в гости!

Помимо меня, вас также будут ждать: 

• Константин Владимиров, руководитель отдела компиляторов и средств разработки Syntacore. Покажет развитие архитектуры сложного LLVM-based-C++-проекта и конкретные задачи, возникающие при его развитии.

• Андрей Аксёнов, руководитель разработки инфраструктуры поиска Авито/Sphinx. Расскажет историю из продакшена с One Billion Row Challenge, парсингом гигабайтов TSV’шек, десятью странными оптимизациями и боттлнеками вообще везде.

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

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

Полный список спикеров и темы докладов смотрите на сайте. 

Если не получится прийти лично, подключайтесь дистанционно.

Российская компания «Е-Флопс» рассказала о разработке системной платы под названием «Ключевская» для двух Arm-процессоров.

По данным разработчиков, 20-слойная системная плата «Ключевская» не только многофункциональная, но и максимально компактная в рамках модульной концепции. Её размеры: 44,6х20,3 см.

Технические характеристики платы «Ключевская»:

• 2 процессора архитектуры ARM64;

• 48 ядер на процессор, частота до 2,2 ГГц;

• 12 слотов оперативной памяти при использовании 6 каналов;

• память стандарта DDR4 (RDIMM, LRDIMM) с частотой 3200 МГц;

• 80 линий PCIe 4.0, из них 48 линий совместимы с CCIX;

• встроенный интерфейс USB 2.0;

• встроенный интерфейс Ethernet 1 Гб/с;

• 2 разъёма M.2 для встроенных накопителей SSD NVMe x4 M.2 (2242);

• 2 разъёма PCIe 4.0 x16 для подключения до 8 накопителей M.2 NVMe или специализированных карт расширения с горячей заменой;

• слот PCIe 4.0 x16 OCP 3.0;

• 4 разъёма PCIe 4.0x16/CCIX для установки райзеров;

• 2 сетевых разъёма 10/25 Гб/с и 1x USB 2.0, 1x DP (при установке платы ввода-вывода);

• разъем 260-pin SODIMM DDR4 (для установки модуля удалённого мониторинга и управления стандарта RunBMC).

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

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

Разработчики сообщили, что в итоге всё протестированное стабильно работает. Первая партия плат выйдет в сентябре 2024 года.

Наконец новый промышленный компьютер на базе процессора broadcom, который полностью совместим с софтом для raspberry можно взять на тест бесплатно. Производство РФ.

Чат - техническая поддержка, и инструкция.

Запрос образца на тест в свободной форме.

Особенности устройства:

Интерфейс Etnernet 100Mb — 1шт;

Интерфейс Etnernet 1Gb — 1шт;

Интерфейс CAN-BUS – 1шт;

Интерфейс RS485 ISOLATED– 2шт;

Интерфейс RS232 – 1шт;

Интерфейс 1Wire – 1шт; Интерфейс USB – 2шт;

Дискретные входы оптопара- 4шт;

Релейные выходы – 2шт;

Выход оптопара – 1шт;

Разъем mPCIe – 1шт (на выбор):

• Lora;

• WiFi;

• 3G/LTE;

• NB-IOT;

  Разъем m.2 – 1шт Для диска NVMe SSD

  Разъем HDMI;

  Разъем для подключения GSM-антенны;

  Разъем для подключения WiFi-антенны;

  Рабочая температура: -25°C… +80°C. 

  Потребляемая мощность Питание: клеммы DC 12-48В; Passive Poe AC/DC 12-48В; Мощность: 1.56-5.8 Вт в зависимости от конфигурации.

  Системные характеристики Процессор: BCM2711 на базе Raspberry Pi CM4; ЦПУ: 4-ядерный Cortex-A72 (ARM v8) 64-bit SoC @ 1.5GHz Flash: 8/16/32GB eMMC. RAM: 1/2/4/8GB 

  Поддерживаемые протоколы ModBus; Dmx 512, MQTT, Profinet; LoRaWAN; CAN; OPC UA и доугте

  Поддерживаемых платформы и ПО

  NodeRed; OpenHab; CoDeSys; MasterSCADA 4D; Home Assistant; iRidiumMobile; Совместимый софт с raspberry pi4

  Поддерживаемые веб-сервисы ApacheHTTP; NGINX.

  Операционная система Поддержка Linux, Ubuntu, Debian, Astra Linux, OpenWrt

Числа, которые должен знать каждый программист в 2024 году и далее:

• L1 cache reference = 1 ns (1 нс)

• Branch mispredict = 3 ns (3 нс)

• L2 cache reference = 4 ns (4 нс)

• Send 1K bytes over 1 Gbps network = 11 ns (11 нс)

• Mutex lock/unlock = 17 ns (17 нс)

• Main memory reference = 100 ns (100 нс)

• Read 1 MB sequentially from memory = 1 us (1 мкс)

• Compress 1K bytes with Zippy = 2 us (2 мкс)

• Read 4K randomly from SSD = 16 us (16 мкс)

• Read 1 MB sequentially from SSD = 19 us (19 мкс)

• Read 1 MB sequentially from disk = 474 us (474 мкс)

• Round trip within same datacenter = 500 us (500 мкс)

• Disk seek = 2 ms (2 мс)

• Send packet CA->Netherlands->CA = 150 ms (150 мс)

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

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

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

• в коде переменные и функции имеют значимые названия и поэтому ничего не надо комментировать

• специалисту и так должно быть все понятно что тут написано

• Я ко всем функциям и объектам дал пояснения. Этого вполне достаточно.

• Всякие другие слова, которые объясняют почем комментировать не надо

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

Между ноль комментариев и комментарий к каждой строке лежат все промежуточные состояния.
На картинке ниже тексты от двух библиотек. Слева около 20 процентов комментов, а справа менее 5.
Обе библиотеки работают без проблем. Ну раз нет проблем, так зачем комменты?

Разработчик, который сдал готовый отлаженный код, не хочет тратить время на комменты. А я как заказчик текста, хотел бы иметь комментариями минимум 30 процентов текста. Чтобы я мог если надо быстро передать текст другому разработчику. Или на аутсорсинг. Или обновить код через 10 лет. Когда бывший разработчик давно будет хакером на Бали.

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