Привет, не знаю, крутятся ли здесь те, кто с такими вещами работает. Но попробую спросить.
Проблема комплексная и касается всего - выбора "железа", платформы и средств разработки.
Короче есть большие проекты в области энергетики - тиристорные компенсаторы, электролизеры и т.д. Для них нужна система управления.
Сейчас есть то, что для каждого применения есть свой контроллер со своими средствами разработки. В итоге от проекта к проекту совт надо почти всегда переделывать. В итоге стоимость адаптации может во много раз превышать стоимость самого железа.
Тем более, что в фирме специалистов по железу нет.
Чтобы понять, что за контроллер и что от него требуется:
Процессор - мультипроцессорная система из DSP и Pentium с 1гГц тактовой частоты. Может быть 2-4 ядра.
2. Шина VME и соответсвующая стойка.
3. Ввод вывод - до 40 аналоговых сигналов с периодом сэмплирования <20мкс.
4. Цифровой ввод-вывод - до 100 сигналов с временем реакции до 1мс.
5. Коммуникационные интерфейсы - IEC61850 и все остальное.
6. Срок эксплуатации - 25лет.
Стоимость системы для одного проекта ранжируется от 20 до 100к$. Но это не главное.
Главное - что стоимость программирования высокая. И то, что процессоры меняются каждый год и менять платформу - это тоже сложно.
Также клиенты требуют проверенный код - то есть если им сказать, что код сделан в Матлабе - то это как магическое слово для них.
В настоящий момент, насколько я знаю такие монстры, как Mathworks предлагают широкий спектр средств автоматической генерации кода и я подумал, а можно ли используя эти средства добиться полной реутилизации програмных наработок и обойти устаревание плятформы.
В идеале хотелось бы быть полностью независимым от платформы - то есть использовать готовые процессорные платы, для которых софт писался бы только в матлабе. И чтобы можно было реализовывать все функции - DSP, автоматы состояний, коммуникации. Без платформо-зависимых решений.
А для систем ввода-вывода использовать стандартное железо, работающее на шине PCI или VME.
Наколько я знаю сейчас есть уйма плат для таких решений в различных форм-факторах.
В общем нужна мощная процессорная карта и система ввода-вывода в стандартных форм-факторах.
Что-то можете посоветовать?

Странно получается. Процессоры меняются каждый год ... срок эксплуатации - 25 лет... Что-то тут не то. Не то тут что-то.
Замена оборудования раз в 25 лет - за это время поменяются и требования к системе, зачем же заботиться о переносимости программ?

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

Предлагаю к просмотру небольшой видеоролик от производителя "железа", авось пригодится: для просмотра нажмите сюда.
1. Насколько я представляю себе электроэнергетику, в электрических сетях уровни напряжений в аварийном и рабочем режимах могут превосходить друг друга в десятки раз, поэтому будет лучше применить АЦП с широким входным диапазоном напряжений. АЦП для связи здесь вряд ли сгодятся.
2. Согласно стандарту МЭК61850, необходимо наличие минимум двух каналов связи сети Ethernet по 100 Мбит/с каждый: а) оптического канала для приёма данных небольшого объёма с измерительных устройств и управления дистанционными устройствами и б) второго медного или оптического канала для связи с АСУТП для съёма и сохранения различных некритичных ко времени данных, но большого объёма. Для оптического канала связи критичным показателем является время отработки алгоритма от принятия данных с измерителей до выдачи управляющего воздействия на управляемые устройства, поэтому, на мой взгляд, процессором, а тем более работающим под управлением операционной системы, задачу разбора входящих пакетов с последующей отработкой управляющего алгоритма и выдачей сетевого пакета управления при полной загрузке канала будет решить весьма сложно, а на 1 Гбит/с уже и вряд ли возможно за допустимое время. Выход тут один: аппаратно разбирать входящие сетевые пакеты, отрабатывать алгоритм и выдавать собранный сетевой пакет на управляемое устройство. Да и инженеры по энергетике мыслят к тому же схематично, что позволит довольно просто переложить алгоритмы в "Матлаб" с последующей их загрузкой в ПЛИСину. Тут и одновременность отработки многоканальных входных и выходных данных удастся решить, на мой взгляд, довольно легко. Будет дорого, но зато масштабируемо и переносимо. Удастся ли приобрести уже готовое "железо" для этой задачи? Не уверен, но при верном подходе выполнить поставленную задачу - вполне. Желаю успеха!

По обсуждаемому вопросу, на мой взгляд, может быть полезен к просмотру ещё один видеоролик со съезда молодых пытливых умов в области компьютерных наук "Defcon". Особенно любопытно выступление последнего докладчика о запуске операционной системы Linux на программном процессоре Microblaze внутри ПЛИСины. Как это применить к поставленной задаче? К примеру, можно вместо написания своих подпрограмм просто использовать линуксовые стандартные сетевые протоколы связи, например ftp, в составе своего ПО. Со временем процессоры десять раз поменяются, а "линуксовый" код уж пригодится всяко, так же как и "матлабовский". Успехов!

Кстати для обновления. Проэкт уже закрутился.
Будет система на базе VPX, состоящая из процессорного и DSP модулей.
В качестве процессора будет использоваться одноплатный комьютер на PowerPC с ОС VxWorks (можно также Intel i7 - но там проблемы по долговечности поставок). Там будут крутиться все коммуникационные стеки, и если надо не сильно быстрые алгоритмы сделанные на матлабе и с помощью автоматической генерации кода.
В качестве основной DSP лошадки для всех алгоритмов управления инверторами будет использоваться плата FPGA на Xilinx Virtex-6. Для нее ПО будет делаться на Xilinx DSP System Generator.
Чтобы вводить аналоговые данные в ФПГА будут использованы платы АЦП от различных производителей с производительностью от 50kSps до 1Msps.
Весь обмен будет производиться через PCI express.

Возможным вариантом решения могло бы быть использование высокопроизводительного ПЛК. Правда не интересовался подробными ТТХ подобных изделий по быстродействию. Но реализации на VME точно бывают. В плюсах такого решения были бы премственность кода написаного по МЭК в фирменной среде разработки приложений, поддержка производителя на очень долгий срок, возможность апгрейда вычислительных модулей.