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

Регистриран на: Нед Сеп 26, 2004 8:21 pm
Мнения: 27949
Местоположение: София
Мнение Re: Питане за облачни архитектури
По добре е да мислиш за малоумника който я поддържа или за този който го е избрал. Всяка система се нуждае от редовна поддръжка,в противен случай спира, дори да я е направил дедо боже или Дедо Боре...


Съб Яну 21, 2017 8:42 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Re: Питане за облачни архитектури
Цитат:
Но тук възниква въпросът чисто практически ти как ще направиш поддръжката на тая система. Дали ще плащаш на IBM да реагират в рамките на минути независимост коя част от денонощието и кой ден е в годината?

Не те разбирам? IBM-ската нали не мислиш че стои в заключен трезор във Форт Нокс и трябва да летя до там за да правя нещо? Това е платформа, която може би ще ми свърши работа ( и това проучвам), но тая платформа има много нива (за разлика от SQL, но няма да се дракам). Може да се хоства при тях, може да се хоства при амазон или подобни, може при кварталния доставчик. Каква поддръжка имаш точно предвид - ако има бъг в кода да оправят, или ако клиента ми реве че не може да се закачи да дойдат да рестартират сървъра?
Ако имам подходящ клиент сигурно и опцията да им плащам да поддържат. Не щото съм голямата работа, ами щото съм преценил че те ще ми свършат работата.
Ти на майкрософт ли се обаждаш ако SQL-а спре или омаже данни?
Дребен пример пак имащ връзка с ESP-то - itead имат един продукти - релета с интернет връзка. Едно от оценените като плюс в някакъв форум или ревю, не помня, беше че облака им е на амазонския AWS. Нали се сещаш че е доста по-добър вариант в сравнение с това да е хостната в някоя китайска ферма за щрауси? Може би не е удобно на писачите им, но е изискване на пазара. Няма как с твой хостинг да направиш надеждна система, минимума е да го сложиш в истински data center - дали ще е София или Варна, или UK, USA - все няма как да го пипнеш на момента. Това са тнтм постановки - пет страници по-назад говорих за гъвкавост точно за да мога да го сложа на истински хостинг като амазона. Имаше и още две опции - клиента иска да е на негов сървър (което пак не се връзва да сглабяме рак-ове) или за развой/тест да е някъде при мен локално, по възможност на пц дето ми е под ръка. Няма такива сценарии като сървър в мазето на градския доставчик.

Цитат:
Пак ти казвам, от гледна точна на архитектурата на една система SQL има функция на фундамент

Дай някой жокер какъв фундамент е SQL-а - явно тук се разминаваме във вижданията си и може оттам да идва неразбирателството?
Аз се сещам за няколко:
- споменатия persistence на данните
- възможност за изваждане на данни по някакъв критерии
- възможност за свързване на данни/таблици
- възможност за организиране на структури - чрез създаване на таблици и връзки

Казахме че Persistence е опция, плъгин, екстра според мен така че липсва от ядрото на mqtt. Някой брокери (HiveMQ) имат плъгин система с която да вкарват допълнителна обработка в ядрото - ползват я точно за ефективен persistence - да не се налага да се закача отделен клиент към брокера.
Вадене на данни по критерии - това при MQTT има аналогия в йерархията на topics и възможността да се ползват wildcards за зони.
Свързване на части - съвсем базово го има в смисъла на йерархията - устройствата могат да се организират в папка /devices/...
Организирането на структури (създаване на таблици) също не е нещо сложно и трябва да се направи на ниво планиране на йерархията от топици.

SQL ти позволява да направиш произволна структура и да си достъпиш данните колкото и да е увъртяна структурата. Кой обаче ползва SQL на такова ниво? Аз що си мисля че структурата на базата се определя от модела на обектите и системите, данните, които тя съхранява? Не е ли това дето му викат моделиране, data binding или подобни щуротии? Нали не се очаква че като имам модела на едно устройство и правя софтуера му примерно ще трябва да повтарям на ръка това описание (обекти, методи, събития, данни) за да направя някаква таблица?
Няма смисъл от измислени структури, има си обектен модел на това устройство и връзките в системата и те еднозначно определят как трябва да изглеждат "таблиците". Дали ще са таблици или друго нещо което може да менажира структури няма значение.

Огромната разлика между SQL базираната и MQTT такава е че MQTT сменя модела на event базиран. Там няма - дай да питам дали пък не се е освободило паркомясто през секунда.
Не твърдя че MQTT е достатъчния компонент който да направи архитектурата - той е едно от звената. Ако трябва да се предостави услуга през http "вземане на паркомясто" в смисъла клиента праща паркинг на който иска да отиде и очаква обратно потвърждение за номера на мястото, то ще има следващ алгоритъм който ще се регистрира в брокера и ще свърши логиката по проверка и резервиране.


Съб Яну 21, 2017 9:44 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Re: Питане за облачни архитектури
ДедоБоре написа:
я по-подробно от тук нататък?

За кое, не виждам въпрос - кажи кой фючър на SQL те прави щастлив да му търсим аналогията. Да започнем отнякъде - MQTT предлага publish-subscribe, тежи 83К, има last will, има retain, има бридж между брокери с опции в коя посока и префикс за "втъкнатите" от другия топици.
А, ако искаш да ме подведеш да те убеждавам как да минеш на него - няма да се хвана. Това е тежка тема - не за бира, а за team building от понеделник до петък минимум

Цитат:
---
никой не ти говори за SQL в ПИК.
гролям брой на конекциите в esp8266 също е нон-сенс. и въобще да се разчита на LWIP за серозно неща е под критика също.
не ти ли светка някоя червена лампичка, защо ЕСП струва $2 доставено до пощенската ти кутия?
[/quote]
Затова казах че давам отделен пример и че не мисля да ползвам есп-то за решението което се търси в тази дискусия.
А защо е 2 долара не знам - имаше анализ на резултатите от тестовете за емисии на модула, мисля в eevblog и коментираха че се справя далеч под максимумите. А лъчи здраво, чува добре, новото е 125 градуса. Нямам идея как става това.
Откак за долар намериха как да му слагат и криптиран сторидж за сертификати и ускорение на TLS (през i2c :) ) нямам за какво да му намеря кусур.


Съб Яну 21, 2017 9:55 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

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

Приказката беше за изграждане на корпоративен сървър, разбирай на територията на клиента. Поне при нас досега не сме срещали голям клиент, който да се навие сървърите му да са изнесени. В тоя смисъл ти отговаряш за целия софтуер, хардуер както и ако нещо се счупи да го оправиш буквално за отрицателно време. Ако предлагаш цялостно решение разбира се, но в тоя област трудно се продоват половинчати неща.

Цитат:
Ти на майкрософт ли се обаждаш ако SQL-а спре или омаже данни?

хе-хе, даже и не съм си помислял да ползвам техен SQL дори за проба.

Цитат:
Нали се сещаш че е доста по-добър вариант в сравнение с това да е хостната в някоя китайска ферма за щрауси?

Аз мисля ти обяснявах, че е много по-добър вариант да се ползва хостинг, отколкото домашния ти компютър... И че за малки клиенти е важно да *можеш* да ползваш непретенциозен хостинг, само че има малка подробност че непретенциозния хостинг е само хостинг. Забрави да качваш приложения, забрави за MQTT.. А тоя дето става няма пък да ти хареса като цена.

Цитат:
Няма как с твой хостинг да направиш надеждна система, минимума е да го сложиш в истински data center

Повечето големи компании имат собствени центрове (включително и нашата) с климатизация, с оптика, захранване и всичко останало. Не винаги е последния писък на технологията, но достатъчно като надеждност. А и да не е, това не е твой/мой проблем. Пак казвам ти даваш изискванията си за твоите машини и софтуер и за тях носиш отговорност. Ако падне тока вината не е твоя.

Цитат:
Цитат:
Пак ти казвам, от гледна точна на архитектурата на една система SQL има функция на фундамент

Дай някой жокер какъв фундамент е SQL-а - явно тук се разминаваме във вижданията си и може оттам да идва неразбирателството?

Първият и най-важен параметър на един сериозен SQL сървър е неговата надеждност, всичко останало е на втори план.
Както и сам може да се сетиш безсмислено е да правиш голяма и/или сложна база данни, ако тя не е надеждна.
Всъщност не е задължително буквално всичко да е в SQL-a. Може да е комплексно решение, т.е. като почнеш от ОС-а, примерно ние ползвахме CentOS заради възможността няколко машини да изграждат и репликират NAS и върху тоя NAS се слага вече SQL. Решенията са различни, но въпросът е че от към надеждност системите се изграждат до ниво база данни, като всичко до това ниво е мислено и мислено с десетилетия от специалисти само и само да бъде надеждно.
Което не означава, че едно ниво над базата данни нещата са ненадеждни. Зависи от конкретното ниво естесвено. В случая с MQTT не мога да кажа нищо, не го познавам. Но принципно това е ниво над стандарта и със съвсем друга идея и много повече функции, много от които нямат нищо общо с надеждността. Така че в най-добрия случай това ниво ти позволява надеждност при определени условия, а ти май изобщо не си наясно какви са тези условия.

Цитат:
....

По-надолу си се опитал да правиш някакви сравнения между MQTT и релационните бази данни.... че и предимства и недостатъци..
Няма да коментирам, все някъде трябва да сложим чертата ;-)


Нед Яну 22, 2017 12:01 am
Профил
Ранг: Форумен бог
Ранг: Форумен бог
Аватар

Регистриран на: Нед Ное 21, 2004 10:31 pm
Мнения: 9635
Мнение Re: Питане за облачни архитектури
gicho написа:
ДедоБоре написа:
я по-подробно от тук нататък?

За кое, не виждам въпрос - кажи кой фючър на SQL те прави щастлив да му търсим аналогията. Да започнем отнякъде - MQTT предлага publish-subscribe, тежи 83К, има last will, има retain, има бридж между брокери с опции в коя посока и префикс за "втъкнатите" от другия топици.
А, ако искаш да ме подведеш да те убеждавам как да минеш на него - няма да се хвана. Това е тежка тема - не за бира, а за team building от понеделник до петък минимум

точно това ти обяснявам, че аналогия няма. едното е брокер, другото е собственик.
когато си собственик, можеш да си позволиш да си избереш брокера от борсата - директен ТСР порт, JSON, MQTT, XML, ако щеш HTTP. това е надстройка за "търговия". но някой трябва да има "стока".

и обратно, брокера не държи никаква реална стока в ръцете си. само урежда размяната по някаква процедура. и естествено си търси различни видове собственици на стока и има предлага посредничество, но самия той нито има представа, нито някога владее (разбирай съхранява, управлява) самата стока (разбирай съхранени данни)

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

аз също спирам с обясненията. и в момента нямам време за тийм билдинг 8)

---

gicho написа:
Затова казах че давам отделен пример и че не мисля да ползвам есп-то за решението което се търси в тази дискусия.
А защо е 2 долара не знам - имаше анализ на резултатите от тестовете за емисии на модула, мисля в eevblog и коментираха че се справя далеч под максимумите. А лъчи здраво, чува добре, новото е 125 градуса. Нямам идея как става това.

подготовката на подобен чип във фабрика за чипове е някъде $400-$500К. в такава, в континентален такай, може да е по-евтино, но няма да е значително. колко струва китайския труд за проектирането на чипа е разтегливо понятие. да, кажем, че ще успеят да докарат себестойност от $1 за милион бройки. и после ги продават 2 години за по $2, с включени пощенски разходи. нормално ли ти се струва?

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

gicho написа:
Откак за долар намериха как да му слагат и криптиран сторидж за сертификати и ускорение на TLS (през i2c) нямам за какво да му намеря кусур.

мдаааам...


Нед Яну 22, 2017 10:27 am
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Re: Питане за облачни архитектури
Ех, писах един час с прекъсвания и загубих поста...
Отначало:

Цитат:
точно това ти обяснявам, че аналогия няма. едното е брокер, другото е собственик.

Абсолютно съгласен - само че хвърлям бомбата - собственикът не е SQL базата, а устройството което е измерило данните или изпълнява действието. В SQL базата имаш виртуални бледи копия на данните. Нещо като надуваема кукла - почти същото и може би върши работа, но не е истинското.
Преди малко говорих за "разпределена система", в която данните са разпределени в различни устройства. И д-ъто си да скъсаме данните пак ще са там, най-много да им направим копия някъде. В модела влизат още "събития" и "методи" - тия не знам как се "мапват" в SQL, мога да кажа как става в MQTT или Redis.
Ползване на SQL предполага (налага) един модел (pattern) който за мен е лимитиран, защото не пасва на ембедед системите. А те са "reactive", event базирани, разпределени.



Транспортите са ясни - и в единия, и в другия типично се ползва TCP за транспорт. MQTT-SN предлага и UDP като опция, като може да се отваря и към други транспорти.

SQL е език за писане на query-та. Другите части като мрежов протокол (не го знам дали е отворен, това което правят "драйверите" за SQL бази), сториджа и тем подобни са вкарани в продукти, което носят аналогично име. Хубаво, натъпкали ги заедно и приемаме че SQL има и нещо като брокер - идващите заявки да се предава за обработка и съхранение. Този сървър, брокер, или каквото е там какво предлага? MQTT предлага publish-subscribe с екстри, Redis.io е база с publish-subscribe възможности. Къде се класира "нещото" на SQL-а?

Идеята на темата е архитектура - не конкретни инструменти. Node.js ми е отдавна на устата, но едва след като palavrov го спомена се осмелих да говоря за него. SQL е инструмент - уникален с .. нищо, освен с "maturity" или както там се казва. Някой биха казали динозавър, анахронизъм може би, но само някой дето имат право на лош вкус и смелост да го натрапват.

Ако го гледаме от такава висота, къде и как се моделира една система от устройства, SQL център и "frontend" устройства? Как пасва на MVC или подобни pattern-и?
https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Номерът е че node.js като цяло но по-скоро много от компонентите му (AngularJS, ...) директно са мислени и правени с идеята на тези pattern-и, и не само тези. SQL може да се ползва като някакво средство за реализация на M-то (модела) но не е самия модел - той е структурата на данните дето са в устройството. Същото е с MQTT - организацията на топиците би трябвало да следва модела на данните и УСЛУГИТЕ като цяло в устройството.


Цитат:
мдаааам...

За справка - тръгваш оттук:
https://blog.cesanta.com/iot-security-woes-cool-to-talk-about-a-problem-but-not-a-solution
минаваш през тук:
https://github.com/cesanta/mongoose-os/tree/master/third_party/cryptoauthlib
и стигаш дотук:
http://www.atmel.com/devices/ATECC508A.aspx
Добро, лошо, евтино, скъпо - не знам, не съм го ползвал още (вариант с криптото, иначе с mongoose имам малко опит). Но е работещо и от малкото които могат да се закачат към AWS IoT директно.


Пон Яну 23, 2017 11:28 am
Профил
Ранг: Форумен бог
Ранг: Форумен бог
Аватар

Регистриран на: Нед Ное 21, 2004 10:31 pm
Мнения: 9635
Мнение Re: Питане за облачни архитектури
gicho написа:
Ех, писах един час с прекъсвания и загубих поста...

ето ти чудесен пример за локални и централизирани данни :D

иначе се чудя дали въобще да пиша нещо.
от реда на мислите ти, май никога не си задълбавал в SQL, че и в структурни бази данни (с релации) въобще.
единствено си прав, че SQL буквално е език, ама на жаргон се разбира и всичко около него. а пък да твърдиш че е отмиращ динозавър, работещ по единствен, лимитиран "патерн"... 8O


Пон Яну 23, 2017 2:43 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Re: Питане за облачни архитектури
Цитат:
ето ти чудесен пример за локални и централизирани данни :D

Да де, ама положителен ли, отрицателен ли ... Бе май "отзад" e SQL, ама няма да му връзваме кусур.
Явно сесията изтече от дълго чакане и сгафих с напред-назад бутоните като видях че трябва да се логвам, и така. Иначе обикновено се логвам и като върна ми дава мнението както го редактирам, и мога да си коп-на.


Пон Яну 23, 2017 4:50 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

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


даже и това буквално не :-)

wiki написа:
Популярна шега относно SQL е че "SQL не е структуриран, нито ограничен до запитвания, нито език (на английски: is not structured, nor is it limited to queries, nor is it a language)." Основа за това е, че чистият SQL не е класически програмен език, тъй като не отговаря на Дефиницията на Тюринг.



gicho, системите са два основни типа - разпределени и централизирани. На практика обаче централизираните системи масово преобладават поради простата причина, че много трудно се правят децентрализирани. Има много проблеми и то теоретично нерешими проблеми при разпределените системи, затова ако не си сигурен какво правиш, по-добре не се хващай с разпределена система.
Просто за да работи коя да е система ти трябва точна информация. Не може да се вземат правилни решения, ако има липсваща или неточна информация. Затова целта е на едно място да ти и управлението и информацията. Това ти е "центърът" и всичко се върти около него. Като обикновено ти се грижиш да направиш управлението и събирането на информация, а за нейното съхранение и поддържане се разчита на база данни (ние му викаме SQL). Счупи ли ти се бозата - нямаш информация, не може да вземаш решения, всичко умира... Затова най-важното при бозите както ти казах е да не се чупят.
Колкото до това че данните са в устройството... както казах, задължително е данните и управлението да са на едно място. И ако ти това не може да го постигнеш, то няма никакво значение дали системата ти е централизиран или разпределена. Щом си тръгнал да изнасяш някаква си информация от устройството се предполага че тя може да се изнася по принцип и че би била полезна за нещо. Ако имаш ограничение в количеството изнасяна информация - то това ограничение също не зависи от типа на системата. Макар че при централизираната може много по-добре да използваш наличния лимит. Просто при централизацията ще имаш един сървър, през който минава всичко и съответно на едно място имаш информацията кой какви лимити и мераци има и може да вземеш оптималното решение кой да духа супата и кой да върти "педалите".
Това дали системата ще е централизирана или не, обаче, не зависи от тия неща... Критерия за това е как и кой взема решенията. За да тръгнеш да правиш разпределена система трябва или да не си си пил хапчетата или да имаш крещяща нужда да се вземат независими едно от друго решения на различни места. Нещо не мога да си представя практическо приложение на това. Разпределена система е когато имаш много взаимно заменяеми устройства и много задачи и не се интересуваш кое устройство какви параметри има и какво прави, важното е те помежду да се разбират. Както е ятото дронове примерно.


Пон Яну 23, 2017 4:52 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Re: Питане за облачни архитектури
Е няма как да не се хвана, това е задачата. А и е предизвикателство. Времето ще покаже какво ще се получи.
Съгласен съм с изводите ти за централизирана система, само че не съм съгласен че е задължително да е такава. Със сигурност има различни проблеми за решаване, и опитите за виртуално променяне на естествения вид на системата към някакъв измислен такъв не мисля че помагат.
Както споменах моят опит е че централизирането води до проблеми - твоят е че разпределението води до такива. Общовалидно ще е да кажем че и в двата вида има проблеми - остава да разберем кога едното решение е по-добро и кога другото. За съжаление при мен системите са разпределени вече и си има изискване да останат такива, за да могат да си вършат основната работа.

Дори и да искам няма как да тръгна към централизация, по простата причина че конкуренцията "от там се връща". Такива централизирани модели е имало и точно външните решения което сме ползвали и интегрирали са били такива. За съжаление клиентите вече не ги искат и питат за нови неща, а напоследък сочат нанякъде (някой конкурент) и питат "А вие кога?". Неприятното е че сме изостанали доста в тази част - може би донякъде от консерватизъм, пък ако щеш мързел, лежане на стари лаври и други подобни.

Виж модела на OPC UA - добър е макар да ми горчи в устата още от предишния. Но в новия са се постарали да откраднат верните идеи и да позабравят егото. Нещо което трябва да се случи и при нас.

Едит: да допълня - в нашите системи (а и в повече ембедед устройства) има нива, или области на контрола. Имам предвид процеси, алгоритми които вървят с различни изисквания към времето на реакция.
Например най-бързите процеси (условно < 10мкс) са на хардуер - дискретна логика, ASIC, CPLD/FPGA. Процеси които са с реакция 20-100мкс са на програмен контрол локално в един процесор и то някакъв deterministic - без Linux и много нива на кеш, нагоре до 250мкс си позволяваме да ги пускаме на 2 или 3 процесора на една платка, над 500 изборът е голям - може да "влязат" вече в real-time linux-а или да ходят до отделни устройства на 100м едно от друго вързани по индустриален real-time ethernet бъс. Нагоре като прехвърлим над 100мс може да се гледа и към изолират стандартен етернет или други такива, нормални операционни системи и Windows. Още по-нагоре - да кажем статистика колко детайла са брак може и на секунди, минути и т.н. и това ниво може вече да ходи в облака например.
Няма как контрола да стане централизиран - всяко ниво работи с данни от и към горно ниво, които са по-бавни (т.е. реално се "консумират") от горното ниво. В едната посока горното ниво "конфигурира" по-долното (по-бързо) ниво и го следи "от време на време", т.е. с неговата по-бавна реакция, за статус или изходни данни. Най-простото е един PID регулатор който примерно управлява двигател с цикъл 100мкс и HMI който реагира за 10-20мс примерно. Каквото и да правим няма как да качим пид-а на 10-20мс, още по-малко да свалим рисуването на 100мкс.

Ятото дронове е подходящ пример - то е там за да изпълни някаква работа (задача), измислена от "горното" ниво - човек, артист, CAD. Задачата от типа на "пръснете се в една равнина на през 2м един от друг и се качете на 100м" се подава за изпълнение, оттам ятото работи за да я свърши - примерно мерейки разстояние през 10мс и коригирайки. Към човека долу 100 дрона през 10мс биха могли да подават данни, но човека няма да може да ги обработи (щото монитора му е 50Hz примерно). Виж, ако комуникационния канал позволи да минат тия данни контрола може да се прави централизирано - на лаптопа дето човека гледа. И двата подхода са възможни, и целта е лесно да може да се "сменя" между двете постановки - т.е. да се прехвърлят алгоритмите на различни места. Едното може да е "главния" дрон с някое атомче, може и на thinkpad-а с xeon-а долу, пък ако интернета го позволява - защо не и в офиса на фирмата. Винаги трябва да им мерки за защита - дали облака ще падне, дали батерията на thinkpad-а, дали на главния дрон атомчето ще прегрее - в крайна сметка всеки дрон трябва да има някаква fail safe реакция. Няма как тя (реакцията, защитата) да стане на лаптопа еле пък в облака. А като има защита във всеки дрон системата ще работи и с атом, и с xeon, и с амазон.


Вто Яну 24, 2017 12:03 am
Профил
Ранг: Форумен бог
Ранг: Форумен бог
Аватар

Регистриран на: Сря Апр 27, 2005 11:48 am
Мнения: 4671
Мнение Re: Питане за облачни архитектури
Нали говориш за IOT облак? Мултимедиини и файлови облаци дал господ....
Какви ФПГА, какви АСИКс... В 80% от случаите ще имаш "атомчето" концентратор - някое GSM-че на 80 мандахерца я с JAVA, я с Опен CPU и реално ще работят на около 10 мипса с радио модулчета бипкащи на 8 мипса с трафик и латенция до 15 секунди, като сложиш и GPRS латенцията и стана мазало

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


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

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


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


Вто Яну 24, 2017 10:14 am
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Re: Питане за облачни архитектури
Цитат:
IOT облак

"Как мечки, нали за зайци?"
Не, говорех за IIoT - туй отпред иде да показа Industrial IoT, още популярно по панаирите като "Industry 4.0". Туй щяло да бъде следващата "индустриална революция".
Има доста общи неща с IoT, но има и свои специфики - да кажем разширено IoT.
Няма кой да даде пари за OpenCPU при положение за за един долар за PHY вече сме сложили ethernet и/или wifi отделно, а и процесора е поне от класа на последните модули на sierrawirelss. Ако нещо ще влиза в шкафа на машината ще е най-вече през жична мрежа - как се добавя 2G,3G,wifi или каквото и да е друго вече е известно - с "бисквитка", с бридж, ...
Не изключвам в специфични случаи да се появи нуждата и от такива неща, но те ще трябва да влязат в системата. Т.е. не е лошо отсега да се мисли за съвместимост и в тази посока.

Цитат:
засега разпределените системи или са с някакво ограничено приложение

В известна степен е така - затова и фирмите се борят да излязат на този пазар. Може да е балон, но докато някой подава енергия да помпим балона ще се борим.

Цитат:
Не знам колко е "измислен", но това е моделът по който почти всички работят и предпочитат да работят. Особено когато става дума за управление, PID и т.н.

Не знам за коя област говориш, но в нашия квартал не е така. Има два стандарта - стария IEC61131 който всичко големи го поддържат - Siemens, AB, Шнайдер, Бекхоф, ... И новият, който обаче трудно пробива засега - IEC61499.
Има две-три изречения на викито за IEC61499 които ще цитирам без коментар:
https://en.wikipedia.org/wiki/IEC_61499
Цитат:
IEC 61499-1 defines the architecture for distributed systems. In IEC 61499 the cyclic execution model of IEC 61131 is replaced by an event driven execution model. The event driven execution model allows an explicit specification of the execution order of function blocks. If necessary, periodically executed applications can be implemented by using the E_CYCLE function block for the generation of periodic events as described in Annex A of IEC 61499-1.

За по-любознателните:
https://eclipse.org/4diac/
Изображение


Вто Яну 24, 2017 10:39 am
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Нед Фев 26, 2006 5:52 pm
Мнения: 10356
Местоположение: Добрич
Мнение Re: Питане за облачни архитектури
gicho написа:
Цитат:
Не знам колко е "измислен", но това е моделът по който почти всички работят и предпочитат да работят. Особено когато става дума за управление, PID и т.н.

Не знам за коя област говориш, но в нашия квартал не е така. Има два стандарта - стария IEC61131 който всичко големи го поддържат - Siemens, AB, Шнайдер, Бекхоф, ... И новият, който обаче трудно пробива засега - IEC61499.
Има две-три изречения на викито за IEC61499 които ще цитирам без коментар:


мда... и накрая страницата има едно пдф-че дето се казва:

Цитат:
1. I NTRODUCTION
The centralized control approach is the most commonly used in industrial systems
nowadays
....
3.2 The industry’s view
The industry’s view is the disappointing view. Even though the standard was officially
accepted in 2005 there is no indication that the industry is going to adopt the standard (IEC61499).


Изобщо не съм в час с индустрията... може и да навлезе, може и да не навлезе. Но както казваше баба ми, не всичко което лети се яде ;-)


Вто Яну 24, 2017 11:25 am
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Re: Питане за облачни архитектури
Така е, отчетох го че трудно пробива засега. Тази област е консервативна и докато някой голям не се излъже да се напъне няма да стане. Отделно "поддръжката" не е още на ниво - единични са решенията които го използват, най-популярния "runtime" е на java, само ISAGRAPH има нещо - и то отскоро.
Доста съм се ровил и интересното е че тоя стандарт се приема радушно в академичните среди (на запад де, ако беше по нашенско щеше да е негатив за стандарта). За моделиране на системи и то cross-domain - механика, хардуер, софтуер. Има едно университетско инструментче - PtolemyII:
http://ptolemy.eecs.berkeley.edu/ptolemyII/
Нещо като академичен аналог на Симулинк.
Този доктор има доста интересни публикации, а и излизат други свързани неща покрай неговите:
http://www.vyatkin.org/category/publications/


Вто Яну 24, 2017 1:31 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.
Хостинг и Домейни