ПОЗНАВАТЕЛЬНОЕ

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

Отёска стен и прирубка косяков - Когда на доме не достаёт окон и дверей, красивое высокое крыльцо ещё только в воображении, приходится подниматься с улицы в дом по трапу.

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

Проблемы модели и средства интеграции АСУ в НГО.

При создании следует обращать внимание на:

1) интеграцию экономических и информационных процессов, технических, программный и организационно-методических средств.

2) Создание гибких систем управления, способных адаптироваться к изменяющимся условиям производства

3) Индустриализацию процессов создания АС, развитие САПР и тиражирование типовых элементов АС.

2ой ответ:

Задача – это промежуточный желаемый результат на пути, к цели достижимый за рассматриваемый промежуток времени.

Проблема – совокупность задач, решение которых дает существенное изменение в рассматриваемой предметной области. Управление (контроль) – анализ условий. Цель – желаемый результат, недостижимый за рассматриваемый промежуток, но доступный в будущем, причем за рассматриваем период врем к нему можно приблизиться.

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

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

Имеют место разрывы: организационные, технич, семантич и в технологиях программирования и сопровождения АСУ.

Основные факторы, тормозящие процессы интеграции:

1. Руководство предприят не считает автоматиз достаточ важной сферой, не занимается непосредствен руководством стратегии управлен АСУ.

2. Организационный автоматизац занимает разные подразделен, не имеющ общ руководства и работающ в отрыве друг от друга.

3. Отсутств полный контроль и учет кач-ва и колич-ва материальн и энергетич потоков

4. Разные средства и системы установлены в разн годы и не позволяют связать их друг с другом отсутств периферий устройства.

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

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

7. Среди руководства подразделен сущ-ет тенденц замены ср-в их полными аналогами.

Мероприятия, способствующие интеграции:

Обследование и анализ сущ-щих на предприят систем автоматизац:

а) тех и экон дост-ва и имеющи-ся недостатки

б) сущест-е возможности интеграц с др сист.

в) обеспечен их исходн данными и треб-ми харак-ми

г) тех и экон целесообраз-ть развития и интеграц тех ср-в.

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

Средства интеграции и интеллектуализации.

Наиболее общим ср-вом объед-я разнород производств-х сист-м на ниж ур-не упр-я явл стандарт OLE для промыш упр-я. Обеспеч совместимость и взаимозаменяемость ср-в от разных пр-лей, т.е. ПО любой подсистемы может выпо-ть роль клиента при обмене данными с устройством любого произв-ля (контроллером интеллект прибором, устройств ввода-выв, т.е. для которого есть OPC-сервер). Объединен различ программ ср-в для решения общих задач реализуется объектными технологиями COM/DCOM и CORBA. Они позволяют разрабат программы как объекты и взаимодейст с ними по стандарт интерфейсам.

CORBA, в отличие от COM, нацелена на разные ОС => шире возможности.

SCADA

Ethernet (на нижнем уровне). Стандарты: Profibus, Fielbus. Это средства для обмена данными. Позволяют в единой сетевой среде использовать компоненты различных фирм.

Средства вернего уровня: Единое хранилище данных – ср-во интеграц, содерж всю корпоратив инф-цию – POSC.

Язык XML – для Web-интеграции.

Стандарт MES – стандарт взаимодейст ниж и верх уровня, т.е. БД и средств получен данных.

Средства искус интеллекта – средства интеллектуализации. Использование нейросетевых технологий, fuzzy logic, ЭС. Проблема интеллектуализации разрешима в России.

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

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

Техническое обеспечение – совокуп тех средств, -ll-.

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

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

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

Методология и миссия POSC (Energistics) по формированию информационно-логических моделей в предметной области НГО

Petrotechnical Open Software Corporation (POSC), что в переводе означает Корпорация, Занимающаяся Открытыми Программными Средствами для Нефтяной и Газовой Промышленности. Это некоммерческая корпорация.

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

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

Спецификации корпорации POSC, относящиеся к этим стандартным интерфейсам, касаются следующих областей:

- Базовая вычислительная среда;

- Управление данными и информацией;

- Доступ прикладных программ к данным;

- Обмен данными;

- Интерфейс пользователя.

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

Самым главным является модель данных для разведки и эксплуатации месторождений - словарь терминов, используемых для разведки и эксплуатации месторождений - под названием Epicentre.

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

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

С моделью данных Epicentre тесно связано описание того, как прикладные программы получают доступ к хранилищу данных PDS через интерфейс прикладного программирования (Application Programming Interface) API. Интерфейс API, используемый для доступа прикладной программы к хранилищу данных, является еще одним важным компонентом Платформы для Интеграции Программных Средств. Он известен под названием Спецификация Доступа к Данным (DАЕ).

Логическая модель Epicentre: объекты (сущности) и их атрибуты, отношения между объектами. Примеры подмножеств модели Epicentre.

Самым главным понятием в методологии POSC является понятие модели данных для разведки и эксплуатации месторождений - словарь терминов, используемых для разведки и эксплуатации месторождений - под названием Epicentre.Она определяет семантику многих технических терминов, относящихся к области разведки и эксплуатации месторождений, и является основным архитектурным компонентом Платформы SIP, определяющим смысл данных, содержащихся в хранилище PDS.

Модель в виде ER-диаграмм описана на языке EXPRESS, который не является стандартным языком запросов. Необходимо преобразовать EXPRESS в набор операторов SQL, совместимых с соотв-ей СУБД. Корпорация разработала средства проецирования ORACLE, MSSQL, и т.д.

В модели множество ключей, кот имеют цифровую структуру.

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

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

Из-за ее независимости от реализации корпорация POSC называет Epicentre Логической Моделью Данных. Она также предназначена для интеграции данных от разных дисциплин и может хранить информацию о нефтяном и газовом месторождении в течение всего срока его службы.

В модели данных Epicentre, логически целостные элементы - сущности (entities) соответствуют объектам реального мира, характеристики логически целостных элементов называются атрибутами (attributes), a явления (occurence) объектов называются экземплярами (instances). Также есть различия в описании связей по сравнению с традиционными реляционными моделями. Обычно для реализации связи между таблицами используется внешний ключ, т.е. повторение идентификатора. В модели данных Epicentre вместо повторения идентификатора в логически целостном элементе (entity), к этому элементу добавляется атрибут (attribute).

В Реляционной Реализации Модели Данных Epicentre, Версия 2.2, объекты и атрибуты представлены посредством таблиц и столбцов.

Обычные атрибуты в логической модели Epicentre проецируются как столбцы в реляционной реализации.

Отношения в логической модели реализуются в виде внешних ключей в реляционной реализации модели данных.

Примеры подмножеств модели Epicentre:

Код модели	Наименование (английский)	Наименование (русский)
АС1	Activity Schedule	Схема деятельности
АС2	Activity Effects	Результаты деятельности
POV1	PFNU Business Objects	Бизнес-объект PFNU
POV2	PFNU Port Behavior	Поведение порта PFNU
RVA	Reservoir Activities	Поведение пласта
WB1	Wellbore Component Facility	Элементы, относящиеся к стволу скважины
WO1	Well Operations	Работа скважины

и др.

Сущности супертипа (supertype entities) отмечаются как (abstract) или, если они не являются абстрактными, оставляются без комментариев. Только экземпляр неабстрактной сущности супертипа может существовать независимо. При описании сущности: имя, описание, назначение, семантика и даже атрибуты, локальные правила, где описываются правила применения сущностей и их иерархию.

Ссылка на диаграммы, в кот присутствует эта сущность.

Атрибут может указывать на другую сущность (унаследованную оттуда). После каждого атрибута следует список его описателей, и потом следуют значки. Атрибут:

Если * I Этот атрибут унаследован от одного из супертипов сущности (entity’s supertype).

* К - Этот атрибут является ключом.

* М - Этот атрибут является обязательным. Обязательный атрибут не может быть нулем или не может отсутствовать в действительном экземпляре сущности;

* O - Этот атрибут является произвольным;

* V - Этот атрибут представляет обратную связь.

Если атрибут представл-т связь, то будет дано кол-во элементов, куда входит атрибут set (набор), list (список) и array (матрица)

Пример:

Horizontal_pipe_flow_model // распределение давления по отдельным фазам в горизонт трубопроводам

Identificator(O; K; I) pfnu_internal_behavior

// наслед-ся из другой сущности model(abstract)

// product float network unit – единицы сетей, передающих //продукцию, модель внешнего поведения этой сети абстрактная

Initial_port (M,K,I: pfnu_port)

//обязательный, ключевой, наследуемый начальный порт

Data collection (I, V: set [O?] : data collection(

// набор данных, набор, приписыв-х модели наследуемы атрибут обратной связи (collection_content))

Graphical_element(I,V:set[ O?] ) : gr_el

//одним или большим числом граф элементов описывается (depicted_object)

Все эти элем-ы имели жесткую структуру, дальше идут свойства

Pty_pressure_change(I,V:set:pfnu_intenal_behavior_model)

E_and_p_date>object_of_interest>technical_objects> pfnu_intenal_behavior_model>pipe…;

Иерархия. Далее в каждой диаграмме сод
Правила формирования POSC-совместимой информационно-логической модели для решения отдельной задачи.

1) Частное расширение – без сообщения другим пользователям модели.

2) Публичное расширение – с объявлением проведенных расширений для использования в последующем расширении моделей

Оба вида расширений выполняются в соответствии с правилами создания POSC-совместимых моделей.

Rule R1 – семантическое расширение. Расширение и выделение подмножеств. Расширение не может быть точным повторением существующих в Epicentre структур, аналогичных по содержанию.

R2 – правила расширения могут быть дополнены обратными им правилами сжатия и наоборот.

R3 – в качестве метамодели для проецирования (создания БД) не может выступать подмножество полной модели.

R4 – спецификации полей той части модели, которая сохранена, не должны изменяться.

R5 – может быть добавлена новая таблица к реляционной модели. Поле может быть добавлено к существующей таблице.

R6 – необязательные поля могут быть добавлены в таблицу. Обязательные поля могут быть добавлены только в новые таблицы, которые расширяют исходную модель.

R7 – необязательные поля могут быть удалены. Обязательные поля не могут быть удалены.

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

Т.е. мы должны удалять таблицы с теми ключами в оставшихся таблицах, кот-е на нее указывают.

Этапы реализации реляционной базы данных на основе логической модели Epicentre. Операции по проецированию логической модели в физическую схему БД.

Процесс получения физической реализации Логической Модели Данных Epicentre можно разделить на три главных этапа:

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

- спроецируйте разделенную на подмножества логическую модель на физическую схему. При реляционной реализации этот процесс состоит из создания файла DDL с входящими в него операторами CREATE TABLE (СОЗДАЙТЕ ТАБЛИЦУ),которые определяют действительные таблицы и столбцы, представляющие логическое подмножество;

- используйте механизм обеспечения целостности ссылочных (referen-tial) данных для хранилища данных. Это может быть осуществлено за счет использования в системе управления реляционной базой данных (RDBMS) ограничений целостности (integrity constraints) и триггеров (triggers), за счет использования ограничений целостности на уровне совместимости DAE и/или в процедурах по документированию, которые будут выполнять люди и прикладные программы, получающие эти данные.

Жестким требованием к любому проецированию Epicentre является то, что оно должно сохранять связь логически целостных элементов или логических объектов (entities) с их физическим представлением в базе данных. Это нужно для того, чтобы реализовать интерфейс прикладного программирования для доступа к данными и обмена данными, предлагаемый корпорацией POSC, и обеспечить недвусмысленное понимание данных в хранилище данных при обмене данными. Предлагаемая корпорацией POSC реляционная реализация модели Epicentre отвечает этим требованиям за счет набора логических схем в табличной форме, которые преобразуют объекты (entities) Epicentre в их эквивалентные представления в виде реляционных таблиц.

Корпорация POSC называет свой спроецированный реляционный язык DDL плюс заполненные логические схемы в табличной форме – Реляционная Реализация Модели Данных Epicentre.

Объединение логических моделей данных в единую модель с использованием методологии POSC

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

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

2ой вариант ответа:

1) объединить те части модели, кот были унаследованы из Epicentre

2) добавить те объекты, кот используются независимо в расширениях 1-го и 2-го подмножества.

3) согласование изменения расширения путем нахождения консенсуса.