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

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

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