Стандартизация модели данных разумного города: Часть 1. Ядро

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

Арно Ле-Ор, старший инженер-программист, IBM

Фото Арно Ле-ОраАрно Ле-Ор (Arnaud Le Hors), член группы стандартизации программного обеспечения IBM, отвечает за стратегическую и техническую координацию нескольких видов деятельности IBM в области стандартизации. В течение 15 лет работает в области открытых стандартов как сотрудник X-консорциума и W3C. Принимал участие во всех аспектах разработки стандартов, включая технические, стратегические, политические и юридические, как внутри этих организацией, так и на стороне – для SDO и таких компаний, как IBM. Участвовал в разработке HTML, XML и других стандартов и является одним из ведущих архитекторов XML-парсера Xerces, разработанного Apache Software Foundation.



Джон Миган, старший инженер-программист, IBM

Джон Миган (John Meegan) - старший сотрудник группы стратегии и технологий программного обеспечения IBM, где он в настоящее время занимается стандартизацией в связи с инициативами IBM в области разумного города и облачных вычислений. До начала работы со стандартами несколько лет занимался разработкой стратегии открытого ПО в IBM Software Group, обсуждая и уточняя ее как с клиентами, так и с отраслевыми экспертами. Несколько лет проработал в подразделении Software Group Strategy, участвуя в разработке стратегии сервера Web-приложений IBM, что впоследствии привело к выпуску семейства продуктов IBM WebSphere. Получил ученую степень бакалавра искусств (BA) в области информатики в Колумбийском университете.



Кит Уэллс, старший инженер-программист, IBM

Фото Кита УэллсаКит Уэллс (Keith Wells) работает инженером-программистом в лаборатории IBM в Research Triangle Park (штат Северная Каролина). Г-н Уэллс несколько лет участвует в проектах Emerging Technologies и Emerging Technologies Toolkit. В настоящее время он исследует новые возможности в области сложных документов, разработки на базе моделей, стандартов программного обеспечения и технологий на базе XML.



04.05.2012

Введение

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

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

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

Стандарты являются ключом для:

  • взаимодействия;
  • представления и обмена данными;
  • объединения данных;
  • виртуализации;
  • обеспечения гибкости.

Можно разработать и нестандартные решения, но это ограничит долгосрочный эффект.

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

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

  • определять содержание;
  • устанавливать структуру содержания;
  • устанавливать отношения с другой информацией.

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

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

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


Сценарий: плановые дорожные работы

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

Краткое описание

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

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

Для координации сценария плановых дорожных работ необходим следующий персонал:

  • операторы;
  • руководители;
  • ответственные исполнители;
  • аналитики;
  • управляющие материальными фондами.

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

  • время реагирования;
  • время исполнения;
  • стоимость для города;
  • экономия для города;
  • влияние на городские службы.

Основная последовательность событий

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

    Определив последствия для конкретных учреждений, все вместе выполнят общий анализ (см. пункт 4).

    1. Ведомство автобусного транспорта определяет, что будет затронут один из его маршрутов.
    2. Ведомство водоснабжения определяет, что с ремонтом дороги можно синхронизировать техническое обслуживание трубопровода (в том же районе).
    3. Управление электрическими сетями определяет, что с ремонтом дороги можно синхронизировать техническое обслуживание подземной инфраструктуры (в том же районе).
    4. Отдел общественного жилищного фонда определяет, что будут затронуты несколько подведомственных ему зданий.
    5. Полицейское управление определяет, что ему, возможно, придется назначить своих сотрудников для регулирования движения в часы пик во время ремонта.
  4. Руководители затронутых учреждений инициируют межведомственное сотрудничество и анализ последствий.
    1. Управляющие материальными фондами всех затронутых учреждений/ведомств координируют и завершают составление планов действий.
    2. Так как ремонт дороги затрагивает несколько ведомств, общая координация работ возлагается на руководителя городского уровня.
  5. Руководители дорожного, автобусного, водопроводного, ЖКХ и полицейского управлений поручают соответствующим управляющим материальными фондами составить графики работ.
    1. Работы координируются между учреждениями в целях обеспечения безопасности и бесперебойной реализации.
    2. Соответствующие вещательные каналы предупреждают граждан о следующих мероприятиях.
      1. Перекрытие дороги и организация альтернативных маршрутов.
      2. Изменение расписания движения автобусов и маршрутов автобусов.
      3. Отключение водоснабжения на время ремонта водопровода.
      4. График отключения электроэнергии.
      5. Изменение порядка предоставления коммунальных услуг жителям затронутых домов.
    3. Руководитель городского уровня должен быть в курсе хода и сроков завершения работ.
  6. Ремонтные работы, скоординированные персоналом учреждений (ответственными исполнителями), завершаются в соответствии с графиком.
    1. Наряды на работу во всех затронутых учреждениях закрываются.
    2. Соответствующие вещательные каналы уведомляют граждан.
  7. Руководитель городского уровня выполняет окончательный расчет затрат и анализ последствий для определения эффективности общего результата.

Ключевые концепции модели

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

  • Организация
    • Определение: группа лиц, организованных для определенных целей.
    • Примеры: полицейское управление, служба ЖКХ, управление автобусного транспорта, транспортное ведомство, управление водоснабжения, электроэнергетическая компания.
    • Основные характеристики: наименование, тип организации, описание, определение, Web-сайт.
    • Основные отношения: организации (родительские-дочерние), материальные фонды, местоположение.
    • Предполагаемые стандарты: Национальная модель обмена информацией (National Information Exchange Model - NIEM): NIEM-Core (nc:) OrganizationType, организация UCore (Universal Core)
    Оповещение
    • Определение: предупреждение или уведомление о предстоящем событии.
    • Примеры: уведомление о ремонте дороги.
    • Основные характеристики: отправитель, описание, срочность, степень серьезности, степень уверенности, время наступления, место, поддерживающие ресурсы.
    • Основные отношения: отправитель (организация или лицо), местоположение, событие, наряды на выполнение работ.
    • Предполагаемые стандарты: Протокол всеобщего оповещения (Common Alerting Protocol - CAP) обеспечивает расширенную поддержку оповещений. применимы также концепции UCore Event.
  • Событие
    • Определение: происшествие или событие, которое может потребовать реакции.
    • Примеры: ремонт дороги, автомобильная авария, разрыв водопровода, преступление.
    • Основные характеристики: дата и время события, описание, идентификатор.
    • Основные отношения: место, оповещения, наряды на работу, ответственный (организация или лицо).
    • Предполагаемые стандарты: NIEM:nc:IncidentType, CAP:alert:incidents, UCore Event, событие по онтологической классификации сервис-ориентированной архитектуры (SOA).
  • Персона
    • Определение: отдельный человек, индивидуум.
    • Примеры: Джеймс, Боб, Салли
    • Основные характеристики: полное имя; имя, фамилия, пол, дата рождения, место рождения, гражданство, национальность.
    • Основные отношения: работодатель, местонахождение, адрес, организация, должность (например, оператор, руководитель, ответственный исполнитель, аналитик, управляющий материальными фондами).
    • Предполагаемые стандарты: NIEM:nc:PersonType, UCore Person, действующее лицо (Human Actor) по онтологической классификации SOA.
  • Материальные фонды
    • Определение: осязаемый объект, который можно отслеживать во времени.
    • Примеры: дорога, водопровод, электрический конденсатор, автобус, здание.
    • Основные характеристики: описание, идентификатор.
    • Основные отношения: организация, лицо, производитель, место, наряд на выполнение работ, событие.
    • Предполагаемые стандарты: NIEM:ip: AssetType, UCore Entity
  • Наряд на выполнение работ
    • Определение: наряд на выполнение некоторой работы по установке, ремонту или замене.
    • Примеры: ремонт дороги, техническое обслуживание главной электрораспределительной подстанции, изменение маршрутов автобусов.
    • Основные характеристики: описание, идентификатор, комментарии, приоритет, состояние, место, дата/время начала, срок/время окончания.
    • Основные отношения: этапы работ, наряд на выполнение работ (родительский-дочерний), событие, оповещение, организация, история технического обслуживания, спецификация, лицо, материальные фонды.
    • Предполагаемые стандарты: соответствующие стандарты на данный момент не определены.
  • Процесс и процедура
    • Определение: последовательность действий, направленных на достижение некоторой цели.
    • Примеры: уведомление о ремонте дороги и координация.
    • Основные характеристики: документ о ходе работ.
    • Основные отношения: технологические операции, наряды на выполнение работ, событие, оповещение, организация, лицо, материальные фонды.
    • Предполагаемые стандарты: онтологический процесс SOA.
  • Ключевой показатель эффективности
    • Определение: меры или критерии для оценки состояния или эффективности работы лица, процесса или предмета.
    • Примеры: время реакции, время исполнения, стоимость для города, экономия для города, влияние на городские службы.
    • Основные характеристики: описание, единицы измерения, предельные значения.
    • Основные отношения: КПЭ (родительские-дочерние), организация, событие, оповещение, процесс и процедура, материальные фонды.
    • Предполагаемые стандарты: соответствующие стандарты на данный момент не определены.
  • Место
    • Определение: географический пункт, точка, положение или территория, указанная своими координатами в земной системе координат, имя или адрес.
    • Примеры: местоположение ремонтируемой дороги: городской перекресток, расположение водопровода.
    • Основные характеристики: географические координаты, почтовый адрес, метка времени.
    • Основные отношения: лицо, организация, материальные фонды, событие, оповещение.
    • Предполагаемые стандарты: NIEM:пс:LocationType, местонахождение по системе UCore, пункт, указанный на географическом языке разметки (Geography Markup Language - GML), местонахождение по системе OpenGIS® Open Location Service (OpenLS).
  • Время
    • Определение: система, используемая для измерения последовательности событий, сравнения продолжительности событий и интервалов между ними, а также для количественной оценки темпов изменения, например, движения объектов.
    • Примеры: время начала и срок окончания работ.
    • Основные характеристики: годы, месяцы, недели, дни, часы, минуты, секунды, миллисекунды.
    • Основные отношения: продолжительность.
    • Предполагаемые стандарты: NIEM:nc:DateTime, W3C DateTimeDescription

Набор стандартов

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

Национальная модель обмена информацией (NIEM)

NIEM – это структура обмена информацией на основе XML, ставшая результатом совместной работы учреждений и организаций США всех уровней (федеральных, государственных, племенных и местных) при участии частного сектора. (См. ссылку на Web-сайт в разделе "Ресурсы".) Целью этого партнерства является эффективный обмен критически важной информацией в ключевые моменты принятия решений в разных сферах деятельности, включая правосудие, службу общественной безопасности, службу преодоления чрезвычайных ситуаций и стихийных бедствий, разведку и службу национальной безопасности. NIEM предназначена для разработки, распространения и поддержки корпоративных стандартов и процессов обмена информацией, которые позволяют организациям автоматизировать обмен информацией.

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

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

Чтобы компоненты стали универсальными, все отрасли должны договориться об их семантике и структуре. После создания набор универсальных компонентов NIEM остается неизменным и относительно компактным.

NIEM облегчает добавление внешних стандартов, даже при дублировании семантики. Например, определены группы замены и типы регуляторов для внешних геопространственных компонентов:

  • Open Geospatial Consortium (OGC);
  • Logical Interchange Format (LIF);
  • LandXML;
  • Международная ассоциация по совместимости (IAI) и
  • ANSI.

Предметно-ориентированные концепции NIEM уникальны для каждого учреждения или государственного ведомства. К предметным областям NIEM относятся:

  • биометрия;
  • ХБРЯ (защита от химического, биологического, радиоактивного и ядерного оружия);
  • преодоление чрезвычайных ситуаций;
  • иммиграция;
  • защита инфраструктуры;
  • разведка;
  • международная торговля;
  • судопроизводство;
  • береговые службы;
  • проверка политической благонадежности;
  • дела молодежи и семьи.

Система NIEM принята многими американскими федеральными ведомствами и учреждениями штатов и местных органов власти, а также распространена на другие предметные области. Государственные учреждения других стран тоже рассматривают NIEM. Например, Евроюст и SEMIC-ЕU включили исследование NIEM в европейские стандарты межведомственного обмена информацией. Однако на сегодняшний день NIEM не считается международным стандартом и не содержит международных словарей или таксономий.

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

Универсальное ядро

Универсальное ядро (UCore) – это инициатива по обмену информацией федерального правительства США, которая поддерживает Национальную стратегию по обмену информацией и все связанные с ней ведомственные и учрежденческие стратегии. (См. раздел Ресурсы). UCore позволяет обмениваться информацией, определив спецификацию (XML-схему), содержащую согласованные представления для наиболее общих и понятных концепций: кто, что, когда и где. UCore определяет структуру, метаданные, правила расширения, защитную маркировку и физическую схему, позволяющие разнородным системам обмениваться информацией друг с другом. Тем не менее, одна из ключевых задач, решаемых при создании системы UCore, заключалась в том, чтобы сохранить ее простой для объяснения и реализации.

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

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

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

Протокол общего оповещения (CAP)

Протокол общего оповещения (Common Alerting Protocol - CAP) ― одна из инициатив EDXL. (См. раздел Ресурсы). EDXL представляет собой набор стандартов обмена данными OASIS, относящимися к событиям и аварийным ситуациям. EDXL – это широкая инициатива по созданию комплексной системы для широкого круга стандартов обмена данными по чрезвычайным ситуациям для поддержки операций, логистики, планирования и финансов.

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

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

Геопространственные стандарты

Open Geospatial Consortium (OGC) – это международная организация, охватывающая более четырехсот организаций, которая предлагает целый ряд стандартов для геопространственных и навигационных служб. (См. раздел Ресурсы). Эти стандарты находятся в свободном доступе на безвозмездной основе и относятся к моделям данных, кодировкам, интерфейсам и практическим рекомендациям.

Краткая спецификация OGC

Краткая спецификация OGC составляет концептуальную основу для OGC Standards Baseline, ядра стандартов OGC. Эталонная модель OGC описывает эти стандарты и то, как они соотносятся друг с другом. (См. раздел Ресурсы).

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

Географический язык разметки OpenGIS (GML)

Наиболее известный стандарт OGC, GML, определяет XML-грамматику для обмена геопространственной информацией через Интернет. Стандарт представлен в виде XML-схемы и стал эталонным для передачи и хранения географической информации в отрасли. (См. раздел Ресурсы).

Так как GML распространяется только на географические понятия, местоположение в GML может быть выражено только в виде геометрических точек. В частности, GML не поддерживает гражданского местонахождения. По этой причине GML не оптимален для разработки ядра эталонной модели для решений разумного города. Лучшим подходом представляется использование одного из более богатых, высокоуровневых стандартов, основанных на GML, таких как OpenGIS Location Services (OpenLS).

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

OpenLS определяется как XML-схема, основанная на XML-схеме GML.

В других статьях этого цикла мы рассмотрим другие стандарты OGC, а именно CityGML и KML.

Онтология времени в OWL

Онтология времени в OWL ― это рабочий проект W3C, описывающий лексику и отношения к датам, времени, продолжительности и часовым поясам. (См. раздел Ресурсы). Эта онтология позволяет выражать факты, относящиеся к дате и времени. Например, ее можно использовать для обнаружения конфликтов в расписании, сопоставления дат, описания промежутка времени, расчета времени в определенной географической точке или просто для указания времени на Web-странице.

В этой онтологии определены такие OWL-классы, как Interval, DurationDescription, DateTimeDescription и DayOfWeek.

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

Онтологии SOA

Онтология сервис-ориентированной архитектуры (SOA) организации The Open Group (TOG) обеспечивает онтологическое OWL- и UML-описание основных понятий, терминов и семантики сервис-ориентированной архитектуры. (См. раздел Ресурсы). Этот общий словарь позволяет предприятиям и программистам выражать деловые и маркетинговые понятия в технических терминах для решения задач и создания благоприятных возможностей. Онтология SOA создает основу, которая обеспечивает взаимодействие между коммунальными службами, а также способствует ясности и взаимопониманию между заказчиками и техническими специалистами в процессе разработки.

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

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


Рекомендации

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

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

Заключение

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

Указатель стандартов

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

Стандарт Примеры поддерживаемых понятий Имеющиеся примеры применения
Common Alerting Protocol (CAP) Категория, статус, область применения, степень уверенности, степень серьезности, срочность, время начала, срок окончания, тип ответного действия, инструкции. Международный стандарт (OASIS плюс рекомендация МСЭ-Т X.1303), применяемый главным образом в США, в том числе Министерством внутренней безопасности, Национальной службой погоды, Службой геологоразведки США, Управлением по чрезвычайным ситуациям штата Калифорния, Министерством транспорта штат Вирджиния и Региональным альянсом информационной и сетевой безопасности (RAINS) штата Орегон.
Национальная модель обмена информацией (NIEM) Вид деятельности, адрес, происшествие, дата и время, документ, предмет, событие, местоположение, организация, лицо Специфичен для США; примеры применения: Министерство национальной безопасности США, Министерство юстиции США, Службы гражданства и иммиграции США, Федеральное агентство по чрезвычайным ситуациям (FEMA), Программа обмена информацией правоохранительных органов, Программа обмена характеристиками логических объектов, OneDOJ, Министерство здравоохранения и социальных служб.
Географический язык разметки OpenGIS (GML) Пункт Международный стандарт (OGC), широко применяемый в отрасли, который считается эталоном в своей области.
OpenGIS Location Services(OpenLS) Местоположение Международный стандарт (OGC), используемый для приложений с определением местоположения, таких как приложения для мобильных телефонов.
SOA Ontology Услуга, процесс, задача, событие, действующее лицо, эффект, система, правила, договор на обслуживание, интерфейс обслуживания, элемент Международный стандарт (TOG), содержащий словарь и отношения SOA и используемый для описания и моделирования SOA-решений.
Universal Core Объекты и фонды, события и оповещения, люди, организации, места, собрания Стандарт, специфический для США, которым ведают совместно Министерство обороны, Министерство юстиции, Министерство национальной безопасности и Управление директора национальной разведки. Внутри Министерства обороны, похоже, Корпус морской пехоты, ВМС и ВВС также склоняются в сторону поддержки UC.
Онтология времени W3C в рамках OWL Интервал, DurationDescription, DateTimeDescription, DayOfWeek Международный стандарт (W3C) с неопределенным освоением. Наше Web-исследование не обнаружило конкретных случаев применения.

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


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

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Open source
ArticleID=819420
ArticleTitle=Стандартизация модели данных разумного города: Часть 1. Ядро
publish-date=05042012