OKTET Labs предлагает методологию разработки встроенного программного обеспечения. Мы предполагаем, что выполняются некоторые из следующих условий:

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

Примеры таких применений включают:

• communication devices (ATM controllers, Level 3 accelerators, traffic processing units in network devices, cryptographic processing)
• mass storage subsystem (SCSI host adapters, SCSI devices firmware, mass storage devices, RAID)
• link layers in mobile terminals (GSM, etc)
• graphic accelerators software

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

• Ограничить источники проблемы на каждом этапе.
  
  Если тестируемое программное обеспечение скомпилировано с использованием нерабочих компиляторов и запущено на нерабочем оборудовании или симуляторе, с использованием неправильного набора тестов, поиск источника проблемы может быть довольно сложным, и многие разработчики должны быть вовлечены в этот процесс одновременно.
• Разные разработчики должны разрабатывать код и тесты (это довольно традиционно).
• Общий язык.
  
  Когда это возможно, для разработки кода, тестирования, инструментов следует использовать один и тот же, достаточно гибкий, язык.
• Уровень программирования на языке ассемблера должен быть улучшен, когда это возможно.
  
  Ассемблер должен поддерживать определение структуры данных и обработку структурированных данных, определение/вызов функций, передачу параметров. Ассемблер должен допускать явные или неявные проверки во время сборки (например, использование регистров. Ассемблер должен поддерживать структурированные программные конструкции (условные операторы, циклы, переключатели и т.д.). Должна поддерживаться встраивание функций. Фактически, исходные тексты на ассемблере написаны как программа (в подготовленной среде); результатом ее выполнения является исполняемый код.
• Связывание ассемблера и среды выполнения.
  
  В ассемблерной программе должна быть предусмотрена возможность вставки проверок во время выполнения и отпечатков трассировки. В более общем плане, в ассемблерной программе должна быть предусмотрена возможность вставки произвольного высокоуровневого кода, предназначенного для выполнения, когда управление достигнет соответствующего места. Конечно, лучше использовать тот же язык, который используется для программирования на ассемблере, и иметь доступ к контексту, определяемому в соответствующем месте кода на ассемблере (аргументы функции, локальные переменные и т.д.). Это весьма полезно для разработки тестов, защитного кодирования, отладки.