CC BY
101
УДК 004.414
С. К. Андрюшкевич
Конструкторско-технологический институт вычислительной техники СО РАН ул. Институтская, 6, Новосибирск, 630090, Россия
E-mail: [email protected]
ПОСТРОЕНИЕ ИНФОРМАЦИОННОЙ МОДЕЛИ КРУПНОМАСШТАБНЫХ ОБЪЕКТОВ ТЕХНОЛОГИЧЕСКОГО УПРАВЛЕНИЯ C ПРИМЕНЕНИЕМ АСПЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА
Сложность построения информационной модели крупномасштабных распределенных систем технологического управления обусловлена наличием большого количества элементов и технологических процессов, тесно связанных между собой. В отличие от модульного подхода к декомпозиции, аспектно-ориентированный подход ориентирован на выявление спутывающих элементов предметной области. В настоящей работе представлена информационная модель таких систем, построенная на базе аспектно-ориентированных принципов, определены ее задачи и основные элементы.
Ключевые слова: аспектно-ориентированное проектирование, крупномасштабные системы управления, информационная модель, автоматизация.
Введение
Автоматизированные системы технологического управления (АСТУ) представляют собой совокупность программно-аппаратных систем, которые исходя из условий обеспечения надежности, минимизации потерь и обеспечения качества процессов технологического управления наряду с организационными мероприятиями призваны решать задачи управления, а также задачи поддержания технологического оборудования в надлежащем состоянии. К крупномасштабным системам АСТУ относятся системы, которые функционируют на территориально распределенных предприятиях, обладающих большим количеством информационных и технологических элементов. Такие системы должны функционировать в условиях высокого уровня изменчивости объекта автоматизации, неоднородности технических и программных средств, а также в рамках разобщенных организационных структурных подразделений предприятия. Системы класса АСТУ являются многокомпонентными, они должны интегрировать существующие технические системы предприятия и осуществлять эффективное информационное взаимодействие со всеми участниками технологического процесса и системами различных уровней. Организация такого взаимодействия требует разработки информационного фундамента, на котором будет базироваться все информационное взаимодействие систем и сотрудников компании. Сложность построения такого фундамента связана с большим количеством задач, процессов, технологических элементов, которыми управляет АСТУ. В большинстве случаев решаемые задачи не являются изолированными, а оказываются полностью или частично вовлеченными в другие задачи.
Задача формирования единого информационного пространства хорошо известна в области корпоративной автоматизации и в машиностроении. В корпоративных системах ключевую роль играют системы управления нормативно-справочной информацией (НСИ) [1] или системы управления мастер данными [2], являющиеся основным источником идентификационных данных. Однако для задач технологического управления только ведения справочников
ISSN 1818-7900. Вестник НГУ. Серия: Информационные технологии. 2010. Том 8, выпуск 3 © С. К. Андрюшкевич, 2010
и реестров недостаточно, так как требуется знание о фактической физической структуре элементов и их взаимодействии. В машиностроении широко применяются CALS-технологии [3], описывающие изделия на конструкторском уровне, пригодном для проектирования или производства. Этот уровень детализации является излишне высоким для задач АСТУ, где большую роль играет точность описания вширь, а не вглубь.
В настоящей работе представлена информационная модель крупномасштабных объектов технологического управления, построенная с применением аспектно-ориентированных принципов проектирования, являющаяся основой информационного пространства АСТУ. Аспектно-ориентированный подход [4] позволяет справиться со сложностью предметной области технологического управления, а также повысить добротность [5] системы, как на стадии проектирования информационной модели, так и на стадии ее реализации.
Инженерия предметной области
Трудности описания крупномасштабных объектов связаны с большим объемом и сложной структурой процесса управления, по которому строится модель предметной области. Существуют подходы к преодолению проблем построения типовой информационной модели, основанные на принципах инженерии предметной области (domain engineering) [4], Semantic Web и аспектно-ориентированного проектирования. Основной цикл инженерии предметной области состоит из трех шагов [6].
1. Идентификация предметной области. Происходит установление границ, определение круга, представляющих ее компонентов, лиц и их целей.
2. Моделирование предметной области. Выполняется сбор, систематизация и формализация информации о предметной области, поступающей из различных источников.
3. Проектирование предметной области. Формируется архитектура ядра, фиксируются интерфейсы взаимозаменяемых компонентов, принимаются ключевые решения по реализации системы автоматизации. Модели предметной области служат источником для проектирования семейства систем.
Идентификация предметной области
В ходе идентификации предметной области крупномасштабных АСТУ были выявлены следующие основные классы задач:
• оперативно-диспетчерское управление;
• мониторинг состояния и режима функционирования оборудования;
• сбор и хранение данных от различных источников;
• учет показаний средств измерений и датчиков;
• техническое обслуживание и ремонт;
• технологический документооборот между подразделениями и филиалами;
• анализ данных и информации;
• информационный обмен с внешними системами, в том числе с автоматизированными системами управления предприятием (АСУП).
Моделирование предметной области
Известным способом уменьшения сложности анализа структуры является процесс декомпозиции. Рассмотрим традиционный модульный подход и относительно новый - аспектноориентированный. Принцип модульной декомпозиции - разбиение сложного целого на более мелкие элементы, которые подвергаются дальнейшему разбиению. При этом порождаемые элементы называются модулями, а их отношения вложенности образуют иерархию. Основным правилом такого разбиения является отсутствие пересечения границ модулей, т. е.
ни один модуль не может пересекать границы другого модуля. Принцип аспектной декомпозиции - составление набора описаний сложного целого, каждое из которых описывает его лишь частично. Признак (проекция), по которому было произведено подобное описание, называется аспектом. При этом аспекты сами могут образовывать модульную структуру. Аспекты возникают тогда, когда требуется определить элемент, не являющийся модулем, когда его части (элементы) входят в состав нескольких модулей. Если изобразить аспект на модульной структуре, то его граница будет пересекать границы модулей. Аспекты также можно структурировать относительно друг друга, этот процесс называется модуляризацией аспектов (рис. 1).
На рис. 1 слева представлено модульное разбиение целого на модули (M). Справа представлена другая модульная структура - структура аспектов (А), полученная в результате применения модульной декомпозиции (модуляризации) не к целому, а к аспектам. И слева и справа представлены модульные структуры. При этом если изобразить пересечение двух модульных структур, мы «проявим» границы аспектов, например, пересечение границ модуля М модулем А1.1, мы получим аспект А1.1 (слева) и обратно, пересечение границ А модулем M1.2 - получим аспект М1.2.
Существует несколько подходов к выделению аспектов при проектировании предметных областей [7].
1. Аспекты как роли. Ролью называют тип, определяющий связанный набор свойств, описание которого происходит через описание взаимодействия с другими ролями. Применение ролей призвано позволить объекту одного типа иметь различные свойства в различных контекстах (обстоятельствах) в различные моменты времени. При этом объекты различных типов могут иметь схожие свойства. Примеры ролей: «пользователь», «покупатель», «администратор» и т. д.
2. Аспекты как направления упорядочивания. Различные способы таксономии, системы классификации могут представлять исследуемую область совершенно по-разному. Взгляды на предметную область, в основе которой лежат разные принципы упорядочивания, очень сложно, если вообще возможно, унифицировать. Таким образом, принципы упорядочивания также могут быть источниками аспектов. Примеры подобных аспектов: «четвероногие», «млекопитающие», «электрические» и т. д.
Рис. 1. Схемы проявления аспектов на модульной структуре (слева) и модуляризации аспектов (справа) [4]
3. Предметно-ориентированные аспекты. В ходе автоматизации предметной области можно обнаружить аспекты специфичные для выбранной предметной области. В области программирования известны такие аспекты, как аутентификация, кэширование, журналирование, сохраняемость, синхронизация, управление транзакциями и т. д.
4. Аспекты моделирования. В ходе процесса моделирования предметной области могут выявляться аспекты специфичные для процесса моделирования: варианты использования, диаграммы классов, схемы данных и т. д. Таким образом, в процессе моделировании возникают свои аспекты.
5. Аспекты как нефункциональные требования. Аспектами могут являться нефункциональные требования, например, производительность, безопасность, удобство использования и т. д.
Рассмотрим возможности аспектно-ориентированного подхода к моделированию и проектированию предметной области, направленного на преодоление сложности структуры предметной области технологического управления. Крупномасштабная АСТУ является модульной системой, состоящей из технических, программных и организационных подсистем. Описания выполнения технологических задач, в которых задействованы подсистемы, также принято выделять в отдельные единицы - сценарии. Сценарии, как правило, не могут быть выполнены в рамках одной подсистемы, они охватывают несколько подсистем. Одна подсистема может участвовать в нескольких сценариях. В таких случаях возникает пересечение одних единиц (подсистем) с другими (сценариями).
Как уже было отмечено, выявление не укладывающихся в модульную структуру и пересекающих границы других модулей элементов - основной принцип выявления аспектов. В традиционном аспектно-ориентированном программировании подобными элементами являются технические задачи, такие как трассировка, отладка, безопасность и т. д. В задачах технологического управления такое место занимают классы решаемых задач. Классы задач АСТУ являются предметно-ориентированными аспектами систем управления. Для простоты дальнейшего изложения остановимся на следующей схематичной структуре классов задач (рис. 2).
Рассмотрим пересечение (cross-cutting) аспектов АСТУ на примере из области диспетчеризации энергоснабжения - процесс подачи оперативной заявки. Оперативная заявка (ОЗ) -это официальное обращение в верхний орган оперативно-диспетчерского управления, содержащее просьбу об изменении оперативного состояния оборудования энергообъекта.
На рис. 3 представлены три схемы:
• схема документа оперативной заявки;
• логическая схема данных базы данных (БД);
• схема процесса документооборота.
Рис. 2. Аспекты технологического управления - классы задач АСТУ
Рис. 3. Схематичное представление переплетения аспектов на примере процесса формирования и утверждения оперативной заявки
В нашем примере обозначенные классы задач (аспекты) пересекают модульную структуру всех трех схем. Цветными блоками с номерами показаны аспекты, пересекающие части структуры отдельной схемы.
На примере процесса подачи оперативной заявки видно, как поддержка прикладного бизнес-процесса отражается в связях структурных элементов БД, электронных документов и частях программного кода, обеспечивающих их повторное использование при решении других прикладных задач. Сочетание аспектно-ориентированных принципов в проектировании и программировании позволяет повысить качество создаваемой системы по ряду критериев. Явное выделение аспектов, принцип формирования функциональных подсистем, принцип их многократного применения при решении различного набора задач АСТУ в сочетании с изменениями в технологии разработки - сквозное применение аспектных принципов от проектирования до реализации - может быть высоко оценено по генетическим, структурным и прагматическим критериям качества систем.
Особо следует отметить тот факт, что схема описания процесса полностью вкладывается в элемент аспектной декомпозиции предметной области АСТУ. В отличие от схемы данных или документа, шаги процесса не претерпели пересечения с другими аспектами. Ввиду того, что задачи АСТУ лежат в плоскости управления, выражаемая процессами аспектная декомпозиция позволит максимально полно описать систему во всех ее проекциях (процессах и задачах).
Информационная модель объекта автоматизации
Сложность построения информационной модели для крупномасштабных распределенных систем технологического управления состоит в том, чтобы полученное решение позволяло осуществлять неразрушающее расширение системы АСТУ новыми классами задач. Существует множество определений термина «информационная модель», приведем некоторые из них.
• Методология SADT предлагает следующее определение термина «модель»: М есть модель системы S, если М может быть использована для получения ответов на вопросы относительно S с точностью А [8].
• Стандарт STEP явно не определяет термин «информационная модель». Используется термин «информационная модель изделия» (product information model), как информационная модель, которая содержит абстрактное описание фактов, понятий и инструкций об изделии [9].
• ГОСТ 34.003-90 определяет термин «информационная модель» как модель объекта, представленную в виде информации, описывающей существенные для данного рассмотрения параметры и переменные величины объекта, связи между ними, входы и выходы объекта и позволяющей путем подачи на модель информации об изменениях входных величин моделировать возможные состояния объекта [10].
В настоящей работе под информационной моделью объекта автоматизации понимается следующий комплекс информационных описаний.
• Онтология. Формализованное описание сущностей, понятий и правила логического вывода предметных знаний.
• Логическая схема базы данных. Схема, сформированная в соответствии с методологией SADT в нотации IDEF1X. Отражает все сущности предметной области и связи между ними, существенные для задачи автоматизации.
• Модели процессов технологического управления. Модели процессов оперируют онтологическими сущностями предметной области, что позволяет сохранить формальное описание процесса в виде шагов, вариантов выбора в базе данных (БД).
• Физическая схема базы данных. Описание сущностей базы данных. Схема формируется на базе логической схемы, однако ее основная задача - организация оптимального способа физического хранения данных.
• Наполнение справочными данными (в том числе аспектами). Начальное справочное наполнение определяет область технологического управления. В зависимости от наполнения модель может описывать различные наборы отношений, параметры сущностей, определяющих предметную область применения.
• Объектная модель. Представляет собой описание элементов предметной области в виде объектов, доступ к которым может быть осуществлен программным способом через соответствующий прикладной программный интерфейс (Application Program Interface, API).
Ввиду того, что разрабатываемая модель должна иметь практическое применение, для описания каждой части информационной модели был выбран соответствующий инструмент описания, нотация и язык [11]:
• OWL 1 - для описания онтологий;
• IDEF1X - для логической и физической схем данных;
• SQL - для взаимодействия с БД;
• UML - для описания объектной структуры и процессов;
• Java - для программной реализации.
Проектирование предметной области сводится к составлению перечисленных выше описаний и моделей. Отправной точкой процесса проектирования предметной области является постановка задач. Можно выделить следующие классы задач, решение которых невозможно без информационной модели [12]:
• диагностика оборудования и комплексов технологического оборудования;
• решение оптимизационных задач;
• расчетные задачи, основанные на знаниях о топологии и связях различных элементов технологического оборудования;
• построение проблемно-ориентированных отчетов.
1 OWL Web Ontology Language. Режим доступа: http://www.w3.org/standards/techs/owl
Принципы проектирования предметной области
Представление аспектов системными функциями
Ключевым проектным решением построения информационной модели является введение понятия «Системная функция» (System Function), в точности соответствующего аспектам АСТУ - классам решаемых задач. Это позволило реализовать возможность неразрушающего расширения информационной модели при построении на ее базе семейства систем. Перечень системных функций является общесистемным справочником. Ссылки на справочник системных функций образуют точки пересечения аспектов (cross-cutting), являющихся также точками расширения модели. Основными точками пересечения аспектов оказались отношения «N-М», в которых системная функция является обязательным параметром. Введение понятия системной функции обладает рядом преимуществ перед традиционным подходом, при котором требуется экстенсивное расширение состава таблиц в схеме БД для расширения перечня решаемых задач.
• Повышение семантической нагрузки отношений между элементами модели. Ссылки на справочник системных функций в первичных ключах многопараметризованных отношений позволили их предметно ориентировать, что обеспечило прозрачность и трассируемость вовлеченности информационных элементов в различные аспекты.
• Неразрушающее расширение системы. Расширение перечня системных функций позволяет повторно использовать структуры отношений без внесения структурных изменений в схему данных. Достаточно расширить справочник новыми системными функциями.
• Локализация области применения системных функций. Справочник системных функций в разных предметных областях, как правило, имеет различный состав. От внедрения к внедрению он может быть изменен. Например, отношения «Сотрудник работает», «Используется», «Технологически зависит» применимы только к некоторому набору информационных элементов. Для решения этой задачи был разработан и применен шаблон конкретизации справочника путем создания выделенной сущности-фильтра для каждой точки использования реестра системных функций - многопараметризованных отношений.
Основные информационные элементы
В результате декомпозиции предметной области были выделены следующие основные части логической схемы данных (рис. 4) [13].
• Организационная структура. Блок организационной структуры включает все информационные элементы, относящиеся к финансово-административной области. Эти элементы, практически незадействованные в моделях технологических объектов, являются справочной информацией, которая полностью поступает из внешних систем корпоративного управления или системы ведения НСИ.
• Технологические ресурсы и взаимодействие между ними. Блок оперирует технологическим оборудованием (ресурсами), комплексами оборудования, их топологией расположения и параметрами. Версии модели отслеживаются на структурном уровне с использованием конфигураций производственных объектов.
• Точки локализации управляющих воздействий. Всякая автоматизированная систем подключается к своему объекту в некоторых точках. В этих точках система измеряет состояние объекта и оказывает на него воздействия. Такие точки называются точками локализации управляющих воздействий.
• Словари, справочники и классификаторы. Блок модели, оперирующий основными справочными сущностями, используемыми всеми элементами информационной модели. Справочники выражены в виде наборов сущностей связей между ними, т. е. также являются композитными информационными элементами.
Рис. 4. Схематичный состав информационной модели предметной области энергообеспечения
• Технологический документооборот. Документы, участвующие в технологическом документообороте, формируются внутри системы по информационной модели предприятия. Далее документ проходит стадии, правила движения по которым также представлены в виде информационной модели.
На примере технологических ресурсов можно показать взаимоотношение модульной и аспектной декомпозиции:
• модульные элементы представлены сущностями БД в виде иерархии наследования (категоризации) - самостоятельными таблицами;
• аспектные элементы выделены в многопараметризованных отношениях «N-М», в которых системные функции выступают обязательными параметрами.
Следует отметить, что для полноценной работы АСТУ необходимы еще две части информационной модели: модель защиты информации и часть, отвечающая за ведение оперативных данных (события и результаты измерения / расчета), которые в данной работе не рассматриваются .
Объектная модель предметной области
Разработанная информационная модель представляет собой многостороннее описание сущностей и связей между ними - базу данных, в которой информация структурирована тре-
буемым образом. Однако эта БД является пассивным программным элементом. Для решения задач технологического управления этого недостаточно. Конечным потребителям (пользователям, подсистемам, внешним системам) модели помимо работы с данными требуется предоставить возможность выводить из данных БД новые знания. Для этого необходимо организовать промежуточный программный слой между БД и прикладным программным обеспечением. Такой слой позволит представить БД активным компонентом системы и решить следующие задачи.
• Сшивка (weaving) аспектов системы. Пользователям доступны предметно-ориентированные программные объекты, методы, для выполнения которых на физическом уровне может потребоваться обработка информационных сущностей и их связей в нескольких аспектах функционирования системы.
• Локализация логики работы с сущностями предметной области. Работа с сущностями информационной модели должна быть локализована в одном месте. Необходимо соблюдать принцип единственности изменений, при котором логика обработки запросов одного характера должна иметь в программном коде единственную реализацию.
• Инкапсуляция особенностей реализации физической схемы БД. Изменения структуры БД, начального наполнения не должны влиять на прикладной программный код, использующий эти структуры. Изменения должны доходить до программного кода только в случае изменения семантики выполняемых операций.
Применение объектной модели
На примере оперативных заявок рассмотрим возможность использования объектной модели и информационной модели состояния. Для простоты изложения примем следующую схему ведения ОЗ (см. рис. 3).
1. Инженер на подстанции формирует заявку на отключение оборудования.
2. Заявка отправляется в диспетчерский пункт на утверждение. Может быть утверждена или отправлена на доработку.
3. Если заявка была отправлена на доработку, автор заявки вносит в нее корректирующие изменения и повторно посылает заявку на согласование.
4. Если заявка была утверждена, то ремонтная бригада выезжает на объект для выполнения работ.
5. О ходе выполнения работ руководитель работ докладывает диспетчеру, который меняет статус выполнения заявки.
6. По завершению работ заявка закрывается.
Для упрощения оперативная заявка будет состоять из семи элементов: номер заявки, наименование подразделения, наименование энергообъекта, отключаемое оборудование, инвентарный номер, содержание работ и исполнитель работ. На примере этапа формирования заявки будет показано, в составе каких процедур происходит сшивка (weaving) аспектов системы (отмечено звездочкой).
Шаг 1. Формирование заявки. Источником входной информации для системы при формировании заявки является только автор - инженер, формирующий заявку. Далее представлены поля заявки и способы их заполнения из информационной модели.
• Заявка моделируется документом определенного вида - «Оперативная заявка».
• Номер заявки заполняется автоматически и не может быть изменен пользователем. Следующий номер заявки формируется последовательно по факту утверждения заявки.
• Наименование подразделения (*) устанавливается автоматически. Пользователь системы (инженер) моделируется с помощью информационной сущности «сотрудник». Сотрудник моделируется как ресурс энергосистемы, который связан (через отношения технологических ресурсов и производственных объектов) с одной актуальной конфигурацией производственного объекта: с параметром системной функции «кадровое обеспечение» - искомое подразделение. Задача выбора актуальной конфигурации возложена на объектную модель.
• Наименование объекта (*) - один из производственных объектов, подчиненный подразделению инженера. При составлении заявки инженер должен выбрать из списка доступных объектов. Отношение подчинения между производственными объектами моделируется в многокритериальном отношении производственных объектов системной функцией «иерархия производственных объектов».
о Отключаемое оборудование (*) - ссылка на оборудование, находящееся в составе энергообъекта, на отключение которого формируется заявка. Инженер должен выбрать одну единицу оборудования. Перечень оборудования, входящего в состав энергообъекта моделируется многоцелевым отношением технологических ресурсов и производственных объектов системной функцией «балансовая принадлежность оборудования». В перечень оборудования для выбора должны попасть только те единицы оборудования, которые находятся в состоянии «включено». Определение состояния является сложной задачей, выполняемой информационной моделью состояния. При построении этой модели происходит анализ оперативных данных отключений оборудования в едином технологическом журнале: если отключение не было зафиксировано в журнале, то производится анализ заявок на отключение оборудования и устанавливается, находится ли оборудование в процессе действия другой заявки на отключение.
• Инвентарный номер (*) - инвентарный номер оборудования подставляется автоматически после выбора отключаемого оборудования. Оборудование может обладать несколькими номерами в различных системах категоризации. Информационная модель содержит все эти номера, доступ к которым осуществляется через объектную модель. Различные номера оборудования моделируются таблицами трансляции, которые связаны с оборудованием многоцелевыми отношениями системной функцией «Инвентаризация».
• Содержание работ - текстовое поле, заполняется инженером при составлении заявки. Моделируется как составная часть документа вида «Оперативная заявка».
• Исполнитель работ (*) - ссылка на производственный объект, обслуживающий выбранный энергообъект. Исполнитель работ выбирается из списка, который подготовлен объектной моделью на основании записей в многоцелевом отношении «Отношения производственных объектов» системной функцией «Техническое обслуживание и ремонт».
Шаги 2-6 относятся к описанию технологического документооборота, их рассмотрение выходит за рамки данной статьи.
Заключение
Процесс построения информационной модели крупномасштабных объектов технологического управления устанавливает высокие требовании к подходам и средствам автоматизации, обусловленным необходимостью решения сразу трех задач.
1. Обеспечение единства справочников, классификаторов и реестров технологического оборудования;
2. Обеспечение единства информационной модели объекта управления на всех уровнях крупномасштабного объекта автоматизации;
3. Предоставление программного проблемно-ориентированного способа работ с данными, хранящимися в БД АСТУ, позволяющего получать на их основе знания.
Предложенный в статье подход к построению информационной модели на базе аспектноориентированных принципов проектирования позволяет решить все три задачи. Применение ключевых проектных решений существенно снизило затраты времени и труда на внедрение системы, ее адаптацию под конкретного заказчика, сведя ее к уточнению начального наполнения некоторых справочников.
Представленные результаты были реализованы в семействе продуктов Энергиус на базе Интеграционной платформы «Энергуис» (ИП «Энергиус») [14], внедрение которых было выполнено на нескольких федеральных государственных крупномасштабных предприятиях в
ходе коммерческих проектов. В результате проектирования предметной области была разработана модель с более чем 300 информационными сущностями с более 1 500 предметными связями. Принципы проектирования информационной модели также применялись в ходе выполнения научно-исследовательского проекта «Разработка интеллектуальной системы пространственно-технологического мониторинга на базе глобального спутникового позиционирования с целью повышения энергоэффективности и экологической безопасности существующих методов добычи углеводородов» (шифр проекта 02.514.11.4126) в рамках федеральной целевой программы «Исследования и разработки по приоритетным направлениям развития научно-технологического комплекса России на 2007-2012 годы». По результатам НИР был разработан экспериментальный образец системы мониторинга технологической инфраструктуры (ЭО СОМТИ) [15]. В настоящее время ведутся работы по дальнейшему расширению созданной информационной модели. Результаты работ будут применены в следующих версиях ИП «Энергиус».
На примере объектной модели было показано, каким образом должна происходить сшивка аспектов. Такая сшивка сейчас выполняется вручную в ходе написания соответствующего программного кода. Без сомнений, эта задача относится к компетенции аспектноориентированного программирования, ее решение применительно к системам класса АСТУ является темой дальнейших исследований и разработок коллектива в целом и автора в частности.
Список литературы
1. ГОСТ 34.003-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения».
2. Loshin D. Master Data Management. The MK/OMG Press, 2009.
3. Норенков И. П., Кузьмик П. К. Информационная поддержка наукоемких изделий (CALS-технологии). М.: Изд-во МГТУ им. Н. Э. Баумана, 2002.
4. Чернецки К., Айзенкер У. Порождающее программирование: методы, инструменты, применение. Для профессионалов. СПб.: Питер, 2005. 731 с.
5. Поттосин И. В. Добротность программ и информационных потоков // Открытые системы. 1998. № 6. С. 41-45.
6. Ковалев С. П. Применение онтологий при разработке распределенных автоматизированных информационно-измерительных систем // Автометрия. 2008. Т. 44, № 2. С. 41-49.
7. Steimann F. Domain Model Are Aspect Free // MoDELS 2005. LNCS 3713. Р. 171-185.
8. Марка Д., МакГоуэн К. Методология структурного анализа и проектирования: Пер. с англ. М., 1993. 240 с.
9. ГОСТ Р ИСО 10303-1-99. Системы автоматизации производства и их интеграция. Представление данных об изделии и обмен этими данными. Ч. 1: Общие представления и основополагающие принципы.
10. ГОСТ 34.003-90 Информационная технология. Автоматизированные системы. Основные положения. Приложение 1.
11. Андрюшкевич С. К. Практика построения информационной модели предметной области для систем технологического управления // Программа и тезисы докладов IX Всерос. конф. молодых ученых по математическому моделированию и информационным технологиям. Кемерово: ИВТ СО РАН, 2008. С. 70-71.
12. Andryushkevich S. K., Kovalyov S. P. Distributed Plants Intelligent Monitoring Using Information Models of State // Proceeding of IASTED International Conference on Automation, Control, and Information Technology (ACIT-CDA 2010). Novosibirsk, 2010. Р. 250-255.
13. Андрюшкевич С. К., Ковалев С. П. Опыт адаптации стандартных информационных моделей для распределенных объектов технологического управления // Высокие технологии, фундаментальные исследования, образование: Сб. тр. VII Междунар. науч.-практ. конф. «Ис-
следование, разработка и применение высоких технологий в промышленности». СПб.: Изд-во Политехн. ун-та, 2009. С. 56-57.
14. Ковалев С. П., Андрюшкевич С. К., Гуськов А. Е. Свидетельство о государственной регистрации программы для ЭВМ № 2009613359. Интеграционная платформа учета и управления энергообеспечением «Энергиус», 2009.
15. Андрюшкевич С. К., Золотухин Е. П., Ковалев С. П. Свидетельство о государственной регистрации программы для ЭВМ № 2010613850. Экспериментальный образец программного комплекса системы оперативного мониторинга технологической инфраструктуры «ЭО СОМТИ» (ЭО ПК СОМТИ), 2010.
Материал поступил в редколлегию 21.06.2010
S. K. Andryushkevich
BUILDING INFORMATION MODEL OF LARGE-SCALE DISTRIBUTED CONTROL SYSTEMS
USING ASPECT-ORIENTED APPROACH
The complexity of building information model of large-scale distributed control systems is due to the presence of a large number of elements and processes are closely intertwined. In contrast to the modular approach to the decomposition, the aspect-oriented approach focuses on the identification of confounding (crosscut) elements of the domain. This paper shows an information model of such systems, built on the basis of aspect-oriented principles, defines its objectives and main elements.
Keywords: aspect-oriented design, distributed plants, information model, automation.
