Способы описания системы управления

Как создать шаблон описания системы и начать его использовать

Когда в IT-компании работают 6 человек, которые пилят одну систему и обсуждают её в кулуарах, описание системы и документация кажутся ненужными. Но когда систем уже более 100, без описания не обойтись. Ведь непродуманное изменение UI может остановить создание заказов. Мы создали единый шаблон описания системы, чтобы документация стала максимально полезной.

Меня зовут Александра Камзеева, я работаю системным аналитиком уже 9 лет, из них 3.5 года в Lamoda. Я много читаю, анализирую текущую документацию и создаю новую. В работе я всегда структурирую информацию и делаю её максимально удобной.

Плюсы хорошего описания системы таковы:

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

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

Что такое шаблон и зачем он нужен

Для начала я опишу свое понимание шаблона. Давайте представим, что мне надо найти маленькую машинку в неприбранной комнате. Не факт, что я справлюсь. Зато могу случайно наступить на детальку Лего.

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

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

В каких условиях мы работаем с документацией

В Lamoda есть более 100 систем, которые автоматизируют доставку заказов, контакт-центр, склад, фотостудию, другие операционные и бизнес-процессы. Разработкой и поддержкой занимаются больше 300 инженеров. Любому из них может понадобиться описание любой из этих 100 систем.

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

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

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

Просто добавь две кнопки

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

У нас был проект Self Order Management (SOM). Мы решили добавить в личный кабинет клиента две кнопки: «Перенос даты доставки» и «Отмена заказа». До этого клиент мог отменить или перенести заказ только звонком в контакт-центр. Понятно, что у некоторых покупателей не было времени или желания общаться с оператором. В итоге торговый представитель мог привезти ненужный заказ или не застать клиента дома. В таких случаях Lamoda несет издержки. Проект был нужный и важный.

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

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

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

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

Проблема чистого листа

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

Как мы создавали шаблон и что получилось

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

Сначала мы определили признаки хорошего шаблона:

1. Хороший шаблон помогает найти нужную информацию быстрее и легче за счет структуры описания системы.
2. Информация в системе не дублируется. Конечно, это достигается не только документом, но и культурой ведения документации. В шаблоне можно заложить атомарность разделов, чтобы ссылаться на них. Это не даст лишний повод для дублирования информации.
3. Хороший шаблон применим к большинству систем. Да, он скорее всего будет избыточен для отдельной системы, но так он может покрыть если не все кейсы, то большинство.
4. Он помогает сохранить всё нужное и напоминает о важном.

Далее проанализировали текущее описание разных систем и выявили часто встречающиеся разделы:

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

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

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

Проверяем качество шаблона

Полученный документ мы проверили на наше определение хорошего шаблона в Lamoda:

1. Он помогает найти нужную информацию быстрее и легче. У нас получилась удобная структура: я двигаюсь по дереву и понимаю, что и где находится. Если нужна информация о процессах системы (например, отмена заказа), значит, иду в “Описание основных процессов”.
2. Информация о системе не дублируется благодаря атомарности разделов. Например, можно описать печатные формы в одном разделе, а затем ссылаться на него из раздела “Описание основных процессов”, чтобы информация не повторялась.
3. Хороший шаблон применим к большинству систем. Наш шаблон учитывает разделы для всех систем Lamoda, поэтому структура описания адаптирована под каждую систему. Например, система процессинга заказов не использует описание пользовательских интерфейсов или ссылки на исследования АВ-тестирования. А для сайта — это два ключевых раздела.
4. Хороший шаблон помогает ничего не забыть. Об этом я расскажу подробнее в следующий главе.

Самые полезные разделы шаблона

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

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

Чек-листы – раздел, который напоминает о самом важном в регулярном процессе. Например, у нас есть “Чек-лист подключения нового метода оплаты” в описании системы управления методами оплаты. Там прописано, что мы должны согласовывать добавление или изменение метода оплаты с бухгалтерией, с контакт-центром, с доставкой и с другими бизнес-подразделениями.

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

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

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

Как я начала использовать шаблон в своей системе

1. Прежде всего, я создала нужные разделы шаблона без наполнения. Это было легко и заняло не более 30 минут.
2. Дальше было самое сложное: мы поставили регулярные встречи с техлидом, на которых мы начали разбор документации нашей системы. На первой встрече мы распределили текущие страницы по трем кучкам.

В первую кучку мы отправили всё неактуальное и ненужное. Эти страницы мы удаляли или отправляли в архив.

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

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

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

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

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

Как мы распространяли шаблон

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

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

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

Обратная связь о шаблоне

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

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

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

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

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

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

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

Советы себе и желающим повторить наш путь

Источник

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

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

Лекции по курсу «Управление Техническими Системами», читает Козлов Олег Степанович на кафедре «Ядерные реакторы и энергетические установки», факультета «Энергомашиностроения» МГТУ им. Н.Э. Баумана. За что ему огромная благодарность.

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

1. Основные понятия теории управления техническими системами

1.1. Цели, принципы управления, виды систем управления, основные определения, примеры

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

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

Определение: Управление – это такая организация того или иного технологического процесса, которая обеспечивает достижение поставленной цели.

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

Любой процесс управления (автоматического) состоит из следующих основных этапов (элементов):

• получение информации о задаче управления;
• получение информации о результате управления;
• анализ получаемой информации;
• выполнение решения (воздействие на объект управления).

Для реализации Процесса Управления система управления (СУ) должна иметь:

• источники информации о задаче управления;
• источники информации о результатах управления (различные датчики, измерительные устройства, детекторы и т.д.);
• устройства для анализа получаемой информации и выработки решения;
• исполнительные устройства, воздействующие на Объект Управления, содержащие: регулятор, двигатели, усилительно-преобразующие устройства и т.д.

Определение: Если система управления (СУ) содержит все перечисленные выше части, то она является замкнутой.

Определение: Управление техническим объектом с использованием информации о результатах управления называется принципом обратной связи.

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

Рис. 1.1.1 — Структура системы управления (СУ)

Если система управления (СУ) имеет структурную схему, вид которой соответствует рис. 1.1.1, и функционирует (работает) без участия человека (оператора), то она называется системой автоматического управления (САУ).

Если СУ функционирует с участием человека (оператора), то она называется автоматизированной СУ.

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

К системам, работающим по разомкнутому циклу, относятся промышленные автоматы (конвейерные линии, роторные линии и т.д.), станки с числовым программным управлением (ЧПУ): см. пример на рис. 1.1.2.

Задающее устройство может быть, например, и “копиром”.

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

Автоматические системы управления подразделяются на 3 типа:

• системы автоматического управления (САУ);
• системы автоматического регулирования (САР);
• следящие системы (СС).

САР и СС являются подмножествами САУ ==> .

Определение: Автоматическая система управления, обеспечивающая постоянство какой-либо физической величины (группы величин) в объекте управления называется системой автоматического регулирования (САР).

Системы автоматического регулирования (САР) — наиболее распространенный тип систем автоматического управления.

Первый в мире автоматический регулятор (18-е столетие) – регулятор Уатта. Данная схема (см. рис. 1.1.3) реализована Уаттом в Англии для поддержания постоянной скорости вращения колеса паровой машины и, соответственно, для поддержания постоянства скорости вращения (движения) шкива (ремня) трансмиссии.

В данной схеме чувствительными элементами (измерительными датчиками) являются “грузы” (сферы). «Грузы» (сферы) также “заставляют” перемещаться коромысло и затем задвижку. Поэтому данную систему можно отнести к системе прямого регулирования, а регулятор — к регулятору прямого действия, так как он одновременно выполняет функции и “измерителя” и “регулятора”.

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

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

Примером САУ (системы автоматического управления), в полном смысле этого определения, может служить система управления, обеспечивающая вывод ракеты на орбиту, где управляемой величиной может быть, например, угол между осью ракеты и нормалью к Земле ==> см. рис. 1.1.4.а и рис. 1.1.4.б

1.2. Структура систем управления: простые и многомерные системы

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

В теории Управления Техническими Системам используют 2 основных способа представления звеньев систем управления:

— в переменных “вход-выход”;

— в переменных состояния (более подробно см. разделы 6…7).

Представление в переменных “вход-выход” обычно используется для описания относительно простых систем, имеющих один “вход” (одно управляющее воздействие) и один “выход” (одна регулируемая величина, см. рисунок 1.2.1).

Обычно такое описание используется для технически несложных САУ (систем автоматического управления).

В последнее время широкое распространение имеет представление в переменных состояния, особенно для технически сложных систем, в том числе и для многомерных САУ. На рис. 1.2.2 приведено схематичное представление многомерной системы автоматического управления, где u₁(t)…u_m(t) — управляющие воздействия (вектор управления), y₁(t)…y_p(t) — регулируемые параметры САУ (вектор выхода).

Рассмотрим более детально структуру САУ, представленную в переменных “вход-выход” и имеющую один вход (входное или задающее, или управляющее воздействие) и один выход (выходное воздействие или управляемая (или регулируемая) переменная).

Предположим, что структурная схема такой САУ состоит из некоторого числа элементов (звеньев). Группируя звенья по функциональному принципу (что звенья делают), структурную схему САУ можно привести к следующему типовому виду:

Рис. 1.2.3 — Структурная схема системы автоматического управления

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

Задача системы управления состоит в том (если она устойчива), чтобы “работать” на уничтожение рассогласования (ошибки) ε(t), т.е. ==> ε(t) → 0.

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

Для обозначения управляющего (задающего воздействие) будем использовать либо x(t), либо u(t).

1.3. Основные законы управления

Если вернуться к последнему рисунку (структурная схема САУ на рис. 1.2.3), то необходимо “расшифровать” роль, которую играет усилительно-преобразующее устройство (какие функции оно выполняет).

Если усилительно-преобразующее устройство (УПУ) выполняет только усиление (или ослабление) сигнала рассогласования ε(t), а именно: , где – коэффициент пропорциональности (в частном случае = Const), то такой режим управления замкнутой САУ называется режимом пропорционального управления (П-управление).

Если УПУ выполняет формирование выходного сигнала ε1(t), пропорционального ошибке ε(t) и интегралу от ε(t), т.е. , то такой режим управления называется пропорционально-интегрирующим (ПИ-управление). ==> , где b – коэффициент пропорциональности (в частном случае b = Const).

Обычно ПИ-управление используется для повышения точности управления (регулирования).

Если УПУ формирует выходной сигнал ε₁(t), пропорциональный ошибке ε(t) и ее производной, то такой режим называется пропорционально-дифференцирующим (ПД-управление): ==>

Обычно использование ПД-управления повышает быстродействие САУ

Если УПУ формирует выходной сигнал ε₁(t), пропорциональный ошибке ε(t), ее производной, и интегралу от ошибки ==> , то такой режим называетсято такой режим управления называется пропорционально-интегрально-дифференцирующим режимом управления (ПИД-управление).

ПИД-управление позволяет зачастую обеспечить “хорошую” точность управления при “хорошем” быстродействии

1.4. Классификация систем автоматического управления

1.4.1. Классификация по виду математического описания

По виду математического описания (уравнений динамики и статики) системы автоматического управления (САУ) подразделяются на линейные и нелинейные системы (САУ или САР).

Каждый “подкласс” (линейных и нелинейных) подразделяется на еще ряд “подклассов”. Например, линейные САУ (САР) имеют различия по виду математического описания.
Поскольку в этом семестре будут рассматриваться динамические свойства только линейных систем автоматического управления (регулирования), то ниже приведем классификацию по виду математического описания для линейных САУ (САР):

1) Линейные системы автоматического управления, описываемые в переменных «вход-выход» обыкновенными дифференциальными уравнениями (ОДУ) с постоянными коэффициентами:

где x(t) – входное воздействие; y(t) – выходное воздействие (регулируемая величина).

Если использовать операторную («компактную») форму записи линейного ОДУ, то уравнение (1.4.1) можно представить в следующем виде:

где, p = d/dt — оператор дифференцирования; L(p), N(p) — соответствующие линейные дифференциальные операторы, которые равны:

2) Линейные системы автоматического управления, описываемые линейными обыкновенными дифференциальными уравнениями (ОДУ) с переменными (во времени) коэффициентами:

В общем случае такие системы можно отнести и к классу нелинейных САУ (САР).

3) Линейные системы автоматического управления, описываемые линейными разностными уравнениями:

где f(…) – линейная функция аргументов; k = 1, 2, 3… — целые числа; Δt – интервал квантования (интервал дискретизации).

Уравнение (1.4.4) можно представить в «компактной» форме записи:

Обычно такое описание линейных САУ (САР) используется в цифровых системах управления (с использованием ЭВМ).

4) Линейные системы автоматического управления с запаздыванием:

где L(p), N(p) — линейные дифференциальные операторы; τ — время запаздывания или постоянная запаздывания.

Если операторы L(p) и N(p) вырождаются (L(p) = 1; N(p) = 1), то уравнение (1.4.6) соответствует математическому описанию динамики звена идеального запаздывания:

а графическая иллюстрация его свойств привдена на рис. 1.4.1

5) Линейные системы автоматического управления, описываемые линейными дифференциальными уравнения в частных производных. Нередко такие САУ называют распределенными системами управления. ==> «Абстрактный» пример такого описания:

Система уравнений (1.4.7) описывает динамику линейно распределенной САУ, т.е. регулируемая величина зависит не только от времени, но и от одной пространственной координаты.
Если система управления представляет собой «пространственный» объект, то ==>

где зависит от времени и пространственных координат, определяемых радиусом-вектором

6) САУ, описываемые системами ОДУ, или системами разностных уравнений, или системами уравнений в частных производных ==> и так далее…

Аналогичную классификацию можно предложить и для нелинейных САУ (САР)…

Для линейных систем выполеняются следующие требования:

• линейность статической характеристики САУ;
• линейность уравнения динамики, т.е. переменные в уравнение динамики входят только в линейной комбинации.

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

Для систем, описываемых линейными обыкновенными дифференциальными уравнениями с постоянными коэффициентами статическая характеристика получается из уравнения динамики (1.4.1) приравниванием нулю всех нестационарных членов ==>

На рис.1.4.2 представлены примеры линейной и нелинейных статических характеристик систем автоматического управления (регулирования).

Нелинейность членов, содержащих производные по времени в уравнениях динамики, может возникнуть при использовании нелинейных математических операций (*, /, , , sin, ln и т.д.). Например, рассматривая уравнение динамики некоторой «абстрактной» САУ

отметим, что в этом уравнении при линейной статической характеристики второе и третье слагаемые (динамические члены) в левой части уравнения — нелинейные, поэтому САУ, описываемая подобным уравнением, является нелинейной в динамическом плане.

1.4.2. Классификация по характеру передаваемых сигналов

По характеру передаваемых сигналов системы автоматического управления (или регулирования) подразделяются:

• непрерывные системы (системы непрерывного действия);
• релейные системы (системы релейного действия);
• системы дискретного действия (импульсные и цифровые).

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

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

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

Звено, преобразующее непрерывный сигнал в дискретный сигнал, называется импульсным. Подобный вид передаваемых сигналов имеет место в САУ с ЭВМ или контроллером.

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

• амплитудно-импульсная модуляция (АИМ);
• широтно-импульсная модуляция (ШИМ).

На рис. 1.4.5 представлена графическая иллюстрация алгоритма амплитудно-импульсной модуляции (АИМ). В верхней части рис. представлена временная зависимость x(t) — сигнала на входе в импульсное звено. Выходной сигнал импульсного блока (звена) y(t) – последовательность прямоугольных импульсов, появляющихся с постоянным периодом квантования Δt (см. нижнюю часть рис.). Длительность импульсов – одинакова и равна Δ. Амплитуда импульса на выходе блока пропорциональна соответствующей величине непрерывного сигнала x(t) на входе данного блока.

Данный метод импульсной модуляции был весьма распространен в электронно-измерительной аппаратуре систем управления и защиты (СУЗ) ядерных энергетических установок (ЯЭУ) в 70-х…80-х годах прошлого столетия.

На рис. 1.4.6 представлена графическая иллюстрация алгоритма широтно-импульсной модуляции (ШИМ). В верхней части рис. 1.14 представлена временная зависимость x(t) – сигнала на входе в импульсное звено. Выходной сигнал импульсного блока (звена) y(t) – последовательность прямоугольных импульсов, появляющихся с постоянным периодом квантования Δt (см. нижнюю часть рис. 1.14). Амплитуда всех импульсов – одинакова. Длительность импульса Δt на выходе блока пропорциональна соответствующей величине непрерывного сигнала x(t) на входе импульсного блока.

Данный метод импульсной модуляции в настоящее время является наиболее распространенным в электронно-измерительной аппаратуре систем управления и защиты (СУЗ) ядерных энергетических установок (ЯЭУ) и САУ других технических систем.

Завершая данный подраздел, необходимо заметить, что если характерные постоянные времени в других звеньях САУ (САР) существенно больше Δt (на порядки), то импульсная система может считаться непрерывной системой автоматического управления (при использовании как АИМ, так и ШИМ).

1.4.3. Классификация по характеру управления

По характеру процессов управления системы автоматического управления подразделяются на следующие типы:

• детерминированные САУ, в которых входному сигналу однозначно может быть поставлен в соответствие выходной сигнал (и наоборот);
• стохастические САУ (статистические, вероятностные), в которых на данный входной сигнал САУ “отвечает” случайным (стохастическим) выходным сигналом.

Выходной стохастический сигнал характеризуется:

• законом распределения;
• математическим ожиданием (средним значением);
• дисперсией (среднеквадратичным отклонением).

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

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

1) Обыкновенные (несамонастраивающиеся) СУ без адаптации; эти системы относятся к разряду простых, не изменяющих свою структуру в процессе управления. Они наиболее разработаны и широко применяются. Обыкновенные СУ подразделяются на три подкласса: разомкнутые, замкнутые и комбинированные системы управления.

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

Другой пример классификации: по иерархическому признаку (одноуровневые, двухуровневые, многоуровневые).

Источник

Рис. 1.1.4 (а)