Per Aspera Ad Astra. Опции

[RTV_HSB]

Покрутил новую систему Сименс - TIA Portal... Если двумя словами выразить впечатление - халтурщики и вредители :) Пособие - как не надо разрабатывать инструментальные системы. Не тянет даже на дипломную работу студента Академии Мухосранска Автоматизации Всего :) И святая простота ответов на вопросы - у нас есть платные курсы, записывайтесь, ответим и обуем, тьфу, обучим. Денех - нет. Но - держусь :) Через некоторое время возник вопрос - а возможна ли идеальная система для HVAC и близких?

Какая - идеальная?
Но, какой - критерий идеальности? Будем реалистами - исключение звеньев в цепочке от идеи до реализации. Программист - не нужен :)
Далее - простота. "Простота и надёжность служили верным признаком устройства" :)
Самое сложное решение - простое.
Закон Парето 80/20. 80% задач решаются 20% затрат. Делаем для этих 80%.
Следующий критерий... Стоимость.
Название. Победа? Беда? Уже было :) О - Astra. Соответственно - Per aspera ad Astra :)

Суммируя:
1. Программист - не нужен.
2. Простота.
3. 80/20.
4. Стоимость.

Начнем с достаточно очевидного(?). Железо.
Ресурсов контроллера д.б. достаточно для автоматизации простой приточки. Модули расширения и сеть должны позволять автоматизировать систему на несколько тысяч входов/выходов. Сеть - оптимальная по соотношению стоимость/трафик, стоимость/длина линии.
Аналоговые/дискретные входы - 8, напряжение/сопротивление/ток.
Дискретные выходы - 8, реле/оптроны(ШИМ).
Аналоговые выходы - 6, 0-10в.
Интерфейс 1-Wire (300м).
Часы.
Журнал на несколько лет.
Энергонезависимая память с неограниченным кол-м перезаписей.
Кнопки.
Дисплей типа 320х240.
RS-485 на модули расширения ввода/вывода. Виртуальные входы/выходы - минимум 256 каждого типа.
RS-485 на сеть контроллеров. Сетевые переменные, параметры. Шлюз на Ethernet. Сетевые пульты. Мультимастер, равномерное распределение трафика, "все со всеми", выделение % трафика, до 64 устройств в сети, сохраняет работоспособность при выпадании из сети любых устройств. 9600 - 4км, 512Кбит-500м.
Гальваническая развязка входов/выходов, сетевых интерфейсов.
Стоимость контроллера - 100$

Вопрос - достаточно ли такой конфигурации и стоимости для решения 80% задач HVAC? Если нет - чего не хватает?

Язык программирования. Язык программирования без программиста :) Объектно-ориентированное программирование. Должно быть. Где-то читал, что сам автор ООП говорил, что многие реализации ООП не имеют к ООП никакого отношения. И свет в нашем окошке - IEC 61131-3. На FBD невозможно разработать сложную систему, все равно, что системотехника обязать разрабатывать железо только с использованием счетчиков, триггеров, И, НЕ, ИЛИ и т.п. ST как был Паскалем для уроков информатики, так и остался. Почему же? Ну... все при деле. Программисты программируют, консультанты констультируют, платные курсы платят, тьфу - наоборот :). Все при деле. Вся эта пое, тьфу, конструкция из решений 60-х выезжает только за счет framework-ов, библиотек, готовых решений. Если не ставить задачу "все при деле" и совместимости с прошлым, то что может быть? Откуда начинать, что нельзя убрать? Описание технологии, последовательности действий. В основе всего лежит математика. Как описывается работа системы: включаем насос, открываем клапан, ждем прогрева калорифера. Дождались - открываем заслонки, ждем открытия. Дождались - включаем вентиляторы. Старые добрые конечные автоматы и графы состояний. Любая система HVAC описывается в рамках этой математической модели, согласны?
ООП и только ООП. Что такое объект? у нас - вход, выход, калорифер, заслонка, вентилятор и т.д. У объекта - свойства, условия, ссылки и действия. Объект - мета-набор условий, ссылок, свойств и действий.
Актуализация объекта - конкретизация мета. Диаграмма состояний - тоже объект. Программа - набор диаграмм состояний.
Программа - скрипт. Пишется языком (русским :)), понятным технологу/наладчику, в их терминологии, они и будут программистами :)

Движок. Интерпретатор - наше все. OSLess ОС :) Целевой алгоритм - граф состояний в виде таблиц данных. Любой алгоритм может быть реализован в виде кода или в виде данных. Нам - в данных :)

Инструментальная система. GCC & Linux, Linux & GCC. Eclipse IDE. На банга :) Нет, хорошо быть линукс-гуру с окладом содержания в 3 килобакса. Но это - не наш путь :) Скрипты пишем в текстовом редакторе. Простой компилятор переводит скрипты во внутреннее представление.

Разработка новых объектов. Нет объекта в библиотеке объектов. На чем пишем. FBD & ST не предлагать :) Старый добрый Си. Инструменталка. Если объект идет как отдельная перемещаемая программа, то она и транслируется отдельно. Возьмем лучшие инструменталки - IAR, Keil. Для IAR и Keil до 32К кода инструменталка - бесплатна. В 32К можно впихнуть любой объект (?).

Отладка. Для отладки наверное достаточно отображать состояния всех объектов, что при концепции интерпретатора таблиц данных достаточно несложно.

Тестирование целевых алгоритмов. "Тестировать надо на объекте" - не наш путь. Все должно тестироваться "на столе". Так же на скриптах пишется эмулятор объекта и сценарий тестирования. В автоматическом режиме прогоняются тесты и выдается диагностика ОК/НЕ-ОК.

Для гурманов. Поверх скриптов делается графическая оболочка.

Для ленивых - генератор программ. Нажимаем кнопки - заслонка тип 1, калорифер водяной тип 3, датчик температуры Pt1000,..., нажимаем кнопку Готово, на выходе - целевая программа, эмулятор объекта и сценарий тестирования. Включаем тестирование, получаем протокол тестирования. Все режимы Зима, Лето и т.д., все аварии во всех режимах - все проверено.

Я новичок, вопросы к читающим - опытным, неопытным и плавающим по морям :)
- в чем - ошибки?
- есть готовое и лучше?
- закроет ли система Astra 80% задач HVAC и близких?
- что - не так?
- что - упущено?

Сообщение отредактировал RTV_HSB - 17.11.2018, 12:38

[RTV_HSB]

Покрутил новую систему Сименс - TIA Portal... Если двумя словами выразить впечатление - халтурщики и вредители :) Пособие - как не надо разрабатывать инструментальные системы. Не тянет даже на дипломную работу студента Академии Мухосранска Автоматизации Всего :) И святая простота ответов на вопросы - у нас есть платные курсы, записывайтесь, ответим и обуем, тьфу, обучим. Денех - нет. Но - держусь :) Через некоторое время возник вопрос - а возможна ли идеальная система для HVAC и близких?

Какая - идеальная?
Но, какой - критерий идеальности? Будем реалистами - исключение звеньев в цепочке от идеи до реализации. Программист - не нужен :)
Далее - простота. "Простота и надёжность служили верным признаком устройства" :)
Самое сложное решение - простое.
Закон Парето 80/20. 80% задач решаются 20% затрат. Делаем для этих 80%.
Следующий критерий... Стоимость.
Название. Победа? Беда? Уже было :) О - Astra. Соответственно - Per aspera ad Astra :)

Суммируя:
1. Программист - не нужен.
2. Простота.
3. 80/20.
4. Стоимость.

Начнем с достаточно очевидного(?). Железо.
Ресурсов контроллера д.б. достаточно для автоматизации простой приточки. Модули расширения и сеть должны позволять автоматизировать систему на несколько тысяч входов/выходов. Сеть - оптимальная по соотношению стоимость/трафик, стоимость/длина линии.
Аналоговые/дискретные входы - 8, напряжение/сопротивление/ток.
Дискретные выходы - 8, реле/оптроны(ШИМ).
Аналоговые выходы - 6, 0-10в.
Интерфейс 1-Wire (300м).
Часы.
Журнал на несколько лет.
Энергонезависимая память с неограниченным кол-м перезаписей.
Кнопки.
Дисплей типа 320х240.
RS-485 на модули расширения ввода/вывода. Виртуальные входы/выходы - минимум 256 каждого типа.
RS-485 на сеть контроллеров. Сетевые переменные, параметры. Шлюз на Ethernet. Сетевые пульты. Мультимастер, равномерное распределение трафика, "все со всеми", выделение % трафика, до 64 устройств в сети, сохраняет работоспособность при выпадании из сети любых устройств. 9600 - 4км, 512Кбит-500м.
Гальваническая развязка входов/выходов, сетевых интерфейсов.
Стоимость контроллера - 100$

Вопрос - достаточно ли такой конфигурации и стоимости для решения 80% задач HVAC? Если нет - чего не хватает?

Язык программирования. Язык программирования без программиста :) Объектно-ориентированное программирование. Должно быть. Где-то читал, что сам автор ООП говорил, что многие реализации ООП не имеют к ООП никакого отношения. И свет в нашем окошке - IEC 61131-3. На FBD невозможно разработать сложную систему, все равно, что системотехника обязать разрабатывать железо только с использованием счетчиков, триггеров, И, НЕ, ИЛИ и т.п. ST как был Паскалем для уроков информатики, так и остался. Почему же? Ну... все при деле. Программисты программируют, консультанты констультируют, платные курсы платят, тьфу - наоборот :). Все при деле. Вся эта пое, тьфу, конструкция из решений 60-х выезжает только за счет framework-ов, библиотек, готовых решений. Если не ставить задачу "все при деле" и совместимости с прошлым, то что может быть? Откуда начинать, что нельзя убрать? Описание технологии, последовательности действий. В основе всего лежит математика. Как описывается работа системы: включаем насос, открываем клапан, ждем прогрева калорифера. Дождались - открываем заслонки, ждем открытия. Дождались - включаем вентиляторы. Старые добрые конечные автоматы и графы состояний. Любая система HVAC описывается в рамках этой математической модели, согласны?
ООП и только ООП. Что такое объект? у нас - вход, выход, калорифер, заслонка, вентилятор и т.д. У объекта - свойства, условия, ссылки и действия. Объект - мета-набор условий, ссылок, свойств и действий.
Актуализация объекта - конкретизация мета. Диаграмма состояний - тоже объект. Программа - набор диаграмм состояний.
Программа - скрипт. Пишется языком (русским :)), понятным технологу/наладчику, в их терминологии, они и будут программистами :)

Движок. Интерпретатор - наше все. OSLess ОС :) Целевой алгоритм - граф состояний в виде таблиц данных. Любой алгоритм может быть реализован в виде кода или в виде данных. Нам - в данных :)

Инструментальная система. GCC & Linux, Linux & GCC. Eclipse IDE. На банга :) Нет, хорошо быть линукс-гуру с окладом содержания в 3 килобакса. Но это - не наш путь :) Скрипты пишем в текстовом редакторе. Простой компилятор переводит скрипты во внутреннее представление.

Разработка новых объектов. Нет объекта в библиотеке объектов. На чем пишем. FBD & ST не предлагать :) Старый добрый Си. Инструменталка. Если объект идет как отдельная перемещаемая программа, то она и транслируется отдельно. Возьмем лучшие инструменталки - IAR, Keil. Для IAR и Keil до 32К кода инструменталка - бесплатна. В 32К можно впихнуть любой объект (?).

Отладка. Для отладки наверное достаточно отображать состояния всех объектов, что при концепции интерпретатора таблиц данных достаточно несложно.

Тестирование целевых алгоритмов. "Тестировать надо на объекте" - не наш путь. Все должно тестироваться "на столе". Так же на скриптах пишется эмулятор объекта и сценарий тестирования. В автоматическом режиме прогоняются тесты и выдается диагностика ОК/НЕ-ОК.

Для гурманов. Поверх скриптов делается графическая оболочка.

Для ленивых - генератор программ. Нажимаем кнопки - заслонка тип 1, калорифер водяной тип 3, датчик температуры Pt1000,..., нажимаем кнопку Готово, на выходе - целевая программа, эмулятор объекта и сценарий тестирования. Включаем тестирование, получаем протокол тестирования. Все режимы Зима, Лето и т.д., все аварии во всех режимах - все проверено.

Я новичок, вопросы к читающим - опытным, неопытным и плавающим по морям :)
- в чем - ошибки?
- есть готовое и лучше?
- закроет ли система Astra 80% задач HVAC и близких?
- что - не так?
- что - упущено?

Сообщение отредактировал RTV_HSB - 17.11.2018, 12:38