Открытое АСУ ТП Версия 2

 Цели: Президент РФ поставил задачу минимум на порядок увеличить степень автоматизации и роботизации отечественных предприятий. Основными препятствиями на пути применения автоматизированный и робототехнических систем являются большая стоимость, большое время реализации проектов и неопределенность результата.  Поскольку основные затраты в таких проектах приходятся на статьи, связанные с проектированием и разработкой, то необходимо оптимизировать именно их. Уменьшить оплату труда инженеров и программистов мы не можем, иначе они «разбегутся» в более прибыльные отрасли экономики, остается только один путь: стандартизация процесса проектирования с целью минимизации времени проектирования. Стоимость аппаратной составляющей не так высока, в первую очередь ее следует сделать полностью суверенной, для нивелирования рисков враждебного влияния со стороны различных «партнеров».

Задачи:

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

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

·         Заменить все типы сетей (цифровых линий связи) на один тип. Физический уровень может быть любым, главное, чтобы это различие не затрагивало логику работы ПО.

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

Решение плюс минимизация числа «сущностей»:

·         В качестве архитектурной основы выбрать стандарт МЭК 61499. Полностью согласен с выбором представителей компании «Северсталь». Данный стандарт позволяет создавать распределенные системы управления и разделять большую задачу на иерархию из множества относительно независимых подзадач.

·         Заменить все типы цифровых линий связи на разрабатываемую сеть ССИ (Синхронная Символьная Иерархия), которая идеально сочетается с архитектурными особенностями стандарта МЭК 61499. Сеть ССИ соответствует всем требованиям для перспективных сетей связи описанных в документах МСЭ-Т группа ИК-13 «Сети 2030». Предлагаемая сеть является единственной полноценно детерминированной сетью цифровой связи, есть гарантии предоставляемой скорости, постоянства задержки передачи данных, отсутствия взаимного влияния клиентов сети друг на друга. Кроме того, предоставляется множество других сервисов, существенно повышающих надежность сети.

·         Заменить множество различных процессорных архитектур на процессоры входящие в семейство RISC-V. Данные процессоры свободны от каких-либо лицензионных обязательств, имеют множество версий от микроконтроллера и до серверных реализаций. Есть отечественный разработчик ядер («YADRO»), есть уже готовые среды разработки (компиляторы), в том числе совместимые с выбранной представителями «Северсталь» IDE «4diac». Кроме того, RISC-V уже поддержан правительством РФ.

·         Заменить «зоопарк» различного несовместимого оборудования отечественного и зарубежного аппаратного обеспечения одним модулем «ASU_TP_SOM» (размер 50х30 мм и ценником по комплектующим менее 2тр), содержащим в себе вычислительную (процессор RISC-V), сетевую (контроллер сети ССИ на четыре порта) и контроллер цифрового интерфейса (для подключения внешней периферии). Такая замена позволит достичь полного единообразия в проектировании, кроме того, сделает базовое оборудование для АСУ ТП и робототехники максимально дешевым из-за высоких тиражей и потенциального превращения предлагаемого модуля в специализированную микросхему с ценником как у микроконтроллера (300р).

·         Предлагаемый модуль, совместно с сервисами сети ССИ, аппаратно реализует большинство составляющих стандарта МЭК 61499 и не требует наличия операционной системы. Множество модулей «ASU_TP_SOM», превращаются в распределенную вычислительную систему с внушительной производительностью (один модуль содержит минимум один 32х разрядный процессор RISC-V с частотой от 100 МГц).

·         При таком подходе от существующей АСУ ТП останутся только уровень датчиков, «актуаторов» и сервера верхнего уровня не входящие в состав аппаратуры работающей в жестком реальном времени.

Реализация стандарта МЭК 61499 с использованием модуля «ASU_TP_SOM»

·         ПО для МЭК 61499 состоит из множества функциональных блоков. Предлагаемая архитектура АСУ ТП должна состоять состоит из множества одинаковых модулей «ASU_TP_SOM», в составе которые есть вычислительный блок на основе процессора RISC-V (100МГц 8МБ памяти). В процессе компиляции можно задать какие функциональные блоки в какие модули помещать. Промежуточных вычислителей (ПЛК) не предусмотрено, каждый модуль непосредственно управляет относительно небольшим числом непосредственно подключенной периферии. Если получившегося числа вычислительных ядер не хватает, то можно подключать модули без периферии.

·         В процессе работы, функциональные блоки обмениваются данными. Модуль «ASU_TP_SOM» в своем составе содержит контроллер сети ССИ, которая позволяет создавать множество независимых виртуальных каналов с гарантией скорости и задержки передачи. Виртуальный канал имеет один источник и один или более приемников (ациклический направленный граф). Создаваемые виртуальные каналы не влияют друг на друга (от загруженности и прочего) и никак не изменяют свои свойства. Функционально виртуальный канал представляет собой цепочку FIFO, данные передаются в последовательно, переполнения буферов невозможны (кроме приемного буфера у получателя). Каждое FIFO имеем свой уникальный номер в адресном пространстве процессоров.

·         Передаваемые данные аппаратно разделены на два типа (данные, заголовок). При появлении заголовка в принимаемых данных можно установить выполнение прерывания, кроме того, заголовок используется для структурирования данных в пределах одного виртуального канала. В МЭК 16499 активация вычислений происходит посредством служебных входов (Event Execution Control), реализацию данного механизма можно завязать на прерывание (30 свободных прерываний). Наиболее оптимальным было бы иметь несколько прерываний: Цикловая синхронизация, начальная инициализация, переходы между типами функционирования. Думаю, не стоит использовать данный механизм для рядовых событий, почему этого не стоит делать можно почитать в методах проектирования цифровых схем, тут много общего.

·         Для подключения периферийных устройств служит цифровой интерфейс из 80 свободно программируемых ног и отдельный процессор RISC-V. Данные, принимаемые из виртуальных каналов, дополнительно обрабатываются (для превращения битовую последовательность нужного формата) и на выходах цифрового интерфейса формируется нужная последовательность импульсов. Формально все тоже самое, как и при работе функционального блока. Совместимость достигается через использование в качестве промежуточного «устройства» цифрового двунаправленного интерфейса с числом ног 80. Требуемые скорости относительно небольшие и встроенный процессор сможет справиться с этой задачей.

·         Возможно редактирование структуры связей и ПО функциональных блоков прямо в процессе работы.

·         В итоге получаем полностью одинаковую сетевую и вычислительную составляющую для всех проектов АСУ ТП и гибкий механизм «драйверов» для управления внешними устройствами.

Типовой сценарий работы АСУ ТП

·         Производится создания карты меж-соединений, «заливка» ПО функциональных блоков.

·         В части блоков происходит генерация тактовых, в сеть передаются слова типа «заголовок», которые при приеме вызывают прерывания, инициализирующие исполнение ПО соответствующих функциональных блоков.

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

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

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

Балыбердин Андрей Леонидович  Rutel@Mail.ru