Дипломная работа «Распределенная информационно-управляющая система Поток-С» (стр. 3 )

2 ПОСТАНОВКА ЗАДАЧИ

Дипломная работа была выполнена в рамках проекта по модернизации существующей (и эксплуатирующейся) распределенной информационной системы ПТС-1 для филиала ПТС (Петербургские Телефонные Сети) ОАО “Северо-Западный Телеком”. Проект предусматривал:

-  обновление существующего ПО и СУБД;

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

-  обновление аппаратного обеспечения на всех уровнях системы;

-  проведение различных сопутствующих экспериментов;

-  монтажные и пуско-наладочные работы.

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

Задачи дипломной работы:

-  разработка специализированного низкоуровнего программного обеспечения контроллера ASK-Lab;

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

-  проведение различных поддерживающих экспериментов на объектах системы.

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

2.1 Описание проблематики

В филиале ПТС ОАО “Северо-Западный Телеком” с 2000 г. запущена в эксплуатацию распределенная информационная система (РИС) ПТС-1. Система обеспечивает возможность мониторинга режима теплоснабжения зданий автоматических телефонных станций (АТС) путем получения данных с датчиков теплосчетчиков. Одной из ключевых задач системы является предупреждение выхода из строя телекоммуникационного оборудования.

Здания АТС расположены в разных районах города. Эти здания отапливаются с использованием городских ТЭЦ и оборудованы средствами учета и регулировки подачи горячей воды в отопительную систему АТС. В настоящее время количество объектов порядка 100.

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

Контроль параметров теплоносителя на объектах осуществляется диспетчером цеха автоматизированного учета энергии (АУЭ) ПТС. Параметры, измеряемые и вычисляемые теплосчетчиками:

-  температура и давление воды;

-  объемный либо массовый расход воды;

-  перенесенная тепловая энергия в подающем и обратном трубопроводе (на входе и выходе системы отопления АТС).

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

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

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

2.2 Общие требования к системам класса ИУС (СДМУ)

Требования к системам дистанцион­ного мониторинга и управления (СДМУ) [5] в зависимости от сферы их применения могут, естественно, отли­чаться. Типовая СДМУ должна обеспе­чивать:

-  немедленное получение в едином диспетчерском пункте системы (ДПС) сигналов тревоги при возникнове­нии аварийных ситуаций на объекте,

-  получение на мнемосхеме пульта диспетчера (ПД) ДПС в режиме реального време­ни полной информации о технологи­ческом процессе и состоянии обору­дования объекта;

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

-  возможность оперативного вмеша­тельства из ДПС в работу оборудова­ния объекта при возникновении не­штатных ситуаций;

-  контроль прохождения команд уп­равления и генерацию сигналов тре­воги при их невыполнении;

-  возможность анализа работы отдель­ных объектов или группы объектов по любым технологическим параме­трам за произвольный промежуток времени;

-  возможность дистанционной наст­ройки и диагностики технологичес­ких контроллеров (ТК) объектов;

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

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

Аппаратура СДМУ, устанавливаемая непосредственно на объектах, должна обладать возможностью гибкого кон­фигурировании в зависимости от тех­нических особенностей объекта. Осно­вой такой аппаратуры, как правило, являются технологические контролле­ры (ТК). Каждый ТК должен иметь возможность подключения:

-  аналоговых датчиков для контроля температуры, давления, уровня, положения исполнительных механиз­мов и т. п.;

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

-  измерительных приборов, имеющих стандартный интерфейс и открытые протоколы связи;

-  контроллеров локальных систем авто­матики, имеющих стандартный интерфейс и открытые протоколы связи;

-  дискретных силовых устройств со­пряжения с исполнительными устройствами и механизмами.

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

2.3 Особенности построения и концепция РИУС ПоТок-С

При разработке архитектуры РИУС ПоТок-С, наряду с общими требованиями, изложенными ранее, были учтены дополнительные требования заказчика.

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

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

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

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

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

Структура системы представлена на рисунках 2.1–2.2. В системе имеется возможность использования четырех типов АРМов. В настоящее время объекты ПТС можно разделить на две группы по признаку наличия автономного контура регулирования. Автономное регулирование тепловым режимом ряда станций осуществляется контроллером ECL Comfort 300 (DANFOSS). Верхний уровень системы включает в себя две подсистемы: чисто информационную ПТС-1 и информационно-управляющую ПТС-2, обслуживающую станции с контуром автономного регулирования.

С учетом опыта эксплуатации предыдущей версии системы, использование которой становится проблематичным при числе узлов порядка 100, в концепцию проекта РИУС ПоТок-С заложено требование обеспечения возможности развития системы по числу контролируемых объектов. Для реализации этого требования в подсистеме ПТС-1 используется СУБД ORACLE и мультиплицированный модемный канал.

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

Эти требования предопределили необходимость использования на теплопунктах станций, входящих в подсистему ПТС-2, контроллеров ASK-Lab верхнего уровня. Этот контроллер был разработан в СКБ Государственного Университета Аэрокосмического Приборостроения

Узлы теплоснабжения, входящие в подсистему ПТС-2 снабжены автоматизированными задвижками (рисунок 2.2а), управление которыми может осуществляться как теплорегулятором ECL COMFORT-300 в автономном режиме, так и в режиме ручного управления с АРМ инженера. Контроллер ASK-Lab кроме обеспечения работы с теплорегулятором ECL COMFORT-300, обеспечивает работу с теплосчетчиком. Обмен с верхним уровнем системы осуществляется по унифицированному протоколу ASK bus 3.1.

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

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

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

2.4 Требования к программному обеспечению системы

В рамках дипломной работы автором разрабатывалось следующее программное обеспечение:

-  специализированное низкоуровнеаое программное обеспечение для контроллера ASK-Lab;

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

2.4.1 Требования к низкоуровнему программному обеспечению

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

-  возможность обращения к 3-м устройствам по одной линии связи (контроллер ASK-Lab, теплосчетчик и теплорегулятор ECL Comfort 300);

-  дистантная и местная настройка параметров контроллера;

-  энергонезависимое хранение параметров контроллера;

-  обмен данными с ПК по линии связи (телефонная линия или прямое соединение контроллера и ПК);

-  использование протокола ASK bus 3.1 в качестве протокола сетевого и транспортного уровня для обмена данными с ПК;

-  обеспечение режима “прозрачности” (поддержка работы программного обеспечения предыдущей версии системы (РИС ПТС-1) для обмена данными с теплосчетчиками)

-  защита данных (использование алгоритма ГОСТ для кодирования-декодирования команд управления и особо важных данных);

-  считывание данных (параметров) с теплосчетчиков и теплорегулятора ECL Comfort 300;

-  изменения параметров теплорегулятора ECL Comfort 300;

-  управление силовыми устройствами (до 8-и);

-  протоколирование событий;

-  контроль времени выполнения задач.

2.4.2 Требования к высокоуровнему программному обеспечению

Разрабатываемое высокоуровневое программное обеспечение для системы видеоконтроля за объектами управления предназначено для работы совместно с модулем IP-видеокамеры [11] и должно обеспечить выполнение следующих функций:

-  прием видео - и аудио - потоков с IP-видеокамеры на ПК, с воспроизведением изображения и звука;

-  управление параметрами изображения и звука;

-  возможность переключения между подключенными к IP-видеокамере источниками видеосигнала (до 4-х камер);

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

-  возможность записи аудио-видео потока на жесткий диск ПК;

-  возможность управления режимами работы программного обеспечения с помощью “горячих” клавиш.

-  Аппаратной эмулятор для данного типа контроллера;

-  ПК для создания и отладки ПО;

Контроллер выбирается исходя из требований, предъявляемых к функциональности данного устройства. Требования к функциям контроллера были приведены в пункте 2.4.1. Для выбора контроллера возможно несколько вариантов.

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

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

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

Как показал обзор существующих решений по контроллерам и встраиваемым компьютерам (смотри подраздел 1.2), среди всего многообразия предлагаемых и доступных устройств нет готовых решений на базе одного устройства. Как правило, основным ограничивающим фактором является требование на наличие 3-х интерфейсов RS-232 и до 8-и каналов дискретного вывода в выбираемом контроллере.

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

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

Контроллер ASK-Lab построен на базе 4-х микропроцессоров PIC18F458, поэтому программатор следует выбирать из устройств, способных программировать микропроцессоры семейства PIC18XXX. В настоящее время доступны следующие программаторы: PICSTART Plus, MPLAB ICD 2, PRO MATE II. Программатор PRO MATE II сочетает в себе невысокую стоимость и возможность программировать различные типы и корпуса микропроцессоров семейства PIC16XXX и PIC18XXX. Поэтому PRO MATE II был выбран в качестве программатора.

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

В данном случае требуется выбрать аппаратный эмулятор для микропроцессоров PIC18F458, так как логика работы контроллера ASK-Lab обеспечивается работой микропроцессоров PIC18F458. В настоящее время доступны следующие аппаратные эмуляторы: MPLAB ICD 2, MPLAB ICE 2000, MPLAB ICE 4000. Эмуляторы MPLAB ICE отличаются стабильностью работы и большой функциональностью. Эмулятор MPLAB ICE 4000 стоит дороже и имеет некоторые функции, которых нет у MPLAB ICE 2000, и которые не используются при разработкеПО в данном проекте. Поэтому MPLAB ICE 2000 был выбран в качестве аппаратного эмулятора.

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

Разработка потребует меньше ресурсов и времени, если она будет вестись на IBM PC, вследствие наличия значительного опыта разработки на ПК именно этой архитектуры, наличия достаточного количества программного инструментария разработчика, а также печатной и электронной литературы.

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

Для разработки низкоуровнего ПО контроллера был выбран ПК следующей конфигурации:

-  Процессор: Intel Pentium 3;

-  Тактовая частота: 600 МГц;

-  Объем оперативной памяти: 128 Мб;

-  Объем дискового пространства HDD: 10 Гб;

-  Видеокарта: встроенная;

-  Звуковая карта: нет;

-  Монитор: 15”.

3.1.1.2 Выбор метода разработки ПО и среды программирования

В работе [8] приведена классификация и сравнительный анализ методов разработки специализированного прикладного ПО.

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

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

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

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

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

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

мОСРВ имеют жесткие ограничения по ресурсам микропроцессора. Так, например, считается, что эффективным будет использование той мОСРВ, которая отнимает не более 30% объема памяти программ и не более 10% процессорного времени при выполнении. В нашем случае выбран микропроцессор PIC18F458 (краткие технические характеристики приведены в Приложении Б). Для данного микропроцессора объем памяти программ составляет 32 Кбайта, объем памяти данных 1 Кбайт, тактовая частота до 40 МГц.

Помимо аппаратных ограничений при выборе конкретной мОСРВ, следует обратить внимание на доступность мОСРВ, практики ее использования и удобства написания ПО под нее. В СКБ ГУАП разработана мОСРВ А3 для микропроцессоров семейства PIC18XXX. мОСРВ А3 сочетает в себе малую требовательность к аппаратным ресурсам микропроцессора, широкие возможности по диспетчеризации задач и простоту использования. Имеется специализированный инструментарий Конструктор А3 для описания ПО под данную мОСРВ. Состав библиотек и драйверов постоянно обновляется. Конструктор А3 позволяет описать структуру взаимосвязей модулей системы, определить временные интервалы и условия запуска задач, а также описание межзадачного обмена. Код ядра мОСРВ A3 генерируется Конструктором А3 при трансляции проекта. Проект транслируется в проект для среды программирования Microchip MPLab IDE v6.xx. В Приложениях В, Г приведено краткое описание мОСРВ А3 и Конструктора А3.

В настоящее время накапливается опыт использования мОСРВ А3 для встраиваемых систем управления. А3 была успешно применена в качестве мОСРВ для многотарифного счетчика электроэнергии ЦЭ27XX. Учитывая простоту использования А3, эффективность ее работы и доступность инструментария, в качестве базовой мОСРВ была выбрана А3.

В качестве среды программирования была выбрана Microchip MPLab IDE v6xx (далее MPLab), т. к. именно в данную среду может быть транслирован проект из Конструктора А3. Данная среда программирования поддерживает все микропроцессоры семейства PICXXX, а также все типы программаторов и аппаратных эмуляторов, перечисленных выше. MPLab имеет удобный интерфейс, качественные средства отладки и мониторинга памяти и других ресурсов.

3.1.2 Разработка структуры ПО

Выше упоминалось, что контроллер ASK-Lab построен на базе 4-х микропроцессоров PIC18F458. На этих микропроцессорах построена внутриплатная одномастерная сеть на базе интерфейса I2С. Мастером сети является один из микропроцессоров, все остальные работают по отношению к мастеру одинаково как периферия. Каждый микропроцессор имеет набор стандартных аппаратно реализованных коммуникационных интерфейсов с оптической развязкой. Кроме стандартных коммуникационных интерфейсов, контроллер имеет внешний разъем, на который выведены порты с периферийных микропроцессоров. Эти особенности аппаратной составляющей контроллера необходимо учитывать при разработке ПО. Структурная схема контроллера ASK-Lab приведена на рисунке 3.1.

Программное обеспечение контроллера ASK-Lab было разработано на основе мОСРВ A3. Ядро мОСРВ, драйвера и библиотеки являются неизменной частью каждой системы. Для удобства проектирования систем под мОСРВ A3 используется специальное инструментальное программное обеспечение Конструктор А3.

Структура ПО контроллера ASK-Lab представлена на рисунке 3.2.

Рисунок 3.2 – Структура ПО контроллера ASK-Lab

Код ядра мОСРВ A3 генерируется программным обеспечением Конструктор А3 при трансляции проекта.

Модули с кодами драйверов устройств собраны в универсальную библиотеку драйверов. Библиотека предназначена для использования в составе мОСРВ A3. Основной функцией библиотеки является программная поддержка аппаратных модулей микропроцессора PIC18 и поддержка аппаратно-программных интерфейсов между микропроцессором и другими устройствами. Описание библиотеки драйверов приведено в

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

Функции, предъявляемые к ПО контроллера были описаны выше. Учитывая специфику аппаратной части контроллера ASK-Lab, функции разделяются между микропроцессорами, входящими в его состав (условные обозначения микропроцессоров: PIC_Master – мастер сети, PIC_SPT и PIC_Danf – переферийные микропроцессоры). При написании ПО всей системы в целом следует особое внимание уделить вопросу межпроцессорного взаимодействия.

Функции микропроцессора PIC_Master;

-  Обмен с ПК по интерфейсу RS-232 и протоколу Ask-Bus v 3.1 (выполнение команд, принятых с ПК, поддержка информационного обмена между ПК и процессорами PIC_SPT и PIC_Danf);

-  Обмен с микропроцессорами PIC_SPT и PIC_Danf по интерфейсу I2С (PIC_Master – мастер сети);

-  Реализация процедуры ввода пароля (используется клавиатура и ЖК-индикатор, хранение пароля в энергонезависимой памяти EEPROM);

-  Ведение журнала событий (хранение в памяти программ);

-  Преобразование данных согласно алгоритму ГОСТ при выполнении команд, требующих разграничения доступа.

В ПО микропроцессора PIC_Master (и всех остальных) были использованы существующие модули и библиотеки (системное ПО) и разработаны новые (прикладное ПО). Список всех модулей, входящих в состав ПО микропроцессора PIC_Master представлен в таблице 3.1.

Таблица 3.1 – Список модулей, входящих в состав ПО микропроцессора PIC_Master

Примечания к таблице:

Из за большого объема этот материал размещен на нескольких страницах: 1 2 3 4 5