Каталог Рефератов - Основные стадии создания автоматической системы управления

	Информационно-образоательный портал
	Рефераты, курсовые, дипломы, научные работы,



МЕНЮ\|

поиск

Основные стадии создания автоматической системы управления

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

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

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

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

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

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

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

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

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

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

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

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

Обучение персонала проводится по группам - управленческого персонала методам управления в условиях функционирования АСУ и персонала эксплуатации новых технических средств - их обслуживанию.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для более четкого проведения приемо-сдаточных испытаний регламентирован ряд положений.

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

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

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

Страницы: 1, 2

© 2003-2013
Рефераты бесплатно, курсовые, рефераты биология, большая бибилиотека рефератов, дипломы, научные работы, рефераты право, рефераты, рефераты скачать, рефераты литература, курсовые работы, реферат, доклады, рефераты медицина, рефераты на тему, сочинения, реферат бесплатно, рефераты авиация, рефераты психология, рефераты математика, рефераты кулинария, рефераты логистика, рефераты анатомия, рефераты маркетинг, рефераты релиния, рефераты социология, рефераты менеджемент.