Проектирование автоматизированных систем на микроуровне

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

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

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

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

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

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

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

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

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

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

 Скачать реферат