Когда-то мне довелось делать программу для управления процессом измерения в мониторе артериального давления (АД). Хочу на этом примере разобрать и продемонстрировать что нужно для решения задач реального времени. Наверно на этом примере можно понять, в том числе, когда нужно использовать RTOS.
Я постараюсь, конечно, рассмотреть эту задачу как гипотетическую, с минимальным погружением в детали того откуда берутся те или иные требования, но очень многое завязано именно на эти детали.
— Дима, посмотри, пожалуйста, тикет по саппорту, ЭТО ОЧЕНЬ СРОЧНО!!!
Было время, когда ответы на такого рода сообщения занимали большую часть рабочего времени нашей дежурной смены от команды разработки. К счастью, постепенно ситуацию удалось исправить.
Подходами, за счет которых это получилось сделать, как раз и хочется поделиться в этой статье. Если у вас, как и у меня, от упоминания технической поддержки начинает дергаться глаз, а необходимость ей заниматься не вызывает ничего, кроме чувства вселенского уныния, добро пожаловать под кат. Серебряной пули не обещаю, но что-то полезное, может, и найдется.
Данная статья поможет молодым специалистам легко начать работу со сценариями использования.
Сценарии использования- это сценарий взаимодействия пользователя (или пользователей) с программным продуктом для достижения конкретной цели.
Цель: моделирование и проектирование взаимодействия пользователя с системой в рамках выполнения одного сценария. Пошаговое подробное взаимодействие пользователя с системой.
Документирование: таблица с описанием действий актора и реагирование системы на определенные шаги пользователя.
Один сценарий использования имеет несколько потоков: основной и альтернативные.
Выделение сценариев
Один сценарий использования должен описывать действия пользователя, которые приведут к одному большому действию- функционалу пользователя. Например, авторизоваться, добавить товар в корзину и тд.
Если мы имеем большой сценарий использования, необходимо выделить из него те части, которые мы можем вынести в отдельный самостоятельный сценарий, но в предусловии указать условия начала инициации данного сценария.
Каждый основной сценарий использования должен быть независимым от другого основного. Если есть определенные условия выполнения- указываем в “Предусловия”
Например, если нам необходимо описать авторизацию пользователя с вводом кода подтверждения, можно выделить отдельный сценарий “Ввод кода подтверждения”, чтобы не нагружать сценарий “Авторизация”. А уже в в сценарии “ввод кода подтверждения” подробно расписать условия ввода кода, повторной отправки, работу таймера повторной отправки, неверный код подтверждения, возможные ошибки.
Мы уже рассказывали на Хабре, чего в целом ждать от нашей новой конференции Flow. А теперь пришло время рассказать конкретнее: программа готова, поэтому делимся описаниями всех докладов.
Если захочется узнать больше подробностей (например, точное расписание) или приобрести билеты, всё это есть на сайте.
SCADA (Supervisory Control And Data Acquisition) – вариант человеко-машинного интерфейса (ЧМИ), если перевести почти дословно – диспетчеризация, управление и обработка данных.
История развития ЧМИ.
Обзор решений SCADA.
Варианты реализации функций модификации прикладной программы без отключения контроллера (сохранения состояния выходов) и останова технологического процесса (в большинстве вариантов это не on-line модификация, как это заявляет изготовитель ПЛК):
На написание этой статьи меня сподвигла одноименная статья на хабре: "Беги, муравей. Беги". В ней рассматривается решение задачи коммивояжёра в среде AnyLogic.
О самой задаче можно почитать здесь: Задача коммивояжёра.
Если кратко, то задача сводится к нахождению самого короткого пути обхода набора точек (городов) на карте. Решение методом перебора не является эффективным, поскольку количество вычислений огромно. Например, для 15 точек существует 43 миллиарда маршрутов, а для 18 точек (городов) уже 117 триллионов!!!
AnyLogic – среда, предназначенная для решения логистических задач с использованием моделей агентов. Мне показалось интересным, что несмотря на «заточенность» среды на агентное моделирование, при создании модели приходится писать достаточно много кода. Поэтому возникла идея: попробовать реализовать подобную модель, используя среду структурного моделирования, в виде графических функционально-блочных диаграмм. Я уже приводил примеры, как можно реализовать принципы объектно-ориентированного программирования (ООП) в графическом языке программирования. См. "Объектное ориентированное программирование в графических языках". Здесь же мы попробуем реализовать агентное моделирование средствами системной динамики.
Дальше будем много хардкороного программежа. Поэтому слабонервным, беременным, девушкам обоего пола, кормящим матерям лучше не читать, во избежание родимчика, свинки и чумки!
Программируемый Логический Контроллер (ПЛК) для технологических процессов – разнообразие форм и размеров.
Из прошлой статьи:
Принцип построения промышленной системы управления (автоматизации) для технологических процессов.
Само понятие «технологический процесс» очень емкое и широкое, технологические процессы есть в любом производстве, например: пищевом, деревообрабатывающем, металлургии, добывающей промышленности, газо и нефтехимическом, энергетическом, сборочном и т.д. К технологическим процессам относятся как основные процессы для данного производства, например выработка пара в котельной, так и вспомогательные технологические процессы, например системы вентиляции помещений, управление лифтом или мостовым краном. В зависимости от типа производства и технологического процесса к системам управления (автоматизации) предъявляются определенные требования по надежности, безопасности, отказоустойчивости, взрывозащите и т.д.
Типовая система автоматизации состоит из: измерительных приборов для контроля параметров технологического процесса (датчики, сигнализаторы, сенсоры и т.д.), промышленного контроллера, исполнительных устройств (клапаны, приводы, частотно-регулируемые преобразователи, пуско-регулирующая аппаратура) и человеко-машинного интерфейса. В системе автоматизации выделяют контуры регулирования (непрерывного управления) и контуры защиты. Контур – логически организованная последовательность элементов, выполняющая отдельную функцию автоматизации. Например, контур регулирования уровня в емкости будет включать уровнемер, ввод/вывод и ПИД-регулятор в контроллере, регулирующий клапан. Контуры могут быть локальными (независимыми) или связанными (многоконтурное регулирование).
Основные понятия РСУ (DSC), PLC (ПЛК), ESD (ПАЗ) и различие между ними.
Когда «молодой специалист» сталкивается с современной терминологией систем промышленной автоматизации, то такие термины как DCS, РСУ, PLC (ПЛК), ESD, SCADA, СБиПАЗ вызывают некоторое недоумение, так как объективно существует несоответствие между термином и оборудованием. А если послушать объяснение менеджеров-продавцов систем автоматизации или их компонентов, почитать форумы, путаницы становится еще больше.
На самом деле термины сложились на «заре автоматизации» и тогда они логично соответствовали текущей ситуации и оборудованию, с тех времен оборудование и принципы построения систем автоматизации значительно изменились, но терминология остается, как «исторически сложившаяся».
Звук – HiFi-сервис с большой командой инженеров. Мы используем передовые технологии и современный стек, и экспериментируем, чтобы решать сложные, нестандартные задачи. Одна из технологий – GraphQL.
Эта статья изначально создавалась как гайд по работе с GraphQL для инженеров Звука (системные аналитики, разработчики, QA). При этом статья может быть полезна всем, кто никогда не работал с GraphQL, но очень хочет понять, зачем он может быть нужен, и как поможет решить задачу вашего бизнеса.
Процесс закупок в средней и крупной компании — это взаимодействие десятка категорий специалистов и руководителей, обработка данных сотен и тысяч товарных позиций, многие гигабайты сопроводительных документов. Правильный подход к автоматизации этих процессов даст компании преимущество за счёт сокращения сроков снабжения и возможности быстрого манёвра в ответ на изменение внешней среды.
Операторы профильных электронных площадок помогают расширить круг потенциальных поставщиков и оперативно с ними взаимодействовать, однако об удобстве работы в таких ситуациях говорить, как правило, не приходится. Собрав и подготовив исходные данные для закупки, их нужно повторно ввести на площадке в требуемом там формате, после получения предложений данные оттуда вручную вставлять в принятые в компании печатные формы документов, а затем направлять их на согласование во внутренней системе электронного документооборота. Существенную часть времени закупщик занимается копированием и адаптацией форматов информации, а не своими непосредственными обязанностями.
Что касается алгоритма проведения закупочной процедуры, здесь закупщик тоже ограничен правилами и возможностями конкретной электронной площадки. Он вынужден совершать ненужные действия или же обходить ограничения, переходя на прямое взаимодействие с контрагентами по телефону или электронной почте. Когда закупка проходит в подобном ключе, разобраться в массиве накопившихся данных может быть непросто даже непосредственному исполнителю, не говоря уже о руководителе или аудиторе.
Привет, Хабр!
Qlik Sense – это BI-система, которая позволяет загружать данные из различных источников и создавать визуализации для проведения анализа. В публикации я рассмотрю Qlik Sense, как инструмент для создания пользовательского интерфейса.
Краткий разбор типичных ошибок и когнитивных искажений при написании технической документации для разработчиков. Обнаружение и hotfix этих дефектов призван сделать ваши тексты лучше, а процесс работы с ними — чуть более осознанным.
Ментальная карта или Mind Map представляет собой инструмент визуального мышления, используемый для сбора информации и идей.
Это диаграмма, которая вмещает в себя задачи, идеи, картинки, слова и другие элементы, связанные с центральной концепцией или предметом. Все составляющие располагаются вокруг центра с использованием нелинейного графического макета, который позволяет пользователю построить интуитивно понятную структуру. Карты отражают существующие мысли, но они также действуют как катализатор, который вытягивает новые идеи.
С Вами снова Владимир и меня все еще зовут девопс.
Сегодня делюсь свежеобретенным представлением о создании архитектуры нового проекта или реконфигурации нового.
Немного контекста: я живу в Санкт-Петербурге и работаю в большой компании с крайне бюрократической структурой управления, в которой девопс – это драйвер, лидер и на-все-руки-мастер.
Стресс-тестирование кредитного портфеля банка преследует цель сформировать ожидаемую оценку потерь в зависимости от прогнозных сценариев макроэкономических факторов. При этом базовой метрикой стресс-теста, как правило, выступает именно ожидаемые потери — математическое ожидание или, в случае с регрессией, условное по макрофакторам математическое ожидание потерь. Однако, если получается построить распределение таких потерь, то тогда стрессовые потери можно определять вероятностно, используя доверительные интервалы и метрики самого распределения.
“Чтобы что” - это что? Как научить аналитика-проектировщика, что является обоснованием функциональных требований, а что нет? Когда заказчик отвечает на вопрос “чтобы что”, как понять, является ли это ответом? Я не нашел книг, где это было бы описано понятно, сжато и лаконично. Чаще всего описаны абстрактные рассуждения, в применении которых на практике возникают проблемы. В статье на примерах разбирается как находить причину требований, какие они бывают, а что не является причиной вовсе.
Сегодня никого не удивишь тем, что бизнес-требования и приоритеты в развитии проектов постоянно меняются. Поэтому важно спроектировать такую архитектуру, которая будет гибкой, легко масштабируемой и поддерживаемой, а также иметь единую терминологию. Это позволит онбордить новых сотрудников на проекте быстро и эффективно.
Мы используем preact/compat — с его помощью получаем доступ к множеству библиотек экосистемы React, что делает разработку более гибкой, и при этом можем использовать Preact. Но эти же плюсы зачастую оборачиваются в обратную сторону: например, нет единой методологии по проектированию приложений, как, например, в Angular. Кроме того, многообразие библиотек усложняет погружение в проект, а свобода в реализации и проектировании может обернуться захламлением кодовой базы, что пугает разработчиков, особенно новичков.
Я встречал проекты, в которых раскиданы несколько одинаковых по функционалу компонентов. Например, пять вариаций одной кнопки, а чистые UI-компоненты находились рядом с компонентами, напрямую связанными с доменной областью приложения.
Для нашей команды эти проблемы также актуальны. Чтобы их решить раз и навсегда, мы обратились к активно развивающейся методологии Feature-Sliced Design (FSD). Ниже я познакомлю с ее главными принципами и с нашим опытом ее использования. Забыл представиться — я Женя, фронтенд-разработчик в команде Quick Experiments inDrive. Расскажу, как мы занимаемся разработкой внутренних стартапов на основе бизнес-гипотез с помощью FSD.
