Информационные системы в составе автоматизированных систем

Лекция 2

 

Любая современная АСУТП имеет в своем составе информационную систему для хранения информации о технологическом процессе.

В данной лекции рассмотрены основные вопросы разработки и использования информационных систем (понятие системы было раскрыто в лекции 1).

 

2.1 Системный подход

Этот термин начал применяться в первых работах, в которых элементы общей теории систем использовались для практических приложений.

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

 

2.2 Понятие информации

Информация – совокупность сведений, воспринимаемых из окружающий среды, выдаваемых в окружающую среду либо сохраняемой внутри информационной системы.

Данные – представленная в формальном виде конкретная информация об объектах предметной области, их свойствах и взаимосвязях, отражающая события и ситуации в этой области.

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

Информация в ЭВМ делится на:

· процедурную (выполняемые программы);

· декларативную (данные, которые обрабатывают программы).

Организация хранения и обработки больших объемов информации привела к появлению баз данных.

 

2.3 История развития баз данных

Можно сказать, что путь развития БД - это путь все большего и большего отстранения программного обеспечения от физических структур данных.

До появления БД информация хранилась в отдельных файлах. Самые первые системы управления файлами позволяли программистам создавать, записывать, обновлять и читать эти файлы. Файловая система имеет органический недостаток: программы должны точно "знать", где расположены данные. Как следствие - для определения адресов в развитых системах хранения данных необходимо применение довольно сложных, трудно оптимизируемых и модифицируемых алгоритмов.

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

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

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

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

Процесс отделения программ от структур данных в конечном итоге завершили реляционные базы данных (РБД).

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

РБД позволили моделям данных отражать взаимосвязи прикладной области, а не методы программного доступа к данным и структурам данных. Это – огромный шаг вперед по нескольким причинам:

· Отражающие прикладную область знаний модели данных являются интуитивно понятными конечному пользователю.

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

· Благодаря нормализации удается избежать чрезмерного дублирования данных.

Индустрия РБД в настоящее время вполне созрела. Условия на рынке сейчас диктует "большая пятерка": IBM, Informix, Microsoft, Oracle и Sybase. На нее падает львиная доля всех расходов на разработку БД.

 

2.4 Базы данных реального времени

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

· производственные процессы генерируют данные очень быстро. Чтобы хранить производственный архив системы, например, с 7500 рабочими переменными, в БД каждую секунду необходимо вставлять 7500 строк. Обычные БД не могут выдержать подобную нагрузку;

· объёмы производственной информации настолько велики, что она просто не вмещается в традиционную БД! Например, многомесячный архив завода с 7500 рабочими переменными требует под БД около 1 Терабайта дисковой памяти. Сегодняшние технологии такими объемами манипулировать не могут;

· SQL как язык не подходит для обработки временных или периодических данных, типичных для производственных систем. В частности, чрезвычайно трудно указать в запросе периодичность выборки возвращаемых данных.

Результатом преодоления этих ограничений стало появление класса продуктов, называемых базами данных реального времени (БДРВ). Отмечаются две концепции создания БДРВ: новая независимая разработка БД или разработка БДРВ на основе известных реляционных БД, например, MS SQL Server. Более перспективным представляется второй способ, поскольку, во-первых, он дешевле, а во-вторых, технологичнее (идёт по стопам Microsoft, используя его новые технологии!). В качестве примера реализации БДРВ отметим, например, IndustrialSQL Server (компания Wonderware) и Plant2SQL (Ci Technologies). Основные функции БДРВ, построенные на основе MS SQL Server заключаются в следующем:

· сохранение некритичной во времени информации в БД Microsoft SQL Server, в то время как вся технологическая информация сохраняется в специальном формате;

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

· поддержание целостности данных, что обеспечивает запись больших объемов информации без потерь;

· добавление в Microsoft SQL Server свойств сервера реального времени.

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

Рисунок 2.1 – БДРВ на основе MS SQL Server

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

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

Следует подчеркнуть, что в зависимости от требований создаваемой системы возможны следующие варианты решений:

· использование только РБД, в таблицы которой подсистема АСУТП по SQL-запросам записывает технологические данные; в дальнейшем последние могут быть использованы обеими подсистемами;

· использование БДРВ, которые обеспечивают более высокие характеристики регистрации данных и упрощают (без использования SQL) процесс внесения данных в таблицы;

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

 

2.5 Характеристика БДРВ на примере IndustrialSQL Server

Сервер реального времени

В язык запросов IndustrialSQL Server включены средства работы с временными характеристиками данных. Входящие в состав Wonderware FactorySuite серверы ввода/выводы используют новый протокол SuiteLink. В этом протоколе впервые была введена концепция отметок времени и качества информации, выставляемых серверами ввода/вывода. Кроме того, благодаря протоколу SuiteLink удалось еще более повысить скорость накопления информации.

Система регистрации событий

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

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

Гибкий открытый доступ

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

А имеющиеся клиентские приложения дают пользователям возможность выбирать именно те средства, которые наилучшим образом позволяют решать поставленные задачи.

Хотя методы доступа и являются стандартными, безопасность данных никоим образом не ущемляется. IndustrialSQL Server опирается на средства ограничения несанкционированного доступа систем Microsoft SQL Server и Windows NT, гарантируя тем самым требуемый уровень защиты информации. IndustrialSQL Server представляет собой единственное место доступа к производственной информации и единую платформу разработки прикладных приложений для производства и связи с управленческими системами.

Регистрация в системе, поддержание групп пользователей и управление доступом к БД упрощается благодаря Microsoft SQL Enterprise Manager.

SQL с поддержкой временных параметров

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

Простота конфигурирования

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

Открытая и гибкая база данных

Мощная и гибкая БД IndustrialSQL Server поддерживает доступ к информации реального времени, архивным и конфигурационным данным любыми программными средствами.