101933 (Проектирование автоматизированных систем на микроуровне), страница 2

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

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

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

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

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

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

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

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

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

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

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

3. Общие характеристики системы

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

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

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

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

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

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

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

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

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

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

4. Технико-экономическая эффективность системы

Основным источником экономического эффекта от создания АСУ является улучшение экономических показателей управляемой системы – предприятия или организации, достигаемое за счет повышения качества управления.

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

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

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