После уточнения перечня и содержательной постановки задач по каждой функции переходят к формальным постановкам отдельных задач. Суть ее – в формальной записи целевой функции и ограничений для оптимизационных задач или в записи формул и уравнений для задач прямого счета, или в любом ином виде формальной записи содержания задачи.
Формальная постановка задачи сопровождается изложением ее организационно-экономической сущности (описанием задачи на содержательном уровне), с указанием круга объектов, для которых она предназначена; обоснованием необходимости ее решения; описанием исходных данных и получаемых результатов. Определяются связи данной задачи с другими; требования к решению задачи: периодичность решения, предельные сроки получения результатов, необходимая точность расчета и другие специфические условия.
Для каждой задачи должен быть определен метод решения, позволяющий получить требуемые результаты наиболее эффективным путем с наименьшими затратами ресурсов ЭВМ, простотой ввода данных, если это требуется делать вручную, наглядностью получаемых результатов, удобством их использования. Далее необходимо составить алгоритм расчета в виде схемы с пояснениями: порядок и последовательность ввода исходной информации, ее источник (массив данных или ввод с пульта); порядок расчетов, выдача данных на дисплей или печать, или запись на машинный носитель. Следует предусмотреть методы контроля достоверности входной и выходной информации, а при необходимости – меры защиты от несанкционированного доступа.
Для проверки задачи, охватывающей ее постановку, алгоритмизацию, программирование и проведение расчетов на ЭВМ, подготавливается контрольный пример. Он включает исходные данные, которые могут быть как реальными, так и специально подобранными. Объем их может быть меньшим или равным тем объемам, которые реально ожидаются в системе. Подбор исходных данных не является отладочным тестом для программ, он предназначен для проверки правильности решения данной задачи, с точки зрения пользователя, т.е. реализации некоторой функции управления. Поэтому должен быть предусмотрен метод проверки правильности получаемых результатов. Результаты постановки задач целесообразно представить в виде системных спецификаций.
Основной характеристикой системы управления является ее назначение по классу управляемых объектов. Вместе с тем существует ряд параметров, характеризующих свойства системы в целом. К ним относятся: время реакции на входной сигнал, пропускная способность, коэффициент готовности, локализованность, количество пользователей и их удаленность, средства доступа и общения с пользователями и др. Все эти параметры определяются или задаются при проектировании системы на макроуровне.
Время реакции определяется от момента поступления входного сигнала до появления соответствующего выходного результата. Эта характеристика особенно важна для систем, работающих в реальном масштабе времени. Следует оговориться, что фактически все без исключения системы управления работают в реальном масштабе времени: управляющие воздействия выдаются с таким расчетом, чтобы они могли быть своевременно реализованы. Это относится ко всем системам управления, включая системы перспективного планирования: ясно, что план должен быть сформирован и выдан до начала планируемого периода, а не позже. Однако время выдачи плана не очень критично, минуты, часы и даже дни ничего не решают. Поэтому принято считать, что режимом реального времени является такой, когда для обеспечения необходимой с точки зрения технологического процесса скорости реакции системы управления требуется принимать специальные меры, а задержка выдачи результатов приводит к снижению скорости и сбоям управляемого процесса.
Требования к скорости реализации могут быть различными для единичного входного сигнала и поступающей одновременно пачке сигналов. В большинстве случаев должны быть предусмотрены два режима – ускоренный для обработки единичных сигналов и обычный для пачки. Кроме того, возможны случаи, когда сигналы поступают по одному в случайные моменты времени, но имеют различный приоритет в отношении скорости обработки. Наличие таких или подобных им режимов должно быть выявлено на предпроектной стадии и учтено при проектировании.
Пропускная способность определяется по количеству сигналов, которые могут быть обработаны в единицу времени. При случайном характере поступления сигналов пропускная способность определяет наличие и длину очередей. В системах массового обслуживания, когда число пользователей велико, а время ожидания ими обслуживания критично (при длительном ожидании пользователи зачастую покидают систему необслуженными), систему рассчитывают на максимальную, пиковую нагрузку. Такие пики кратковременны, поэтому в остальное время система недогружена. В подобных случаях рассматривают возможность загрузки системы задачами, не требующими быстрой реакции, допускающими задержку получения результатов. Такие задачи часто называют фоновыми, они как бы образуют фон, на котором происходит решение задач, требующих быстрого решения, с переменной интенсивностью. Если сигналы поступают в систему с переменной интенсивностью, но не требуют немедленной реакции, следует рассмотреть возможность их накопления в некоторой промежуточной емкости – буфере, где они хранятся в ожидании обслуживания.
Коэффициент готовности системы определяется как вероятность того, что она окажется работоспособной в произвольно выбранный момент времени в установившемся (стационарном) режиме эксплуатации. Иными словами, это доля или процент времени, в течение которого система фактически работоспособна в стационарном режиме, относительно общего времени, когда она должна быть работоспособна. Подавляющее большинство нарушений работоспособности в АСУ связано со сбоями или выходом из строя различных элементов технических средств; в меньшей степени, но заметно, сказываются недостатки в программном обеспечении.
Время восстановления обусловливает максимальную и среднюю продолжительность нерабочего состояния системы и распределение перерывов в работе по времени. Пользователю не безразлично, происходит ли в системе один перерыв в сутки продолжительностью 30 мин или один перерыв на 2 мин каждый час, хотя общее время неработоспособности в обоих случаях одинаково.
Каким бы высоким ни был коэффициент готовности, разработчик должен решить ряд вопросов, связанных с возможными перерывами работы, и в первую очередь определить, что должно происходить в это время в системе. Помимо обычных мер по вводу в действие резерва, если он экономически оправдан, следует так разрабатывать систему, чтобы обеспечить возможность автономной работы в течение некоторого времени всех элементов системы, кроме, естественно, вышедших из строя.
Восстановление нормального режима не должно требовать от пользователя каких-либо специальных мер и операций, он должен просто продолжать прерванную работу. Это означает, что разработчик должен предусмотреть возможность автоматического запоминания состояния системы в момент, непосредственно предшествующий аварийной ситуации, и полного восстановления этого состояния после ее ликвидации. Все операции, выполненные в автономном режиме, должны быть впоследствии обработаны так, как если бы они выполнялись в нормальном режиме. Если провести полное восстановление системы в автоматическом режиме по каким-либо причинам невозможно, система должна подсказывать пользователю, какие операции ему необходимо дополнительно выполнить и с какого места начать повторение операций прерванной задачи. В любом случае недопустима потеря какой-то части введенной в систему информации.
Как указывалось выше, система должна быть ориентирована на удовлетворение интересов пользователя. Недопустимо вводить какую-либо регламентацию поведения пользователя исходя из интересов или удобства разработчиков. Упрощая себе процесс разработки за счет предъявления излишних требований к пользователям, разработчики рискуют создать нежизнеспособную систему, к которой пользователи просто не будут обращаться. Сказанное в полной мере относится к нарушениям нормальной работы системы. Если они серьезно влияют на ритм работы пользователя, требуют от него существенной дополнительной работы, то есть большая вероятность отказа от такой системы.
Значительную трудность для разработчика представляет анализ возможных конфликтных ситуаций. Многие разработчики избегают эти трудности самым простым способом – игнорируя их. Предписания и инструкции, регламентирующие нормальный режим работы, не гарантируют отсутствия конфликтов между пользователями и системой. Такие конфликты возникают при случайных или преднамеренных действиях пользователя, нарушающих установленные правила. Так, например, может быть утерян выданный ЭВМ документ, не введены в систему вовсе или введены в искаженном виде некоторые исходные данные для расчетов, не использованы в процессе управления полученные на ЭВМ результаты и т.п. Выявленные возможные конфликтные ситуации служат основой для принятия разработчиком решения - как должна функционировать система в этих условиях. Лучше всего, если система немедленно реагирует на эти ситуации, вводя необходимые дополнительные операции, предотвращающие нежелательные последствия. Более простым способом является фиксация в памяти системы происшедших нарушений с последующей выдачей их для анализа и принятия мер, направленных на исключение подобных нарушений в дальнейшей работе.
Основным источником экономического эффекта от создания АСУ является улучшение экономических показателей управляемой системы – предприятия или организации, достигаемое за счет повышения качества управления.