ТЗ на разработку собственного контроллера для проекта

[Wagan]

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

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

Намечу несколько основных на мой взгляд позиций будущего ТЗ, которые стоит уточнить и определить в первую очередь, так как они могут сильно влиять на стоимость и сроки разработки.

1. Требования к конструкции
Габаритные размеры, размещение компонентов и разъемов для коммуникации с внешним миром.
Исполнение корпуса.

2. Требования к интерфейсам
Перечень с краткими пояснениями по применению.

3. Требования к операционной системе
Есть, нет, если есть, то какая и т.п.

4. Требования по питанию
Тип, значение, наличие внешнего БП или встроенного.

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

[sergejey]

Есть пара вопросов перед обозначением требований. Точнее, мне видятся варианты устройств, поэтому хотелось бы решить, что мы обсуждаем:

1. Контроллер уровня производительности ПК который может вместить в себя MajorDoMo
2. Контроллер, который работает независимо либо совместо с головной системой на MajorDoMo (как MegaD или Узел автоматики)

В зависимости от этого надо будет думать дальше, т.к. первый вариант гораздо более требовательный к железу нежели второй.

[Wagan]

К счастью MajorDoMo работает на таких контроллерах, как BeagleBone или других, с похожим по производительности процессором. Следовательно, мы можем сделать контроллер, выполняющий роль сервера для системы. Для масштабирования можно предложить два режима работы: сервер и полевой контроллер. Такой подход позволит применять в сложных системах (для больших объектов) сразу несколько наших железок, одна из которых будет выполнять роль сервера для работы MajorDoMo, а все остальные контроллеры - для работы с внешним оборудованием.

[shemnik69]

Wagan! А если все таки раздельно т.е обособленные самодостаточные устройства.
Поясню. Контроллер это промежуточное устройство между датчиком и центральным (ЦПУ) где и размещается MD. на контроллер пусть он будет как черный ящик где входа и выхода будет отведена задача пролучения сигнала. начальная обработка приведение к уровню (отработка от помех и тп.) и вывод конечной информации.
Протокол вывода должен быть IP/TCP а также RX/TX (через) на основе cтандарта RS485 /
Тут много преимуществ. Простота развертывания и т.п.
По входам это обязательно должно быть масштабируемый формат. (например 4*8*16*32) и т.д Опто-развязка обязательно.
Выход: Здесь нужно знать потребности но скажем как минимум 4 релейных (переключаемых) и релейные платы должны быть легко подключаемыми (можно даже взять типовые от других производителей) (но полностью завершенных по конструкции (не Ардуино платы) например DIN формат).
Теперь по деталям.
Какая база? Отечественный или импорт. Давайте оговорим эти вопросы.

[Wagan]

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

И кроме того, автор системы говорил о создании продукта, работающего из коробки. Именно поэтому предлагаю сделать начинку той коробки, то есть из нее пользователь будет доставать не ПК, а нашу железку, которую останется только сконфигурировать при первом запуске с помощью мастера настройки...

[Wagan]

...
Теперь по деталям.
Какая база? Отечественный или импорт. Давайте оговорим эти вопросы.

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

[shemnik69]

наверное не поняли друг друга.
Я имел ввиду вот что. Система МД она по сути управляющий модуль и по сути уже отработана и на стандарт Win b Linux/ Т.е по сти само железо ей не столь кричино .если ставится выше упомянутая ОС.
Вопрос в том что сама система без связи через промежуточные контроллеры подготавливающие информация к подаче ее в MD мало эффективна.
Вот таже Малинка (Raspberyy) имеет выходные порты и много но имеет свою мало описанную и плохо поддержанную программно.
Да и подключение скажем разветвленной сетки датчиков (на которых сразу возникнут всякие паразитные наводки и статика) легко выводят из строя саму плату. Вот тут и нужны такие контроллеры которые берут на себя все неприятности и упрощают согласование "нежного" процессорного модуля МД с сеткой датчиков где присутствует и 220 и 24 и 12 в и все сопутствующие этому неприятности.

Вот как так.

[Wagan]

Да, возможно, не поняли друг друга. Что конкретно Вы предлагаете разрабатывать для продукта из коробки?


Отправлено с моего iPad используя Tapatalk

[shemnik69]

Ваша идея в том чтобы на некую платформу поставить именно саму систему. Т.е это должен быть посути мини (микро) комьпьтер со всеми атрибутами RAm. HDD. UART. и т.д. Таких платформ в принципе достаточно и все равно на них установка самой системы не получается и коробки. нужно все равно подключать периферию и тд. Настраивать сценарии писать скрипты и т.д. Это верхняя часть и самая и трудная и самая простая с точки реализации (Soft)/
Поставили мы систему скажем на Cubic 2/ прекрасно.. сама система сама в себе и ....?
К кубику нужно подключить что то что уже будет понимать скажем команду "set5 1" которая и будет уже управляющей. Например включит что то.
В основном многие свои данные предают на контроллеры типа ардуино просто потому что данный сегмент простой и доступный а также довольно гибкий по всяким подключениям кроме того ассортимент всяких дополнений довольно широк.
Если же в основу брать саму идею универсального блока то он должен быть модульный и легко наращиваемый по своим свойствам. В тоже время его собственный "интелект" должен быть тоже не уровня "динозавра".
Моя позиция это распределенная сеть простых блоков общая совокупность которых и позволяет решать любую задачу.
Скажем человек (заказчик) хочет иметь управление освещением и пусть воротами. Что ему нужно ?
Не стану описывать изобилие систем ворот и осветительные приборы это дело вкуса. а вот управляющих модулей то не так много. Не случайно же МД популярен. Вот тут сказывается гибкость самой системы совмещения ее с чем угодно. Ли.бы это обладало некоторыми свойствами. так получить и упорядочить эти свойства и задача разрабатываемого устройства.
Писать можно много и ... но суть такая что устройство должно сочетать и простоту и в тоже время быть легко наращиваемым по своим функциям. И еще ... он должен иметь начальный программируемый уровень автоматизации. Своего рода программатор задач. тут уже союз не просто схемных решений но и программистов.
С Уважением!

[shemnik69]

Скажем не беря саму идею MagaD как основу, но взяв концепцию, то можно с использованием скажем Atmega 256 (128) создать приличный по возможностями модуль.
Оснастим его портами на вход (кнопки. выключатели. и тп) и выходами (реле, тиристоры ) можно практически 90% задач отработать. На плату можно поставить процессор IP стека либо готовый аналог. (ENC)
Тогда уже возможно иметь довольно мощный WEB интерфейс, а добавив простой модуль Flash -ки то и память любого размера. А поскольку практически основная система на данный МК уже отработана то не возникнет сильных проблем.

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

Вот как то так.