Студопедия  
Главная страница | Контакты | Случайная страница

АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатика
ИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханика
ОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторика
СоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансы
ХимияЧерчениеЭкологияЭкономикаЭлектроника

Классификация АСУ

Читайте также:
  1. I. Понятие МПЗ, классификация и оценка материалов.
  2. II Классификация.
  3. II. Классификация инвестиций
  4. II. Классификация Леонгарда
  5. II. Методы и источники изучения истории; понятие и классификация исторического источника.
  6. II. Объекты и субъекты криминалистической идентификации. Идентификационные признаки и их классификация.
  7. III. Классификация проблем абонентов ТД.
  8. V. Классификация ЭВМ по назначению
  9. Аварии на химически опасных объектах (ХОО) с выбросом аворийно химически опасных веществ (АХОВ), классификация, фазы развития.
  10. Активы, обязательства. Классификация имущества организации по составу и размещению, характеристика внеоборотных и оборотных активов.

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

По уровню управления:

 общегосударственная автоматизированная система(ОГАС) - автоматизированная система сбора и обработки информации для учета, планирования и управления народным хозяйством на базе государственной сети вычислительных центров (ГСВТ) и единой автоматизированной системы связи страны;

 отраслевая автоматизированная система управления (ОАСУ) - АСУ министерства или ведомства, предназначенная для управления подведомственными организациями как автономно, так и в составе ОГАС;

 территориальная АСУ - система, предназначенная для управления административно-территориальным районом (республики, края, области, района, города), как автономно, так и в составе ОАСУ и (или) ОГАС;

 АСУ производственным объединением (фирмой) - предназначена для управления производственным объединением (фирмой) как автономно, так и в составе ОАСУ и (или) ОГАС. АСУ предприятием (АСУП) - предназначена для управления предприятием как автономно, так и в составе АСУ, производственным объединением и(или) АСУ фирмой.

Если рассматривать предприятие как систему верхнего уровня, то следующими уровнями по нисходящей линии будут уровни:

 завод;

 цех;

 производственный участок;

 производственное оборудование.

По характеру объекта управления АСУ делят на:

 АСУ предприятия (АСУП);

 АСУ технологическими процессами производства (АСУТПП);

 АСУ территориальными организациями;

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

 АСОД (автоматизированная система обработки информации);

 АСНТИ – управление научно-техническими исследованиями.

АСУП (АС управления предприятием) применяется на уровне от предприятия до цеха, АСУТП (АС управления технологическими процессами) – на уровне от цеха и ниже.

Автоматизированная система организационного управления (АСОУ) предназначена для управления коллективами людей в экономических и социальных системах.

Различают АСУП для предприятий с производством непрерывного типа; дискретного (мелкосерийное и единичное производство) и непрерывно-дискретного (поточно-массовое и крупносерийное производство).

Функции АСУП:

 календарное планирование производства, потребностей в мощностях и материалах;

 оперативное управление производством;

 сетевое планирование проектов;

 управление проектированием изделий;

 учет и нормирование трудозатрат;

 учет основных фондов;

 управление финансами;

 управление запасами (складским хозяйством);

 управление снабжением – статистика закупок, контракты на закупку;

 маркетинг (статистика и анализ реализации, контракты на реализацию, прогноз, реклама).

Процедуры, выполняющие эти функции – бизнес-функции.

Маршруты, состоящие из бизнес-функций- бизнес- процессы.

 

14.4 Взаимодействие компонент распределённой системы

Ключевым сервисом промежуточной среды для создания распределенных систем является обеспечение обмена данными между компонентами распределенной системы. В настоящий момент существуют две концепции взаимодействия программных компонент: обмен сообщениями между компонентами и вызов процедур или методов объекта удаленной компоненты по аналогии с локальным вызовом процедуры. Поскольку в настоящее время любое взаимодействие между удаленными компонентами в конечном итоге основано на сокетах TCP/IP, первичным с точки зрения промежуточной среды является низкоуровневый обмен сообщениями на основе сетевых сокетов, сервис которых никак не определяет формат передаваемого сообщения. На базе протоколов TCP или HTTP затем могут быть построены прикладные протоколы обмена сообщений более высокого уровня абстракции для реализации более сложного обмена сообщениями или удаленного вызова процедур.Удаленный вызов является моделью, происходящей от языков программирования высокого уровня, а не от реализации интерфейса транспортного уровня сетевых протоколов. Поэтому протоколы удаленного вызова должны обязательно базироваться на какой либо системе передачи сообщений, включая как непосредственное использование сокетов TCP/IP, так и основанные на нем другие промежуточные среды для обмена сообщениями. Реализация высокоуровневых служб обмена сообщениями, в свою очередь, может использовать удаленный вызов процедур, основанный на более низкоуровневой передаче сообщений, использующей, например, непосредственно сетевые сокеты. Таким образом, одна промежуточная среда может использовать для своего функционирования сервисы другой промежуточной среды, аналогично тому, как один протокол транспортного или сетевого уровня может работать поверх другого протокола при туннелировании протоколов.
Обмен сообщениями:Существует два метода передачи сообщений от одной удаленной системы к другой – непосредственный обмен сообщениями и использование очередей сообщений. В первом случае передача происходит напрямую, и она возможна только в том случае, если принимающая сторона готова принять сообщение в этот же момент времени. Во втором случае используется посредник – менеджер очередей сообщений. Компонента посылает сообщение в одну из очередей менеджера, после чего она может продолжить свою работу. В дальнейшем получающая сторона извлечет сообщение из очереди менеджера и приступит к его обработке.
Простейшей реализацией непосредственного обмена сообщениями является использование транспортного уровня сети через интерфейс сокетов, минуя какое-либо промежуточное программное обеспечение. Однако такой способ взаимодействия обычно не применяется в системах автоматизации предприятия, поскольку в этом случае реализация всех функций промежуточной среды ложится на разработчиков приложения. При таком подходе сложно получить расширяемую и надежную распределенную систему, поэтому для разработки прикладных распределенных систем обычно используются системы очередей сообщений.
Существует несколько разработок в области промежуточного программного обеспечения, реализующие высокоуровневые сервисы для обмена сообщениями между программными компонентами. К ним относятся, в частности, MicrosoftMessageQueuing, IBM MQSeries и SunJavaSystemMessageQueue. Такие системы дают возможность приложениям использовать следующие базовые примитивы по использованию очередей:
• добавить сообщение в очередь;
• взять первое сообщение из очереди, процесс блокируется до появления в очереди хотя бы одного сообщения;
• проверить очередь на наличие сообщений;
• установить обработчик, вызываемый при появлении сообщений в очереди.
Менеджер очереди сообщений в таких системах может находиться на компьютере, отличном от компьютеров с участвующими в обмене компонентами. В этом случае сообщение первоначально помещается в исходящую очередь на компьютере с посылающей сообщения компонентой, а затем пересылается менеджеру требуемой. Для создания крупных систем обмена сообщениями может использоваться маршрутизация сообщений, при которой сообщения не передаются напрямую менеджеру, поддерживающему очередь, а проходят через ряд промежуточных менеджеров очередей сообщений (рис. 2.1).

Использование очередей сообщений ориентировано на асинхронный обмен данными. Основные достоинства таких систем:
• время функционирования сервера может быть не связано со временем работы клиентов;
• независимость промежуточной среды от средства разработки компонент и используемого языка программирования;
• считывать и обрабатывать заявки из очереди могут несколько независимых компонент, что дает возможность достаточно просто создавать устойчивые и масштабируемые системы.
Недостатки систем очередей сообщений являются продолжением их достоинств:
• необходимость явного использования очередей распределенным приложением;
• сложность реализации синхронного обмена;
• определенные накладные расходы на использование менеджеров очередей;
• сложность получения ответа: передача ответа может потребовать отдельной очереди на каждый компонент, посылающий заявки.
Дальний вызов процедур:Идея удаленного вызова процедур (remoteprocedurecall, RPC) появилась в середине 80-х годов и заключалась в том, что при помощи промежуточного программного обеспечения функцию на удаленном компьютере можно вызывать так же, как и функцию на локальном компьютере. Чтобы удаленный вызов происходил прозрачно с точки зрения вызывающего приложения, промежуточная среда должна предоставить процедуру-заглушку (stub), которая будет вызываться клиентским приложением. После вызова процедуры-заглушки промежуточная среда преобразует переданные ей аргументы в вид, пригодный для передачи по транспортному протоколу, и передает их на удаленный компьютер с вызываемой функцией. На удаленном компьютере параметры извлекаются промежуточной средой из сообщения транспортного уровня и передаются вызываемой функции (рис. 2.2). Аналогичным образом на клиентскую машину передается результат выполнения вызванной функции.

 

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

 




Дата добавления: 2014-12-20; просмотров: 26 | Поможем написать вашу работу | Нарушение авторских прав




lektsii.net - Лекции.Нет - 2014-2024 год. (0.007 сек.) Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав