(doc, 1.6 Мб)

На правах рукописи
ОЛЕНЕВ Валентин Леонидович
ПРОЕКТИРОВАНИЕ ПРОГРАММНЫХ МОДЕЛЕЙ СЕТЕВЫХ
ПРОТОКОЛОВ ДЛЯ ВСТРОЕННЫХ СИСТЕМ
Специальность 05.13.11 – Математическое и программное обеспечение вычислительных машин, комплексов и компьютерных сетей
АВТОРЕФЕРАТ
диссертации на соискание ученой степени
кандидата технических наук
Санкт-Петербург − 2011
Работа выполнена на кафедре «Информационных систем» в Федеральном государственном бюджетном образовательном учреждении высшего профессионального
образования «Санкт-Петербургский государственный университет аэрокосмического приборостроения» (ГУАП).
Научный руководитель:
доктор технических наук
Шейнин Юрий Евгеньевич
Официальные оппоненты:
доктор технических наук, профессор
Водяхо Александр Иванович
кандидат технических наук, доцент
Щекин Сергей Валерьевич
Ведущая организация
Санкт-Петербургский институт
информатики и автоматизации РАН
Защита состоится «____» __________ 2011 г. в ______ часов на заседании диссертационного совета Д 212.233.02 при Федеральном государственном бюджетном образовательном учреждении высшего профессионального образования «СанктПетербургский государственный университет аэрокосмического приборостроения »
по адресу:
190000, Санкт-Петербург, ул. Б. Морская, 67, ГУАП.
С диссертацией можно ознакомиться в библиотеке ГУАП.
Автореферат разослан «____» __________ 2011 г.
Ученый секретарь
диссертационного совета
Осипов Л.А
доктор технических наук, профессор
2
ОБЩАЯ ХАРАКТЕРИСТИКА РАБОТЫ
Актуальность темы. Встроенные системы стали использоваться повсеместно: в автомобилестроении, мобильной индустрии и других вещах, без которых жизнь современного человека уже сложно представить. Многие встроенные системы состоят не только из
одного процессора, а могут содержать целые сети-на-кристалле. Составляющие элементы
таких сетей должны взаимодействовать между собой, руководствуясь жесткими правилами
для достижения требований энергопотребления, физических размеров и стоимости, выдвигаемых к встроенной системе. Такие правила называют протоколами для встроенных систем. Разработка протоколов передачи данных для таких систем является очень трудоемкой задачей, состоящей из нескольких этапов: она начинается с концептуального проектирования системы и заканчивается сбором устройства, работающего по заданному протоколу. Однако в процессе разработки спецификации протокола зачастую возникают моменты,
когда необходимо выбирать тот или иной путь решения проблемы, анализировать различные подходы к реализации и проверять спецификацию на ошибки разработчиков. Именно
поэтому программное моделирование становится все более необходимым элементом проектирования протоколов передачи данных для встроенных систем. Оно позволяет обнаружить ошибки на ранних этапах разработки спецификаций, значительно уменьшить само
время разработки, а так же в дальнейшем использовать полученные программные модели
для тестирования реальных плат. Программное моделирование протоколов ведется во многих крупных компаниях, таких как Nokia, STErricsson, Qualcomm, в работах, курируемых
Европейским Космическим Агентством (ESA), в разработках авиационных компаний и т.д.
Однако каждая компания ведет разработку своими путями. Методы проверки на программных моделях широко используются и описаны в работах таких авторов как Э. М.
Кларк, О. Грамберг и Д. Пелед, Ю.Г. Карпов, в результатах исследований компании Cadence. Однако на данный момент не существует четко сформулированных и описанных
формальных методов организации программного обеспечения для моделирования стеков
протоколов встроенных систем, что осложняет их разработку и реализацию. Поэтому, разработка методики построения программного обеспечения для написания программных моделей протоколов передачи данных для встроенных систем и верификации этих программных моделей является актуальной проблемой.
В данной диссертации предлагается использовать широко используемый в последнее время подход компонентного проектирования, описанный в работах Э. Дж. Брауде,
Кулямина В.В., Э. Ванга и К. Квана, для разработки набора стандартных модулей, предназначенного для построения архитектурных диаграмм программных моделей протоколов
встроенных систем. А также предлагается разработать методику, позволяющую строить
архитектурные диаграммы на основе этого набора модулей, что позволит значительно
упростить процесс проектирования программной модели. Кроме того, предлагается осуществлять верификацию полученных архитектурных диаграмм на предмет ошибок по3
строения и организации взаимодействий между модулями, пользуясь теорией сетей Петри
и в частности, теорией раскрашенных сетей Петри, развитой и доработанной К. Енсеном.
Результатом такой работы может быть сгенерированный из полученной архитектурной
диаграммы скелет программной модели на языке SystemC.
Целью работы является разработка методов и алгоритмов проектирования программных моделей сетевых протоколов для встроенных систем. Разработка методики проектирования программного обеспечения для реализации и верификации архитектурных
диаграмм программных моделей стеков протоколов передачи данных, обеспечивающей
повышение эффективности разработки и корректности программных моделей.
Для достижения поставленной цели в работе решались следующие задачи:
 разработка метода проектирования и анализа программных моделей протоколов передачи данных;
 разработка набора типовых модулей для построения архитектурных диаграмм программных моделей протоколов встроенных систем;
 разработка метода организации межмодульных взаимодействий в программных моделях сетевых протоколов;
 разработка метода перехода от архитектурной диаграммы программной модели к
интерпретирующей ее раскрашенной сети Петри;
 разработка алгоритма разметки раскрашенной сети Петри для осуществления верификации архитектурных диаграмм программных моделей;
 исследование и разработка метода перехода от раскрашенной сети Петри к эквивалентной ей классической сети Петри в целях применения методов анализа классических сетей Петри к раскрашенным сетям;
 разработка методики верификации архитектурной диаграммы на основе данных, полученных при анализе набора классических сетей Петри.
Методы исследования. Для решения поставленных задач использовались методы
теории имитационного моделирования, теорий сетей Петри и раскрашенных сетей Петри,
методы теории программирования и принципы объектно-ориентированного и компонентного программирования, методы теории множеств, теории комплектов.
Научной новизной обладают следующие результаты работы:
1. метод проектирования архитектурной диаграммы программной модели протокола передачи данных для встроенных систем по его спецификации;
2. набор модулей для проектирования архитектурных диаграмм программных моделей протоколов передачи данных для встроенных систем;
3. метод построения раскрашенной сети Петри на основе архитектурной диаграммы программной модели;
4. алгоритм разметки раскрашенной сети Петри для осуществления анализа движения фишек при помощи деревьев достижимости;
4
5. метод верификации архитектурной диаграммы программной модели протокола
на основе результатов анализа сетей Петри.
Практическая значимость диссертации заключается в том, что в ней предложена
методика построения программного обеспечения для разработки программных моделей
протоколов и стеков протоколов передачи данных во встроенных системах, обеспечивающая упрощение и ускорение этого процесса разработки. Для апробации результатов работы был разработан программный комплекс ESPMS, реализующий методы и алгоритмы,
описанные в данной диссертационной работе.
Внедрение и реализация результатов работы. Основные исследования и результаты диссертационной работы использованы в Институте высокопроизводительных компьютерных и сетевых технологий Государственного Университета Аэрокосмического
Приборостроения для разработки программных моделей протоколов передачи данных для
таких компаний как Nokia и ОАО «НИИ Авиационного оборудования». Результаты внедрения подтверждены соответствующими актами.
Апробация результатов работы. Основные положения и результаты диссертации
докладывались и обсуждались на конференции Cadence CDNLife (2008 г.), Научных сессиях ГУАП (2008, 2009, 2010 гг.), а также международных конференциях FRUCT в 2009 и
2010 гг.
Публикации. По теме диссертации опубликовано семнадцать печатных работ, в том
числе две статьи в рецензируемых журналах по перечню ВАК.
1.
2.
3.
4.
Основные положения, выносимые на защиту:
Метод перехода от спецификаций протоколов передачи данных к архитектурным
диаграммам программных моделей этих протоколов, составленных из набора типовых модулей;
Метод формального описания архитектурных диаграмм программных моделей раскрашенными сетями Петри;
Алгоритм разметки раскрашенных сетей Петри для осуществления анализа движения фишек по сети Петри методом построения деревьев достижимости;
Метод верификации архитектурной диаграммы программной модели на основе результатов анализа достижимости набора классических сетей Петри, эквивалентных
раскрашенной сети Петри по поведению.
Объем и структура работы. Диссертационная работа состоит из введения, списка
используемых сокращений, четырех глав, заключения, списка использованных источников
и трёх приложений. Диссертация содержит 144 страницы машинописного текста, 56 рисунков и 16 таблиц, а также приложения объемом 38 страниц, включая 10 рисунков и 3
таблицы. В списке использованной литературы 119 наименований.
5
КРАТКОЕ СОДЕРЖАНИЕ РАБОТЫ
Во введении обоснована актуальность выбранной темы, определена цель и сформулированы решаемые в работе задачи. Перечислены новые научные результаты, полученные при выполнении работы, показаны практическая значимость и апробация работы,
описаны внедрение и реализация результатов. Приведены основные положения, выносимые на защиту.
В первой главе диссертации дано понятие встроенных систем и разрабатываемых
для них сетевых протоколов, а также описан сам процесс разработки этих протоколов.
Встроенной системой называют специализированную компьютерную систему
управления, встроенную непосредственно в устройство, которым она управляет. Она основана на работе микропроцессоров и спроектирована таким образом, что конечный пользователь не может перепрограммировать ее.
Сетевым протоколом называют набор правил, а также технических процедур, которые регулируют порядок и позволяют осуществлять соединение и обмен данными между
двумя и более включёнными в сеть устройствами. Сетевые протоколы, проектируемые для
межкристальных коммуникаций во встроенных системах, ориентированы на минимальное
энергопотребление, минимальные аппаратные затраты, высокую точность и скорость передачи данных, не высокую стоимость реализации. Протоколы передачи данных по своей
сути являются параллельными системами, поскольку ориентированы на одновременное
выполнение нескольких задач на разных уровнях. Например, независимо друг от друга и
параллельно работают сервисные точки доступа между уровнями, параллельно работают
сами уровни. Данные, передаваемые на удаленное устройство и принимаемые от него, тоже передаются параллельно, принимающая и передающая части сетевого устройства тоже
работают независимо и параллельно. Далее в диссертации под термином протокол подразумеваются протоколы для межкристальных коммуникаций во встроенных системах.
Также в первой главе диссертации дано понятие программной модели. Программная
модель является представлением объекта, системы или понятия в форме, отличной от реальной, но приближенной к алгоритмическому описанию, включающей набор данных, характеризующих свойства системы и динамику их изменения со временем. Исходя из параллельности протоколов, сделан вывод, что программные модели протоколов передачи
данных для встроенных систем являются параллельными программными системами. В работе дано понятие верификации и проверки проектируемых сетевых протоколов на программной модели.
В первой главе показано место программного моделирования в процессе разработки
стеков протоколов передачи данных на различных этапах проектирования, показана сложность и трудоемкость этих процессов. Сформулированы требования к языку проектирования и написания программных моделей протоколов, основываясь на которых был выбран
язык проектирования SystemC.
6
На основе проведенного анализа в первой главе показано, что на данный момент не
существует четко сформулированных и описанных методов организации программного
обеспечения для моделирования стеков протоколов для встроенных систем, что осложняет
их разработку и реализацию. Программные модели разрабатываются каждый раз полностью с нуля и абсолютно разными способами. Зачастую выбранные способы являются не
самыми удобными. Отсутствие формализованных подходов и методик написания подобного программного обеспечения в значительной степени усложняет процесс проектирования и тестирования встроенных систем. Разработка методов и алгоритмов проектирования
программных моделей могла бы ускорить работу и облегчить процесс разработки.
Ставится задача создания метода компонентного проектирования программных моделей протоколов, позволяющего строить программные модели протоколов передачи данных на основе набора типовых модулей и верифицировать эти модели на предмет ошибок
построения. Процесс написания программной модели включает проектирование архитектурной диаграммы, на которой будут присутствовать все необходимые модули и межмодульные связи. Следуя определению, данному П. Клементсом, архитектурной диаграммой
называется описание составляющих элементов программы, их внешних свойств и установленных между ними отношений. Внешними свойствами называются те предположения,
которые сторонние элементы могут выдвигать в отношении данного элемента – в данном
случае это интерфейсы, предоставляемые модулем. Таким образом, исходя из требований
к архитектурным диаграммам, при проектировании должны быть определены их программные элементы и приведена информация об их взаимоотношениях, в состав которой
должен входить целый ряд структур, каждая из которых должна решать свои определенные задачи. Архитектурная диаграмма ориентирована на независимую и параллельную работу каждого из модулей. При приходе данных в интерфейс модуль начинает выполняться,
поэтому данные, идущие по архитектурной диаграмме двумя разными путями, обрабатываются параллельно и независимо.
При построении архитектурной диаграммы указывается задача, решаемая каждым
модулем, но не алгоритм ее решения. То есть на архитектурной диаграмме отображается
модуль, цель которого выполнить определенную задачу протокола, описанную в спецификации. Из этой спецификации известно, какие данные поступают на вход модуля, и какие
должны получиться на выходе. При этом алгоритм работы модуля при проектировании архитектурной диаграммы не описывается. Количество модулей на архитектурной диаграмме обусловлено количеством задач, выполняемых протоколом, каждая из которых описана
в спецификации. Типы модулей также определяются в зависимости от задачи, которую
этот модуль должен выполять в рамках модели. Исходя из спецификации протокола, определяются требуемые данные, которые поступают на уровень протокола или в модуль. Зная
задачу, выполняемую этим модулем, и отталкиваясь от описания этой задачи в спецификации, определяются данные, которые являются для модуля выходными. Взаимосвязи между
7
модулями расставляются, основываясь на связях между задачами, выполняемыми протоколом. Если после выполнения одной задачи над данными, они обрабатываются следующей задачей, то между модулями архитектурной диаграммы, соответствующими этим задачам, ставится связь, передающая нужные данные. Так формируются маршруты следования данных между модулями.
На основе такой архитектурной диаграммы в дальнейшем генерируется «скелет»
программной модели. Скелетом программной модели называется код, полученный (возможно, автоматически) на основе архитектурной диаграммы; он включает в себя описания
модулей, портов, интерфейсов и методов, отвечающих за передачу данных между модулями. Вышеописанный метод приведен в следующей главе диссертации. На основе скелета
программной модели может писаться код, описывающий алгоритмы работы каждого из
модулей.
Вторая глава начинается с описания основных принципов компонентного проектирования. Даются понятия архитектурного проектирования программных моделей. Приведено описание принципа модульности, который предписывает организовывать сложную
систему в виде набора более простых систем. Основываясь на этом, дано понятие компонента или модуля программной модели протокола и приведено описание типа, к которому
относятся компоненты, разработанные в данной диссертационной работе. На основе этих
свойств определен набор модулей, необходимых и достаточных для программного моделирования выделенного класса протоколов.
Также во второй главе определен ряд свойств спецификаций протоколов, к которым
могут быть применены методы, описанные в данной диссертации:
1. Моделируемый протокол должен быть описан по слоям или составлять целиком
один уровень;
2. Между уровнями могут быть описаны сервисные точки доступа;
3. Спецификация протокола должна описывать структуру передаваемых данных
относительно каждого уровня;
4. Спецификация должна содержать описание основных функций протокола, описанных для каждого из уровней.
Под данную классификацию подходит большинство стандартов для стеков протоколов передачи данных встроенных систем.
Разработан метод перехода от спецификации стандарта протокола передачи данных
к архитектурной диаграмме программной модели этого протокола. Метод позволяет составить архитектурную диаграмму протокола по слоям (уровням) при помощи предложенного
в работе набора типовых модулей: модуль инициализации (IM), стандартный модуль (CM),
симплексный канал (SC), дуплексный канал (DC), сервисная точка доступа (SAP). Взаимодействие модулей осуществляется посредством портов и интерфейсов.
8
Множество модулей, необходимых для реализации программных моделей протоколов передачи данных для встроенных систем выглядит следующим образом:
M={IM, CM, SC, DC, SAP}
Каждый модуль имеет порты (
) и интерфейсы (
), которые представляют из се-
бя структуры, описанные в языке SystemC (sc_port и sc_interface). Каждый интерфейс описывает ряд методов, определенных в модуле, которые могут быть вызваны на исполнение
через порт удаленного модуля, связанный с данным интерфейсом.
Модуль инициализации IM предназначен для инициализации подмодулей, то есть
использование модуля инициализации позволяет применять вложенность архитектурной
диаграммы. Это дает возможность структурировать архитектурную диаграмму программной модели и логически разбивать ее на уровни моделируемого протокола. Пример использования модуля инициализации показан на рис. 1.
Рис.1 Пример использования модуля инициализации
Модуль не учавствует в процессе передачи данных по модели, не имеет входов и
выходов (портов и интерфейсов).
Стандартный модуль CM может иметь от нуля до нескольких входов и выходов (N
портов и M интерфейсов). Особенности работы каждого CM (функциональность) задаются
разработчиком в дальнейшем написании соответствующей программы на языке SystemC.
Модуль показан на рис. 2.
...
...
Рис. 2 Стандартный модуль
Предикат срабатывания модуля обозначим RCM.
RCM(data1, data2,…, datan) = (data1  Ø)  (data2  Ø)  ...  (datan  Ø) ,
где datai – данные, поступившие на i-й интерфейс модуля. То есть срабатывание модуля происходит при поступлении данных на вход одного или нескольких интерфейсов.
Модуль симплексного канала SC, рис. 3, принимает и передает данные одного или
нескольких типов в одном направлении. Объекты передаются через канал путем записи в
очередь FIFO и чтения из нее. Используется для моделирования передачи данных между
9
устройствами или какими-то отдельными модулями, в которых требуется накопление данных.
Рис. 3 Симплексный канал
Предикатом срабатывания модуля обозначим RSC.
RSC(data) = ( data  Ø ),
где data – данные, поступившие на интерфейс модуля. То есть срабатывание модуля
происходит при поступлении данных на вход интерфейса. Затем данные записываются в
очередь FIFO.
Модуль дуплексного канала DC, рис. 4, принимает и передает данные одного или
нескольких типов в обоих направлениях. Объекты передаются через канал путем записи в
очередь FIFO и чтения из неё. Используется для моделирования передачи данных между
устройствами или какими-то отдельными модулями, в которых требуется накопление и
двунаправленная передача данных.
Рис. 4 Дуплексный канал
Предикатом срабатывания модуля обозначим RDC.
RDC(data1, data2) = (data1  Ø)  (data2  Ø) ,
где datai – данные, поступившие на i-й интерфейс модуля (i={0,1}). То есть срабатывание модуля происходит при поступлении данных на один или оба интерфейса. Каждый
из интерфейсов связан с разными портами. Затем данные записываются в очередь FIFO,
связанную с интерфейсом, на который эти данные пришли.
Модуль типа «Сервисная точка доступа» (SAP) является более сложной, чем канал
структурой, которая способна передавать различные примитивы. Примитивами называются передаваемые аргументы в виде структур данных, в данном случае это методы с набором параметров. И очередь FIFO, расположенная в SAP, должна быть адаптирована к приему разного вида примитивов с разным количеством аргументов.
Рис. 5 Сервисная точка доступа
Зачастую введение одного или нескольких SAP определяет использование дополнительных стандартных модулей для организации межслоевой коммуникации. Это позволяет
10
вынести функции создания примитивов и чтения данных из примитивов из самого модуля
SAP. Графическое изображение модуля SAP показано на рис. 5.
Предикатом срабатывания модуля обозначим RSAP.
RSAP(prim1, prim2) = ( primivive1  Ø)  ( primitive2  Ø) ,
где primi – примитив, поступивший на i-й интерфейс модуля (i={0,1}). Срабатывание
модуля происходит при поступлении примитивов на один или оба интерфейса, каждый из
которых связан с разными портами. Затем примитивы со всеми содержащимися в них данными записываются в очередь FIFO, с которой связан интерфейс, на который этот примитив пришел. На следующем такте модельного времени данные передаются дальше через
соответствующий порт.
Доказана необходимость и достаточность данного набора модулей для моделирования описанного класса протоколов.
Архитектурная диаграмма может быть использована для генерации «скелета» программной модели на языке SystemC. Однако для генерации программной модели недостаточно просто построить архитектурную диаграмму, необходимо также проверить эту диаграмму на наличие определенного класса ошибок, способных нарушить работу программной модели.
Проведен анализ видов ошибок, которые могут быть допущены при построении архитектурной диаграммы. Выделены следующие виды ошибок архитектурной диаграммы,
задачи выявления которых поставлены в диссертации:
1. ошибочная постановка связи порт/интерфейс;
2. ошибочное описание вызываемого метода С++ класса;
3. ошибочное указание или отсутствие описания данных в методе;
4. отсутствие названия порта;
5. отсутствие названия интерфейса;
6. отсутствие названия метода С++ класса;
7. отсутствие названия модуля;
8. отсутствие связи порт/интерфейс;
9. повторное название интерфейса в рамках программной модели;
10. повторное название модуля в рамках программной модели;
11. повторное название порта в рамках одного модуля;
12. повторное название метода С++ класса в рамках одного модуля.
Любая спецификация протокола, соответствующая вышеописанным требованиям,
содержит описание протокола по уровням. Для каждого уровня присутствует описание
функциональности, которую этот уровень обеспечивает в рамках работы протокола. На
основе этого описания при проектировании архитектурной диаграммы программной модели определяется количество и назначение используемых модулей. Количество моделируемых уровней протокола формирует количество IM модулей, количество описанных задач,
11
выполняемых каждым уровнем, формирует количество CM модулей, используемых для
моделирования уровня. Для выполнения каждой отдельной задачи предусматривается отдельный модуль программной модели, выбранный из определенного в диссертации набора
модулей. Если какая-либо задача уровня включает накопление данных в рамках одного
модуля, то вместо CM – используется DC или SC модуль. Если между уровнями в спецификации описаны сервисные точки доступа – для них используется модуль SAP.
Таким образом, для каждого уровня формируется множество модулей Y, в котором
содержатся имена модулей. Каждое имя должно быть уникально в рамках программной
модели.
Y={y0, y1, y2,…, yx};
(1)
Спецификация протокола описывает данные, которые являются входными и выходными для уровней протокола. То есть имеется описание pdu (protocol data unit) относительно каждого из уровней (формат пакета, сегмента, кадра и т.п.). Следовательно, из спецификации можно определить формат данных, поступающих на вход модели, и получаемых на выходе. Далее, в зависимости от задач, выполняемых протоколом на том или ином
уровне, определяется, меняются ли данные при прохождении через тот или иной модуль,
или нет. Если данные меняются – можно выделить новый тип данных, идущий на выход
модуля и, соответственно, дальше по модели. Так составляется множество данных, которые должны присутствовать в модели.
D={d1, d2, d3,…,dn}
(2)
Это множество данных может быть дополнено в процессе дальнейшего проектирования архитектурной диаграммы.
На основе полученных множеств модулей и данных составляются две таблицы:

Таблица требований спецификации, в которой отражается, в какие модули должны
попасть те или иные данные;

Таблица взаимосвязей, на основе которой строится архитектурная диаграмма, отображаются взаимосвязи между модулями, а так же данные, методы С++ классов и
передаваемые с их помощью данные.
Таблица требований спецификации
Таблица 1
Номер
0
Данные
Модули
y 0 , … yf
a0
…
n
y k , … ym
an
В Таблице требований спецификации отражены сведения, какие данные ai, согласно
спецификации, должны попасть в какие модули yj. Каждому данному из множества D присваивается свой номер и ставится в соответствующий столбец. Данные в столбец «Модули» ставятся в зависимости от того, входными для каких модулей эти данные являются по
спецификации. Модулей для одного данного может быть указано несколько, если данные
12
идут маршрутом через несколько модулей, или идут по нескольким модулям параллельно.
Пример такой таблицы показан в Таблице 1.
По результатам данной таблицы составляются множества модулей X, в которых
должны побывать данные. Если поле в столбце «Модули» пустое, то для этого данного ai
множество Xi также будет пустым. Например,
X0 = {y0, … yn}; (для а0)
(3)
Процесс построения таблицы взаимосвязей выглядит следующим образом. В таблицу для каждого модуля выписываются методы С++ классов, отвечающие за передачу и
прием данных в модуль.
yx: {z0, z1, …, zn}
(4)
Для каждого метода С++ класса ставится признак, говорящий о выполняемых им
функциях. По признаку, поставленному в первом столбце таблицы, методы для каждого
модуля делятся на два множества: входящие и исходящие. Например,
In(y0)={ z0, z1,…, zm};
Out(y0)={ zm+1, zm+2,…, z m+n};
(5)
Данные, которые передаются или принимаются при помощи этого метода С++ класса, заносятся в третий столбец таблицы. Это делается на основе вышеопределенного множества D. Например,
A(yx, zm) = {a1, a2, …, an};
(6)
Затем необходимо определить и обозначить порты и интерфейсы модулей. Например,
B(yx) = {if1, if2, …, ifi};
B(yx+1) = {port1, port2, …, porti} ;
(7)
Если порт связан с интерфейсом, то вызываемая портом и предоставляемая интерфейсом функция – это один и тот же метод. Соответственно, они будут иметь одно и то же
название в таблице.
Далее по связям порт-интерфейс ставятся метки (числовые значения), которые идентифицируют связи между блоками. Это в дальнейшем упростит процесс верификации архитектурной схемы. Для этого производятся следующие операции над множествами:
Если выполняется условие
In( y x )  Out ( yt )  zn
,

A
(
y
,
z
)

A
(
y
,
z
)
x
n
t
n

(8)
тогда для метода С++ класса zn в модулях yx и yt ставится одна числовая метка g. Для портов, не связанных ни с каким интерфейсом числовые метки не ставятся; аналогично для
интерфейсов, не связанных с портами. Если порт связан с несколькими интерфейсами или
наоборот, интерфейс – с несколькими портами, то одинаковая числовая метка также ставится для всех портов и интерфейсов. Это описывает те случаи, когда данные параллельно
13
отправляются в несколько модулей архитектурной диаграммы и дальше работа осуществляется в параллельных потоках.
G = {g0, g1, …, gn}
(9)
Пример, как может выглядеть архитектурная диаграмма, показан на рисунке 6.
y0
port0
y6
if0
z0(a0)
z1(a0)
port1
if1
port3
y1
if2
port2
z5(a1)
z2(a1)
port5
if5
if6
port6
z6(a1)
z2(a1,a2)
port7
if3
y2
if4
y3
z3(a1)
z4(a2)
port4
if7
y4
If8
z9(a1)
port9
port8
z7(a1),
z8(a2)
If9
y5
Рис. 6 Пример вида архитектурной диаграммы
Пример окончательного вида таблицы взаимодействий отображен в Таблице 2.
Подобная таблица предоставляет основные данные, необходимые для создания архитектурной диаграммы:
1) Названия модулей;
2) Методы С++ классов, отвечающие за межмодульное взаимодействие, и их названия;
3) Названия портов и интерфейсов между модулями;
4) Методы С++ классов, которые должны быть описаны в соответствующих интерфейсах;
5) Взаимосвязи между портами и интерфейсами;
6) Данные, необходимые для верификации архитектурной диаграммы.
По данным полученной таблицы строится архитектурная диаграмма программной
модели, а также производится формальная проверка на следующие виды ошибок:

отсутствие названия порта;

отсутствие названия интерфейса;
14

отсутствие названия метода С++ класса;

отсутствие названия модуля;

отсутствие связи порт/интерфейс;

повторное название интерфейса в рамках программной модели;

повторное название модуля в рамках программной модели;

повторное название порта в рамках одного модуля;

повторное название метода С++ класса в рамках одного модуля.
Остальные потенциальные ошибки обнаруживаются в архитектурной диаграмме пу-
тем ее верификации. Такой метод верификации описан в третьей главе диссертации.
Таблица взаимосвязей (пример)
Таблица 2
Признак
Метод
Данные
Порт/Интерфейс
Метка
ifj
g0
ifj+1
g1
porti
g1
y0
a0
→
zm
…
an
a1
→
zm+1
…
an+k
…
yx
a1
←
zn
…
an+k
…
После построения таблицы взаимосвязей добавляются данные во множество D.
Данные, отсутствующие во множестве, но присутствующие в столбце «Данные» таблицы
взаимосвязей, добавляются во множество D.
D={type1 data1,type2 data2,type3 data3,…,typem datan}
(10)
Также во второй главе диссертации приведено описание, как на основе таблицы взаимосвязей можно сгенерировать скелет программной модели протокола передачи данных.
В третьей главе обоснован выбор теории сетей Петри для верификации архитектурных диаграмм, получаемых по представленному во второй главе методу. Приведен анализ сетей Петри, включающий применение их для нужд программного моделирования,
формальное описание сетей Петри и их модификация – раскрашенные сети Петри. Применение сетей Петри дает возможность рассматривать в динамике перемещение данных по
архитектурной диаграмме, в том числе и параллельное перемещение. Разметка сети Петри
15
дает возможность увидеть, какие фишки находятся в каких позициях, или какие данные
находятся в каких модулях архитектурной диграммы. Применение раскрашенных сетей
Петри дает возможность различать типы данных и проводить анализ их движения по архитектруной диаграмме независимо друг от друга.
Сеть Петри - это набор N = (Р, Т, F, W, M0), где
P – конечное множество позиций;
Т – конечное множество переходов;
F – конечное множество дуг.
А W: F → N\{0} и M0: P → N — две функции, называемые соответственно кратностью дуг
и начальной разметкой.
Раскрашенная сеть Петри – это кортеж Ň =(Σ,P,T,F,K,C,G,E,I), где
Σ – конечное множество цветов;
K – функция позиций, ставит в соответствие каждой дуге пару, состоящую из связанных с
ней перехода и позиции;
C – функция цвета, представляет собой список цветов, определенных для каждой позиции;
G – предохраняющая функция, представляет собой список булевых выражений, связывание
перехода должно удовлетворять каждой из этих функций (может быть не определена или
быть true для всех переходов)
E – функция выражений дуг, определяется по означиванию выражения дуги, определенного на множестве цветов для конкретной позиции;
I – функция инициализации позиций, ставит в соответствие каждой позиции переменную,
определенную на множестве цветов (может быть определена как конкретный цвет или отсутствовать);
Предложен метод построения раскрашенной сети Петри по архитектурной диаграмме программной модели протокола. Это позволяет описать структуру модели формальными методами, а так же применить их для анализа архитектурной диаграммы и её верификации. Метод включает в себя ряд шагов для составления раскрашенной сети Петри, а так
же алгоритм для ее маркировки.
Для построения раскрашенной сети Петри по архитектурной диаграмме протокола
необходимо сопоставить составляющие архитектурной диаграммы с формализмами теории
сетей Петри. Построение осуществляется по следующему методу:
1) каждому модулю yn, участвующему в передаче данных, сопоставляется позиция сети
Петри pn;
2) каждому вызываемому С++ методу и передаваемым с его помощью данным zx(ay) по
связи порт-интерфейс сопоставляется свой переход ty (в том случае, когда метки g в
таблице взаимосвязей в модулях совпадают (G(yx,zn)=G(yt,zn)));
3) порту (
) сопоставляется дуга к переходу;
16
4) интерфейсу ( ) сопоставляется дуга из перехода;
5) комбинации (тип данных, имя переменной), которые должны быть переданы от модуля к модулю (ay), задают цвета дуг, фишек и позиций;
Раскрашенная сеть Петри, построенная по вышеописанному методу, будет обладать
следующим рядом свойств, выделяющих ее из общего класса раскрашенных сетей Петри в
отдельный подкласс:
1. Каждой дуге a сопоставляется не выражение, а одна переменная, отвечающая за цвет
фишки, по которой данный переход сработает. Таким образом, по одной дуге фишки
разных цветов ходить не могут;
2. Каждому переходу t сопоставляется не выражение, а так же, как и в предыдущем
случае, цвет фишки;
3. Функция позиций I также будет содержать лишь данные о цвете и количестве фишек, поставленных в конкретную позицию;
4. Дуги, входящие и исходящие из одного перехода могут иметь лишь одинаковый
цвет.
После составления сети Петри на основе данного метода, необходимо ее разметить.
В соответствии с множеством D (формула 10) и порядковым номерам таблицы требований,
каждой комбинации (тип данных, имя переменной) присваивается свой цветной маркер,
однозначно идентифицирующий это данное среди других. Переходу, где осуществляется
только вызов метода С++ класса без передачи каких-либо данных в модуль (<вызов>),
фишки не присваиваются и он не анализируется в процессе проверки. Для примера с рисунка 6 распределение цветов показано в Таблице 3.
Распределение цветов
Таблица 3
Номер
Тип данных Название
Цвет
Пример
0
тип0
a0
Черный прерывистый
___
1
тип1
a1
Серый
____
2
тип2
a2
Черный
____
Пример построенной раскрашенной сети Петри показан на рисунке 7а.
В соответствии с теорией сетей Петри примем следующие обозначения:
Pm – множество позиций для разметки (до начала выполнения алгоритма Pm=P);
Pnext – множество позиций, в которые осуществляется переход из текущей позиции;
Сm – множество уже поставленных цветов (до начала выполнения алгоритма Cm= Ø);
С(tout) – множество цветов, определенных для переходов из текущей позиции;
С – полученное множество цветов фишек, которые ставятся в текущей позиции;
Разметка раскрашенной сети Петри производится, начиная с позиции, соответствующего модулю SAP архитектурной диаграммы или определенного разработчиком как точка начала разметки, по следующему алгоритму:
17
1) Определяется, в какие позиции Pnext осуществляется переход из текущего pi;
2) Определяются цвета фишек, которые необходимо поставить в текущей позиции по
формуле
C = С(tout)\ Cm
(11)
3) Во множество Cm записываются новые цвета, определенные для данной позиции.
Cm = Cm∩С
(12)
4) Обновляется множество неразмеченных позиций
Pm=Pm\pi
(13)
5) Определяются позиции для осуществления следующего перехода:
Pnext=Pm ∩ Pnext
(14)
Поскольку позиций в Pnext может быть несколько, то далее разметка происходит для
каждого из этих позиций параллельно.
a. Если Pnext=Ø, то останавливается дальнейшая разметка этой ветви;
b. Если нет, то переходим к разметке позиций, определенных в Pnext, начиная для
каждого из них с п.1;
Алгоритм разметки останавливается, когда нет новых мест для осуществления перехода. Конечность алгоритма доказана.
После проведения разметки получим раскрашенную маркированную сеть Петри, которую можно применять для анализа архитектурной диаграммы и, следовательно, работы
и поведения программной модели. Пример разметки такой сети с рисунка 7а показан на
рисунке 7б. Разметка начата с позиции p0.
Для раскрашенных сетей Петри не применимы методы анализа классических сетей
Петри, поэтому в работе применен принцип построения классической сети Петри, эквивалентной данной раскрашенной сети по поведению, что является достаточным для анализа
архитектурной диаграммы программной модели протокола.
Таким образом, с учетом вышеописанных замечаний, алгоритм построения сети
Петри, эквивалентной раскрашенной, выглядит следующим образом:
1. Каждой позиции p в раскрашенной сети Петри Ň сопоставляется столько позиций в
эквивалентной сети Петри N, сколько цветов в C(p). После такого преобразования
в сети Петри N можно различать фишки, которые в Ň имеют разные цвета. Фишки
в N утрачивают свой цвет, но они размещаются в разных позициях;
2. каждый переход t раскрашенной сети Петри Ň без изменений становится переходом классической сети Петри N;
3. если срабатывание перехода t раскрашенной сети Петри Ň удаляет хотя бы одну
фишку из позиции p, то дуга из этой позиции p в переход t ставится в классической
сети Петри N;
4. если срабатывание перехода t раскрашенной сети Петри добавляет хотя бы одну
фишку в позицию p, то дуга из перехода t в позицию p ставится в классической се18
ти Петри N;
5. количество фишек для каждой позиции сети Петри N ставится в соответствии с количеством фишек соответствующего цвета, определенным начальной маркировкой
M0 раскрашенной сети Петри Ň.
Результатом использования данного алгоритма для вышеупомянутого подкласса
раскрашенных сетей Петри является классическая сеть Петри, которая состоит из набора
связных компонентов, которые между собой не связаны. Это является отличительной особенностью построения классических сетей Петри, эквивалентных раскрашенным сетям
Петри из подкласса, обладающего свойствами, описанными ранее.
p0
p0
t0
t0
t1
t1
p1
p1
t4
t4
t2
t3
p3
t6 t7
t2
p2
p3
t5
t6 t7
t8
p2
t5
t8
p4
p4
t9 t10
t3
t9 t10
t11
t11
p5
p5
а)
б)
Рис. 7. Пример раскрашенной сети Петри, построенной по
архитектурной диаграмме с рисунка 6
В тексте диссертации приведено доказательство следующих теорем.
Теорема 3.1: При построении классической сети Петри N из раскрашенной сети Петри Ň,
полученной из архитектурной диаграммы программной модели протокола передачи данных по предложенному алгоритму, раскрашенная сеть Петри Ň преобразуется в несколько
классических сетей Петри N0…Nx-1 по признаку цвета из Σ.
Теорема 3.2: Классические сети Петри N0…Nx-1, полученные из раскрашенной сети Петри
Ň по предложенному алгоритму, не имеют общих дуг F, позиций P и переходов T.
19
Теорема 3.3: Алгоритм построения набора классических сетей Петри, дает набор сетей
Петри N0…Nx-1, который эквивалентен раскрашенной сети Петри Ň.
Дальнейший анализ может проводиться для каждой полученной сети Петри в отдельности. Таким образом, к раскрашенной сети Петри, полученной из архитектурной диаграммы, можно применять методы анализа классических сетей Петри.
Пример разбиения раскрашенной сети Петри с рисунка 7б на несколько классических сетей Петри показан на рисунке 8.
p0
p1
p2
p3
t4
t0
t1
t2
t3
p2
p3
p1
t5
t6
p4
t7
t8
t9
p4
p5
t10
t11
p5
Рис. 8. Пример разбиения раскрашенной сети Петри с рисунка 7б
на набор классических сетей Петри
100000
010000
001100
000100
001000
000110
010000
000010
010000
000011
000001
000100
000002
000010
Рис. 9. Деревья достижимости, построенные для
набора классических сетей Петри с рисунка 8
Из двух существующих методов, применяемых для анализа сетей Петри (метода деревьев достижимости и метода матричных уравнений), для дальнейшего исследования был
выбран метод деревьев достижимости, так как метод матричных уравнений не дает всех
необходимых для верификации данных. Применяются классические методики построения
20
деревьев достижимости для сетей Петри, в том числе алгоритм, позволяющий добиться
построения конечного дерева достижимости, описанный в работах Дж. Питерсона. Деверья достижимости, построенные по такому алгоритму для сетей Петри с рисунка 8, приведены на рисунке 9.
После построения дерева достижимости для каждой из классических сетей Петри,
полученных по вышеописанному алгоритму, анализируются вершины этих деревьев достижимости. Каждой из вершин дерева достижимости соответствует маркировка сети Петри от M0 (начальной маркировки) до Mj. Например, маркировка 00201 показывает, что две
фишки находятся в позиции p2 и одна фишка в позиции p4. Для каждой из вершин дерева
достижимости составляется множество позиций Ω, в которых находятся фишки. Таким образом, для n вершин дерева достижимости будет Ω0…Ωn-1 множеств. Из этих множеств для
каждой ветви дерева достижимости составляется множество достижимости Q по следующей формуле:
Q

i
(15)
i 0.. k
Каждое множество Q fi содержит данные о том, в какие позиции попала фишка цвета
c, пройдя по маршруту f. Или соответственно, в терминологии архитектурных диаграмм, в
какие модули попали данные, соответствующие цвету c. Например, для рис. 10:
Q00 = Ω0Ω1={p0}{p1}={p0, p1}
(16)
Здесь возле обозначения Q нуль в верхнем индексе означает номер ветви в дереве
достижимости, а нуль в нижнем индексе – номер данных в таблице требований.
Исходя из вышеописанных принципов построения сетей Петри на основе архитектурных диаграмм, каждая позиция pi сети Петри соответствует модулю yj архитектурной
диаграммы. Также, фишки, ходящие по каждой классической сети Петри Nm, соответствуют определенному типу данных an. Поэтому, на основе полученных множеств Q может
осуществляться верификация архитектурной диаграммы программной модели протокола
передачи данных.
Каждая позиция p во множестве Q замещается связанным с ним модулем архитектурной диаграммы y. Таким образом, множество Q00 преобразуется в
Q00 = {y0, y1}
(17)
На основе множеств Q, полученных из ветвей деревьев достижимости, и множеств
X, полученных из таблицы требований, для каждого цвета c осуществляется верификация
архитектурной диаграммы.
Для каждого цвета ci=ai ставятся в соответствие множество Xi и множества Q fi. Далее для каждого маршрута f определяется множество модулей, по которым прошли и в которые не попали данные типа aj по формуле:
Δ f i = Xi \ Q f i
21
(18)
Если Δ=Ø, то это означает, что данные определенного типа, пройдя маршрутом f,
попали во все требуемые модули. Таким образом, верификация была завершена без ошибок.
Если же Δ≠Ø, то в результате в множестве Δ оказывается набор модулей, в которые
данные aj не попали, пройдя маршрутом f. Если для данных aj нет такого маршрута, идя по
которому данные попали во все требуемые модули, то в построении архитектурной диаграммы допущена ошибка.
При наличии ошибки анализируются множества Q и Ω. Множества Q дают информацию о том, каким маршрутом фишки двигались по сети Петри, а множества Ω – какая
разметка сети Петри была в тот или иной момент работы сети. То есть, разработчик может
понять, в какой именно модуль, по какой связи данные не пришли.
Таким образом, в результате верификации будет получено некоторое количество
множеств Δ0… Δb. Каждое из этих множеств показывает те модули y0…ym, в которые не попали данные ai. Таким образом, анализ показывает, какие требования спецификации, отраженные в таблице требований, не выполнены. На основе этого делаются выводы о необходимых изменениях в архитектурной диаграмме.
Например, возьмем сетевой уровень протокола, который должен проверять сетевой
адрес пакета. Для этого по спецификации он должен получить примитив, говорящий о
пришедшем пакете, из канального уровня через SAP, затем проверить адрес пакета. Если
адрес верный, то в пакете отбрасывается заголовок сетевого уровня и передается в SAP
транспортного уровня. Если адрес неверный, то пакет отбрасывается. Таким образом,
нужно 4 модуля: SAP сетевого и транспортного уровня (y0 и y3), модуль проверки адреса
(y1), модуль отбрасывания сетевого заголовка пакета (y2). Отсюда видно, что пакет проходит по пути y0→ y1→ y2. Допустим, что при составлении архитектурной диаграммы была
допущена ошибка, и не был предусмотрен C++ метод, передающий данные типа «пакет»
из y1 в y2. Следовательно, анализ архитектурной диаграммы покажет, что данные типа «пакет» прошли по маршруту y0→ y1 и не попали в модуль y2. Из этого разработчик увидит
несоответствие между архитектурной диаграммой и спецификацией протокола.
В третьей главе диссертации приведен разработанный метод верификации архитектурной диаграммы средствами формальной теории сетей Петри. Результаты анализа раскрашенных сетей Петри на достижимость дают возможность проанализировать архитектурные диаграммы, по которым они были построены. Можно отследить в какие позиции
сети Петри могут попасть фишки определенного цвета (какие данные могут попасть в какие модули), отследить, все ли связи между модулями поставлены верно, и все ли С++ методы и, указанные в них типы данных, верно подписаны на диаграмме, а также отследить
маршрут следования данных по модулям.
В результате верификации произведена проверка архитектурной диаграммы на следующие типы ошибок:
22
 ошибочная постановка связи порт/интерфейс;
 ошибочное описание вызываемого метода С++ класса;
 ошибочное указание или отсутствие описания данных в методе.
Описанная во второй и третьей главах методика построения и верификации архитектурной диаграммы позволяет обнаружить все вышеописанные виды ошибок, которые могут возникнуть при построении архитектурной диаграммы.
В четвертой главе диссертации описываются применения методики создания архитектурных диаграмм и их верификации на реальных программных моделях, разрабатываемых для крупных компаний:
 программная модель уровня PHY Adapter стека протоколов UniPro;
 программная модель уровня PHY стека протоколов UniPro;
 программная модель Символьного уровня протокола SpaceWire;
Информация, приведенная в четвертой главе диссертации, показывает, что методика
перехода от спецификации к архитектурной диаграмме и дальнейшей ее верификации
успешно применялась на практике. Она позволила исправить ошибки на начальном этапе
проектирования программных моделей протоколов встроенных систем, что облегчило и
ускорило их разработку.
Рисунок 10. Внешний вид программы ESPMS.
Также в четвертой главе приведено описание инструментально-программного комплекса ESPMS (Embedded Systems Protocols Modelling Software), разработанного с использованием разработанных методов и алгоритмов, предложенных в диссертационной работе
23
(рис.10). Система ESPMS описана на языке С++ с помощью Qt. Она выполняет следующие
функции:
 построение архитектурных диаграмм при помощи встроенного редактора;
 анализ архитектурной диаграммы сетями Петри в соответствии с методом, изложенным в главе 3.
Разработанная в данной диссертационной работе методика позволила уменьшить
время написания программной модели и снизить трудозатраты на реализацию. В качестве
примера в работе приведены результаты проекта по написанию программной модели протокола передачи данных для встроенных систем UniPro. Методика, представленная в данной диссертации, уменьшила трудозатраты на написание программной модели на 40%.
В заключении представлена обобщенная итоговая оценка проделанной работы
и приведены основные результаты проведенного исследования и их соотношение с целью
и задачами, научной новизной, практической значимостью и положениями, выносимыми
на защиту, поставленными и сформулированными во введении. Приложение А содержит
программный код приложения ESPMS, реализующего вышеописанные методы и алгоритмы. Приложение Б содержит пример перехода от спецификации протокола к архитектурной диаграмме и верификации этой архитектурной диаграммы. Приложение В демонстрирует содержимое текстового файла с результатами верификации примера архитектурной диаграммы в программе ESPMS.
ОСНОВНЫЕ РЕЗУЛЬТАТЫ РАБОТЫ
1. Разработан метод проектирования и анализа программных моделей протоколов передачи данных при помощи построения и верификации архитектурных диаграмм;
2. Разработан и обоснован набор типовых модулей для построения архитектурных
диаграмм программных моделей протоколов передачи данных для встроенных систем;
3. Разработан метод организации межмодульных взаимодействий в архитектурной
диаграмме;
4. Разработан метод перехода от архитектурной диаграммы программной модели к
формальной модели в терминах раскрашенной сети Петри;
5. Разработан алгоритм разметки раскрашенной сети Петри для осуществления верификации, отличающийся осуществлением разметки без каких-либо данных о требуемом поведении раскрашенной сети Петри (на входе алгоритма – сеть Петри, полученная из архитектурной диаграммы программной модели);
6. Предложен метод перехода от раскрашенной сети Петри к эквивалентному ей набору классических сетей Петри в целях применения метода анализа деревьями достижимости к раскрашенным сетям; определены условия, при которых при построении
24
классических сетей Петри эквивалентных по поведению раскрашенной сети Петри
последняя будет делиться на несколько сетей по признаку цвета;
7. Разработан метод верификации архитектурной диаграммы на основе данных, полученных при анализе набора классических сетей Петри деревьями достижимости.
Таким образом, решены все задачи, поставленные для достижения сформулированной в работе цели, и методика построения и верификации архитектурных диаграмм программных моделей протоколов встроенных систем полностью описана и протестирована.
ОСНОВНЫЕ ПУБЛИКАЦИИ ПО ТЕМЕ ДИССЕРТАЦИИ
1. Оленев В.Л. Моделирование на языке SystemC в процессе разработки протоколов передачи данных// Известия высших учебных заведений. Поволжский регион. Технические науки. Пенза, 2009. №4 (12). C. 61-69.
2. Оленев В.Л. Исследование и разработка системы для создания моделей протоколов передачи данных и их верификации// Ползуновский вестник. Барнаул,
2010. №2. C. 36-42.
3. Valentin Olenev, Alexey Rabin, Alexander Stepanov, Irina Lavrovskaya, Sergey Balandin,
Michel Gillet. Co-Modeling of Embedded Networks Using SystemC and SDL // International Journal of Embedded and Real-Time Communication Systems (JERTCS), 2011.
#2(1). C. 24-49.
4. Оленев В.Л., Онищенко Л.В., Еганян А.В. Методы межмодульного взаимодействия
при моделирования протоколов встроенных систем// Научная сессия ГУАП: Сб.
докл./ СПбГУАП. СПб., 2008. С. 119-122.
5. Valentin Olenev, Sergey Balandin, Michel Gillet, Elena Suvorova, Ludmila Onishenko, Artur Eganyan. Efficient Inter-module Interaction in SystemC Models of Large Embedded
Systems// Cadence Designer Network, CDNLive, 2008. 5 стр.
6. Valentin Olenev. Different approaches for the stacks of protocols SystemC modelling// 4th
Seminar of Finnish-Russian University Cooperation in Telecommunications (FRUCT)
Program, 2008. 4 стр.
7. Оленев В.Л. Анализ подходов к моделированию стеков протоколов передачи данных// Научная сессия ГУАП. Часть 1: Сб. докл./ СПбГУАП. СПб., 2009. C. 112-114.
8. Valentin Olenev, Alexander Stepanov. Comparative Analysis of SDL and SystemC languages for Real-Time Systems Modelling// 5th Seminar of Finnish-Russian University
Cooperation in Telecommunications (FRUCT) Program, 2009. 5 стр.
9. Оленев В.Л., Степанов А.С., Лавровская И.Я., Рабин А.В. SystemC and SDL CoModeling Methods// 6th Seminar of Finnish-Russian University Cooperation in Telecommunications (FRUCT) Program / Proceedings printed by Saint-Petersburg State University
of Aerospace Instrumentation (SUAI). 2009. С. 136 – 140.
25
10. Оленев В.Л., Шейнин Ю.Е., Суворова Е.А., Баландин С., Gillet M. SystemC Modelling
of the Embedded Networks// 6th Seminar of Finnish-Russian University Cooperation in
Telecommunications (FRUCT) Program/ Proceedings printed by Saint-Petersburg State
University of Aerospace Instrumentation (SUAI). 2009. С. 85 - 95.
11. Оленев В.Л., Коробков И., Коблякова Л., Шутенко Ф. Remote Memory Access in Embedded Networked Systems// 6th Seminar of Finnish-Russian University Cooperation in
Telecommunications (FRUCT) Program/ Proceedings printed by Saint-Petersburg State
University of Aerospace Instrumentation (SUAI). 2009. С. 77 – 84.
12. Оленев В.Л., Коробков И., Мартынов Н., Шадурский А. Modelling of the SpaceWire
communication protocol// 7th Conference of Open Innovations Framework Program
FRUCT/ Proceedings printed by Saint-Petersburg State University of Aerospace Instrumentation (SUAI). 2010. С. 96 – 104.
13. Оленев В.Л., Степанов А.С., Лавровская И.Я., Рабин А.В. SystemC and SDL Comodelling implementation// 7th Conference of Open Innovations Framework Program
FRUCT/ Proceedings printed by Saint-Petersburg State University of Aerospace Instrumentation (SUAI). 2010. С. 130 – 137.
14. Оленев В.Л., Пешаков И. Исследование и разработка системы моделирования протоколов передачи данных на языке SystemC// Научная сессия ГУАП. Часть 1: Сб.
докл./ СПбГУАП. СПб., 2010. C. 112-119.
15. Оленев В.Л., Степанов А.С., Лавровская И.Я., Рабин А.В. Разработка и исследование
методов совместного моделирования встроенных систем на языках SDL и SystemC//
Научная сессия ГУАП. Часть 1: Сб. докл./ СПбГУАП. СПб., 2010. C. 122-127.
16. Оленев В.Л., Степанов А.С., Лавровская И.Я. SDL and SystemC co-modelling: the protocol SDL models Tester// 8th Conference of Open Innovations Framework Program
FRUCT/ Proceedings printed by Saint-Petersburg State University of Aerospace Instrumentation (SUAI). 2010. С. 198 – 207.
17. Оленев В.Л., Коробков И.Л., Шадурский А.В., Мартынов Н.А. RMAP and STP protocols modelling over the SpaceWire SystemC model// 8th Conference of Open Innovations
Framework Program FRUCT/ Proceedings printed by Saint-Petersburg State University of
Aerospace Instrumentation (SUAI). 2010. С. 111 – 121.
_________________________________________________________________________
Формат 60х84 1/16. Бумага офсетная. Печать офсетная.
Тираж 100 экз. Заказ № 527.
_________________________________________________________________________
Редакционно-издательский центр ГУАП
190000, г. Санкт-Петербург, ул. Б. Морская, 67
26