Pan Mario napisał:

>>> Przepuszczać jakieś dane procesowe przez internet
>>> bez zapakowania w VPN? Raczej nie ryzykowałbym.
>>
>> Robie przelewy w banku przez internet i nie używam
>> przy tym VPN. Taki chojrak ze mnie!
>
> Masz połączenie szyfrowane. Ja bym się bał zostawiać
> zdalny dostęp np do sterownika PLC czy do HMI przez
> internet bez zabezpieczenia.

To już co innego. Mam wrażenie, że VPN jest jednym z częściej
nadużywanych narzędzi -- "nie znam się, nie wiem o co chodzi,
więc na wszelki wypadek zrobię VPN". Szyfrowanie owszem, ale
też nie zawsze jest czego się bać. A jeśli się szyfruje, to z
głową -- czasem jest limit transfetu danych, albo wąski kanał,
więc trzeba szyfrować rozsądnie, a nie przez obudowanie czymś,
co da stukrotny naddatek przesyłanych danych.

--
Jarek

do góry

> Jeśli dopiero robi się urządzenie, to zaprojektowanie gdziazda USB do
> modemu nie jest ekscentrycznym pomysłem, tak się robi. Nie jest wielkim
> wyzwaniem, by obsługiwane były wszystkie modemy (przynajmniej te z
> dłuuugiej listy zalecanych przez producenta).

Tak, ale akurat moje urządzenie jest już nie tylko gotowe, ale także od
dawna produkowane, jest już w wielu miejscach zainstalowane.
Dlatego taka opcja jest korzystna, bo wymaga tylko wymiany "firmware",
co można zrobić bez demontowania go nawet.

Oczywiście nowa wersja powinna mieć np. USB, ale problem w tym, że z
braku czasu powstaje już 2-3 lata. I jest na etapie przemyśleń :)


> Miałem wielokrotnie do czynienia z urządzeniami, które komunikowały się
> ze światem przez port szeregowy. Takie ustrojstwo żyje własnym życiem,
> a po podłączeniu czegoś do RS232 można sobie z nim pogadać o tym, jak mu
> ostatnio szło. Zawsze było to tak, że podłącza się standardowy program
> terminala, na którym pojawaia się wtedy zachęta w rodzaju "Sundayman
> Advanced Devices, please type 'help'". Wtedy można prostymi żołnierskimi
> poleceniami przeczytanymi w tym helpie pogadać z diwajsem, skonfigurować,
> wydać mu polecenia, odpytać z raportów. Gdy ten sprzęt projektowano,
> takie rozmowy zawsze odbywały się in situ, bo nikt nawet nie myślał
> o komunikacji przez sieć.

No i obecnie tak to mam zrobione. Znaczy szczątkowo, bo nie było
potrzeby bardziej - wszystko jest konfigurowalne via LCD, ale niektóre
rzeczy właśnie tak są zrobione.


> Ja dostosowując się do zwyczaju pisałem skrypty, które zastępowały
> człowieka przy rozmowie, a potem to czego się dowiedziały, słały gdzieś
> przez sieć. Programy takie jak minicom (a wcześniej Telix pod DOS) są
> znakomitym wsparciem do takich działań. Jeszcze raz chcę podkreślić
> jaka tu konwencja -- o wszystkim decyduje zewnętrzny komputer.

Będzie mi chyba łatwiej dostosować mój program w urządziu do obsługi
modemu, niż dodawać tą "inteligencję" na zewnątrz. Tak mi się wydaje...

,
> by samo urządzenie decydowało *kiedy* chce gadać i jak, nie jest zbyt
> szczęśliwy. W szczególności jest w konflikcie z działaniami in situ
> przy udziale czynnika ludzkiego,

No tak, ale nic nie stoi na przeszkodzie, żeby był wybór - w menu
urządzia będzie opcja "MODEM on/off". I będzie albo można sobie ręcznie
pisać w teminalu, albo - sterowanie zdalne.

> zanim jeszcze nie zrobiło się zbyt dalekich kroków, gdy projetk nie
> jest ukończony, warto obstalować sobie konsultacje z kimś, kto ma
> doświadczenie i pojęcie o takich rzeczach.

No jak pisałem - ta obsługa via GSM ma być dodatkiem do już dawno
istniejącego systemu.

do góry

> Używałem tych takich w czerwonych obudowach. To znaczy moje były
> w kolorze aluminium, ale poza tym wszystko to samo z dokłdnością
> do każdej śrubki. W środku trochę co innego ale nie tak bardzo
> co innego. Widzę, że firmy trzymają się wspólnych standardów,
> nawet żelastwo to samo. Ale to przebrzmiały standard, dostsowanie
> się do niego dzisiaj, to szaleństwo.

Pewnie tak :) Ale na razie to wystarczy. Użyszkodnik będzie i tak bardzo
zadowolony :)


> została, całkiem nieużywana. Nie wiem co z nią zrobić. Bo nie mam
> ochoty tykać nawet długim kijem.

Możesz podać jakiś model czy coś bliżej ?
Z tego co doczytałem, to chyba różne firmy stosuję swoje własne komendy
AT do obsługi np. TCP/IP ?

do góry

> Na razie chłop nie wygląda na niezadowolonego.

Bardzo jestem zadowolony i wdzięczny za wszelkie uświadomienie :D

> zdawał się prosty, a w praktyce jest nie warty realizacji. Teraz
> poznał inne, sam zdecyduje co robić dalej. O rozwiązaniach, które
> polegają na zagadaniu przez RS modemu celem wywołania tkwiących
> w nim procedur komunikujących się przez TCP/IP (ftp, mail i inne)
> też wspomniałem od razu. I choć pisania przy tym wiele nie ma, to
> cały czas uważam, że jeśli komuś to tylko raz potrzebne, to nie warto.
> Sugeruję, by wziął bardzo skomplikowaną rzecz, którą tysiące ludzi
> wspólnymi siłami wymyślali przez wiele lat. Bo tak najprościej
> i najtaniej.

Podsumowując :

1. rzecz dotyczy urządzenia, które jest w wielu miejscach zainstalowane
(ale można wymienić software), i na razie nadal będzie robione w tym
samym wykonaniu przez jakiś czas... Aż zrobię nową wersję :)

2. do dyspozycji jest RS232, w środku siedzi Atmega128

3. chodzi o przesyłanie małych ilości danych ( no bo komend w rodzaju
"ustaw parametr x=128", czy odczyt jakiegoś parametru.
Oczywiście wolałbym to wysyłać "w bloku" kompleksowo, to będzie kilkaset
bajtów, albo max. kilkadziesiąt dla odczytu pamięci.

Te dane docelowo mają trafić do programu na PC, który to odpowiedni
pokaże. Taki soft coś jak np. dla central alarmowych.

4. Rozwiązanie musi być bezpieczne "formalnie" - czyli część GSM z
papierami, certyfikatami itp.

5. Ilość urządzeń obsługiwana w jednej sieci może sięgać kilkudziesięciu
( najczęściej 20-50 ).

6. transmisja musi być w miarę bezpieczna - choć nie spodziewam się,
żeby ktoś rozkminiał dane przesyłane do tych sterowników, bo to mało
atrakcyjne jest (sterowanie pompami). Pomyślę oczywiście nad jakimiś
zabezpieczeniami typu hasło, itp.
Ale - z drugiej strony, gdyby ktoś się do tego dobrał, mogłyby być
bardzo nieprzyjemne konsekwencje...

7. koszt jak zawsze jest ważny - ale bez przesady. Lepiej, żeby
kosztowało 500 i nie sprawiało problemów, niż ma kosztować 100 i nie
działać, albo działać byle jak.

8. dobrze by było, żeby była (przynajmniej opcjonalnie) możliwość
działania całego interesu w chwili wyłączenia sieci 2G (kiedy to będzie
i czy będzie ??)

8. z uwagi na minimalne doświadczenie z tego typu transmisja (że tak
ładnie to określę) - mile widziane rozwiązania łopatologiczne.
Czyli żebym (na razie) nie musiał robić z tego doktoratu.

9. Dobrze by było faktycznie, żeby się oprzeć na rozwiązaniu, które
dałoby się przystosować/zastosować także w "nowej wersji", gdzie już
nie musi być na RS232

____________________________________________________
________________


No to - dla takich założeń - co byście zrobili ??

do góry

> Zwykły modem GSM900, który działa z arduino ma zaimplementowane IP stack
> i ma możliwośc zestawienia połączenia TCP za pomocą komend AT.
> Kosztuje 20 dolców jako dev kit..
> http://www.ebay.com/itm/311519547314?hash=item488803
0fb2
> 11 dolców jako moduł http://www.ebay.com/itm/311447881171
> lub klika dolców jako sam moduł http://www.ebay.com/itm/401050420211

oj, mam wątpliwości, co do możliwości zastosowania takiego rozwiązania.
Musi być modem, który jest "gotowym produktem", z odpowiednim papierem,
CE, itp. Na pełnym legalu w zakresie stosowanie tego do telemetrii.

do góry

On 25/02/2016 17:49, sundayman wrote:
>
>> Zwykły modem GSM900, który działa z arduino ma zaimplementowane IP stack
>> i ma możliwośc zestawienia połączenia TCP za pomocą komend AT.
>> Kosztuje 20 dolców jako dev kit..
>> http://www.ebay.com/itm/311519547314?hash=item488803
0fb2
>> 11 dolców jako moduł http://www.ebay.com/itm/311447881171
>> lub klika dolców jako sam moduł http://www.ebay.com/itm/401050420211
>
> oj, mam wątpliwości, co do możliwości zastosowania takiego rozwiązania.
> Musi być modem, który jest "gotowym produktem", z odpowiednim papierem,
> CE, itp. Na pełnym legalu w zakresie stosowanie tego do telemetrii.
>

http://www.simcom.eu/index.php?m=termekek&prime=1&su
b=40&id=0000000147&page=1

Certificates:

CE
FCC
ROHS
PTCRB
GCF
IC
ICASA
TA
REACH
AT&T

do góry

> No to - dla takich założeń - co byście zrobili ??
bo się kuśwa pogubiłem :/

do góry

sundayman pisze:

>> Używałem tych takich w czerwonych obudowach. To znaczy moje były
>> w kolorze aluminium, ale poza tym wszystko to samo z dokłdnością
>> do każdej śrubki. W środku trochę co innego ale nie tak bardzo
>> co innego. Widzę, że firmy trzymają się wspólnych standardów,
>> nawet żelastwo to samo. Ale to przebrzmiały standard, dostsowanie
>> się do niego dzisiaj, to szaleństwo.
>
> Pewnie tak :) Ale na razie to wystarczy. Użyszkodnik będzie i tak
> bardzo zadowolony :)

To był przejaw troski o tego, kto to będzie implementował.

>> została, całkiem nieużywana. Nie wiem co z nią zrobić. Bo nie mam
>> ochoty tykać nawet długim kijem.
>
> Możesz podać jakiś model czy coś bliżej ?
> Z tego co doczytałem, to chyba różne firmy stosuję swoje własne
> komendy AT do obsługi np. TCP/IP ?

W takim właśnie aluminiowym opakowaniu został mi modem Wavecom. Miałem
też takie bez otoczki, sama płytka OEM, wielkości biletu na tramwaj,
nawet niewiele grubsza. Specjalnie sprytne toto nie było, umiało robić
GPRS przez odpalenie pppd na linuksie, do którego było podłączone.
Wtedy to i tak było dużo, ja więcej nie potrzebowałem. Miałem też modemy
firmy Telit -- te już potrafiły same zrobić sobie połączenie TCP/IP,
ale ja z tego nie korzystałem, traktowane były tak samo jak Wavecomy.
To wtedy była nowość, później te rzeczy rozwijano, może warto się tym
zainteresować. Komenty AT może się tu i tam różnią, ale to chyba nie
jest wielki problem -- one mają być wysokopoziomowe, zakładam, że ich
potrzeba z dziesięć na krzyż, można uwzględnić kilka dialektów. Przykład
da się zobaczyc choćby tu: http://www.multitech.com/manuals/s000457l.pdf .
Dialog wysyłania i odbierania pliku przez FTP jest w okolicach str. 111.

--
Jarek

do góry

sundayman pisze:

>> Ja dostosowując się do zwyczaju pisałem skrypty, które zastępowały
>> człowieka przy rozmowie, a potem to czego się dowiedziały, słały gdzieś
>> przez sieć. Programy takie jak minicom (a wcześniej Telix pod DOS) są
>> znakomitym wsparciem do takich działań. Jeszcze raz chcę podkreślić
>> jaka tu konwencja -- o wszystkim decyduje zewnętrzny komputer.
>
> Będzie mi chyba łatwiej dostosować mój program w urządziu do obsługi
> modemu, niż dodawać tą "inteligencję" na zewnątrz. Tak mi się wydaje...

Może się wydawać. Po jednej stronie jest nauczenie starego i mało kumatego
systemu nowych sztuczek, a po drugiej wytłumaczenie inteligentnej bestii
jak ma gadać z bratem mniejszym. Radzę wziąć tego minicoma odpalonego na
dowolnym systemie z Linuksem (Mac OS też może być ostatecznie) i pogadać
ze swoim ustrojstwem, napisać skrypt, który dialog automatyzuje. Korzyść
może być przy tym jeszcze taka, że potrafią przy tej robocie wypłynąć
braki, niedoróbki i nielogiczności w interfejsie, które komplikują pisanie
skryptu. Wtedy poprawić, zwiększyć klarowność -- nie tylo roboty, ale
i ludzie się ucieszą. Jak się wszystko sprawdzi na pececie, to przenieść
na małe urządzenie. Tu i tam może działać tak samo.

Potem mozna ocenić, czy lepiej działać tak, czy gadać wprost z modemem
(wskazówki dałem przed chwilą).

--
Jarek

do góry

sundayman wrote:

>
>
>> No to - dla takich założeń - co byście zrobili ??
> bo się kuśwa pogubiłem :/

Weź dowolny modem, np SIM900D (to tylko przykładowy typ; ma uarta).
Napisz w swoim urządzeniu coby się łączył z internetem i np. co 5minut
wysyłał dane na internet (na Twój serwer) i jednocześnie sprawdzał czy są
dla niego jakieś dane konfiguracyjne, tak w skrócie.

jp

do góry