Программы виндовс ce. Программы для Windows CE. Системные утилиты. Удобный пользовательский интерфейс

«Yamazaki») является шестой версией операционной системы Windows Embedded, ориентированной на предприятия, изготавливающие промышленные контроллеры и устройства бытовой электроники. В Windows Embedded CE 6.0 полностью переделано ядро, которое поддерживает свыше 32000 процессов, по сравнению с 32 в предыдущих версиях. С 32 Мб до 2 Гб поднялось выделяемое для процессов виртуальное адресное пространство.

В марте 2011 Windows Embedded CE 6.0 сменила улучшенная Windows Embedded Compact 7

Энциклопедичный YouTube

1 / 1

✪ Installing Windows CE in Beaglebone Black

Субтитры

Описание

Windows Embedded CE - это компонентная, многозадачная, многопоточная, многоплатформенная операционная система с поддержкой реального времени. Разработчикам доступны около 600 компонентов, используя которые они могут создавать собственные образы операционной системы, которые включает только необходимую данному конкретному устройству функциональность. Операционная система предоставляет разработчикам приложений набор API , основанный на стандартном Win32 API и дополненный специализированным API для встраиваемых устройств. Поскольку CE поддерживает только часть Win32 API и имеет определённую специфику, связанную со встраиваемой природой операционной системы, приложения, написанные для настольных версий операционной системы Windows, могут потребовать дополнительной адаптации и модификации для запуска их на встраиваемых устройствах; и в любом случае, для запуска программ на устройстве потребуется их перекомпиляция.

Так же, как и настольные версии Windows, Windows Embedded CE использует стандартный формат исполняемого файла - Portable Executable (PE). Это позволяет использовать большинство стандартных утилит, работающих с форматом PE, например Dependency Walker (проверка зависимостей) или DumpBin.

Средства разработки операционной системы Embedded CE 6.0 интегрированы с Visual Studio 2005. Они поставляются как дополнение к этому современному пакету разработки. Интеграция с Visual Studio позволяет использовать одну среду для разработки как прикладных, так и системных программ. Вместе с новыми средствами разработки поставляется новый ARM эмулятор устройства, интегрированный в Platform Builder, облегчает процесс конфигурирования, создания и тестирования образов операционных систем. Вся мощь редактора исходного кода современной Visual Studio доступна разработчикам на CE 6.0: подсветка синтаксиса и технология InteliSense (включая BIB файлы). Появились новые графические редакторы: редактор реестра, редактор образа операционной системы. CE 6.0 использует улучшенные компиляторы Visual Studio 2005. Новые компиляторы имеют улучшенную совместимость с языком С++ ; предоставляют улучшенные библиотеки; поддерживают CRT, ATL и MFC , а также предлагают усовершенствованные проверки безопасности времени выполнения (/GS). В новой версии CE появилась возможность «посмертной» отладки. Это предоставляет дополнительные возможности по диагностике потенциальных проблем и оптимизации производительности. В поставку включена утилита, определяющая необходимую лицензию времени исполнения, поддерживающая экспорт отчётов в HTML , что улучшает взаимодействие при работе над проектом и учёт.

Связь с Windows Mobile и Windows Phone

Windows Embedded CE 6.0 не используется в платформе Windows Mobile, однако лежит в основе Zune HD . Следующая версия Windows Mobile, Windows Phone 7 Series , частично основана на Windows Embedded CE 6.0 R3.

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

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

Краткий обзор рынка

Среди наиболее популярных терминалов сбора данных на ОС Windows можно выделить ряд моделей, под брендами CipherLab, Motorola, Honeywell. Сегодня активно выпускаются модели для различных целей, выполненные в компактных корпусах или же, наоборот, в массивном исполнении для складских нужд и высоким классом защиты (IP 65, IP66, IP67 и др.). По большому счету их основные задачи во многом схожи: складcкой учет, инвентаризация, работа с учетными программами, комплектация и отгрузка товаров.

Преимущества перед DOS-терминалами

• Начинка и техническая сложность .
  Терминалы сбора данных на Windows , в отличие от более простого класса оборудования – DOS терминалов имеют более сложную техническую начинку и опции, такие как встроенная фото и видеокамера, диктофон, всевозможные беспроводные интерфейсы и пр.
• Работа по RDP .
  Windows-терминалы оснащаются большими цветными дисплеями с высоким разрешением, что очень удобно для работы по RDP (Remote Desktop Protocol). Это позволяет выполнять задачи на компьютере, а управлять процессом на экране ТСД для экономии ресурсов, повышения производительности и мобильности работы.
  Dos терминалы лишены такой возможности из-за недостаточных технических характеристик.
• Поддержка протокола.Net Compact Framework.
  .NET Compact Framework – это набор компонентов для запуска приложений на терминале сбора данных или других мобильных устройств.
  Одним из преимуществ терминалов CipherLab перед другими брендами - продуманный генератор приложений, который конфигурирует работу ТСД (поставляется в комплекте). Перед началом работы с ТСД сотрудник склада может обозначить на компьютере ряд алгоритмов (детальная информация по штрихкодам, сортировка по товарным группам и т.д.), после чего синхронизировать устройство с ПК и передать все запрограммированные условия и алгоритмы сбора данных. Программирование основывается на использовании логики и не требует специальных знаний. Библиотеки для Windows CE и Windows Mobile отличаются, а значит и генераторы приложений будут разными.

Windows Embedded Handheld

Операционная система Microsoft Windows Embedded спроектирована на платформе Windows Mobile и относится к семейству встраиваемых ОС в различные устройства, в том числе и в терминалы сбора данных. Последней версией на сегодняшний день является Windows Embedded Handheld 6.5 (разработана в 2010 году и официально представлена в 2011 г.). За счет своей универсальности и гибкой архитектуры Microsoft Windows Embedded может использоваться в POS терминалах, мобильных, встраиваемых и портативных устройствах.

Обязательным требованием данной ОС является наличие хорошего мощного «железа»: процессора, оперативной памяти и т.д. Использование такой системы повышает системные требования, и, как следствие, увеличивается стоимость самого устройства.
К терминалам сбора данных, собранных на ОС Microsoft Windows Embedded можно отнести Cipher 9200 , Cipher CP30, Cipher 9600 и др. Все эти устройства имеют ПО для связи с ПК и работы с 1С и генератор приложений с поддержкой Windows Mobile.

Windows CE

Впервые Windows CE появилась на рынке в далеком 1996 году в качестве компакт-версии Win95. С тех пор, произошел ряд существенных изменений. Начиная с 2000 года, данная версия Windows стала развиваться и внедряться как самостоятельная ОС. Основной упор был сделан на создание компонентов не для настольных ПК, а для мобильных устройств, с совместимостью приложений через WIN32 API .

Windows CE и Windows Mobile не являются как взаимозаменяемые операционные системы. Отличительной особенностью Windows CE является модульная система, с поддержкой различных компонентов, платформ, мультизадачности. Преимуществом Windows CE является то, что данная ОС не требует серьезных ресурсов для работы и предназначена для устройств с минимальным объемом памяти и простым одноядерным процессором (минимально для работы системного ядра необходимо всего 32 КБ!).

Последней версией на сегодняшний день считается Windows CE Compact 7.0. Среди наиболее популярных терминалов сбора данных на Windows CE, вышедших в последнее время следует отметить Cipher 9700, Cipher CP55. Современные тенденции выпуска оборудования для автоматизации предполагают наличие различных версий, чтобы клиент мог выбирать то, что нужно для решения задач его компании. Так, некоторые модели ТСД выпускаются в нескольких модификациях на обеих платформах. Ярким примером таких устройств можно считать складской индустриальный терминал сбора данных Cipher CP60.

Подведение итогов: так что же выбрать?

По степени быстродействия эти 2 системы практически полностью одинаковы, хотя раньше программы и приложения на Windows CE работали заметно быстрее. Сегодня же терминалы сбора данных оснащаются мощными производительными процессорами, большими объемами оперативной памяти и существенной разницы в работе простой пользователь, вряд ли ощутит.
В общем и целом сама Windows CE проще по своей архитектуре, имеет классический интерфейс рабочего стола (кнопка «Пуск» и т.д.). Данная ОС интересна в первую очередь разработчикам.

И все же это очень хорошо и целесообразно с точки зрения производителей выпускать современные терминалы сбора данных на операционной системе Windows CE, несмотря на высокую популярность Windows Handheld Embedded 6.5.3. Особенно это удобно тем, кто имеет много программ под старые терминалы на CE и не хочет терять свои наработки.

Выбор ОС может объясняться наличием готовых решений на определённой системе. Допустим, компания приобрела драйверы Wi Fi терминала сбора данных для 1С Предприятия на основе Mobile SMARTS для стареньких ТСД. За время использования у сотрудников появились собственные наработки (базы данных с уникальной доработкой от программиста, наборы утилит, программ и т.д.). И вот, спустя несколько лет, когда пришло время менять оборудование, встает вопрос о том, как сохранить эти наработки и продолжить стабильную отлаженную работу. Софт и драйверы, а также библиотеки .NET Compact Framework для Windows Handheld Embedded несовместимы с написанными для Windows CE. При этом на установку и отладку оборудования были затрачены серьезные финансовые, временные и трудовые ресурсы.

Чтобы избежать таких ситуаций, производители продолжают выпускать на рынок терминалы сбора данных на Windows CE, несмотря на огромную популярность Windows Handheld Embedded.

Среди наиболее успешных новинок ТСД на Windows CE следует отметить CipherLab CP55, CipherLab 9700, CipherLab CP60. Их популярность объясняется современной начинкой, продолжительным временем автономной работы, широкими возможностями для программирования и способностью работать в неблагоприятных условиях.

Данная статья будет интересна тем людям, которые неудачно прошили планшет с процессором WM8505, т.е. не могут подобрать для него стабильно работающую прошивку с OS Android. Здесь я расскажу, как установить на свой планшет русскую версию OS Windows CE 6.0 Embedded.

По одной из моих задумок, решил восстановить старенький планшет, отправленный давно на донорство. На момент восстановления в нем отсутствовали: Wi-Fi модуль, камера, сенсор, аккумулятор, микросхема GL850G (служит USB хабом) и прочая мелочь. Чтобы как-то можно было управлять планшетом, например, стандартной мышкой, вывел пару USB гнезд по уже «накатанной», но усовершенствованной технологии, о которой я рассказывал в . Привожу несколько фотографий данного процесса.

Потому что на плате отсутствует микросхема GL850G, максимальное количество портов USB равняется двум. Если кому-нибудь будет интересно, как и откуда брать разводку USB в отсутствии чипа GL850G, спрашивайте, отвечу в комментариях, хотя все и так видно на фото.

Итак, приведя «железо» планшета в более-менее рабочее состояние, я решил попытаться найти на него прошивку на базе Android OS, но ни одна из них, после установки не запускалась – made in china, что сказать. В результате выбор остановил на WinCE 6.0 RUS. Загружается она в разы быстрее по сравнению с android, что для меня было огромным плюсом. Минусом стал тот факт, что драйвера на камеру найти так и не удалось.

Скачать WinCE 6.0 русскую версию для планшета с процессором WM8505 можно . Устанавливается windows по знакомому сценарию. Необходимо распаковать архив и скопировать содержимое на флеш карту microCD, чтобы в корне флешки оказалась папка script. Затем вставляется данная microCD карта в планшет, он включается и начинается процесс установки, который занимает порядка пяти минут. Сложного ничего в нем нет, главное следить за надписями на экране и следовать им. В процессе установки Windows CE 6.0 Embedded на планшет, нужно будет один раз вынуть microCD карту и принудительно перезагруситься. Вот все, что от Вас потребуется.

Хочу отметить тот факт, что microCD карта памяти на 2 GB class 6 не подошла для этих целей, а на 16 GB class 4 – работала стабильно и надежно. Немаловажным является и тот факт, что в процессе установки WinCE 6.0 на планшет следует обязательно отпаять (отсоединить) камеру, т.к. драйверов на нее в OS нет, и windows на процессе их поиска зацикливается. Возможно, это будет касаться и модуля Wi-Fi, проверить не смог, т.к. он у меня банально отсутствовал при установке, и проверить данный факт возможности не было.

Для многих Windows CE ассоциируется с ОС, созданной для карманных компьютеров. Достаточно большой класс карманных компьютеров основан на этой ОС, при этом ее возможности и области применения гораздо шире. Windows CE разрабатывалась не только для рынка карманных компьютеров, но и для рынка бытовой техники и встраиваемых систем. Не зря в названии ОС есть аббревиатура CE, что, по одной версии, означает Consumer Electronic, а по другой - Consumer Edition (To consume – потреблять в составе чего-то).

Глобальная идея Б. Гейтса - внедрить Windows CE во все устройства, которые "питаются" электричеством. Уже сейчас эта система используется в Интернет-приставках (WebTV), сотовых телефонах, карманных компьютерах, в автомобилях, промышленных системах и т.п.

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

Это позволяет создавать ОС под конкретное устройство и его функции. Высокая надежность устройств с Windows CE обеспечивается тем, что эти системы могут выполняться непосредственно из ROM или специальной Flash памяти. При желании прикладные программы можно разместить в той же Flash памяти, что позволит существенно повысить надежность всей системы.

Наличие в Windows CE поддержки стандартных коммуникационных протоколов Internet: sockets, TCP/IP и PPP позволяет использовать такие системы для практически полноценного доступа в Internet. Для осуществления dial-up соединений в Windows CE встроена поддержка протоколов подмножества TAPI и Unimodem.

Windows CE, хотя и появилась на рынок как "ОС для карманных компьютеров", но поддерживает большой выбор мониторов (монохромные (gray scale), LCD, цветные VGA дисплеи и даже TV) с широким спектром разрешений (до 1024х768)), различные типы процессоров (Hitachi SH3,SH4, NEC 4100, Philips 3900, Intel 486 и более поздние, MIPS, Motorola PowerPC и процессоры технологии ARM), накопители CD-ROM и DVD, поддерживает наборы "чипсетов" для периферийных шин (PCI, ISA и т.д.) и многое другое.

Windows CE - это полноценная 32-х разрядная, объектно-ориентированная, многозадачная ОС с поддержкой фиксированной очереди приоритетов с исполнением до завершения. Она имеет встроенные функции энергосбережения, поэтому у разработчика есть реальная возможность управлять питанием CPU и даже выключать дисплей в целях экономии энергопотребления (что неплохо используется в Cassiopeia E-105 при проигрывании аудио (MP3 файлов) - здорово экономит аккумуляторы!). Windows CE 3.0, поддерживает Java и DirectX-компоненты, и является при этом ОС реального времени, т.е. способна обеспечить гарантированное, быстрое время отклика (так называемый детерминизм) и низкие задержки, необходимые для интенсивно работающих приложений реального времени.

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

Windows CE поддерживает реентерабельность (процессы с низким приоритетом могут отдавать управление процессам с более высоким приоритетом), и обеспечивает вытесняющее управление критическим разделом (preemptable critical section management).

При всех этих возможностях Windows CE не такая "прожорливая" по памяти, как ее конкуренты. Минимальная конфигурация, состоящая из ядра (500 наиболее распространенных функций Win32 API, простая база данных, драйверы для ROM, RAM, FAT файловой системы), коммуникационных протоколов (TCP/IP, PPP, и IrDA) и одного приложения, не требующего для работы дисплея, может вполне обходиться ОП 256KB и требовать менее 0.5 MB ПЗУ.

Для полноценной работы Windows CE, использующей все компоненты архитектуры, требуется всего 2 MB ПЗУ, выполняется она (вместе с графической оболочкой) в ОП менее 512 KB. В карманных компьютерах Windows CE вместе с полным комплектом офисных приложений требует до 4 MB ПЗУ и всего 2 MB ОП.

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

Для разработчиков очень важны доступность и возможности средств разработки, т.к. это почти на 50% определяет успех подобного типа систем. В этом смысле Windows CE является очень перспективной системой - практически все средства разработки от Microsoft, существующие для "больших окон", имеют свои аналоги для Windows CE. Это Windows CE ToolKit for Microsoft Visual C++, Visual Basic и J++. Для работы этих SDK требуются соответствующие среды разработки для Windows NT 4.0 и выше.

19. Классификация программных средств систем управления технологическими процессами

Различают базовое и прикладное программное обеспечение (рис.1).

Рис. 1. Классификация программных средств системы управления.

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

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

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

Выбор ОС зави­сит от жесткости требований реального времени. Для задач, критичных к реакции системы управления, в настоящее время применяются такие операционные системы реального времени, как OS-9, QNX, VxWorks. В системах с менее жесткими требованиями к реальному времени возможно применение версий Windows NT/CE, точнее их расширений реального времени.

OS-9 относится к классу Unix-подобных операционных систем реального времени и предлагает многие привычные элементы среды Unix. Все функциональные компоненты OS-9, включая ядро, иерархические файловые менеджеры, систему ввода/вывода и средства разработки, реализованы в виде независимых модулей. Комбинируя эти модули, разработчик может создавать системы с самой разной конфигурацией - от миниатюрных автономных ядер, ориентированных на ПЗУ контроллеров, до полномасштабных многопользовательских систем разработки.

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

Операционная система QNX разработки канадской фирмы QNX Software Systems Ltd. является одной из наиболее широко используемых систем реального времени. QNX гарантирует время реакции в пределах от нескольких десятков микросекунд до нескольких миллисекунд (в зависимости от быстродействия ПЭВМ и версии QNX). Кроме того, высокая эффективность QNX в задачах управления в реальном времени обеспечивается такими свойствами, как многозадачность (до 250 задач на одном узле), встроенные в ядро системы сетевые возможности, гибкое управление прерываниями и приоритетами, возможность выполнения задач в защищенном и фоновом режимах.

Операционная система QNX нашла применение как на нижнем уровне АСУТП (ОС для контроллеров), так и на верхнем уровне (ОС для программного обеспечения SCADA).

Операционная система реального времени VxWorks предназначена для разработки ПО встроенных компьютеров, работающих в системах «жесткого» реального времени. К операционной системе VxWorks прилагается и инструментальная среда Tornado фирмы Wind River Systems со средствами разработки прикладного программного обеспечения. Его разработка ведется на инструментальном компьютере в среде Tornado для последующего исполнения на целевом компьютере (контроллере) под управлением VxWorks.

ОС VxWorks поддерживает целый ряд компьютерных платформ, в том числе Intel 386/486/Pentium, PowerPC, DEC Alpha. К платформам, поддерживаемым инструментальной средой Tornado, относятся Sun (Solaris), HP 9000/400,700, DEC Alpha, PC (Windows 95 и NT) и другие.

Операционная система Windows знакома всем как настольная система. Но это, прежде всего, относится к платформам Windows 3.хх/95, в которых действительно отсутствует поддержка реального времени. Ситуация резко изменилась с появлением Windows NT. Сама по себе Windows NT не является операционной системой реального времени в силу ряда ее особенностей. Система поддерживает аппаратные (а не программные) прерывания, отсутствует приоритетная обработка отложенных процедур и др. Но в конце ХХ века ряд фирм предприняли серьезные попытки превратить Windows NT в ОС жесткого реального времени. И эти попытки увенчались успехом. Компания VenturCom разработала модуль Real Time Extension (RTX) - подсистему реального времени (РВ) для Windows NT. Эта подсистема имеет собственный планировщик со 128 приоритетами прерываний, который не зависит от NT. Максимальное время реакции на прерывание составляет 20-80 мкс вне зависимости от загрузки процессора. Теперь при каждом прерывании от таймера приоритет передается критичным по времени задачам. А в оставшееся от их работы время могут выполняться «медленные» процессы: ввод/вывод, работа с диском, сетью, графическим интерфейсом и т. п.

32-разрядная Windows CE была создана компанией Microsoft для малых компьютеров (калькуляторов), но в силу ряда достоинств стала претендовать на роль стандартной ОС реального времени. К числу этих достоинств относятся:

Открытость и простота стыковки с другими ОС семейства Windows;

Время реакции порядка 500 мкс;

Значительно меньшие по сравнению с другими ОС Windows требования к ресурсам памяти и возможность построения бездисковых систем.

А в 1999 году компанией Direct by Koyo ОС Windows CE была впервые установлена на платформу микроPLC.

Выбор операционной системы программно-технических средств верхнего уровня АСУТП определяется прикладной задачей (ОС общего пользования или ОСРВ). Но наибольшую популярность и распространение получили различные варианты ОС Windows (Windows NT/2000). Ими оснащены программно-технические средства верхнего уровня АСУТП, представленные персональными компьютерами (ПК) разной мощности и конфигурации - рабочие станции операторов/диспетчеров и специалистов, серверы баз данных (БД) и т. д.

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

Вот несколько основных аргументов в пользу Windows:

Windows имеет очень широкое распространение в мире, в том числе и в России, в связи с чем легко найти специалиста, который мог бы сопровождать системы на базе этой ОС;

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

ОС Windows и Windows-приложения просты в освоении и обладают типовым интуитивно понятным интерфейсом;

Приложения, работающие под управлением Windows, поддерживают общедоступные стандарты обмена данными;

Системы на базе ОС Windows просты в эксплуатации и развитии, что делает их экономичными как с точки зрения поддержки, так и при поэтапном росте;

Microsoft развивает информационные технологии (ИТ) для Windows высокими темпами, что позволяет компаниям, использующим эту платформу «идти в ногу со временем».

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

В 90-х годах широкое распространение получила ОС реального времени QNX. Имеется множество примеров использования QNX на всех уровня иерархической структуры АСУТП (от контроллеров до серверов и рабочих станций). Но в последние годы активность компании на рынке SCADA-систем значительно снизилась, что привело и к снижению числа продаж этого программного продукта. Объясняется это тем, что еще в 1995 году компания QNX Software Systems Ltd. объявила об «уходе» во встроенные системы.

С точки зрения разработки системы управления предпочтительна такая программная архитектура, в ко­торой ПО всех уровней управления реализовано в единой операционной системе. В этом случае «автоматически» снимаются все вопросы, связанные с вертикальным взаимодействием различных программных компонент системы управления. Но на практике это далеко не так. Достаточно часто в разрабатываемых системах контроля и управления нижний и верхний уровни реализуются в разных ОС. И наиболее характерна ситуация, когда на уровне контроллера используется ОС реального времени, а на уровне оператора/диспетчера SCADA-система функционирует под Windows NT. Без специализированных решений по организации взаимодействия между подсистемами здесь не обойтись.

Ø Для функционирования системы управления необходим и еще один тип ПО - прикладное программное обеспечение (ППО).

Известны два пути разработки прикладного программного обеспечения систем управления:

Создание собственного прикладного ПО с использованием средств

традиционного программирования (стандартные языки

программирования, средства отладки и т.д.);

Использование для разработки прикладного ПО существующих

(готовых) инструментальных средств.

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

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

С точки зрения области применения готовые инструментальные средства можно разделить на два класса:

Средства, ориентирован­ные на разработку программ управления внешними устройствами, контрол­лерами - CASE -системы (Computer Aided Software Engineering );

Средства, ориентированные на обеспечение интерфейса оператора/ диспетчера с системой управления – SCADA -системы(Supervisory Control And Data Acquisition - диспетчерское управление и сбор данных).

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

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

В 1992 году Международная Электротехническая Комиссия (МЭК, IEC - International Electrotechnical Commission,) взяла под контроль процессы, связанные с развитием этого типа прикладного ПО. Были выдвинуты требования открытости системы, выполнение которых позволило бы унифицировать программные средства и упростить разработку:

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

Наличие коммуникационных средств (интерфейсов) для взаимодействия с другими компонентами системы управления;

Возможность портации ядра системы на ряд программно-аппаратных

платформ.

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

Названия некоторых из этих пакетов приведены ниже:

RSLogix 500, RS Logix 5, RSLogix 5000 фирмы Rockwell Software для программирования контроллеров различных семейств Allen-Bradley;

DirectSOFT для контроллеров семейства Direct Logic фирмы Koyo;

Пакеты PL7и Concept- ПО для программирования контроллеров различных семейств компании Schneider Electric;

Пакеты STEP 5, STEP 7 Micro, STEP 7 для программирования контроллеров семейств S5 и S7 фирмы Siemens;

Пакет Toolbox для конфигурирования контроллеров семейства Moscad;

Пакет TelePACEдля программирования контроллеров серий

TeleSAFE Micro 16 и SCADAPack фирмы Control Microsystems.

Стандартом МЭК 1131-3 определены пять языков программирования контроллеров: три графических (LD, FBD, SFC) и два текстовых (ST, IL).

В конце 90-х годов появились открытые программные продукты ISaGRAF, InControl (Wonderware), Paradym (Intellution), предназначенные для разработки, отладки и исполнения программ управления как дискретными, так и непрерывными процессами.

Сейчас уже можно сказать, что подавляющее большинство контроллеров и систем управления обслуживается программными продуктами, реализующими стандарт МЭК 1131-3.

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

В своем развитии SCADA - пакеты прошли тот же путь, что и программное обеспечение для программирования контроллеров. На начальном этапе (80-е годы) фирмы-разработчики аппаратных средств создавали собственные (закрытые) SCADA-системы, способные взаимодействовать только со «своей» аппаратурой. Начиная с 90-х годов, появились универсальные (открытые) SCADA - программы.

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

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

Ниже приведен перечень наиболее популярных в России SCADA-пакетов.

q Trace Mode/Трейс Моуд (AdAstrA) - Россия;

q InTouch (Wonderware) - США;

q FIX (Intellution) - США;

q Genesis (Iconics Co) - США;

q Factory Link (United States Data Co) - США;

q RealFlex (BJ Software Systems) - США;

q Sitex (Jade Software) - Великобритания;

q Citect (CI Technology) - Австралия;

q WinCC (Siemens) - Германия;

q RTWin (SWD Real Time Systems) - Россия;

q САРГОН (НВТ - Автоматика) - Россия;

q MIK$Sys (МИФИ) - Россия;

q Cimplicity (GE Fanuc) - США;

q RSView (Rockwell Automation) - США и многие другие.

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

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

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

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

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

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

В результате, информация, имеющаяся и успешно используемая в АСУТП, недоступна для верхнего уровня.

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

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

Такие системы от различных производителей (в том числе и от производителей SCADA-систем) уже появились в России и с каждым днем находят все более широкое применение. Среди них IndustrialSQL Server – компонент интегрированного пакета FactorySuite (Wonderware), iHistorian - компонент семейства Intellution Dynamics и другие.

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

Наличие базы данных реального времени масштаба предприятия – это только лишь предпосылка для их решения (необходимое, но недостаточное условие). Ряд разработчиков инструментальных систем предлагают использовать с этой целью специальный тип программных продуктов. Это могут быть небольшие системы, предназначенные для решения отдельных типовых задач, например, системы расчета и согласования материальных балансов. Появился ряд интегрированных систем, поддерживающих, наряду с функциями хранения и представления информации, решение задач расчета тепловых и материальных балансов, планирования, оптимизации и т.п. К наиболее известным программным продуктам этого класса ПО относятся InfoPlus компании Aspen Tech, «Калькулятор качества» фирмы ПЕТРОКОМ, PI System (Plant Information System) компании OSIsoft.

Современное развитие информационных технологий (ИТ) создало предпосылки для успешной интеграции всех уровней управления многоуровневой системы и создания интегрированной информационной системы предприятия.

20. Основные функции SCADA-систем

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

Такой подход позволил минимизировать участие операторов/диспетчеров в управлении процессом, но оставил за ними право принятия решения в особых ситуациях.

А что дала SCADA-система разработчикам? С появлением SCADA они получили в руки эффективный инструмент для проектирования систем управления, к преимуществам которого можно отнести:

Высокую степень автоматизации процесса разработки системы

управления;

Участие в разработке специалистов в области автоматизируемых

процессов (программирование без программирования);

Реальное сокращение временных, а, следовательно, и финансовых

затрат на разработку систем управления.

Прежде, чем говорить о функциональных возможностях ПО SCADA, предлагается взглянуть на функциональные обязанности самих операторов/диспетчеров. Каковы же эти обязанности? Следует сразу отметить, что функциональные обязанности операторов/диспетчеров конкретных технологических процессов и производств могут быть существенно разными, да и сами понятия «оператор» и «диспетчер» далеко не равнозначны. Тем не менее, среди многообразия этих обязанностей оказалось возможным найти общие, присущие данной категории работников:

Регистрация значений основных технологических и хозрасчетных

параметров;

Анализ полученных данных и их сопоставление со сменно-суточными

заданиями и календарными планами;

Учет и регистрация причин нарушений хода технологического

процесса;

Ведение журналов, составление оперативных рапортов, отчетов

и других документов;

Предоставление данных о ходе технологического процесса и

состоянии оборудования в вышестоящие службы и т. д.

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

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

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

Выход из этой ситуации был найден в создании методов «программирования без реального программирования», доступных для понимания не только программисту, но и инженеру-технологу. В результате появились программные пакеты для создания интерфейса «человек-машина» (Man/Humain Machine Interface, MMI/HMI). За рубежом это программное обеспечение получило название SCADA (Supervisory Control And Data Acquisition – супервизорное/диспетчерское управление и сбор данных), так как предназначалось для разработки и функциональной поддержки АРМов операторов/диспетчеров в АСУТП. А в середине 90-х аббревиатура SCADA (СКАДА) уверенно появилась и в лексиконе российских специалистов по автоматизации.

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

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

Сбор информации с устройств нижнего уровня (датчиков,

контроллеров);

Прием и передача команд оператора/диспетчера на контроллеры и

исполнительные устройства (дистанционное управление объектами);

Сетевое взаимодействие с информационной системой предприятия

(с вышестоящими службами);

Отображение параметров технологического процесса и состояния

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

для восприятия форме;

Оповещение эксплуатационного персонала об аварийных ситуациях и

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

функционированием программно-аппаратных средств АСУ ТП с

регистрацией действий персонала в аварийных ситуациях.

Хранение полученной информации в архивах;

Представление текущих и накопленных (архивных) данных в виде

графиков (тренды);

Вторичная обработка информации;

Формирование сводок и других отчетных документов по созданным на

этапе проектирования шаблонам.

К интерфейсу, созданному на базе программного обеспечения SCADA, предъявляется несколько фундаментальных требований:

Он должен быть интуитивно понятен и удобен для

оператора/диспетчера;

Единичная ошибка оператора не должна вызывать выдачу

ложной команды управления на объект.

21. Архитектурное построение SCADA-систем

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

C появлением концепции открытых систем (начало 90-х) программные средства для операторских станций становятся самостоятельным продуктом.

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

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

Рис. 2.1. Клиент-серверная архитектура.

Клиент-серверная архитектура предполагает, что вся информация о технологическом процессе от контроллеров собирается и обрабатывается на сервере ввода/вывода (сервер базы данных), к которому по сети подключаются АРМ клиентов.

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

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

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

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

· Важным аспектом в структурном построении сетевых систем управления является структура базы данных реального времени (централизованная или распределенная). Каждая из структур в SCADA/HMI-системах реализуется разными разработчиками по-разному. От реализации существенно зависят эффективность обеспечения единства и целостности базы данных, ее надежность, возможности модификации и т.д.

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

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

· С точки зрения структурного построения SCADA-пакетов различают:

Системы, обеспечивающие полный набор базовых функций HMI;

Системы, состоящие из модулей, реализующих отдельные

функции HMI.

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

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

В клиент-серверной архитектуре системы управления, представленной на рис. 2.2, функции сбора и хранения данных, управления алармами и трендами распределены между тремя серверами. Функция HMI реализуется на станциях-клиентах.

Рис. 2.2. Архитектура модульной SCADA.

Например, SCADACitect имеет в своем составе пять функциональных модулей (серверов или клиентов):

§ I/O - сервер ввода/вывода. Обеспечивает передачу данных между

физическими устройствами ввода/вывода и другими модулями Citect .

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

§ Alarms - сервер алармов. Отслеживает данные, сравнивает их с

допустимыми пределами, проверяет выполнение заданных условий и

отображает алармы на соответствующем узле визуализации.

§ Trends - сервер трендов. Собирает и регистрирует трендовую

информацию, позволяя отображать развитие процесса в реальном

масштабе времени или в ретроспективе.

§ Reports - сервер отчетов. Генерирует отчеты по истечении

определенного времени, при возникновении определенного события

или по запросу оператора.

В одной сети можно использовать только один сервер алармов, сервер трендов и сервер отчетов. В то же время допускается использование нескольких серверов ввода/вывода (I/O Server ). Количество компьютеров с установленным модулем Display (обеспечивающим операторский интерфейс) в сети практически не ограничено.

22. SCADA как открытая система

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

·
Концепция открытых систем предполагает свободное взаимодействие программных средств SCADA с программно-техническими средствами разных производителей. Это актуально, так как для современных систем автоматизации характерна высокая степень интеграции большого количества компонент. В системе автоматизации кроме объекта управления задействован целый комплекс программно-аппаратных средств: датчики и исполнительные устройства, контроллеры, серверы баз данных, рабочие места операторов, АРМы специалистов и руководителей и т. д. (рис. 2.3). При этом в одной системе могут быть применены технические средства разных производителей.

Рис. 2.3. Интеграция SCADA в систему управления.

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

Реализация этой задачи требует от SCADA-системы наличия типовых протоколов обмена с наиболее популярными промышленными сетями , такими, как Profibus, ControlNet, Modbus и другими.

С другой стороны, SCADA-системы должны поддерживать интерфейс и со стандартными информационными сетями (Ethernet и др.) с использованием стандартных протоколов (TCP/IP и др.) для обмена данными с компонентами распределенной системы управления.

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

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

Наиболее широко применимы два механизма обмена:

ODBC (Open Data Base Connectivity - взаимодействие с открытыми базами данных) – международный стандарт, предполагающий обмен информацией с РБД посредством ODBC-драйверов. Как стандартный протокол компании Microsoft, ODBC поддерживается и наиболее распространенными приложениями Windows;

SQL (Structured Query Language) – язык структурированных запросов.

· Программное обеспечение SCADA должно взаимодействовать с контроллерами для обеспечения человеко-машинного интерфейса с системой управления (рис. 2.3). К контроллерам через модули ввода/вывода подключены датчики технологических параметров и исполнительные устройства (на рис. 2.3 не показаны).

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

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

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

Для взаимодействия драйверов ввода/вывода и SCADA до недавнего времени использовались два механизма (рис. 2.4):

DDE (Dynamic Data Exchange - динамический обмен данными);

Обмен по собственным (известным только фирме-разработчику) протоколам.

Рис. 2.4. Обмен информацией с помощью DDE-протокола.

Взамен DDE компания Microsoft предложила более эффективное и надежное средство передачи данных между процессами – OLE (см. ниже). А вскоре на базе OLE появился новый стандарт OPC, ориентированный на рынок промышленной автоматизации.

· OPC-интерфейс

OPC – это аббревиатура от O LE for P rocess C ontrol (OLE для управления процессами). Технология OPC основана на разработанной компанией Microsoft технологии OLE (Object Linking and Embedding – встраивание и связывание объектов). Под объектами здесь подразумеваются так называемые компоненты , которые представляют собой готовые к использованию мини-приложения. Встраивая и связывая эти компоненты, можно разрабатывать приложения компонентной архитектуры . Этот новый подход к разработке приложений, предложенный компанией Microsoft, получил название технологии COM (Component Object Model – модель компонентных объектов). Теперь приложение-клиент может удаленно вызывать те или иные функции этих объектов так, как будто объекты находятся «рядом». Объект может нахо­диться и в самом деле рядом (в адрес­ном пространстве приложения) - тогда это просто СОМ .

Если же объект находится в другой программе на том же компьютере или на другом узле сети, то это DCOM -Distributed (распределенная) СОМ .

Так что же такое ОРС? OPC представляет собой коммуникационный стандарт, поддерживающий взаимодействие между полевыми устройствами, контроллерами и приложениями разных производителей. Стандарт OPC описывает компонентные объекты, методы и свойства (базирующиеся на технологии OLE/COM) для серверов данных реального времени, таких как PLC, DCS, систем архивирования данных и других, и обеспечивает передачу информации, содержащейся на этих серверах, стандартным OLE-клиентам.

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

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

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

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

Использование технологии OPC в настоящее время возможно лишь в операционных системах, построенных на технологии OLE/COM, т.е. в ОС Microsoft Windows 95/98 и Windows NT. Идут разработки поддержки этой технологии для операционной системы UNIX.

Таким образом, любое устройст­во, для которого есть ОРС -сервер, мо­жет использоваться вместе с любой со­временной SCADA -системой, реализованной на платформе MS Windows.

Развивающая стандарт OPC некоммерческая организация OPC Foundation (http://www.opcfoundation.org), насчитывает свыше 200 членов. В нее входят почти все ведущие мировые производители программно-аппаратных средств автоматизации.

Хотя стандарт ОРС и основан на универсаль­ном фундаменте - COM /DCOM , он разра­батывался специально для использова­ния в промышленной автоматизации и поэтому имеет вполне содержатель­ную концептуальную сторону.

Стандарт состоит из трех основных спецификаций:

Доступ к данным реального времени (Data Access);

Обработка тревог и событий (Alarms & Events);

Доступ к историческим данным (Historical Data Access).

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

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

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

OPC-интерфейс допускает различные варианты обмена: с физическими устройствами, с распределенными сетевыми системами управления и с любыми приложениями (рис.2.5). На рынке имеются и инструментальные пакеты для написания OPC-компонентов.

Рис. 2.5. Обмен данными по OPC-интерфейсу.

Использование технологии OPC позволяет конечным пользователям выбирать программно-аппаратные средства, наиболее отвечающие их потребностям, независимо от того, кто их производит.

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

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

С другой стороны, сегодня в мире существует множество компаний, занимающихся разработкой различных программных компонентов для SCADA-систем, например, ActiveX-объектов. Их использование при разработке систем автоматизации упрощает и ускоряет процесс проектирования. Этот процесс все больше начинает напоминать процесс «сборки» прикладного программного обеспечения из готовых компонентов. Снижаются требования к квалификации программистов – количество задач, решаемых системой с помощью программ собственной разработки на высокоуровневых языка типа C или Visual Basic уменьшается. Все это способствует расширению области применения SCADA-систем.

· ActiveX-объекты

ActiveX – это технология Microsoft, основанная на COM/DCOM (см. выше) и предназначенная для написания сетевых приложений. Она предоставляет программистам наборы стандартных библиотек, значительно облегчающих процесс кодирования.

Стандарт ActiveX позволяет программным компонентам взаимодействовать друг с другом по сети независимо от языка программирования, на котором они написаны (Visual Basic, Visual C++, Borland Delphi, Borland C++, любые средства разработки на Java).

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

Технология ActiveX включает в себя клиентскую и серверную части.

Серверная часть технологии ActiveX реализована с помощью Microsoft Internet Information Server (IIS).

Клиентская технология ActiveX реализуется на машине-клиенте с помощью библиотек, поставляемых вместе с Microsoft Internet Explorer , являющимся полнофункциональным Wев-браузером (WWW - World Wide Web) и контейнером для ActiveX-элементов. Сегодня технология ActiveX успешно внедряется в системы, функционирующие на Windows-платформе. Нет сомнения, что в ближайшее время эти технологии будут использоваться и на других платформах, так как информационные технологии развиваются очень высокими темпами.

Какое же отношение технология ActiveX имеет к SCADA-системам? Разработчики SCADA-программ на платформе WindowsNT/2000/XP воспользовались этой технологией Microsoft. Сейчас уже многие SCADA являются контейнерами для ActiveX-объектов. А это значит, что огромное количество готовых к многократному использованию ActiveX-объектов, создаваемых многочисленными производителями подобного программного продукта, могут встраиваться с минимальным программированием в SCADA-приложения. И тогда процесс разработки человеко-машинного интерфейса будет напоминать работу с конструктором, заключающуюся в подборе и встраивании готовых компонентов.

В режиме исполнения ActiveX-компоненты поддерживают динамический обмен данными с другими сетевыми программно-аппаратными компонентами по OPC-интерфейсу.

Пример ActiveX-объекта приведен на рис. 2.6.

Рис. 2.6. ActiveX-объект «Сводка сигнализации».

Итак, открытость программного обеспечения SCADA обеспечивается целым рядом факторов, а именно:

Возможностью создания собственных программных модулей

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

Наличием специальных драйверов для связи SCADA с наиболее

популярными контроллерами разных фирм;

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

драйверов;

Возможностью их работы в типовых операционных системах;

Наличием типовых программных интерфейсов (DDE, OLE, OPC, ActiveX, ODBC, SQL и др.), связывающих ПО SCADA с другими программно-аппаратными средствами системы управления, включая и СУБД.

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

23. Актуальность интеграции программных средств АСУТП и АСУП

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

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

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

Вверху, на уровне АСУП (в мировой практике этот уровень управления получил название ERP - Enterprise Resources Planning - планирование ресурсов предприятия), имеются структуры, обеспечивающие финансово-хозяйственную деятельность предприятия в целом, планирование и учет производства, в том числе:

Управление финансами;

Бухгалтерcкий учет;

Энергетическое обеспечение;

Материально-техническое обеспечение;

Сбыт готовой продукции;

Ремонтно-техническое обеспечение;

Управление персоналом и т. д.

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

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

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

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

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

Положительные результаты автоматизации технологических процессов очевидны – успешно идет процесс замены морально и физически устаревших средств автоматизации на современные и надежные микропроцессорные системы (DCS или SCADA). На предприятиях появились специалисты, владеющие компьютерными системами и современными методами управления, специалисты по информационным технологиям (ИТ).

· Для решения задач автоматизации управления административно-хозяйственной деятельностью предприятий (АСУП) в последнее время создается и широко внедряется большое количество типовых систем управления. По функциональным возможностям все эти системы неравнозначны. Среди них имеются и так называемые коробочные продукты, реализующие очень небольшое количество функций (бухгалтерские, складские и т. п.), и мощные системы, способные моделировать происходящие на предприятии процессы управления (SAP/R3, Baan, Oracle Applications). Представлены и системы среднего класса (JD Edward’s, MFG – Pro, SyteLine, Renaissance, Concorde XAL, SunSystems, БОСС-Корпорация, Галактика, Парус, Ресурс и др.), способные реализовать достаточно большое количество функций по различным направлениям – финансы, персонал, сбыт.

Особенностью всех этих систем является применение современных реляционных баз данных, таких как, например, Oracle, Informix, Microsoft SQL Server и других, наиболее хорошо приспособленных для решения задач анализа. На этом уровне нужна только предварительно подготовленная, интегриро

Windows CE

Введение.

Windows CE (она же WinCE) - это вариант операционной системы Microsoft Windows для наладонных компьютеров, мобильных телефонов и встраиваемых систем. Сегодня Windows CE (Consumer Electronics - бытовая техника) не является «урезанной» версией Windows для настольных ПК, она основана на совершенно другом ядре и является операционной системой реального времени с набором приложений, основанных на Microsoft Win32 API.

Windows Mobile (также известна как Windows Phone для ветки 6.5.x) - мобильная операционная система, разработанная Microsoft для собственных аппаратных платформ Pocket PC (коммуникатор) и Smartphone. В настоящее время переживает постепенный отказ от поддержки и разработки. Изначально классические устройства Windows Mobile были карманными персональными компьютерами без возможности подключения к сотовой сети и имели название Pocket PC (PPC). Наследниками Pocket PC являются операционные системы Windows Mobile Professional, кроме функций КПК поддерживающая ещё и функции телефона, и Windows Mobile Classic, тоже предназначенная для КПК, но построенная на более современных технологиях.

Pocket PC (сокращенно Р/РС или PPC) - программная и аппаратная платформа для карманных персональных компьютеров и коммуникаторов компании Microsoft, а также общее название устройств с сенсорным экраном, работающих под управлением операционной системы Windows Mobile. На некоторых таких аппаратах возможно запустить и другие ОС, например GNU/Linux, NetBSD. В русском языке специального термина, обозначающего данный вид устройств нет. Термин Карманный ПК используется для обозначения всего класса мобильных компьютеров, которые в английском называются PDA. В 2007 году компания Microsoft отказалась от использования названия Pocket PC в обозначении версий Windows Mobile 6, изменив соответственно схему обозначения устройств. Коммуникаторы должны называться Windows Mobile 6 Professional devices, а простые КПК (без телефонных функций) - Windows Mobile 6 Classic Devices. Однако, такие длинные названия неудобны, поэтому устройства на базе Windows Mobile продолжают называть Pocket PC.

Архитектура Windows CE.

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

Последней версией из этого семейства является система Microsoft Windows Phone 7 (основанная на Windows Embedded CE 6.0, вышла 11 октября 2010 года). В отличие от других ОСРВ Windows CE проектировалась так, чтобы она была совместимой с универсальными ОС. В настоящее время на большинстве современных устройств установлены и работают Windows Mobile 6.0 и Windows Mobile 6.5, основой у которых является Windows CE 5.2.

Windows CE 5.0 является преемником Windows CE 4.2, третьего релиза семейства Windows CE .NET, 32-разрядная операционная система для мобильных и встраиваемых компьютеров реального времени с поддержкой x86, ARM, MIPS и SuperH микропроцессорной архитектуры.

Новое по сравнению с предыдущей версией:

• 
  Около 50 новых драйверов устройств;
• 
  Средства испытания и обслуживания: Windows Error Reporting (отчет об ошибках Windows), расширение функциональности Windows CE Test Kit (испытательного комплекта для Windows CE)
• 
  Мультимедиа: Direct3D Mobile для мультимедийных, игровых и других приложений
• 
  Безопасность: прогнозирование опасностей, настройки безопасности по умолчанию, поддержка стандарта шифрования AES, поддержка XML-стандартов (повышается управляемость и гибкость операций при работе с Windows CE).
• 
  Для ОС Windows CE 5.0 Microsoft смягчила условия лицензии на исходный код, распространяющийся в рамках инициативы Shared Source. Так, потребители смогут распространять модифицированные версии системы в коммерческих целях, при этом сохраняя за собой права на сделанные изменения. Ранее Microsoft требовала сублицензировать ей все выполненные модификации.

Windows CE 5.0 существует в нескольких модификациях. Windows CE 5.0 часто устанавливается на GPS-навигаторах, обеспечивая минимальную функциональность. В то время как Windows CE 5.0 .NET устанавливают на устройствах класса КПК.

В состав Windows CE 5.0 .NET входит специальная версия исполняющего ядра.NET - .NET Compact Framework 1.0 Service Pack 2. Также включен набор программ просмотра документов в форматах приложений, входящих в Microsoft Office (Word, Excel, PowerPoint), Microsoft Inbox (клиент электронной почты) и WordPad (упрощенный редактор текстов в формате Microsoft Word или RTF). На платформе x86, Windows CE 5.0 конкурирует с Java, Symbian OS, Palm OS.

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

Архитектура Windows CE представлена на рис. 1. Наиболее интересным в этой операционной системе является ее модульность и четкое деление на платформенно зависимую и платформенно независимую части. Именно эти два свойства делают довольно легкой адаптацию Windows CE к конкретной платформе и конкретной задаче.

OEM, Microsoft и независимые производители ПО

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

Файловая система.

В Windows CE используется файловая система TFAT (transaction-safe FAT). Основной особенностью данной ФС является то, что она поддерживает прерывание транзакций во время исполнения. Таким образом, такие частые явления, как извлечение карты памяти, или потеря питания не скажутся не целостности ФС, и никакая пользовательская информация не будет потеряна. TFAT работает с 2 копиями таблицы FAT: Таблица FAT1, в которой происходит управление текущими операциями, и таблица FAT0, в которой хранится последняя стабильная копия FAT. Изменения в FAT0 не будут сохранены до тех пор, пока все элементы транзакции не будут выполнены успешно. Если транзакция не выполняется успешно, то диск восстанавливается в том состоянии, что был до начала выполнения транзакции. После того, как все транзакции выполнены успешно, таблица FAT1 копируется в FAT0.

Теоретический объем TFAT – 2Тб, размер одного сектора – 512 байт. Для того чтобы изменить существующий файл, TFAT разместит новый кластер для изменяемых битов и проложит новый маршрут для цепочки FAT таким образом, чтобы эта цепочка охватывала новый кластер. Это сделано для того, чтобы если транзакция не будет выполнена успешно, то исходная копия файла осталась не поврежденной.

Архитектура ядра.

Ядро обеспечивает базовую функциональность ОС. Эта функциональность включает в себя процессы, потоки и управление памятью. Также ядро обеспечивает некоторые возможности работы с файловой системой.

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

1. 
   Управление памятью
2. 
   Планирование
3. 
   Исполнение программ в реальном времени
4. 
   Системные вызовы

Symbian OS

История появления Symbian OS

Операционная система Symbian OS (EPOC 32) была создана компанией Symbian - совместным предприятием фирм Motorola, Ericsson, Nokia и Psion на базе подразделения Psion Software компании Psion. Позднее к ним присоединилась компании Matsuflowersa, Kenwood, Fujitsu, Siemens и другие.

Первый выпуск («релиз») EPOC 32 в апреле 1997 ознаменовал собой рождение нового поколения операционных систем, основанного на обширном опыте компании Psion в индустрии портативных мобильных устройств.

С 1991, серия устройств под общей маркой Psion Series 3 сделала персональный цифровой органайзер популярным и доступным устройством массового спроса. Новая ОС получила название SIBO (SIxteen-Bit Organiser), часто ее также называют SYMBIAN OS16.

В 1998-2000 гг. значительная часть системы была переписана с целью оптимизации кода для работы на устройствах с ограниченными ресурсами. Начиная с версии системы 9.x появился серьёзный механизм защиты - разграничение API в соответствии с правами приложений (capabilities). Основной язык разработки приложений - С++, имеется поддержка Java. Также существуют библиотеки PIPS для портирования приложений с других ОС.

В 2005 году вышла Symbian OS Series 60 3rd Edition, основанная на новом ядре EKA2, что привело к нарушению обратной совместимости с программами, написанными для предыдущих версий. На данный момент наиболее распространённой (по количеству устройств) версией является Symbian OS Series 60 3rd Edition и 5th Edition(Symbian^1).

11 февраля 2011 Nokia объявила о том, что Windows Phone 7 станет ключевой платформой для смартфонов, однако компания не планирует отказываться от платформ Symbian и MeeGo, которые развивала в последние годы. Symbian при этом станет франшизной.

Архитектура Symbian OS (на примере версии 7.0s)

Рис. 1. Архитектура Symbian OS

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

• 
  Kernel and Hardware Integration - ядро и аппаратная часть системы;
• 
  Base Services - базовые сервисы;
• 
  OS Services - сервисы операционной системы;
• 
  Application Services - пользовательские сервисы;
• 
  UI Frameworks - инфраструктура пользовательского интерфейса;
• 
  Java 2 ME - платформа Java 2 ME.

Ядро и аппаратная часть системы

Рис. 2. Уровень Kernel и Hardware Integration

Абстрактный уровень ядра и аппаратной части системы (Kernel and Hardware Integration) состоит из двух подсистем, изображенных на рис. 2. Ядро системы (Kernel Services) оптимизировано для работы на процессорах архитектуры ARM с эффективным управлением всех имеющихся сервисов системы. Ядро системы обеспечивает многопоточность работы, управление памятью и питанием, а также обеспечивает возможность переноса на любое аппаратное обеспечение.

Драйверы устройства (Device Driver) обеспечивают низкоуровневую поддержку программных контроллеров для следующих устройств:

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

Базовые сервисы

Рис. 3. Уровень Base Services

Базовые сервисы системы (Base Services) обеспечивают основной или базовый каркас для последющих компонентов Symbian OS . Уровень базовых сервисов состоит из двух подсистем: Low Level Libraries (Низкоуровневые библиотеки) и Fileserver (Файл сервер). На рис. 3. представлен базовый уровень.

Компонент Low Level Libraries содержит низкоуровневые библиотеки и утилиты, с помощью которых можно решать задачи в следующих областях:

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

Файл сервер требуется для корректной работы с файловыми системами. Поддерживаются типы носителей:

• 
  RAM (Random Access Memory)- оперативно-запоминающее устройство (ОЗУ), применяющееся для чтения и записи данных;
• 
  NOR flash;
• 
  NAND flash;
• 
  ММС-карта памяти;
• 
  SD-карта памяти.

Сервисы операционной системы

Сервисы операционной системы (OS Services) содержат набор компонентов инфраструктуры Symbian OS для работы с графикой, мультимедиа, криптографией, связью и так далее. Это полноценные микропрограммы, базовая составляющая которых основывается на предыдущих уровнях операционной системы. Уровень OS Services разделен на четыре подсистемы, с набором различных компонентов. На рис. 4 изображен уровень OS Services.

Рис. 4. Уровень OS Services

Сервис связи с компьютером (PC Connect Services) обеспечивает связь телефона с компьютером посредством специализированного программного обеспечения, а так же инструментальные средства разработчика (Toolkit) для создания программ на компьютере.

Графический сервис (Graphics Services) предусматривает работу с экраном и клавиатурой на основе- графической подсистемы, предоставляя прямой доступ к экрану, устройству ввода и сглаживанию графики. Все это происходит на основе HAL (Hardware Abstraction Layer - уровень аппаратной абстракции).

Сервис передачи данных (Comms Services) обеспечивает для Symbian OS инфраструктуру коммуникаций. Прежде всего, это телефония (Telephony), работа с сетью (Networking Services) и сервис связи с последовательным и инфракрасным портами, USB и Bluetooth.

Система телефонии предоставляет возможность работы со стандартами:

• 
  GSM (Phase2+),
• 
  GPRS (r4, Class В),
• 
  CDMA 2000 (lx),
• 
  EDGE (ECSD, EGPRS),
• 
  WCDMA(r4).

Сетевой интерфейс поддерживает протоколы связи:

• 
  TCP, IPv4, IPv6, MSCHAPv2;
• 
  IPSec;
• 
  TCP/IP;
• 
  множественная адресация.

В свою очередь сервис связи предусматривает работу с основными средствами связи:

• 
  IrDA;
• 
  Bluetooth.

Подсистема в уровне OS Services - это Generic Services (Общие сервисы), состоит из двух сервисов: Cryptography Services (Криптография) и Multimedia (Мультимедиа). Криптография отвечает за безопасность системы в области криптографии, управления сертификатами и инсталляции программного обеспечения на телефон. В криптографии поддерживаются стандарты:

• 
  DES; Q 3DEC;
• 
  RC2-128;
• 
  RSA;,
• 
  PKCS#7.

Система мультимедиа необходима для работы со звуком, видео и графикой (как 2D, так и 3D). Работа с этими компонентами осуществляется через соответствующие системные библиотеки. На рис. 5 представлена составляющая системы мультимедиа.

Рис. 5. Система мультимедиа

Создание трехмерных игр в Symbian OS возможно при соответствующей аппаратной поддержке и на основе OpenGL ES. Работа с 2D графикой построена через GDI (Graphics Device Interface - интерфейс графического устройства) системы Symbian. Также все телефоны под управлением Symbian OS поддерживают работу со звуком и видео.

Пользовательские сервисы

Уровень пользовательских сервисов (Applications Services) инкапсулирует различные механизмы, обеспечивающие пользователю работу с данными. Symbian OS содержит встроенный пакет приложений, таких как: календарь, заметки, будильник, передача SMS, доступ к электронной почте и так далее. Сервис пользовательских услуг состоит из четырех подсистем, изображенных на рис. 6.

Рис. 6. Уровень пользовательских сервисов

PIM (Personal Information Manager - персональный информационный менеджер) обеспечивает стандартные механизмы по работе с пользовательскими данными. Примером могут служить простой органайзер, записная книжка или офисные приложения, реализованные в Symbian OS . Имеется большой набор API для создания своих пользовательских программ.

Синхрониизация данных (Data Synchronization) построена на основе механизма ОМА SyncML 1.1, обеспечивающего синхронизацию данных по принципу сервер/клиент.

Передача сообщений (Messaging) поддерживает все основные виды сообщений: Также поддерживается работа по протоколам POP, SMTP/ШАР для передачи и приема, например, электронной почты (Browsing). Осуществляется поддержка WAP, HTTP, XHTTP, а системная библиотека имеет множество классов для создания своих программ.

Инфраструктура пользовательского интерфейса

Инфраструктура пользовательского интерфейса (UI Framework) - это система, на основе которой производители мобильных устройств могут создавать свой графический интерфейс на базе механизмов Symbian OS . Мудрым и взвешенным решением было разделение системы на ядро и графику. Инфраструктура пользовательского интерфейса состоит из двух компонентов. Первый - UI Applications Framework (Прикладная инфраструктура) предоставляет возможность в создании собственного пользовательского интерфейса, который вы можете наблюдать на своем телефоне. Второй - UI Toolkit (Инструментальные средства разработчика пользовательского интерфейса). На основе этих средств производители телефонов разрабатывают свои SDK, и с помощью которых программисты создают свои программы. Такой подход расширяет круг производителей, заинтересованных в портировании Symbian OS на свои модели телефонов.

Многозадачность и другие особенности ядра EKA2 в Symbian OS.

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

Android

Особенности платформы Android

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

• 
  Операционная система Android многопользовательская Linux система, где каждое приложение это, по сути, уникальный пользователь.
• 
  По умолчанию система присваивает каждому приложению уникальный идентификационный номер – пользовательский ID. При этом об этом ID знает только операционная система, для приложения же оно оказывается скрыто. После этого ОС выставляет разрешения для каждого файла в приложении, и, таким образом, только это приложение может обратиться к ним.
• 
  Каждый процесс в системе имеет свою собственную виртуальную машину, таким образом, код запускается в изоляции от других приложений.
• 
  По умолчанию каждое приложение запускает свой собственный Linux процесс. Android запускает процесс, когда компоненты приложения нуждаются в обработке, затем заканчивает процесс, когда ресурсы ему больше не нужны, или же когда ресурсы системы должны быть освобождены под другую задачу.

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

• 
  В рамках операционной системы есть возможность для двух разных приложений установить один и тот же ID, что даст возможность приложениям обращаться к файлам друг друга. Для экономии системных ресурсов у приложений с общим ID есть возможность выполняться в одном и том же процессе Linux и использовать общую виртуальную машину (приложения так же должны иметь одинаковый сертификат).
• 
  Также каждое приложение может запросить доступ к контактам пользователя, SMS сообщениям, носителям данных, камере, Bluetooth и пр. В таком случае все приложения должны получить подтверждение от пользователя на эти операции.

Android обладает широким спектром возможностей подключения, охватывающим Wi-Fi, Bluetooth и протоколы передачи данных через сотовую сеть (GPRS, EDGE, 3G и др.). В стек программного обеспечения Android входит и поддержка сервисов, основанных на определении местоположения (например, GPS), и акселерометров, поддержка видеокамеры.

Исторически двумя областями, где мобильные приложения отставали от своих настольных собратьев, были графика/мультимедиа и способы хранения данных. Android решает проблему графики благодаря встроенной поддержке 2-D и 3-D графики, включая библиотеку OpenGL. Задача хранения данных упрощается благодаря наличию в платформе Android популярной базы данных с открытым исходным кодом SQLite. На рисунке 1 показана упрощенная схема уровней программного обеспечения Android.

Всего, как видно из схемы, существует 5 уровней в архитектуре: уровень приложений, уровень каркаса приложений, уровни общих библиотек и виртуальной машины, и уровень ядра (Linux kernel 2.6).

Уровень приложений (Applications)

В состав Android входит комплект базовых приложений: клиенты электронной почты и SMS, календарь, различные карты, браузер, программа для управления контактами и много другое. Все приложения, запускаемые на платформе Android написаны на языке Java.

Уровень каркаса приложений (Application Framework)

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

Основой всех приложений является набор систем и служб:

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

2. Контент-провайдеры (Content Providers) – это службы, которые позволяют приложениям получать доступ к данным других приложений, а также предоставлять доступ к своим данным.

3. Менеджер ресурсов (Resource Manager) предназначен для доступа к строковым, графическим и другим типам ресурсов.

4. Менеджер извещений (Notification Manager) позволяет любому приложению отображать пользовательские уведомления в строке статуса.

5. Менеджер действий (Activity Manager) управляет жизненным циклом приложений и предоставляет систему навигации по истории работы с действиями.

Уровень среды исполнения (Android Runtime)

В состав Android входит набор библиотек ядра, которые предоставляют большую часть функциональности библиотек ядра языка Java. Платформа использует оптимизированную, регистр-ориентированную виртуальную машину Dalvik, в отличии от нее стандартная виртуальная машина Java – стек-ориентированная. Каждое приложение запускается в своем собственном процессе, со своим собственным экземпляром виртуальной машины. Dalvik использует формат Dalvik Executable (*.dex), оптимизированный для минимального использования памяти приложением. Это обеспечивается такими базовыми функциями ядра Linux, как организация поточной обработки и низкоуровневое управление памятью. Байт-код Java, на котором написаны ваши приложения, компилируются в dex-формат при помощи утилиты dx, входящей в состав SDK.

Уровень ядра Linux (Linux Kernel)

Android основан на ОС Linux версии 2.6, тем самым платформе доступны системные службы ядра, такие как управление памятью и процессами, обеспечение безопасности, работа с сетью и драйверами. Также ядро служит слоем абстракции между аппаратным и программным обеспечением.используется Linux Kernel 2.6.

Android включает в себя набор библиотек, написанных на C/C++, используемые различными компонентами системы. Разработчики так же могут воспользоваться этими библиотеками.

Архитектура приложений

Как уже говорилось, Android работает поверх ядра Linux. Android-приложения пишутся на языке программирования Java и выполняются в виртуальной машине (VM). Важно отметить, что виртуальная машина – это не JVM, как можно было бы ожидать, а открытая технология Dalvik Virtual Machine. Как было сказано выше, каждое приложение Android запускается внутри экземпляра Dalvik VM, который, в свою очередь заключен в пределах управляемого ядром Linux процесса, как показано на рисунке 2

Компоненты приложения

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

• 
  Activities (действия)

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

• 
  Services (сервисы)

Services – компонент, запускающийся в фоновом режиме для выполнения длинных операций или для выполнения работы удаленных процессов. Не поддерживает пользовательского интерфейса. К примеру, сервис может проигрывать музыку в фоновом режиме, в то время как пользователь находится в другом приложении, или передавать данные по сети не прерывая работы пользователя с текущим activity. Другие компоненты могут запускать service и управлять им (например тот же activity).

• 
  Content providers (источники данных)

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

• 
  Broadcast receivers (приемники)

Broadcast receiver – компонент отвечающий за получение глобальных событий системы. Таковыми могут быть, к примеру, отключение экрана, разрядка батареи, входящий звонок и т.д. Приложения так же могут инициализировать подобные события. Это может понадобится для того, чтобы позволить другому приложению узнать об успешной загрузке данных на устройство и об их доступности для него. Кроме того этот компонент не имеет пользовательского интерфейса, однако может создавать окно предупреждения при наступлении события. Если в общем, то broadcast receiver своего рода «порт» для других компонентов и он предназначен для выполнения минимального объема работ. К примеру, он может инициализировать services для выполнения некоторой работы, привязанной к определенному событию.

Отличительной особенностью OC Android является то, что приложения могут запускать компоненты других приложений. Однако приложения отделены друг от друга жесткими правами доступа на каждый ресурс, и потому не могут напрямую обращаться к чужим ресурсам, даже если эти ресурсы помечены как общедоступные. Однако ядро может обращаться ко всем приложениям и в т.ч. к их компонентам. Поэтому, чтобы приложению 1 получить компонент приложения 2 ему придется сначала обратиться к ядру. Ядро решит, можно ли передать приложению 1 компонент приложения 2 (в случае, если изначально архитектура приложения была рассчитана на запуск отдельных его компонентов другим ПО) и передаст, если такая возможность имеется.

На рисунке выше отмечен порядок действий:

1. 
   Приложение 1 обращается к ядру с просьбой выделить для него некоторые ресурсы из приложения 2
2. 
   Ядро обращается к приложению 2
3. 
   Ядро запускает и получает Activities приложения 2
4. 
   Ядро возвращает запущенное Activities приложению1