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

Этот пост — не про финальный продукт, а про инженерную задачу, которую ранее никто в России (и никто в мире) не решал. Работы над судовым радаром ближней зоны СИД360-76 начались в 2021 году — а первый прототип заработал в лаборатории уже в 2022 и в этом же году был уже временно установлен для тестов на судне. Поводом стал запрос от оператора ледокольного флота: при проводке судов во льдах ледоколы вплотную подходят к борту сопровождаемого судна. В такой ситуации «слепая зона» обычных радаров становится критически опасной. Нужно было решение, которое «видит» препятствия буквально в нескольких метрах от борта и позволит избежать ситуации с наваливанием судов друг на друга.

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

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

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

На нескольких проектах я сталкивался с ситуацией, когда есть Kubernetes с разными окружениями типа dev, stage, prod и т. д.

Код сервисов в эти самые окружения попадает в процессе CI/CD: то есть мы мержим какую‑то ветку с разрабатываемой фичей или исправлением бага в ветку, которая «привязана» к окружению и дальше наш код деплоится в кластер. Думаю, для многих — это уже стандартная история.

Давайте представим, что нужно сделать задачу, относящуюся к какому‑нибудь микросервису, эта задача подразумевает запрос по сети к другому микросервису, а тот, в свою очередь, посылает запрос к еще другим микросервисам. Как быть, когда мы хотим, чтобы нам были доступны данные из других микросервисов, чтобы протестировать то, что мы сделали не в тестах с моками, а в условиях, похожих на «боевые». Тут самым очевидным, как мне кажется, является разворачивание локально микросервиса, код которого мы «ковыряем» и проброс портов до целевого микросервиса в dev кластере (или в другом кластере, предназначенным для тестирования), например:

Сегодня автоматизированные системы управления технологическими процессами (АСУ ТП) являются неотъемлемой частью любого современного производства. Однако сама установка и пусконаладка системы — лишь половина дела. Настоящее испытание начинается в момент, когда оборудование переходит в эксплуатацию. Именно тогда становится очевидной роль обслуживания АСУ ТП — комплекса действий и организационных мер, позволяющих поддерживать системы в работоспособном состоянии, минимизировать простои и обеспечить надёжную работу всего предприятия.

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

В условиях стремительного развития промышленной автоматизации и повышения требований к надежности технологических процессов выбор оптимального программируемого логического контроллера (ПЛК) становится критически важным. Российский рынок предлагает широкий спектр решений, поэтому мы провели анализ и составили рейтинг контроллеров с учетом ключевых критериев. Более 18 лет практики в области автоматизации технологических процессов на рынке Российского АСУТП позволили сформировать комплексное понимание особенностей и тенденций развития отрасли.

1. REGUL R500 (Astra IDE)

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

Тогда какие действия можно предпринять, что добиться той самой эффективности?

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

Кажется, никому из читателей Хабра не нужно объяснять, насколько сложным процессом является разработка авиационной техники и комплектующих. Мы часто читаем об этом. Понятно что, длительность процессов разработки, высокие требования к безопасности, строгие формальные процедуры, сложность конструкции и многодисциплинарность научных подходов – вот причины, по которым средний цикл разработки воздушных судов (ВС) составляет 5-10 лет и не всегда заканчивается успешно.

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

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

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

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

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

Для чего это необходимо делать?

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

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

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

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

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

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

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

В заметке я представил простую утилиту r.exe для авто-замены токенов в файлах и названиях файлов.

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

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

Привет, Хабр! Меня зовут Александр Амелькин. Я технический эксперт департамента разработки BIOS и BMC в компании YADRO, мейнтейнер проекта ipmitool, а также автор и мейнтейнер проекта frugen / libfru, о котором и хочу сегодня рассказать, тем более что совсем недавно я выпустил новую версию 3.0 этого пакета.

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

Основные виды моделирования поведения:

1)    Диаграммы поведения в UML

Привет, постоянные и не очень читатели!

Помните фразу «Хьюстон, у нас проблемы?». Как раз в той пилотируемой экспедиции (Аполлон-13) был применён первый цифровой двойник в истории — только без интернета и облаков. Сегодня же эта технология ушла далеко вперёд: симуляции помогают проектировать ЦОДы, тестировать масштабные сети и предсказывать сбои до того, как всё сгорит.

В свежем лонгриде на Хабре я рассказываю:

Что такое цифровые двойники, откуда идея — и как они экономят миллионы (про недостатки тоже есть);

Где цифровые двойники уже используют на полную;

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

Приятного чтения!

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

Что делать поставщикам в 2025 году? Стоит ли небольшим компаниям задуматься об автоматизации цепочки поставок или лучше продолжать вести учёт в Excel и работать с каждым клиентом лично? Помогут ли B2B-кабинеты и предиктивная аналитика увеличить объёмы поставок для среднего бизнеса? Сохранит ли свою актуальность продукция крупных корпораций, учитывая глобальный тренд на устойчивое развитие и поддержку местных производителей?

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