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

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

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

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

Таким образом, назрела острая необходимость в новой методологии, которая бы формализовала и автоматизировала весь цикл разработки коммуникационных протоколов - от формирования технических требований до создания верифицированных спецификаций и прототипов. Именно такая методология проектирования коммуникационных протоколов представлена в [2]. Её ключевые преимущества — полнота охвата процесса, возможность параллельной разработки поуровневых и сетевых моделей, встроенный механизм обнаружения и исправления ошибок на ранних стадиях.

ПРОЕКТИРОВАНИЕ КОММУНИКАЦИОННЫХ ПРОТОКОЛОВ

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

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

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

Учитывая высокую сложность современных протоколов, созданная спецификация не может быть отдана в реализацию без тщательной валидации. Для этой цели методология предусматривает этап программного имитационного моделирования (этапы 3 и 4). На этапе 3 на базе документа спецификации создаются две взаимодополняющие, но структурно различные модели: поуровне-вая модель (этап 3.1) и сетевая модель (этап 3.2). Поуровневая модель фокусируется на детальной проверке корректности работы каждого отдельного логического уровня протокола (например, канального, сетевого, транспортного), изолируя его механизмы от влияния других уровней и среды. Сетевая модель, в свою очередь, создается только после успешной верификации как минимум одного варианта поуровневой модели. Ее цель - исследовать поведение протокола в условиях, приближенных к реальным: при взаимодействии множества узлов в топологии сети, при наличии больших объемов трафика, потерь и задержек. Таким образом, поуровневая модель отвечает за корректность алгоритмов, а сетевая - за их эффективность и устойчивость в сети.

После создания и настройки моделей (конфигурация параметров, топологии, нагрузок) следует этап 4 - проведение серии имитационных экспериментов. Процесс моделирования для поуровневой (этап 4.1) и сетевой (этап 4.2) моделей осуществляется параллельно для оптимизации времени разработки. Критически важным элементом методологии является механизм управления ошибками. Если в ходе моделирования на любой из параллельных веток (4.1 или 4.2) выявляется несоответствие поведения протокола ожиданиям, составляется детальный отчет об ошибке. Данный отчет направляется на анализ экспертной группе, а работы в соответствующей ветке моделирования приостанавливаются. Происходит возврат к этапу 2 для пересмотра и уточнения спецификации протокола на основе выявленного недочета. После корректировки документ вновь поступает на моделирование. Такой итеративный цикл «спецификация - моделирование - верификация - доработка» продолжается до тех пор, пока обе команды моделирования не подтвердят отсутствие критических ошибок в поведении протокола.

Стадия проверки (этап 5) заключается в сопоставлении итоговых результатов моделирования с исходными техническими требованиями, собранными на этапе 1. Оценивается, удовлетворяет ли поведение смоделированного протокола всем заявленным критериям производительности, надежности и функциональности. В случае выявления несоответствия спецификация вновь отправляется на

Рис. 1. Структура методологии разработки коммуникационных протоколов доработку (возврат на этап 2). Если же все требования выполнены, спецификация считается проверифицированной и проходит процедуру финализации (этап 6). Полученный документ является базовым для последующих фаз проекта, выходящих за рамки данной методологии, таких как разработка аппаратного обеспечения, написание эталонного программного референс-кода или стандартизация.

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

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

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

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

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

Автоматизация стирает грань между формальным описанием процесса и его реальным выполнением. Разработанная и верифицированная спецификация протокола, представленная в машиночитаемом формате внутри системы, может стать основой для автоматической генерации кода программных моделей (на SystemC, SDL, Python), кода аппаратных описаний (VHDL, Verilog) для прототипирования, тестовых сценариев и тестов для верификации реализаций. Это резко снижает вероятность ошибок при «ручном» переводе спецификации в код и многократно увеличивает скорость перехода от проектирования к реализации.

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

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

АГРЕГАТИВНАЯ МОДЕЛЬ ПРЕДСТАВЛЕНИЯ МЕТОДОЛОГИИ ПРОЕКТИРОВАНИЯ КОММУНИКАЦИОННЫХ ПРОТОКОЛОВ

Для полной автоматизации разработанной методологии необходимо создать ее представление в виде некоторых формализовано взаимосвязанных компонентов. Более того, необходимо провести анализ, может ли быть автоматизирован каждый из компонентов методологии в отдельности. Однако, представленная методология представляет собой совокупность различных действий, каждое из которых может быть представлено как отдельная сложная формализованная система. Широкую известность в качестве универсального метода для формального описания функционирования таких систем получил подход, разработанный Н. П. Бусленко [3]. Агрегативной системой, или Асхемой, называют категорию сложных систем, которые из-за своей высокой структурной сложности не могут быть представлены в виде единой математической модели, а только как комбинация из отдельных элементов, описанных различными формальными техниками.

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

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

Чтобы описать реальную систему при помощи А-схемы, нужно отдельно описать каждый из агрегатов (Аn) и связи между ними. Таким образом, для представления методологии проектирования коммуникационных протоколов как агрегативной системы [4], каждый процесс, обозначенный на рисунке 1, должен быть представлен как отдельный агрегат. Каждый из этих элементов характеризуется следующими множествами:

. моменты времени Т ,

. входные сигналы X ,

. выходные сигналы Y ,

. внутренние параметры системы H ,

. состояния системы Z в конкретные моменты времени t ∈ T .

Также возможно описать множества внешних сигналов управления агрегатами G . Однако, разработанная методология не подразумевает отдельное управление каждым из элементов, поэтому управляющих сигналов для агрегатов А -схемы не будет.

Работа агрегативной схемы представляет собой процесс непрерывной обработки информации, которая разделяется на два основных типа: внешнюю и внутреннюю. Внешняя информация поступает в систему из окружающей её среды от взаимодействующих с ней объектов. Внутренняя же информация формируется непосредственно агрегатами в ходе их функционирования. Основным механизмом, обеспечивающим как взаимодействие А -схемы с внешней средой, так и связь между отдельными агрегатами внутри системы, является обмен специальными сообщениями - сигналами. В рамках методологии фундаментальной единицей такого обмена выступают элементарные сигналы, означающие передачу конкретных документов. Их передача осуществляется мгновенно и независимо друг от друга по специально выделенным каналам связи, отображаемым на схеме. Архитектура связей в А -схеме подчиняется строгим структурным правилам, обеспечивающим детерминированность и однозначность информационных потоков. Так, каждый входной контакт любого элемента системы может быть соединён не более чем с одним элементарным каналом, что исключает конфликты при получении данных. В то же время выходной контакт агрегата способен выдавать сигнал одновременно по любому конечному числу каналов. Критически важным дополнительным условием является правило, согласно которому множественные каналы, исходящие от различных источников, не могут быть направлены на один и тот же входной контакт другого элемента; каждый вход получает данные только из одного строго определённого источника. Это гарантирует отсутствие коллизий и чёткую прослеживаемость путей прохождения информации в сложной системе.

Переходы агрегата А_i из состояния z_i(t₁) в z_i(t₂) определяются внутренними параметрами h_i(t) ∈ Н и входными сигналами х_i(t) ∈ X . Но поскольку в данном случае интерес представляет только структурная составляющая А -схемы, без учета динамики функционирования, внутренние параметры, влияющие на совершение переходов в пространстве состояний, можно не рассматривать.

Взаимодействие элементов А-схемы и внешней среды представляется как обмен сигналами между агрегатами А_n и А₀ . То есть внешняя среда представляется в виде отдельного агрегата системы ( А₀ ), который, так же, как и остальные агрегаты, содержит входные и выходные контакты.

Каждый агрегат А_n формально описывается двумя множествами, использующимися для описания их сопряжения с прочими элементами А-схемы и внешней средой:

. входные контакты Х_i(n) = {Х₁(n), Х₂(n), ..., Х_b(n)} ,

. выходные контакты Y_j(n)} ={Y₁(n), Y₂(n), ..., Y_с(n)} .

Для описания сопряжения элементов в А-схеме используется оператор R в совокупности с множествами Х_i(n) и Y_j(n) . Этот оператор сопряжения R задается в виде таблицы, в которой на пересечении строк с номерами элементов (агрегатов) n и столбцов с номерами контактов i располагаются пары чисел, указывающие номер элемента и номер контакта, с которым соединен контакт Х_i(n) .

Поставим в соответствие каждому из элементов методологии проектирования коммуникационных протоколов конкретный агрегат А -схемы. Соотношение агрегатов и названий этапов методологии представлено в таблице 1.

На рисунке 2 представлена А -схема, отображающая процесс проектирования, соответствующий методологии проектирования коммуникационных протоколов.

Оператор сопряжения R представлен в таблице 2.

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

ПОДХОД К АВТОМАТИЗАЦИИ ПРОЕКТИРОВАНИЯ ПРОТОКОЛОВ НА БАЗЕ АГРЕГАТИВНОЙ МОДЕЛИ

Сбор технических требований на внутреннюю функциональность протокола и технических требований к сетевой функциональности (агрегаты А₁ и А₂ ) может быть реализован при помощи различных методик сбора и формирования требований [5, 6, 7] и статистических методов анализа [8].

Таблица 1. Соотношение агрегатов и названий этапов методологии

Агрегат	Название этапа в методологии
А о	Внешняя среда (инициатор создания протокола)
A i	Сбор технических требований на внутреннюю функциональность протокола
А 2	Сбор технических требований к сетевой функциональности
А з	Разработка / доработка спецификации протокола
А 4	Разработка поуровневой модели стека протоколов
А 5	Разработка сетевой модели стека протоколов
А б	Настройка поуровневой модели
А 7	Настройка сетевой модели
А 8	Моделирование точка-точка
А 9	Моделирование работы сети
А 10	Проверка на соответствие требованиям внутренней функциональности
Ап	Проверка на соответствие требованиям к сетевой функциональности
А 12	Анализ найденных ошибок и фиксация требуемых изменений
А 13	Финализация спецификации

Рис. 2. А-схема процесса проектирования коммуникационных протоколов

При этом требования сразу могут быть записаны как формулы в терминах темпоральных логик. В этом случае можно будет применить разработанные методы формальной верификации ( model checking ). Это автоматизированная проверка математической модели системы (часто в виде графа или автомата) на соответствие формальным требованиям (спецификациям) [9, 10]. Проведение этой операции позволит математически доказать отсутствие ошибок. Использование математического подхода темпоральными логиками превращает сбор требований в полностью автоматическую процедуру, сделать требования однозначными (формализация), выявить противоречия (логический анализ), доказать выполнимость требований (верификация) еще на ранней стадии проекта.

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

Таблица 2. Оператор сопряжения R

Номер агрегата Номер входного контакта 0 1 2 3 4 5 6 7 0 13,0 - - - - - - - 1 0,0 - - - - - - - 2 0,1 - - - - - - - 3 1,2 2,0 12,0 - - - - - 4 8,0 1,1 3,0 6,2 - - - - 5 4,2 3,1 2,1 7,2 9,3 - - - 6 4,0 8,3 - - - - - - 7 5,1 9,3 - - - - - - 8 6,0 10,2 - - - - - - 9 7,1 11,2 - - - - - - 10 1,0 8,1 - - - - - - 11 9,1 2,2 - - - - - - 12 10,1 8,2 6,1 4,1 5,0 7,0 9,0 11,0 13 10,0 11,1 - - - - - - ли, графы, логические формулы) в привычный технический документ (спецификацию) по строгим правилам [11, 12]. Это также позволит избавиться от рутинного, подверженного ошибкам переписывания одних и тех же данных в разных документах, обеспечивая при этом безошибочность и лаконичность итоговой спецификации. После этого использование алгоритмов автоматического извлечения формальных требований и ключевых понятий из текстов, которое состоит из распознавания именованных сущностей (поиска в тексте упоминания компонентов, параметров, стандартов), далее семантический анализ и извлечение отношений (определение связей между сущностями), а также генерация связных текстовых описаний для разделов спецификации. Это часто делается с помощью шаблонов, заполняемых данными из модели.

Задача этапов, связанных с агрегатами А₄ и А₅ – автоматическое создание программной модели на базе спецификации. Подходы к созданию поуровневой модели (агрегат А₅ ), когда в наличии уже есть формализованные спецификация и технические требования в значительной степени проработаны. Например, методы перехода от спецификаций протоколов передачи данных к архитектурным диаграммам программных моделей, затем формальное описание раскрашенными сетями Петри и верификация архитектурной диаграммы программной модели [13]. Кроме того, при разработке поуровневой модели могут быть использованы формальные техники моделирования, такие как элементы теории автоматов с генерацией кода в язык SDL [14].

Разработка сетевой модели стека протоколов (агрегат А₄ ) – это сложная многофакторная задача, которая должна учитывать не только принципы, описанные в спецификации протокола, но и различные физические свойства сетей, принципы их организации и т.п. Здесь необходимы дополнительные методы и алгоритмы, которые автоматизируют процесс составления сети из компонентов (узлы, коммутаторы, каналы), при необходимости достраивают до требуемой отказоустойчивости, качественно прокладывают маршруты передачи данных, настраивают параметры обеспечения качества сервиса, а также дают возможность запустить на моделирование и собрать статистику для анализа. Совокупности таких методов и алгоритмов представлены в публикациях [15, 16, 17]. Подобные подходы применены и отработаны в составе САПР SANDS.

Для автоматической настройки (агрегаты А6 и А7) моделей создано несколько подходов. Выбор метода зависит от размерности пространства параметров, сложности реализации оценки, наличия ограничений на применение, а также характера параметров (непрерывные, дискретные, стохастические и т.п.). Например, на первоначальных этапах настройка моделей может проводиться вручную, а далее могут быть использованы цифровые двойники. Цифровой двойник настраивает параметры не как одноразовую задачу, а как непрерывный процесс адаптивного оценивания. Цель его использования здесь – наиболее точное отражение поведения и свойств физической системы-оригинала на протяжении всего ее жизненного цикла, что позволяет делать надежные прогнозы и оптимальные управляющие воздействия. При этом цифровой двойник не настроит модель однократно, он будет делать это непрерывно или периодически, подстраиваясь под изменения реального объекта. Именно поэтому применение цифрового двойника для настройки модели выглядит максимально перспективным методом. Однако, для проектирования протоколов возможно использовать и более простые подходы, не использующие концепции искусственного интеллекта [18, 19].

Под моделированием точка-точка и моделированием работы сети (агрегаты А 8 и А 9 ) подразумевается именно процесс симуляции, то есть запуск на исполнение моделей, разработанных и настроенных на предыдущих этапах. Здесь используются формальные методы и алгоритмы, позволяющие ускорить процесс работы программного кода, методы совместного моделирования [20, 21].

Проверка на соответствие требованиям (агрегаты А10 и А 11) может осуществляться при помощи формальных методов верификации, таких как model checking [22]. Агрегаты А8-А11, по сути, отражают процесс верификации. Если модель на предыдущих этапах уже была представлена как сеть Петри или как граф, то есть возможность преобразовать ее в модель Крипке [23], а затем применить методики формальной верификации и проверить спецификации, записанные формулами темпораль- ной логики, на полученных моделях Крипке.

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

Таким образом, процесс, представленный А -схемой на рисунке 2, может быть проиллюстрирован следующей схемой, отображенной на рисунке 3.

Y⁰    X 1

0 0

Технические ■ л требования внутренней функцион-ти в формулах темпоральной логики

X4

Проектиро- 0 ) вание У уровневойА-модели 2 ' (конечный 7 автомат) ]

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

Y4

X6

Y6

А Настройка уровневой Y1 модели   J"

1 цифровым0н

X8

Y 8

0 X10

Y io

Р Интерпре- С тация в Q

модель Дз Крипке

Checking 2

X12

Y12

X13 0

Y i3

X0

Формирование текстового описания будущей технологии передачи данных

Y2

Технические? требования сетевой

0 А

X2

функцион-ти в 1 формулах Q— темпоральной! 2

логики О—

0 .----------- п 0

*<) Автомати- 0—- ' рА ческое Л¹ £2рр проектирование

I Ар сетевой Ар модели

X7

Y7

X9

Y11

2Тформальная 0 интерпретация данных и 0 внесение Йр) изменений 6 (AI) 7

Автоматическое приведение спецификации к формату и С ГОСТ (AI)

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

Интерпре-

1 нтерпре- 0 тация в I2

I модель у Р Крипке 0?

1 Model jP Checking —

Рис. 3. Автоматизированный процесс эволюции коммуникационных технологий