Таблица 1.3.

Практически все системы, даже такие дорогостоящие как системы освещения или разрозненные производственные системы с большим количеством цифровых датчиков, содержат аналоговые или сложные (analog/complex) датчики и активаторы (приводы). И эти датчики требуют поддержки пакетов размером 4-25 бит для обычных данных и несколько более длинных пакетов для передачи калибровочных данных. Более того, чем устройство интеллектуальней, тем длина пакета больше. Уже на сегодняшний день характерный размер передаваемых данных составляет 30 байт, а в ближайшие несколько лет обещает вырасти до 50 и более байт.

В общем, можно выделить два основных требования:

- как можно больший максимальный размер пакета;

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

На следующих двух рисунках проиллюстрировано отличие между единой сетью, поддерживающей передачу пакетов разной длины (рисунок 1.1.), и объединением нескольких сетей, каждая из которых поддерживает передачу пакетов только фиксированной длины (рисунок 1.2.). Метод передачи больших пакетов путем разбивки в несколько маленьких (фрагментация) лучше использовать как вспомогательный, хотя он позволяет повысить производительность. Совершенно очевидно, что единая сеть, поддерживающая пакеты разной длины без использования фрагментации, наиболее предпочтительна.

Рисунок 1.1. Единая сеть, поддерживающая передачу пакетов разной длины.

Рисунок 1.2. Объединение нескольких сетей, каждая из которых поддерживает передачу пакетов только фиксированной длины.

- По-событийное обновление показаний датчиков.

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

- Одноуровневая архитектура.

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

- Выделенный прикладной процессор.

Многократно повторяющиеся прерывания прикладного процессора на обработку приходящих пакетов или других коммуникационных задач отрицательно влияют на производительность в обоих случаях. Они также влияют на надежность узла и системы в целом. Пусть занятый канал послал десять пакетов с интервалом 100 микросекунд при размере пакета 100 бит и скорости 1 мегабит в секунду и ждет подтверждения приема каждого пакета. На обработку прерывания, возникающего при приеме пакета, процессор тратит не менее 25 микросекунд и в итоге приложению может не хватить времени на сортировку приходящих пакетов, осуществление процесса ввода/вывода, выполнения локальных вычислений и генерацию пакетов с ответом. Таким образом, на приемном конце пакеты могут быть потеряны. Потерянные пакеты приведут к срыву завершения транзакции и могут вызвать остановку работы сети в целом.

- Задержки при прохождении роутеров (маршрутизаторов) и шлюзов.

Роутеры, соединяющие подсети, должны работать на уровне приложений модели OSI/ISO, если реализация сетевого уровня протокола не предполагает маршрутизации на своем уровне. Для иллюстрации отличия между маршрутизацией прикладного и системного уровня, приведем аналогию с почтовой службой. Письмо. Посылаемое из города А в город Б, может быть отсортировано прямо по адресу города и доставлено (маршрутизация сетевого уровня). Во втором случае, клерк на почте не читает адрес города, а только фамилии адресата и отправителя и должен помнить, что мистер Джонс из города А всегда пишет мистеру Грину в город Б (маршрутизация прикладного уровня). Такая система требует больше ресурсов и работает медленнее. Читатель может сам сделать выводы о производительности, масштабируемости, восстанавливаемости и гибкости на основании приведенного примера.

- Прогнозируемость.

Прогнозируемость (Determinism) иногда упоминается как фактор, влияющий на производительность без уточнения почему. Однако тот детерминизм, который упоминается везде и всюду, есть прогнозируемость системного уровня и означает, что цикл измерения завершится в течении строго определенного временного интервала, начиная с возникновения события или условия, заставившего датчик сработать. Такая прогнозируемость невозможна в реальном мире за исключением традиционных однопоточных систем полностью контролируемых центральным устройством, подобным PLC (Programmable Logical Controller), выполняющим постоянное сканирование в строго определенные моменты времени, использующим централизованно управляемую шину типа точка-точка или шину с множественным доступом и временным разделением. Схема с прослушиванием несущей и контролем коллизий не гарантирует прогнозируемости уровня соединений (link level determinism). Такие технологии как предупреждение коллизий, разрешение коллизий, определение коллизий, система приоритетов и их комбинации, будучи применяемы в рамках CSMA схемы доступа (carrier-sense multiple access), могут увеличить прогнозируемость системы. Должна существовать возможность включать и выключать эти дополнительные подпротоколы избирательно для канала, узла или параметров узла без остановки всей системы.

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

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

Однако, прогнозируемость, как объективная реальность, более похожа на требования к “реально быстрым” системам, нежели на требования к системам “реального времени”. Цель первых иллюзорна и препятствует выработке любого реального решения. Второе требует системного подхода и предполагает оптимизационные решения для системных требований реального времени.

- Системная интеграция.

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

Наиболее важным из вышеперечисленных факторов является качество реализации стека протоколов передачи данных. Обзор наиболее качественных решений выделяет различия в целесообразности их применимости. Компьютерный мир предоставляет нам очень поучительный урок. Мир ОС UNIX, содержащий максимально совместимые решения, вынужден сейчас развиваться в сторону DOS, несмотря на неоспоримое техническое превосходство. Даже во время второго раунда, когда UNIX все еще мог предложить большие возможности, нежели Windows NT, последний был более популярен. Мир PC страдает от многочисленных ошибок несовместимости, добиваясь жизнеспособности. 98% компаний, ориентированных на PC выходят из бизнеса, поскольку их продукты вызывают слишком много побочных эффектов для других приложений.

Пользователи, купившие свои PC, мучаются каждый день от необъяснимых аномалий операционной системы. Разработчики программного и аппаратного обеспечения PC хорошо помнят кошмары тестирования системного уровня своего продукта на совместимость с огромным числом других программ. В мире множественных реализаций любого сложного стандарта (операционная система, сетевой протокол) немного решений проходят проверку временем с точки зрения Plug&Play совместимости. Понятие правильной реализации теста обречено быть ограниченным в своей практической годности, поскольку реальные тесты всегда не полны, и не дают полной верификации. Более того, все реализации, точные или нет, являются предметом для личных интерпретаций.

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22