Реклама / ООО «ИЗОЛПРОЕКТ» / ИНН: 7725566484 | ERID: 2VtzqucPabn
IPB IPB
Проектирование, монтаж, наладка, сервис

Здравствуйте, гость ( Вход | Регистрация )

- Рекомендации АВОК 5.5.1-2023
«Системы противодымной вентиляции жилых и общественный зданий»

- Рекомендации АВОК 7.8.3-2023
«Проектирование инженерных систем лабораторий»

- Рекомендации АВОК 7.10-2023
«Здания жилые и общественные. Защита от шума и вибрации инженерного оборудования»

АВОК в соц. сетях
ИНН: 7714824045
 
Добавить ответ в эту темуОткрыть тему
> Per Aspera Ad Astra.
RTV_HSB
сообщение 17.11.2018, 12:35
Сообщение #1





Группа: New
Сообщений: 5
Регистрация: 17.11.2018
Пользователь №: 351332



Покрутил новую систему Сименс - 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
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
vladvlad5
сообщение 17.11.2018, 16:13
Сообщение #2





Группа: Участники форума
Сообщений: 463
Регистрация: 15.4.2011
Пользователь №: 103833



Попыток сделать суперконтроллер для HVAC я видел уже с десяток. Все всегда упирается в рынок. Смысл делать контроллер, если его не продать.
Я видел 2-3 очень клевых решения именно для HVAC, они были просты и эффективны и по идее должны были поиметь и конкурентов и рынок, по получалось всегда наоборот.

Возьмем объем комплектной автоматики и объем индивидуальных решений, их даже рядом не поставишь. Ширпотреб рулит в силу ценника и простоты для пользователя и проектировщика.
Здесь все по прям по доктору Геб...су- примитивность завоюет большинство. Большинство всегда ошибается, потому что является дилетантами и не способны будут понять всю красоту Вашего замысла.

Между "выбрать алгоритм и нажать ОК" и "выбрать алгоритм, допилить его в СИ, отрихтовать в эмуляторе и нажать ОК" большинство выберет первое и этого большинства будет 70% рынка.
Мое субъективное мнение - анализ целевой аудитории покажет, что нужны как примитивные контроллеры, так и полнофункциональные, и смешивать их это как на калину поставить двигло от мерса и продавать за 1 800 000 руб, то есть Ваш контроллер будет специфическим изделием со всеми вытекающими.
Также я считаю, что наладка на объекте удаленно по сети намного эффективнее, чем тратить время на эмуляторы и потом на саму пуско-наладку на объекте.

Да и указанный ценник невероятно оптимистичен.
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
RTV_HSB
сообщение 17.11.2018, 17:29
Сообщение #3





Группа: New
Сообщений: 5
Регистрация: 17.11.2018
Пользователь №: 351332



vladvlad5 - практически полностью с вами соглашусь :) Куча "вы живете, а не знаете", ширпотреб рулит и т.д.

Но:

1. В части железа предлагается именно ширпотреб. Точнее - многолетний опыт разработки контроллеров сконцентрирован здесь, в цену калины впихнут мерс. Все, что перечислено - доведено до схемы, делается разводка. Ценник - сумма стоимостей деталей, производства. Плюс прибыль. Надеюсь :)

2. В части программ - тоже ширпотреб, точнее многоуровневый ширпотреб, для стандартных систем - выбор из набора готовых, для разработки - библиотека объектов, инструментальная система, понятная и доступная интегратору, технологу, наладчику. Для новых областей - разработка новых мета-объектов на Си. В удобнейших профессиональных инструменталках.
С вашей оценкой 70% согласен, и они будут предложены. Еще 10% - небольшая доработка. Здесь все давно известно, нечего изобретать велосипед. Но ведь скучно же :) Поэтому и предлагается расширение этого подхода, рассмотрение "в пределе" - какой "ширпотреб" возможен в каждой части. Предложены варианты во всем спектре. Вместо осточертевших "заказчик хочет на FBD", поскольку он где-то слышал, что это - круто :)

3. В части отладки... Рассмотрим случай, когда алгоритм отличается. Я до сих пор удивляюсь - казалось бы есть несколько сотен готовых систем. Приходит заказчик и - готовые не подходят, нужна модификация :)
Пусконаладка на объекте - ждем лета, запускаем режим "Лето", ждем зиму - запускаем режим "Зима". Сидим час, ждем, пока регуляторы выйдут на режим. Как проверить все аварии? Все сочетания входных данных, аварий, режимов и т.д.? Простая система - хорошо. Ну а если рекуператор, первый подогрев водяной калорифер, увлажнитель сотовый, второй подогрев на многоступенчатом ТЭН, многоступенчатый фреоновый охладитель с управлением по скорости, вентиляторы, насосы резервированные - сколько сидеть на объекте? Месяц зимой и месяц летом? Или рассказать заказчику через пару дней, что "все хорошо" и - авось не вылезет ничего? Я уже лет 6 использую эмулятор объекта, конечно, не в автоматическом режиме, в полуручном, прогоняю полную проверку всех сочетаний режимов, переходных режимов, аварий - максимум за день-полтора. Замечаний от наладчиков/заказчиков - по пальцам можно пересчитать. Никто не говорит, что наладчики потом ничего не делают. Но если давно работают с нашими системами, то делают - меньше, знают, что можно не проверять.
=======
Т.е. вопросы именно в части нового, нового угла зрения и новых подходов. Опять же большинство предложенного где-то в том или ином виде реализовано, но - по частям и частично. Тот же мультимастер на RS485 - Профибас, но это же опять хвост разработки 90-х, когда железо было совсем другое. Интересно было бы обсудить "предельный вариант", что было бы в идеале :) Понятно, что с нашими сроками "вчера" :) для этого нового железа будут применяться стандартные решения, портироваться существующее ПО. Но, хотелось бы как минимум обсудить "идеал". А может - и сделать когда-нибудь. В гараже :) Уж очень мне не понравился ТИА Портал :):):)
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
vladvlad5
сообщение 17.11.2018, 18:51
Сообщение #4





Группа: Участники форума
Сообщений: 463
Регистрация: 15.4.2011
Пользователь №: 103833



Наладка на объекте это, как мне видится, работа наладчика и он должен крутить регуляторы, а в ПО должна быть предоставлена такая возможность.
Если мы сейчас говорим про вентиляцию, то большинство алгоритмов весьма просты и эмуляция в этом случае, мо моему субъективному мнению не требуется.
Эмуляция (мне больше нравиться термин симуляция) нужна для того, чтобы проверить работоспособность алгоритма и не более.
На объекте может быть холодный теплоноситель, забитый калорифер, чихающий насос, кетайский привод клапана, жуткие наводки и все это Вы будете учитывать в симуляторе?
Я считаю, что нужно прогнать алгоритм в симуляторе, отработать все интимные моменты и на этом всё.

Был один достаточно успешный производитель, контроллеры простые, универсальные, по дефолту жесткие, но можно было прописать свой алгоритм и для этого нужно было шарить СИ, то есть в принципе, можно сказать, что они свободно программируемые... но я бы так не сказал. Разумеется, никакого софта для удобного сотворения проектов не было, все писалось сразу в код. Была база около 300 алгоритмов по вентиляции и ИТП с предельно конкретным описание каждого, включая ПЗ в проект и чертежи в автокаде. Изначально контроллеры работали локально, но потом появилась сетевая версия, производитель стал пилить свою скаду под это и на этом все закончилось. В чем была прелесть этих контроллеров - низкая цена, полпроекта бонусом и возможность заказать на заводе тот алгоритм, который нужен. Далее - подал питание, проставил часы. нажал пуск и все работает. Из 40 установок, которые я своими руками запустил, коэффициенты ПИД я настраивал только на одной. Вне зависимости от производительности установки она входила в режим буквально за 3-4 минуты. Если готового алгоритма нет - завод его сделает для тебя и добавит в базу. Это было суперудобно и до сих пор я считаю эти контроллеры лучшими в своем сегменте.

Другой производитель, с которым сейчас работаю - у него есть возможность по TCP? запускать и редактировать проекты на удаленном контроллере и это, я считаю одной из самых необходимых вещей в устройствах такого ценового сегмента.

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

Будет контроллер жить или нет решает рынок, а рынок это люди, а люди имеют градацию профессиональных знаний и большинство из них, как я уже говорил, не являются экспертами. Если мануал их не отпугнет и они в 3 секунды поймут что это ПРОСТО, контроллер займет свою нишу, а может быть и будет в ней доминировать. Это будут те самые 80% легких продаж, а оставшиеся 20 придут на профи с их эксклюзивными запросами.
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
RTV_HSB
сообщение 17.11.2018, 20:18
Сообщение #5





Группа: New
Сообщений: 5
Регистрация: 17.11.2018
Пользователь №: 351332



Согласен практически со всем, что вы сказали. Просто мы с вами говорим о разных сторонах одного и того же - вы говорите о тех программах, которые дошли до вас как до наладчика, а я - которые дошли до меня как программиста. Ваших 70%, моих - 10%. Суммируем то, что вы говорите и то, что я:

70% задач - интегратор, технолог/конструктор - выбрал готовое решение, на объекте наладчик решил проблемы забитых калориферов и наводок. Кстати, это одна из главных проблем при принятом в стране полном игнорировании требований ЭМС в силовухе, прокладке кабелей и т.п., поэтому и пошли на полную гальваническую развязку.

20% - небольшая рихтовка, добавилась/убавилась авария, изменился уровень сигнала, стало не 3 секции ТЭН, а 4. Были пропорциональные ступени ТЭН, стали 3 дискретных и одна пропорциональная. В предлагаемой системе интегратор, технолог/конструктор или наладчик - в скрипте (или в графическом представлении) делают изменения в рамках понятных им вещей. Например, для объекта ТЭН "ТЭН_2" убирают флажки "пропорциональное управление" в 3-х секциях. Компилируют и прошивают прошивку. "Компилируют" здесь повторюсь - просто трансляция скриптового языка во внутреннее представление. Отправляется на объект, наладчик проверяет и при необходимости корректирует.

7% - серьезная модификация существующей программы. Например - в приточно-вытяжную добавляется увлажнитель (условный пример, понятно, что и это скорее к 70%). В предлагаемой системе интегратор, технолог/конструктор или наладчик в графической среде добавляет в систему объект "Увлажнитель", настраивает его свойства - тип, проключение на объекты "Входы" и "Выходы", а действие этого объекта "Регулирование влажности" включает в узел диаграммы состояний "Зима-Работа". Трансляция, проверка на симуляторе объекта, передача на объект, наладчик проверяет и при необходимости корректирует.

3% - новая система, нет каких-то объектов в библиотеке мета-объектов. Вот здесь только появляется профессиональный программист на Си, работающий на профессиональной IDE. Но - он разрабатывает только этот объект в соответствии с набором стандартных правил и шаблонов. В дальнейший процесс - к предыдущему пункту добавляется отладка объекта средствами IDE.

Ставится задача именно "мануал их не отпугнет и они в 3 секунды поймут что это ПРОСТО" для каждой из этих групп.

Возможно, я ошибаюсь, но пока не существует такой целостной системы. Если кто-нибудь знает - дайте ссылку.

В части "удаленного" редактирования и запуска на удаленном контроллере - именно поэтому сразу закладывается сеть. Прошивка, отладка, пусконаладка - по сети удаленно. В этом случае добавляется шлюз либо USB-RS485, либо Ethernet-RS485. Стоимость сетевого и безсетевого контроллера при сети RS485 отличается незначительно, поэтому принято сразу так.

В части ПИД-регуляторов для HVAC - это великий миф, на котором зарабатывают разработчики. ПИД-регулятор для стандартного регулирования температуры в HVAC не нужен и более того - вреден. Но все так же вешается лапша на уши заказчиков - о синтезе регулятора, об отклике системы, о полюсах САР, о единичном воздействии - заплатите нам и мы построим модель вашего объекта и по ней рассчитаем коэффициенты и будет вам щастье :) Тактично умалчивая, что любой набор коэффициентов работает только при одном наборе внешних условий - температур, потоков, влажностей и многих других факторов. Возможна только одна универсальная настройка ПИД-регулятора, которая работает при всех вариациях условий.
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
vladvlad5
сообщение 17.11.2018, 21:23
Сообщение #6





Группа: Участники форума
Сообщений: 463
Регистрация: 15.4.2011
Пользователь №: 103833



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

Я давно забросил наладку и уже лет 10 как проектирую, автоматику в том числе. В год автоматизирую от 50 до 350 установок и мне чем проще, тем лучше. А еще хочу осветить достаточно узкую тему.

Весь этот объем - это локальные установки, так как объекты - жилье и социалка. С жильем все понятно, чем дешевле тем лучше , а вот с социалкой - ДОУ, школы, поликлиники немного сложнее.

Смотрите, какая штука получается - делаю проект на шкаф, спецификация, дальше смета на его монтаж и пуско-наладка (какие то копейки по расценкам). Это идет в экспертизу, сметы проверяются и защищаются, и потом эта сумма идет на аукцион.
Монтажники выигрывают, вешают и подключают шкаф и ничего не происходит. Они тут же понимают, что нужно залить проект, который еще нужно где-то взять и еще проверить на соответствие и еще сделать кучу телодвижений, а поняв, что это не так просто, они начинают писать гневные письма заказчику, типа статья ПРОГРАММИРОВАНИЕ не осмечена и давайте допсоглашение заключим, соответственно заказчик тут же меня и ...
Я с этим пару раз сталкивался и поэтому остановился на том, что я закладываю в проект готовый шкаф, который нужно только подключить и нажать Пуск.

Поэтому я яростный поборник простоты и ратую за нее всецело, поэтому прошу меня извинить, если где-то я был чересчур критичен.
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
RTV_HSB
сообщение 17.11.2018, 21:47
Сообщение #7





Группа: New
Сообщений: 5
Регистрация: 17.11.2018
Пользователь №: 351332



Набор опций разный - в описываемом вами случае вы даете задание программисту добавить еще одно свойство в объект "электрокалорифер". Или сделать еще один объект, много свойств в одном объекте тоже плохо, запутывает.

Это да :) У нас до сих пор воспринимают только материальные вещи. Заплатить за то, чего нельзя пощупать руками - не понимают.

По-моему мы нормально обсудили, спасибо, при письменном взаимодействии обычные шероховатости, пока не выработан "общий словарь".

Я тоже когда-то понял, что хорошее решение - простое решение. Но очень сложно его найти и реализовать.
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
RTV_HSB
сообщение 18.11.2018, 18:16
Сообщение #8





Группа: New
Сообщений: 5
Регистрация: 17.11.2018
Пользователь №: 351332



Версия 2.
======
Хотел сухой остаток обсуждений суммировать в первой записи, но редактирование блокировано.
Буду периодически сумму выкладывать. Если вам интересны поднятые темы - включайтесь в обсуждение.
Мечтать - не вредно, вредно - не мечтать :)

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

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

0.>>>>>>>>>>>>>>>>>> Цель.
Выработать идеальную систему комплексного решения для задач HVAC и подобных.
Ну... пусть не идеальную, но более современную, чем все эти дети 60-х - Кодесис, ТИА Портал и остальные многочисленные вариации на эту тему.
Какая - идеальная?

Цитата(vladvlad5 @ 17.11.2018, 18:51) *
Будет контроллер жить или нет решает рынок, а рынок это люди, а люди имеют градацию профессиональных знаний и большинство из них, как я уже говорил, не являются экспертами. Если мануал их не отпугнет и они в 3 секунды поймут что это ПРОСТО, контроллер займет свою нишу, а может быть и будет в ней доминировать. Это будут те самые 80% легких продаж, а оставшиеся 20 придут на профи с их эксклюзивными запросами.

1.>>>>>>>>>>>>>>>>>>> Типовые сценарии.
70% задач - интегратор, технолог/конструктор - выбрал готовое решение, на объекте наладчик решил проблемы забитых калориферов и наводок. Кстати, это одна из главных проблем при принятом в стране полном игнорировании требований ЭМС в силовухе, прокладке кабелей и т.п., поэтому и пошли на полную гальваническую развязку.

20% - небольшая рихтовка, добавилась/убавилась авария, изменился уровень сигнала, стало не 3 секции ТЭН, а 4. Были пропорциональные ступени ТЭН, стали 3 дискретных и одна пропорциональная. В предлагаемой системе интегратор, технолог/конструктор или наладчик - в скрипте (или в графическом представлении) делают изменения в рамках понятных им вещей. Например, для объекта ТЭН "ТЭН_2" убирают флажки "пропорциональное управление" в 3-х секциях. Компилируют и прошивают прошивку. "Компилируют" здесь повторюсь - просто трансляция скриптового языка во внутреннее представление. Отправляется на объект, наладчик проверяет и при необходимости корректирует.

7% - серьезная модификация существующей программы. Например - в приточно-вытяжную добавляется увлажнитель (условный пример, понятно, что и это скорее к 70%). В предлагаемой системе интегратор, технолог/конструктор или наладчик в графической среде добавляет в систему объект "Увлажнитель", настраивает его свойства - тип, проключение на объекты "Входы" и "Выходы", а действие этого объекта "Регулирование влажности" включает в узел диаграммы состояний "Зима-Работа". Трансляция, проверка на симуляторе объекта, передача на объект, наладчик проверяет и при необходимости корректирует.

3% - новая система, нет каких-то объектов в библиотеке мета-объектов. Вот здесь только появляется профессиональный программист на Си, работающий на профессиональной IDE. Но - он разрабатывает только этот объект в соответствии с набором стандартных правил и шаблонов. В дальнейший процесс - к предыдущему пункту добавляется отладка объекта средствами IDE.

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

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

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

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

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

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

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

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

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

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

Добавить ответ в эту темуОткрыть тему
2 чел. читают эту тему (гостей: 2, скрытых пользователей: 0)
Пользователей: 0

 

Реклама
ООО «Арктика групп» ИНН: 7713634274


ООО «УНИСПЛИТ» ИНН: 6453155081 erid:2VtzquYEfbY

Последние сообщения Форума





Rambler's Top100 Rambler's Top100

RSS Текстовая версия Сейчас: 28.3.2024, 13:13