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