Отговори на тема  [ 102 мнения ]  Отиди на страница Предишна  1 ... 3, 4, 5, 6, 7
Питане за облачни архитектури 
Автор Съобщение
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Нед Фев 26, 2006 5:52 pm
Мнения: 10356
Местоположение: Добрич
Мнение Re: Питане за облачни архитектури
За съжаление налагането на стандартите не зависи толкова от качествата им, колкото от частни монополисти и/или държавни бюрократи. И дори хората дето са в кухнята няма как да предскажат бъдещето.
В случая тоя стандарт очевидно не се е наложил и като го гледам не е голяма загуба. Не се заяждам, виждам че ти харесва като идея, но е безумен като концепция. Досега не съм видял нито една сложна система да е проработила с такъв модел, няма как и да проработи. Когато докажете обратното ела и ми се обади ;-)


Вто Яну 24, 2017 7:45 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Re: Питане за облачни архитектури
Доста от приложенията които правим са нещо подобно - няколко PLC-та, често йерархично свързани в 2 или 3 нива - в екстремни случаи стигат до 100-тина контролера. Това управлява примерно голяма поточна линия. Отделните агрегати се контролират от "разпределени" PLC-та, които на горното ниво се координират от друго PLC.
Всяко PLC естествено си има PLC програма и конфигурация за комуникация нагоре (към контролиращия го) и надолу към сензори, серва и други изпълнителни механизми.
Разбира се че това може да се направи "на парче" - обмисля се интерфейса, прави се едната програма с нагласата да "еспортира" тоя интерфейс, прави се другата, която пък да го "импортира" и като се закачат се стискат пръсти, китки, глезени и каквото още имаш да тръгнат. Особеността е че в 61131 няма концепцията за разпределени системи, т.е. мрежа от PLC програми. Т.е. като се дефинира интерфейса той лесно да влиза в двете страни. Проблемът не е толкова програмата, колкото конфигурирането на обмена на данните между двете. Много често това става ръчно, "по-добрите" фирми го правят със сложни PC инструменти които менажират тия неща. Те генерират дефинициите за PLC програмите и конфигурират комуникацията по fieldbus-ите.
Концепцията си е супер и това е което прави 61499 - кофтито е че решенията преди 61499 са специфични за фирмите, изискват доста опит при работата и не помагат като смениш от Rockwell на Siemens примерно. Като сложиш и спецификите на различните PLC-та, бъсове, фирми и става голяма каша.
Няма как това да се направи строго централизирано защото ще се наложи да се балансират две противоположни изисквания - максимално скорост (ниско време за реакция на контролния цикъл - от сенсор през "алгоритъм" до изпълнителен), така и да се преодоляват големи разстояния с малки закъснение, висока надеждност, евтино и сигурно окабеляване, лесна поддръжка.
Това е част от решенията, които би дал 61499 ако навлезе. Другото, което правилно си усетил че ми е присърце, е event модела.

Както и да е, ще се боря - засега съм още на етап много ранно проучване, но се очакват шарени резултати за "акционерите", и то за нула време. Което може бързо да премести решението в друга посока.


Вто Яну 24, 2017 8:03 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Нед Фев 26, 2006 5:52 pm
Мнения: 10356
Местоположение: Добрич
Мнение Re: Питане за облачни архитектури
В тая картинка може да се мисли в посока разпределена система, но първоначалните ти описания бяха повече в "облаците" ;-)

Тъй като не съм запознат с детайлите не мога да преценя, но на твое място бих внимавал кое да е централизирано и кое не. Една истинска разпределена обработка е много сложна задача и не знам в случая дали чак толкова се налага. По-скоро ми струва че трябва гъвкавост и улесняване на връзките. Примерно за home automation ми харесат някои от концепциите за KNX протокола. Там има някои неща като възможност да си правиш виртуални групи, всяко устройство може да го програмираш да участва в колкото си искаш групи. Ако е датчик, то просто ще праща някакво съобщение то "тази група", може да програмираш изпълнителни механизми директно да зависят от датчика, т.е. ако дойде еди какво си съобщение правиш еди какво си. Може да има управления по между тях естествено.
Прилича на MQTT, но е мноооого по-просто и по-универсално. Примерно датчика праща едно съобщение, толкоз. Съобщението може да е само 1 бит. Ключовете по сълбищата са точно такива - натиснат/ненатиснат. Точка. От там насетне тоя бит, т.е. това съобщение се праща по мрежата и е адресирано до някаква виртуална група или до конкретно устройство. Самият датчик нищо повече не го интересува, няма субскрайби, няма ънсъбскрайб и т.н. Просто съобщение с адрес и пейлоад от 1 бит. А както ще стане след това зависи как си програмирал останалото. Може да си програмирал само една ламба да святка за 5 мин като получи тоя бит, а може да си програмирал цяла фабрика да слухти и като види че шефа натиска бутона да се гаси всичко.


Сря Яну 25, 2017 9:25 am
Профил
Ранг: Форумен бог
Ранг: Форумен бог
Аватар

Регистриран на: Сря Апр 27, 2005 11:48 am
Мнения: 4671
Мнение Re: Питане за облачни архитектури
и тъй като датчиците и RF-а им са "ефтинджос" (като пайлоад, захранване и тн) - хвърлят до концентратора (тук може да набуташ линукса с mqtt или някъф интерфейс) и той си мятка до облака...
въпрос на структуриране на "мрежата"
и като почнеш да структурираш, хептен ще се омоташ, а мотиките ще валят от небето...
Облаци....четеш "шарените" картинки за зарибяване на инвеститори...
Накрая инвеститора идва с голямата мотика...

_________________
main[-1u]={1};


Сря Яну 25, 2017 8:40 pm
Профил ICQ
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Re: Питане за облачни архитектури
Принципите са такива - няма какво да се спори. Това с единия бит също е валидно и в тоя контекст ще напомня за "собствеността" върху този бит.
Идеалистично (т.е. правилно структурирано) някъде има хардуер който може да клати един бит за изход (и друг който да следи бит за вход). Това е хардуерния компонент "изход" (или "вход).
Към тоя компонент се закача простия софтуерен такъв - "софтуерен" бит (данни) да се задава като ниво - например "gpio0.write(X)".
За да можем да ползваме тоя механизъм ни трябва информация за локация - дали ще е адрес, хендъл, поинтър, URI или нещо друго няма значение. За да го достъпими отдалечено ни трябва още някой да транспортира тоя бит "данни" отнякъде до това устройство. От една страна, кой, как, кога, защо, за колко ще транспортира не влияе на кода на gpio write. Обратното също - това че тоя бит някой някъде щял да турга на изход няма отношение към транспорта.
Не познавам KNX на ниво различно от реклами, но се предполага че някъде някой прави още една стъпка (в началото някой е монтирал бутона някъде и лампата другаде). Тази стъпка е да опъне жицата - дали директно между двете, дали през шкаф (брокер), дали през облак. Това не се решава автоматично от каквато и да е система - това е "програмиране" или "конфигуриране".
В стила на MQTT това значи да се зададе на публикуващия клиент къде да публикува (базов топик) и той да добави евентуално неговата си структура - за пример "някой" отвън му казва "клиент5/завод7/сграда4/етаж7/коридор11/табло1/осветление/бутонXXX". Бутона хич не го е еня какво е това стига да се събира в максимума от примерно 256 символа за база. Тоя бутон си добавя неговите специфики и става "клиент5/завод7/сграда4/етаж7/коридор11/табло1/осветление/бутонXXX/включване" и публикува там.
Наобратно същото, само че лампата се абонира за база+специфично - примерно "клиент5/завод7/сграда4/етаж7/коридор11/табло1/осветление/лампаYYY/осветеностПроценти".
Какво е характерното - софтуера на у-вa "лампа" и "бутон" изобщо не знае за организации на топиците.
Целта е донякъде да се улесни преизползването - не само на хардуер, не само цял "фирмуер" но и на отделните части в софтуера - ако реша онзи някой си компонент дето е викал функцията "gpio write" може да почне да вика такава през RPC на другия край на света.
Възможни са и "групирания" в смисъл магазин Lidl има някаква структура от компоненти и може да се повтори в друг град и няма нужда да се прави "схемата" от нулата наново. Това реално значи че частта от йерархията която прави връзките в сградата - етажи, коридори, стаи може да се преизползва (копира) но остава да е зададат (map-нат) точките към конкретните крайни устройства.
То това е идеята за структуриране в MQTT и като цяло в RESTful реализациите. Поне аз така го разбирам.
Разбира се MQTT е просто една реализация на подобен модел - такава йерархия може да се направи в най-различни постановки, ценното са идеите за йерархия и известяване при събитие.


Чет Яну 26, 2017 11:50 am
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Нед Фев 26, 2006 5:52 pm
Мнения: 10356
Местоположение: Добрич
Мнение Re: Питане за облачни архитектури
gicho написа:
Не познавам KNX на ниво различно от реклами, но се предполага че някъде някой прави още една стъпка (в началото някой е монтирал бутона някъде и лампата другаде). Тази стъпка е да опъне жицата - дали директно между двете, дали през шкаф (брокер), дали през облак. Това не се решава автоматично от каквато и да е система - това е "програмиране" или "конфигуриране".

Aми седни и прочети малко повече. Не казвам че трябва директно да го ползваш, по-скоро да хванеш идеите и концепциите. Една от идеите е, че физическата връзка (окабеляването) няма нищо общо с функционалността. То това е и една целите на KNX де, щото в една къща не би искал да ти се налага да опъваш нови кабели или да ги променяш. Просто сядаш с мишката и цъкаш кое как да работи, ако искаш да го промениш...


Цитат:
В стила на MQTT това значи да се зададе на публикуващия клиент къде да публикува (базов топик) и той да добави евентуално неговата си структура - за пример "някой" отвън му казва "клиент5/завод7/сграда4/етаж7/коридор11/табло1/осветление/бутонXXX". Бутона хич не го е еня какво е това стига да се събира в максимума от примерно 256 символа за база. Тоя бутон си добавя неговите специфики и става "клиент5/завод7/сграда4/етаж7/коридор11/табло1/осветление/бутонXXX/включване" и публикува там.

Друга идея на KNX е, че не ти трябват такива сложни URL-та. Един бутон няма как да е произведен с някакво конкретно, нито го интересува, още по-малко пък му трябват сложни протоколи за "публикуване" и т.н. KNX е правен първоначално да работи с 8-бит контролерчета дето са с по 32 байта RAM, даже може да нямат никакви интерфейси като UART или чак пък TCP/IP стекове. Има едно просто пакетче, бутона си го праща и толкоз. Не се интересува на кого го праща, нищо... нищо! Даже ако е в типичната за KNX мрежа, пращането може да стане с клатене на GPIO. Толкова е проЗто...

Цитат:
Какво е характерното - софтуера на у-вa "лампа" и "бутон" изобщо не знае за организации на топиците.

Именно...

Цитат:
ако реша онзи някой си компонент дето е викал функцията "gpio write" може да почне да вика такава през RPC на другия край на света.

Кое от къде минава е въпрос на тоя дето инсталира и поддържа системата. Важното в случая е, че за да е възможно това трябва да има и свързаност. Но за да има свързаност, трябва да спазваш OSI модела, така както KNX го прави. Така може да имаш всякакво физическо ниво - от радио, кабел само по една двойка, по която текат както захранване, така и данни. Може да минеш по canbus, по ethernet... и по всичко.

Цитат:
ценното са идеите за йерархия и известяване при събитие.

Ценното са, че йерархията се прави след това. И не е само една, т.е. може да имаш различни йерархии и по различни признаци. Прочети за виртуалните групи...
Всичко това се програмира СЛЕД. Но в зависимост от това кое как си програмирал автоматично се променят и рутиране и бриджаване. На практика се програмира устройството да праща на някакъв адрес или адреси. Адресът е 33-битов и подобно на IP-адресите съдържа разна информация, нужна за рутирането му. Така ако програмираш нещо да праща на физически адрес в същата area, мрежа и под-мрежа то тоя пакет няма да излезе навън. И обратно ако е външен, ще мине през съответния рутер и т.н.
При KNX всичките тия подробности за адресиране, програмиране/конфигуриране, маршрутизиране и т.н. са вече измислени. Много неща са... докато MQTT е само едно нещо и не я ясно нито как ще го навържеш с останалите, нито изобщо дали има смисъл. Понеже тия шарените именца на практика нямат никакъв смисъл да товарят комуникацията в една много излишна посока. Да, в КNX също може да имаш и да си ги групираш на човешки език - завод еди кой си/сграда X/етаж Y/стая ZZ/ ключ за осветление QQ... но това е за хората, вижда се само в софтуера за конфигурация.


Чет Яну 26, 2017 2:12 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Re: Питане за облачни архитектури
Ще го разгледам за обща култура, мерси за насоката - може ли някакъв отфилтриран линк с нещо за начално запознаване, пък после да копая ако се наложи?
Интересно ми да видя как става и конфигурирането - в смисъл като поръчаш 20-те ключа и 10 лампи примерно как се изгражда мрежата. Предполагам имат някакви уникални идентификатори, едва ли се очаква да ги закачам едно по едно към PC-то да им описва какво да прави.
Имат ли дефиниран формат върху жицата, какво върви когато натисна бутон 5 за да се разбере че е бутон 5 а не 4, и т.н. Всичкото broadcast ли е, имат ли някакви концентратори?
Някъде четох изказване на човек от Cisco, които потайно били пуснали сериозни мрежи (говореше за милиони устройства) с идеите на IoT, мисля че ползват CoAP, те май са му сред авторите. Според него основния проблем е не толкова комуникацията на вече изградена и конфигурирана система, а самото начално настройване, конфигуриране и пускане в действие.


Чет Яну 26, 2017 2:29 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Нед Фев 26, 2006 5:52 pm
Мнения: 10356
Местоположение: Добрич
Мнение Re: Питане за облачни архитектури
gicho написа:
Ще го разгледам за обща култура, мерси за насоката - може ли някакъв отфилтриран линк с нещо за начално запознаване, пък после да копая ако се наложи?

Имам стандарта, но той е много просторно описан, аз го четох по време на отпуска... иначе не става. По-добре от нета, има доста описания, от TI имаше едно не лошо въведение, те имаха някаква платка с MSP430 ли беше, не помня.


Цитат:
Интересно ми да видя как става и конфигурирането - в смисъл като поръчаш 20-те ключа и 10 лампи примерно как се изгражда мрежата. Предполагам имат някакви уникални идентификатори, едва ли се очаква да ги закачам едно по едно към PC-то да им описва какво да прави.

Да, точно това се очаква - закача се РС и KNX предлагат софтуер. Любопитното е, че софтуерът почти не се променя и май никой друг не прави подобен софтуер щото просто не се налага ;-)

Цитат:
Имат ли дефиниран формат върху жицата, какво върви когато натисна бутон 5 за да се разбере че е бутон 5 а не 4, и т.н. Всичкото broadcast ли е, имат ли някакви концентратори?

Всеки пакет има изпращач и получател. Всяко устройство има физически адрес, но когато пращаш може да пращаш не само до физически, ами и логически, т.е. виртуални адреси. Самото кодиране на адресите/групите е добре да го видиш.
Данните също имат формати, но се пращат само чисти данни без самия формат. Така че не си програмиран няма да знаеш много-много какво да гледаш и как да го интерпретираш. От друга страна пък пестят от трафик... Включително и самата конфигурация е също бит стрийм, което на мен не ми харесва, но те така си го правят още от едно време, когато конфигурацията буквално се е записвала във флаша на контролерчето. Ако правиш устройства в KNX стековете обикновено си декларираш една структура, вътре полетата са им техни стандартни типове.
Това, което на тях им помага е че имат стандартно описани различни устройства и всяко устройство следва стандарта (иначе не го сертифицират). Затова и нямат особени проблеми със съвместимост и т.н. Затова и техния софтуер работи с мишката и може да правиш каквото си поискаш. Но ако тръгнеш да измисляш нови неща, според мен има опасност да удариш на камък. На тяхно място аз бих заложил повече свобода и гъвкавост по отношение на данните.

edit: като пуснеш търсене на "TI KNX" ти излизат pdf-четата на каубойците


Чет Яну 26, 2017 2:54 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Вто Окт 11, 2011 10:53 pm
Мнения: 4174
Местоположение: Brussels / Пловдив
Мнение Re: Питане за облачни архитектури
Тука един юнак е направил home automation с node & friends и го търкаля с RPi и смартфон. Предполагам, ще го нахокате защо не е сложил SQL и че въобще не се прави така.

https://github.com/deepsyx/home-automation

_________________
Мразя да мразя ...


Чет Яну 26, 2017 3:26 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Нед Фев 26, 2006 5:52 pm
Мнения: 10356
Местоположение: Добрич
Мнение Re: Питане за облачни архитектури
Те много работи се правят без SQL...
Аз все си мисля, обаче че между система от едно RPi и един датчик до индустриално предприятие има дребна разлика ;-)


Чет Яну 26, 2017 3:55 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог
Аватар

Регистриран на: Сря Апр 27, 2005 11:48 am
Мнения: 4671
Мнение Re: Питане за облачни архитектури
относно Циско:
https://www.kaldata.com/it-%D0%BD%D0%BE ... 36390.html

със SQL без, нали зависи от процеса който се обслужва...

_________________
main[-1u]={1};


Чет Яну 26, 2017 7:07 pm
Профил ICQ
Ранг: Минаващ
Ранг: Минаващ

Регистриран на: Пон Яну 23, 2006 9:47 am
Мнения: 56
Местоположение: Varna
Мнение Re: Питане за облачни архитектури
netIOT Edge Gateway ?

https://www.hilscher.com/fileadmin/cms_ ... 01-2016_EN


Сря Мар 04, 2020 8:49 pm
Профил
Покажи мненията от миналия:  Сортирай по  
Отговори на тема   [ 102 мнения ]  Отиди на страница Предишна  1 ... 3, 4, 5, 6, 7

Кой е на линия

Потребители разглеждащи този форум: 0 регистрирани и 3 госта


Вие не можете да пускате нови теми
Вие не можете да отговаряте на теми
Вие не можете да променяте собственото си мнение
Вие не можете да изтривате собствените си мнения
Вие не можете да прикачвате файл

Търсене:
Иди на:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.
Хостинг и Домейни