Использование ПЛК в серийных изделиях: прошивки и таргеты

Мне кажется, что обсуждаемые здесь ПЛК чаще всего используются в уникальных проектах. Конечно, каждый разработчик опирается на свои наработки, но проекты обычно не повторяются "один в один".

У меня же стоит задача использовать ПЛК в оборудовании, которое должно выпускаться некоторое время мелкими партиями или единичными образцами - но по одной и той же документации.

И здесь возникает ряд вопросов, которые мало волнуют разработчиков уникальных проектов.

Вот один из них: новые прошивки ПЛК и, соответственно, новые таргет-файлы для компиляции программ. Поправьте меня, если я неправ (хотелось бы!), но пока я понял так:

1. Появляется ПЛК с новой прошивкой, он корректно работает только при установке соответствующего (нового) таргет-файла, а смена таргет-файла ОДНОЗНАЧНО уничтожает конфигурацию ПЛК в проекте.


2. Никаких способов автоматического переноса конфигурации ПЛК из старого проекта (со старым таргет-файлом) в новый проект (с новым таргет-файлом) - попросту не существует.

Это так? Это означает, что через месяц я куплю новый ПЛК, в котором что-то улучшено и стоит новая прошивка, он начнет мне строить мелкие пакости из-за любви к новому таргет-файлу - и веники? Я беру работающий проект, ставлю новые таргет-файлы и начинаю рисовать конфигурацию ПЛК?

Пожалуйста, скажите мне, что я недочитал-недоучил-недопонял...

1. Прошивка и Target - вещи взаимосвязанные. НО!!!. Естественно мы думаем о пользователях, и стараемся без надобности версию Target не менять. Например уже 4 прошивки для ПЛК работают с одним и тем-же Target файлом версии 2.10 (target не менялся, по моему, уже около 1,5 лет). То есть выход новой прошивки - не всегда выход нового Target-файла. И никогда наоборот (сам по себе Target не появляется). Изменение Target файла вызывается только одним - увеличение функционала области памяти (так и появился подмодуль статистика), исправление распределения данных в нижеуказанной области.
2. Есть золотое правило: работает - не лезь. Так, я знаю несколько контор, которые сделали проект на версии 2.03. У них все отлично работает. Новые контроллеры они возвращают на версию 2.03 и удачно работают.
3. Автоматического переноса нет. Да и не правильно это, если Target сменился. Где-то одна буква или один адрес не совпадет (наложится при новом перераспределении области входов-выходов), и все... Мало того, что некоторые параметры просто перестали бы работать, так и найти причину ошибки при конфигурации в 100-150 переменных НЕРЕАЛЬНО.
4. Есть метод переноса, правда я его не приветствую, когда неким образом конфигурация экспортируется, а потом руками исправляется. Наши программисты где-то на форуме о нем рассказывали.
5. Ну и как Вы правильно заметили - для создания масштабируемых решений стоит немного больше сделать один раз в начале, и сложные\критичные узлы проделать самому, не полагаясь на PLC Configuration. Мало кто из производителей ПЛК с CoDeSys делает в конфигурации обмен по ModBus... В основном программно.

Спасибо за обстоятельный ответ. Хотя и жаль, что я не знал всего этого год назад...
Что ж, будем жить с новыми для меня реалиями.
Позвольте несколько уточнений.

Цитата:

---

Сообщение от Николаев Андрей

уже 4 прошивки для ПЛК работают с одним и тем-же Target файлом версии 2.10 (target не менялся, по моему, уже около 1,5 лет)

---

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

Цитата:

---

Сообщение от Николаев Андрей

3. Автоматического переноса нет. Да и не правильно это, если Target сменился. Где-то одна буква или один адрес не совпадет (наложится при новом перераспределении области входов-выходов), и все... Мало того, что некоторые параметры просто перестали бы работать, так и найти причину ошибки при конфигурации в 100-150 переменных НЕРЕАЛЬНО.

---

Да что Вы такое говорите, уважаемый? Категорически не согласен в самом подходе. Ручками переписывать - вот это источник ошибок! А автоматическая процедура ДОЛЖНА БЫТЬ сделана так, чтобы все учесть. Это уж, извините, тем пацанам нужно руки мыть, что таргеты строчат.
Есть кусок проекта: Конфигуратор ПЛК называется :) Как он возникает? Я вписываю в определенные места (на экране редактора) буковки и сопровождаю это Энтером или сменой фокуса от мышки. И как-то это так укладывается в проекте, что потом компилятор распарсирует всю эту лабуду и получает исполняемый код. Вот этот момент, укладывание в проект - почему туда нельзя автоматически впихнуть подобный же кусок из другого проекта? Если при таком впихивании возникнет неоднозначность, связанная с изменением таргета - так создатели нового таргета и должны такой момент учесть! На худой конец, предупредить пользователя, что вот такой-то фрагмент не конвертирован автоматически.
Убей, не пойму, какие тут проблемы. Автоматически конвертируется ПАЛ в СЕКАМ, ДЖИПЕГ в ПЭЭНГЭ, Гугль уже голос переводит на ходу, трансверситы вообще такое меняют! ... А вы свой продукт обновляете и не можете сделать нормальный сервис по апгрейду. Ребята, поделитесь своими проблемами! Мож, подскажем :)

Цитата:

---

Сообщение от Николаев Андрей

4. Есть метод переноса, правда я его не приветствую, когда неким образом конфигурация экспортируется, а потом руками исправляется. Наши программисты где-то на форуме о нем рассказывали.

---

Любезный, ссылочку очень хотелось бы!

Цитата:

---

Сообщение от Николаев Андрей

5. Ну и как Вы правильно заметили - для создания масштабируемых решений стоит немного больше сделать один раз в начале, и сложные\критичные узлы проделать самому, не полагаясь на PLC Configuration.

---

Дык... Предупреждать же надо. Одно дело, когда нешаблонно мыслящий Валенок с подковыкой чего-то буркнет, а другое - напишите четко, что для ответственных проектов, которые предполагается развивать, нужно самому строить обмен. Хотя, честно, хочется и возразить: лучше сделать апргейдопригодную модель. Вы же, как организация, развиваетесь. Эва, сколько там уже красивых модулей, возможностей и прочего появилось за последние год-два! Читаешь - душа радуется, что российский производитель такое вытворяет. Так не забывайте и про древние косяки. Пользователь не должен об эти косяки бить колени.

Согласен с уважаемым drvlas!! Люблю программировать на овновских ПЛК, но косяки с таржетами попили крови не мало. Особенно когда клиент попалил ПЛК с проектами 2008, а новый ПЛК залить его он сам не смог и высылал мне все это кино. Пришлось вспоминать через 3 года чего это я там писал, тогда 8-(

1. Повторяю в очередной раз вопрос (ибо не силен во внутренностях КДС) - а почему нельзя было нумеровать таргеты???? Т.е. чтобы в конфигурации КДС было скажем ПЛКхх 1.0, 1.5, 2.0, .....
2. Ну и про экспорт-импорт - регулярно развлекаюсь. Он для этого и придуман. Вырезать и собирать модули в текстовом редакторе. А по сути вопроса - Экспорт-Сброс-Импорт.

Развиваю вопрос применения ПЛК100 в серийных средствах измерительной техники.

Наш госстандарт требует аттестации способов защиты программного обеспечения, отвечающего за измерительную часть. При этом ссылаются на некий российский документ РД50, который устанавливает подобные же требования к защите ПО.
В устных пояснениях люди рассказывают, что, мол, у немцев есть какие-то специальные шлюзы, через которые только и можно залить прогу. И эти шлюзы можно физически закрыть и опломбировать. Да еще и заливку делают неким шифровальщиком (навешали, однако, ребята метрологам лапши на уши!).
КАРОЧИ, муть полнейшая, но что делать. Нужно убедить товарищей метрологов, что тетка на мельнице нашу программу вот так запросто не подправит.

Подскажите, плз, как это решается с ПЛК100? В первую очередь, конечно, жду ответа от представителей ф.ОВЕН, но буду благодарен за участие и коллег-внедренцев.

защита плк от перепрограммирования неавторизованным персоналом?... использовать сейфовый шкафчик с проверкой отпечатков пальцев при полном отсутствии связи с внешним миром

Цитата:

---

Сообщение от drvlas

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

---

подправить не подправит, но залить свою при очень большом желании сможет

Вам шутки шутить...

Я свое отношение к этой паранойе уже высказал. Но вопрос не в целесообразности. Нужно тупо выполнить требования. Без фанатизма (ибо требования идиотские), но и без пофигизма.

Уверен, что российские коллеги уже сталкивались с этой задачей.

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

Цитата:

---

Сообщение от drvlas

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

---

Поподробней, пожалуйста.
Вы с поддержкой цифровой подписи типа стандарта 21 CFR 11 не путаете?