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

Для тех, кто сталкивается с этим словом впервые, поясню. ПЛК это специальный мини-компьютер, который работает так:
1. Принимает входные дискретные (Di) или аналоговые (Ai) сигналы;
2. Обрабатывает эти сигналы по заданной программистом программе;
3. Выдает управляющий сигнал через дискретные (DO) или аналоговые (AO) выхода.

Дискретный — когда у сигнала может быть только 2 состояния: 0 или 1, «да» или «нет». Например, кнопка нажата или отжата, лампочка включена или выключена.
Аналоговый — когда значение параметра зависит от уровня электрического сигнала. Например, чем выше уровень сигнала (вольт или миллиампер) от датчика температуры, тем больше измеряемая температура.

Применяются ПЛК в основном в промышленности, станках, системах домашней автоматизации «умный дом» и т.д.

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

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

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

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



Все этапы Яндекс.Алгоритма в этом году пройдут в онлайне, так что поучаствовать в нём смогут и те, кто не готов куда-то ехать. Алгоритм состоит из нескольких отборочных раундов, в каждом из которых нужно решить пять задач за 100 минут. В финал, который состоится 6 августа, выйдут 25 лучших по результатам отбора. Тренировочный раунд, до которого стоит зарегистрироваться, пройдет 3 мая.

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

На последней конференции GPU Technology Conference, организованной компанией Nvidia, мы узнали, что доставка группы людей на Марс и обратно – задача непростая. Одна из проблем такой миссии – необходимость в большом и эффективном ракетном двигателе, который сможет доставить много материала на орбиту, — так объяснил нам Адам Лихтл, директор исследовательской группы SpaceX. С командой из нескольких десятков программистов он пытается справиться со сложной задачей улучшить симуляцию сгорания внутри ракетного двигателя. Для укорачивания полётов к Марсу также нужен большой двигатель.

В этой статье мы продолжаем рассказ о продуктах, разработанных на основе IoT-платформы AggreGate. В 2010-м году, через два года после появления продукта AggreGate Network Manager, мы стартовали проект AggreGate SCADA/HMI – СКАДА-системы 4-го поколения.
Что же такое СКАДА 4-го поколения?

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



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

На связи LogistiX! Мы разработчики промышленной системы управления складом LEAD WMS.

Сталкиваясь с автоматизацией, часто приходится слышать о «волновой сборке» и «волнах заказов». Для начала, маленькая вводная о том, каким образом появился термин «волна». Представим себе график, где по оси X – время, а по оси Y – некоторый показатель. Мы ждем, пока значение показателя по оси Y не увеличится до заданной максимальной величины, и начинаем выполнять действия, приводящие к уменьшению значения. Затем, «упав» до заданного минимального значения, снова ждем накопления. Таким образом, у нас появляется график в виде своеобразных «волн». Приведу простой пример, когда использование таких «волн» нам может быть выгодно при сборке заказов:

О статье

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

Чтобы не перегружать данную статью, разобью ее на 2 части:

1. Постановка задачи и методы реализации;
2. Программное распознавание и электроника.

Инженер

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

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

Тот, кто несет фонарь, спотыкается чаще,
чем тот, кто идет следом
Жан Поль

Предисловие

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

На связи LogistiX! Мы разработчики промышленной системы управления складом LEAD WMS.

WMS – аббревиатура от английского «Warehouse Management System», или «система управления складом». Часто можно встретить русскоязычную аббревиатуру СУС, а некоторые производители относят свои системы даже не к WMS, а к IMS (inventory management system), WCMS (warehouse complex management system), и так далее. Те, кто чуть больше остальных погружен в складскую тематику, при упоминании об управлении складом сразу вспоминают радиотерминалы, этикетки, штрихкоды и прочие обязательные атрибуты внедрения. Те, кто погружен меньше, ассоциирует выражение «управление складом» со «складским учетом», что порой приводит к некоторым терминологическим разногласиям: если штрихкоды — это отсылка на технологии автоматической идентификации, то «складской учет» чаще ассоциируется с оформлением товаросопроводительной документации и ведением информации о складских остатках.

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

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

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

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



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

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

Наименование: Dead End (тупик)
Другое наименование: Kevorkian Component (мертвый компонент)

Суть проблемы

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

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

Для начала приведу сухие теоретические знания. Если теория не интересует — можно пропустить.

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

Наверное не ошибусь, если предположу, что какая-то часть хабра-сообщества помнит это мероприятие, которое проходило в Москве, Киеве, Ростове-на-Дону, Тбилиси, Ташкенте, Иркутске, Магнитогорске, Ленинграде и Минске.



Лично для меня с него началось мое знакомство с высокими технологиями, хотя придя туда, увидел достаточное количество сверстников, оккупировавших компьютеры своими болгарскими 5-дюймовыми дискетами, а как пишет New York Times за 6 июня 1987 года, некоторые уже пытались уломать гидов скопировать им Lotus 1,2,3. Итак,

В своей прошлой статье я описывал возможность управления ПЛК джойстиком и обещал добавить небольшое изменение, связав ПЛК и LabVIEW не через последовательный порт, а через Ethernet (благо, коммуникационные возможности ПЛК100 это позволяют) и при помощи OPC-сервера — в данном случае это Codesys OPC Server. (Кстати, аналогичным образом с LabVIEW можно связать любой другой контроллер — через OPC-сервер, который работает с конкретным контроллером). В этой статье я, собственно, и собираюсь описать, как всё это делается.

Данная статья представляет собой в основном вольный пересказ фрагмента книги Эрика Эванса «Предметно-ориентированное проектирование», в котором он рассуждает о Separate Ways и Bounded Context.

Допустим, есть следующая ситуация: несколько групп разработчиков работают над одним проектом, но решают разные задачи. Например, проект представляет собой конструктор микросхем, и первая команда реализует функциональность прозванивания микросхемы, а вторая – расчётом себестоимости микросхемы. Вопрос: как лучше поступить – 1)позволить обеим командам «вариться в собственном соку», получив на выходе два модуля, код которых практически нигде не пересекается, или же 2)наладить коммуникацию между двумя командами, заставить их работать сообща и получить на выходе единую монолитную систему? На этот вопрос не существует универсального ответа («да» или «нет») и найти ответ в этой ситуации нам поможет аналогия со слоном и мудрецами.

Однажды на моём рабочем столе оказались usb-джойстик и ПЛК (программируемый логический контроллер) фирмы ОВЕН — ПЛК100, при этом на компьютере была запущена среда LabVIEW. Я подумал, что всё это — хотя бы забавы ради — можно объединить, организовав управление ПЛК (его выходами) с помощью кнопок джойстика (позже я решил использовать не просто кнопки, а их комбинации — ВНИЗ, ВПЕРЁД, Y, например).