Тази статия има задачата да постави началото на една дискусия, която трябва да завърши със създаването на единен стандарт и да сложи ред в автоматиката и предаването на данни за нуждите на телеконтрола. Всички желаещи да се включат в разработването му да се чувстват поканени.
Настоящо състояние:
Датчици и системи: всеки си копае в собствената си градинка – СОТ-аджиите в алармите, пожарникарите - в пожарните, Smart home – в къщната автоматика и т.н. Не че няма взаимовръзка, но тя е ограничена и случайна.
Връзки:
Кабелът – единственото достойнство на връзката с кабел датчик-устройство е цената. Основен недостатък е нуждата от кабел до всеки датчик. По-интелигентното решение е с мрежова организация, като има множество протоколи за тази цел, както на PHY : I2C, RS 485 ниво, така и на MAC Layer LIN, CAN, BITBUSS и т.н.
Ethernet/Internet – писан от програмисти за програмисти и неудобен за малката автоматика. Единствената възможност за визуализация и управление в момента е http (и UDP за broadcast), което налага сравнително малко устройство като датчика да съхранява няколко http страници и да поддържа динамични променливи.
RF тук има множество решения от Х-10, през CAN, MiniWiFi до WiFi – IEEE 802.11. По-простите са подходящи, но несъвместими с другите (по-горе и по-долу), а последният стандарт е подходящ за пренос на големи пакети данни с голяма скорост за статични обекти, които не сменят често рутера и също е неподходящ за датчици.
PL (Power Line) - IEC 61334-5-1 е добре разработен за работа с малки устройства, но той също е ориентиран към стационарни обекти.
GSM – като оставим настрана CSD и SMS, които са несериозни, остава TCP през GPRS и/или с надстройка http и ftp, което пак ни води до Etherne/Internet.
Идеала:
Единен стандарт за лек протокол за работа с датчици и устройства, самоорганизираща се разпределена мрежа, което включва автоматичен процес по идентификация, адресация и оторизация на датчици и устройства (т.е. купувате си какъвто и да е датчик, носите го в къщи, включвате го и той сам се интегрира в съществуващата мрежа, разбира се, след ваше позволение).
Решението:
Можем само да предложим, но не и да наложим решение:
еднакви по структура пакети на MAC ниво, които се опаковат в съответна опаковка за RF, TCP, PL и така нататък
xml -организация на описанието на обектите. Хубавото на xml е, че носи само съществената информация под формата на текст, без атрибути на текста, като големина, фонт, цвят и др. Освен това винаги може да се „дописва отдолу“, без да се налагат други корекции (даже динамично).
единен xml NameSpace безплатен сървър, от който всяка web свързана система може да си изтегли задъжителните атрибути на всяко устройство и работа с тях и всеки инженер да изтегли и напише xml-header за ново устройство
минимален xml-header, който задъжително всяко устройство съдържа и който го описва
единна йерархична система за адресация и разпределение на ролите
Как изглежда това например:
В EEPROM на устройството при производството се записва, например, следния header :
<firmsettings>
<name> Thermometer</name>
<maker> ETA-SYS </maker>
<model> TM-01_2012 </model>
<input>
<inputname> Outside temperature </inputname>
<type> analog </type>
<scale>min=”-50” max=”100” </scale>
<scaletype> linear </scaletype>
<dimension> deg Celsius </dimension>
</input>
<input>
<inputname> Inside temperature </inputname>
<type> analog </type>
<scale>min=”0” max=”50” </scale>
<scaletype> linear </scaletype>
<dimension> deg Celsius </dimension>
</input>
<output>
<outputname> AlarmSounder </inputname>
<type> digital </type>
</output>
</settings>
На който не му е станало ясно, това е термометър с два аналогови входа – за външна и вътрешна температура, външният с линейна скала от -50 до +100 градуса Целзий, а вътрешният от 0 до 50 и един цифров изход за включване на алармен зумер.
Отделно при свързването си в дадена мрежа датчикът получава работни настройки, които също запазва в EEPROM. Те обаче могат да се променят в процеса на експлоатация от системата или да се reset-нат, когато датчикът се пренася на друго място. Например:
<worksettings>
<mysystemname> My Meteo Lab </mysystemname>
<mygroup> temperaturesensors </mygroup>
<myaddress> 0f0001 <myaddress>
</worksettings>
Е сега има ли програмист, който не може да прочете фирмените настройки, да зададе работните и след това да напише нещо от рода:
Get (My Meteo Lab/ 0f0001/ Outside temperature)
за да получи външната температура или
Set (My Meteo Lab/ AlarmSounder) = 1
за да задейства зумера, без да се интересува как работи устройството и къде са му регистрите с данни и след това да визуализира информацията на компютър с какъвто искате Skin?
За адресацията и разпределението на ролите (крайно устройство, репитер, рутер) и самоорганизацията (начална и аварийна) – някой друг път.
Ако обсъжданата тема представлява интерес за Вас и имате идеи- пишете ни на eta-sys@goonet.org.