а. Техническое обеспечение систем управления с УВМ

Техническое обеспечение систем управления с УВМ

6.1. ГИБКО ПРОГРАММИРУЕМЫЕ КОНТРОЛЛЕРЫ ИЛИ СИСТЕМЫ НА БАЗЕ ПЕРСОНАЛЬНОГО КОМПЬЮТЕРА

 

Область упрaвления и регулирования перестала быть зоной безраздельного господства гибко программируемых контроллеров особенно там, где решение задач промышленной автоматизации должно сочетаться с созданием систем обработки информации и визуализации, системы на базе ПК находят все большее применение. Спрос на системы управления, ' базирующиеся на ПК (PC-based Control), постоянно растет В рамках своей программы создания интегрированных средств промышленной автоматизации всемирно известный электротехнический концерн Siemens предлагает адекватное, базирующееся на ПК, решение -SIMATIC    WinAC    (Windows Automation Center).

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

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

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

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

Рекомендуемые материалы

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

6.1.1. Интегрированные средства технологического управления

Разработанная фирмой Siemens система автоматизации SIMATIC WinAC, базирующаяся на ПК, дополняет существующий спектр устройств SIMATIC и в полной мере соответствует стратегии фирмы -интегрированные средства технологической автоматизации.

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

Основой данного решения является операционная система (ОС) WindowsNT (последняя версия). Таким образом, для клиентов исключается любой риск потери вложенных средств в связи с последующими доработками   стандартного   программного обеспечения (ПО).

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

6.1.2. "Мягкий" и "жесткий" режимы РМВ

Ключевое требование, всегда предъявляемое к АСУТП, - их способность работать в РМВ. Режим РМВ определяется промышленным стандартом ФРГ № 44 300 как режим функционирования вычислительной системы, при котором обрабатывающие программы в каждый момент готовы обработать поступающие данные таким образом, что результаты станут доступными за строго определенные и предсказуемые интервалы времени. Жесткий режим РМВ означает, что система обязательно реагирует на все события, возникающие в объекте управления через заданное время, мягкий, напротив, предполагает возможность в некоторых случаях нарушения жестко заданных временных рамок.

Хотя WindowsNT и не является ОС, способной работать в жестком режиме РМВ (так, как это могут, например, гибко программируемые контроллеры), ее архитектура "микроядра" позволяет обеспечивать достаточно малые времена ответа в "гибком" режиме РМВ. Применение соответствующим образом структурированных программ позволит достичь в поведении ОС еще лучших показателей в отношении режима РМВ.

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

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

6.1.3. Управление на базе ПК

Определяющую роль в ходе принятия решения в пользу гибко программируемого контроллера или системы на базе ПК играет наличие дополнительных, не связанных непосредственно с проблемой технологического управления, задач, таких, например, как обработка данных, визуализация или коммуникация. Чем больше доля подобных задач, тем выгоднее может оказаться применение систем на базе ПК. Управление на базе ПК при помощи пакета SMATIC WinAC - это намного лучше, чем просто программная эмуляция гибко программируемого контроллера.  Исключительно важна полностью совместимая с контроллерами SIMATIC S7 компонента WinAC-Controlling со встраиваемой в ПК картой. Эта компонента не только берет на себя загрузку и запуск программы управления, но и является для системы средством доступа к устройствам децентрализованной периферии по шине Profibus-DP, a также предоставляет богатые возможности диагностики. В качестве средства визуализации может использоваться компонента SIMATIC WinCC, которая оптимальным образом интегрируется в WinAC. Для тех, кто хочет использовать другое ПО HMI, существует возможность интеграции его через интерфейсы OLE или ОРС. В будущем технология WinAC будет включать в свой состав также компоненты регулирования и позиционирования. WinAC-Computing позволяет связывать данные технологических процессов с такими стандартными программными приложениями, как Excel или Access. И, конечно же, в рамках системы имеется компонента (WinAC-Networks), которая обеспечивает подключение к стандартным вычислительным сетям (например, TCP/IP).

Для проектирования и программирования системы используются те же   инструментальные   средства STEP7, что и для контроллеров SIMATIC S7 (например, AWL, КОР, FUP, SCL, программирование технологических цепочек).

Резюме

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

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

6.2. СИСТЕМОТЕХНИЧЕСКИЙ И АРХИТЕКТУРНЫЙ СИНТЕЗ  АСУ ТП С ИСПОЛЬЗОВАНИЕМ ТИПОВЫХ РЕШЕНИЙ

6.2.1. Задачи системотехнического и архитектурного синтеза

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

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

(ТР), к которым относят небольшое число наилучших (в определенных смыслах), апробированных на практике н отлаженных (с устраненными недостатками) решений [1 ...3]. Для выбора готовых ТР обычно достаточно информации на описательном (качественном) уровне, с лингвистическими переменными [4...6].

Необходимые для решения задач синтеза систем управления исходные данные удобно разделить на два вида:

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

- особенности F- данные, характеризующие предметную область задачи, в том числе характеристики объекта и целей управления, объективные ограничения и т.д.

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

Возможность такого нечеткого описания условий задачи (фадзификация) существенно упрощает ее решение. Множество данных о предметной области задачи выбора З при их лингвистическом описании обозначим f_З, а множество лингвистических требований - как D_З. Искомое решение  конкретной задачи З является, очевидно, элементом некоторого отображения декартова произведения множеств D_З и F_ЗD, образующего факторное множество задачи, на множество S_З  допустимых решений:

                                     (1)

где f_З, означает, что спецификация задачи определяется в общем случае требованиями к решению, т.е. является проблемно- и условно-ориентированной; в этом случае пару (D_З ,f_З) назовем адекватной данной задаче.

С учетом нечеткости исходных множеств решение само нечетко и требует при его реализации устранения нечеткости -дефадзификации, которая составляет самостоятельную проблему, поскольку конкретное факторное множество в соотношении (1) отображается здесь на единственный элемент - ТР :

Проблема типизации - нахождения ТР на известном множестве S_З допустимых решений ~ здесь не рассматривается, поскольку освещена в литературе, например в работе [3].

Системотехнический синтез АСУТП, связанный с выбором нескольких взаимосвязанных структур системы, регламентированных государственным стандартом (алгоритмической, информационной, технической, программной, организационной), является комплексной задачей структурного синтеза (КЗС) З_cc представленной моделью

                                    (2)

где  - множество подзадач КЗС, каждая из которых заключается в синтезе одной из регламентированных структур; - семейство бинарных отношений на множестве подзадач (связи подзадач).

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

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

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

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

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

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

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

Группа  объединяет требования технологического регламента, требования к условиям эксплуатации технологического оборудования и программно-технического комплекса (ЛТК) системы, а также особенности эксплуатации ТОУ, его режимов, влияния возмущений, реализации управляющих воздействий.

Группа  отражает требования к надежности ПТК и его компонент, мерам ее повышения, работе ПТК и персонала при отказах технологического оборудования и средств ПТК, а также качественные характеристики надежности ТОУ и его частей, используемых компонент ПТК.

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

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

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

Группа  - это прочие требования и особенности (экологические, социальные и др.), не вошедшие в перечисленные группы, но существенные для решения данной конкретной подзадачи КЗС (2).

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

Каждую i-ую подзадачу из соотношения (2) определим своей адекватной парой:

                               (3)

Тогда адекватная КЗС (2) пара  не только формируется как объединение соответствующих подмножеств подзадач, но и включает в себя элементы, отражающие требования и особенности взаимосвязи (интерфейса) синтезированных структур. Последние образуют пары, адекватные задачам межструктурного интерфейса , при этом каждая задача  возникает только тогда, когда существует элемент , в модели КЗС (2), и определяется своей адекватной парой

                                   (4)

где знак вопроса используется для обозначения того факта, что адекватная пара в общем случае не вполне определена.

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

Комплексную задачу структурного синтеза (2) можно теперь формально определить своей адекватной парой

                                   (5)

Однако определение (5) практически не может быть использовано, поскольку неизвестно (и это отмечено вопросительным знаком) как само отображение, так и исходные факторные множества:

На практике применяют декомпозиционный подход к решению КЗС (2), основанный на принципах типизации и агрегатизации.

6.2.2. Декомпозиционный подход к проблеме структурного синтеза

Возможность упрощения КЗС (2) связана с ее фадзификацией и декомпозицией.

Далее будем предполагать, что для каждой подзадачи в соотношении (2) известна адекватная ей пара (3), а для каждой пары связанных подзадач  сформулирована (на лингвистическом уровне) соответствующая задача межструктурного интерфейса, определяемая адекватной ей парой (4). Тогда декомпозиционное решение (2) осуществляется по следующей схеме: каждой подзадаче , из (2) ставится в соответствие её ТР, находимое по соответствующей адекватной паре (3), а каждой задаче межструктурного интерфейса –её ТР, находимое по адекватной паре (4); с помощью найденных структурных интерфейсов проводится агрегатное объединение решений (структур); если для какой-то подзадачи ТР неизвестно, оно ищется как агрегатное объединение более простых решений (модулей) для данной структуры, однако в этом случае возникают задачи их стыковки внутриструктурного интерфейса.

Эта схема может быть описана следующей очередностью операций фадзификации (fuz) задач или факторных множеств, дефадзификации (dfz) нечетких решений или отображений, декомпозиции (dec) задач или отображений по определенным признакам и агрегатизации (agr) решений или результатов отображений:

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

сведении исходной -задачи синтеза к задаче выбора на некотором, пока неизвестном множестве З_cc  допустимых структур;

                    (6)

- декомпозиция отображения по функционально-структурному (φ) признаку в соответствии с представлением исходной КЗС моделью (2), где каждой подзадаче , с известной адекватной парой (3) поставлено в соответствие некоторое, пока неизвестное множество {S₁} ее допустимых структур, а каждой паре связанных задач - задача  межструктурного интерфейса с неполной в общем случае адекватной парой;

                      (7)

- декомпозиция неизвестного отображения по структурно-функциональному (о) признаку, когда i-я структура системы представляется некоторым множеством {S_ik} ее допустимых элементов (модулей), связанных между собой функциональными связями R_i, при этом из-за расчленения (детализации) исходного отображения возможно появление дополнительных требований к модулям и описаний их особенностей по сравнению с исходными, так что

                                      (8)

- дефадзификация нечеткого отображения по признаку выбора (критерию) δ, кода из множества S_ik известных допустимых элементов выбирается единственный элемент  (типовой, если решается задача оптимального выбора [3]); признаки выбора различны для разных структур и даже могут различаться для разных элементов одной и той же структуры;

                                             (9)

- агрегатизация выбранных k-х элементов (модулей) i-й структуры системы по признаку σ в соответствии с функциональными связями R_i, — см. формулу (6), обозначенная как агрегатное объединение по признаку о и определяемая как объединение известных элементов в i-ю структуру системы с учетом ее назначения и функциональных отношений R_i при  этом  соединение элементов регламентируется ГОСТ 12.999-84, 22.207-83 на условия их совместимости , (электрической, информационной, конструктивной, метрологической, эксплуатационной); таким образом, агрегатизация является в общем случае нетривиальной операцией;

                  (10)

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

                                             (11)

- агрегатизация выбранных структур системы по признаку φ -см. формулу (6), с использованием выбранных межструктурных интерфейсов.

Синтез структур осуществляется в следующей очередности [7].

Основой для разработки является функциональнее структура АСУТП - модель комплексной задачи управления (КЗУ)

                                                                 (12) ,

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

Получение модели КЗУ (12) является задачей анализа и укладывается (формально) в схему (7), поскольку известные методы такого анализа (дерева целей [8], экспертного опроса и др.) используют лингвистическую информацию. Вместе с тем идентификация структуры (12) для конкретных задач комплексной автоматизации, когда каждая задача З_k получает адекватную математическую постановку, до сих пор не имеет удовлетворительного решения и представляет собой почти не разработанный важнейший раздел теории управления -теорию идентификации практических задач [9].

Дефадзификация по формуле (8) соответствует в этом случае приданию четкости постановке k-й прикладной задачи и сведению ее по возможности к некоторой типовой математической. Признаками выбора при этом являются степень формализации задачи, полнота исходных данных для ее решения, достоверность и точность данных и др. Так, по степени формализации все задачи из модели (12) можно классифицировать на:

·  - полностью формализуемые, решаемые автоматически, без участия оперативного персонала (ОП);

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

·  - неформализованные, выполняемые ОП на основании опыта, неформальных соображений, интуиции.

Для задач ,  разрабатывается алгоритмическая структура АСУТП - модель комплексного алгоритма управления (КАУ)

                                                                (13) ,

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

После формирования алгоритмической структуры (13) становится известным состав массива исходных данных d_k, необходимых для решения k-й задачи по выбранному алгоритму а_k^*, а также специфические требования к данным и особенности источников их получения [см. факторы группы ]. Совокупность данных, учитывающих названные факторы, образует вместе с информационными отношениями  прикладную информационную структуру - базу да иных (БД) АСУТП

                                                           (14)

В БД (14) включают также данные, необходимые ОП для решения неформализованных задач.

Каждый алгоритм а_k^* - структуры (13) может быть реализован в виде аппаратного T_k или программного П_k модуля, и реализация КАУ (13) приводит к программной П_o и технической Т_о структурам

 ,

 элементы которых, а также связи ,  синтезируют не только из элементов а_k. КАУ (13) и связей в структурах (12)...(14), но и с учетом требований и особенностей реализации ПТК АСУТП. Адекватные пары для такого синтеза формируются из элементов групп ,, . Получаемые при этом множества возможных вариантов элементов и связей ПТК подвергаются дефадзификации (8), (10) с последующей агрегатизацией (9), (11).

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

6.2.3. Типовые решения в архитектурном синтезе АСУ ТП

Если основной задачей системотехнического синтеза является нахождение средств решения прикладной КЗУ, то для архитектурного синтеза - нахождение такой организации ПТК, при какой прикладная КЗУ решалась бы наиболее эффективно. Таким образом, архитектурный синтез играет по отношению к системотехническому обслуживающую роль, однако в отличие от последнего не имеет сейчас ни основы для начала процедуры синтеза [подобной структуре КЗУ (12)], ни четкой схемы, ни регламентированных процедур. Переплетение нескольких разнородных аспектов (системных, функциональных, логических и физических) организации ПТК затрудняет структуризацию задачи архитектурного синтеза и декомпозицию соответствующего DF-отображения. Поэтому удобнее использовать эмпирический подход, рассматривая важнейшие архитектурные ТР и соответствующие им адекватные пары. Естественно, при этом трудно избежать субъективизма даже в самом перечислении ТР.

Важнейшим при построении современных систем управления производством является принцип децентрализованной обработки оперативной информации реализуемой в распределенных АСУТП. Основу таких систем составляют управляющие вычислительные сети (УВС) в виде конечного множества станций, каждая из которых имеет в сети свой адрес и предназначена для решения некоторой группы задач, входящих в КЗУ (12) или носящих обслуживающий характер, которая образует некоторую локальную комплексную задачу (ЛКЗ) З₁,. Группировка задач для l-й станции УВС осуществляется с учетом ряда факторов: топологических, функциональных, полноты формализации и др. Так, задачи оперативного контроля и управления из множества  полностью формализованных задач, относящихся к одному (крупному) или группе (компактно расположенных) технологических агрегатов, образуют одну или более ЛКЗ, решаемых автоматически на локальных технологических станциях (ЛТС); задачи из множеств ,  реализуются ОП на операторских технологических станциях (ОТС);задачи координации работы технологического оборудования, входящие в КЗУ (12) или появляющиеся при декомпозиции прикладных оптимизационных задач большой размерности, решаются на ОТС или диспетчерских станциях и т.д. Таким образом, первое типовое архитектурное решение можно записать в виде модели УВС

 ,

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

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

                         (15) ,

где    Ст_l, - единственная передающая станция (указывается первой) для данного не пересекающегося с другими отрезка времени Т_l, передачи;

 - множество принимающих станций, состоящее либо из одной станции (при адресной - передаче), либо из остальных станций сети (при безадресной -передаче);

стрелка показывает информационную связь и направление передачи.

Следует отметить, что современные агрегатные комплексы технических средств КТС для распределенных АСУТП [например, ТДС-3000 и SCAN-3000 фирмы Honeywell (США). "Teleperm" фирмы Siemens (Германия), САУ-600/16 концерна "Научный центр" (РФ) и др.] рассчитаны на использование нескольких магистралей, соединяемых при необходимости в сеть с помощью ретрансляционных станций. Таким образом, в реальных АСУТП применяется агрегатное объединение нескольких ТР [соотношение (15)], расширяющее функциональные возможности АСУ, поскольку в пределах каждой из магистралей сети может осуществляться одновременная и независимая передача данных.

Среди архитектурных ТР повышения надежности магистральных УВС следует отметить различного рода дублирование, в частности использование параллельных магистралей, при этом обе магистрали могут работать одновременно (например, а агрегатном КТС "Contronic P") или одна из них может быть резервной (например, в агрегатном КТС ТДС-3000).

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

Такие ТР с уменьшенным числом уровней широко используют на практике, в частности при построении сетей MAP/TOP для интегрированных АСУТП, где для реализации АСУТП используются только первый, второй и седьмой уровни ЭМ ВОС/МОС на базе готовых конструктивных блоков, выпускаемых серийно ведущими фирмами [10]. Такие ТР можно представить моделью

 ,

где  П. ПТ, Т - соответственно программные, программно-технические и технические средства ПТК для решения прикладных задач;( З_l, З_n -для l- й и n-й станций) и служебных задач (р_i ,р_i^’ - при передаче и приеме данных на i-м уровне);

T₀ -физический канал связи (нулевой уровень); стрелки показывают направления передачи данных и квитирующих сигналов с использованием стандартизованных межуровневых интерфейсов - программных или технических;

^*i - стандартизованный протокол i-го уровня.

Необходимость решения прикладных задач управления в реальном времени, когда время решения Т_k любой такой k-й задачи, входящей в структуру (12), ограничено некоторой предельно допустимой величиной Т⁺_k

                                          (16)

приводит к аналогичному условию доступа к физическому каналу связи в пределах гарантированного времени - τ⁺_l:

                             (17) ,

где  - время доступа i-й станции к физическому каналу по запросу на решение k-й задачи, если ее решение относится к компетенции l-й станции и требует исходных данных, находящихся на другой станции (обычно - на специальном файл-сервере); это время зависит от характера задачи З_k и текущей ситуации S_t, на объекте управления и в УВС.

Если Вам понравилась эта лекция, то понравится и эта - 7. Определение генотипа пробанда.

Поскольку время ввода-вывода исходных данных и результатов решения включается в величину T_k для обеспечения быстрого доступа к магистрали в современных УВС используется в качестве ТР маркерный метод доступа с детерминированной дисциплиной передачи маркера

 ,

при которой гарантируется выполнение условий (16), (17).

Анализ рассмотренных ТР показывает, что их использование связано, с одной стороны, с требованиями повышения надежности АСУТП (обеспечиваются с помощью TP₁), снижения стоимости ПТК (TP₁, TP₂), открытости ПТК и унификации связей (TP₃), обеспечения условий решения КЗУ в реальном времени (TP₁, TP₄), а с другой, ~ с такими особенностями реальных задач управления в АСУТП, как комплексный характер этих задач и их высокая размерность, локализация задач управления по группам технологического оборудования, территориальное рассредоточение ТОУ. Требования более частного характера приводят и к более частным ТР, перечень которых можно продолжить.

6.2.4. Выводы

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