Centralka (nie tylko) alarmowa

Centralka oparta jest na układzie z procesorem ARM, systemem linux i interfejsem ethernetowym (raspberry-pi) i peryferiach podłączanych z wykorzystaniem i2c i portów szeregowych (jeżeli w danym module ich brakuje można ich ilość zwiększyć z użyciem układu FT4232 np. w formie modułu MMusb4232H). Zapewnia to modularność, elastyczność, łatwość w modyfikacji i rozbudowie takiej konstrukcji, a w przeciwieństwie do stosowanej w poprzedniej wersji magistrali równoległej nie wywołuje aż tak strasznej plątaniny połączeń.

Założeniem jest bezpośrednia (poprzez i2c) obsługa przez sterownik linuxowy linii wejściowych z czujników alarmowych (analogowych, gdyż brakuje otwartego standardu komunikacyjnego dla czujników adresowalnych, stosowane są wewnętrzne protokoły danego producenta systemu co uniemożliwia ich wykorzystanie w takim projekcie) - zarówno włamaniowych (np. PIR) jak i p.poż., a także części linii wejściowych i wyjściowych ogólnego przeznaczenia. Z wykorzystaniem magistral szeregowych RS485 i protokołu modbus-rtu podłączane są moduły rozproszonego DI (klawiatury i przełączniki oświetlenia z własnym uC oparte na Atmega8 i FreeMODBUSkopia lokalna), sterowniki wykonawcze oświetlenia, gniazd i ogrzewania (moduły triakowe, moduły tranzystorowe do przekaźników z własnym uC oparte na Atmega8 i FreeMODBUS, czujniki oraz mierniki innych producentów używające modbusa (np. analizatory PM710).

Podłączanie czujników alarmowych

Czujniki systemów alarmowych podłączane jako rezystancyjne linie trójstanowe (alarm, sabotaż/awaria, normalny - schemat ideowy (PDF, PNG) ). Bardzo istotnym zagadnieniem jest zapewnienie niezależności zasilania takich czujników od systemu głównego (zwarcie w linii zasilającej czujnik nie może powodować utraty zasilania przez centralkę). Podobnie linie te powinny być zabezpieczone przepięciowo (przed podaniem zbyt dużego napięcia), a linie sygnałowe powinny być optoizolowane - podanie tam zbyt dużego napięcia nie może uszkodzić lub nawet wyłączyć centralki.

Podłączenie rezystancyjne czujników (przy zachowaniu wyżej opisanych zabezpieczeń) utrudnia dokonanie sabotażu takiej linii w stosunku co do zwykłej linii DI (którą wystarczy przeciąć lub zewrzeć), ale jest on nadal możliwy - wystarczy podłączyć do linii sygnałowej źródło napięcia takiego jakie jest związane z stanem normalnym tej linii, wydawałoby się że problem rozwiąże zastosowanie losowo zmiennego napięcia, ale to też da się obejść. Dodatkowym problemem jest stan przekaźnika w momencie gdy czujka nie ma zasilania - powinien on odpowiadać stanowi usterki, w ostateczności alarmu, ale nigdy stanowi normalnemu linii, tak aby nie dało się obejść systemu przez odłączenie zasilania (lub masy) od czujki. Jedynym rozwiązaniem dającym dużą pewność że odczytywany sygnał jest faktycznie od czujki jest zastosowanie szyfrowanej komunikacji protokolarnej np. poprzez rs485 lub ethernet - wymaga to stosowania zabezpieczonego przed dostępem modułu elektronicznego umieszczanego w samej czujce. Niezależnie od tego pozostaje kwestia traktowania stanu usterki w zależności od tego w jakim jest to systemie (p.poż czy włamaniowym) oraz czy system jest uzbrojony czy rozbrojony.

Pierwotnie planowana była realizacja detekcja stanu linii trójstanowej poprzez zestaw dwóch komparatorów okienkowych, wytwarzających wytwarza dwa sygnały cyfrowe (alarm i usterka). Zaprojektowana została realizacja takiego układu wraz z systemem detekcji zmiany i zatrzaskiwania informacji o niej (wytwarzanie sygnału INT) oparta na elementach o małym stopniu integracji - moduł dla pojedynczej linii (schemat ideowy (PDF, PNG) i projekt PCB (PDF) ) oraz backplane dla 4 takich modułów (schemat ideowy (PDF, PNG) i projekt PCB (PDF) ). Niestety rozwiązanie to jest dość skomplikowane i bardzo duże.
Próba znalezienia układu scalonego bufora który potrafiłby wykrywać zamianę i zatrzaskiwać informację o niej doprowadziła do znalezienia MCP23008. Zgodnie z dokumentacją układu MCP23008 powinien on być wstanie odnotowywać informacje o liniach wywołujących przerwania w trakcie trwania przerwania, dzięki czemu mógłby posłużyć do realizacji takiej detekcji zmiany znacznie upraszczając ten układ, jednak przeprowadzone testy wskazują że niestety nie działa on w ten sposób. Funkcjonalność taką można realizować też na ADC lub poprzez (odpowiednio szybkie) czytanie sygnałów wychodzących z komparatorów okienkowych (alarm i usterka) i programową ich analizę, jednak tracimy wtedy przewagę szybkości realizacji sprzętowej. Mimo to ostatecznie zostało to zrealizowane z wykorzystaniem przetwornika analogowo-cyfrowego wbudowanego w Atmega8.

Realizacja centralki - moduły

Wstępne założenia funkcjonalne (jedna szyna i2c -> max. 16 układów) wyglądały:

  • multiplekser magistrali i2c oparty na PCA9544 lub PCA9548
  • płytka analog + 1wire
    • optoizolacja I2C na bazie P82B96 + układ zasilania części izolowanej (czyli prawie całej płytki i magistral 1wire)
    • 4x lub 8x magistrala 1wire (1x DS2482S-100 + switch 1wire oparty na 4052 lub 4051)
    • 8x analog-input (2x PCF8591)
    • 2x rs485 (2x SC16IS760IPW lub 1x SC16IS762IPW + optoizolacja + driver rs485)
  • płytki (jeden z bitów adresowych ustawiany zworką) z zestawem wejść:
    • 32x digital-input (4x MCP23008 + 8x transoptor ISP620-4X, ISP621-4X lub inny)

Ponaddto planowany był moduł z mikrokontrolerem do obsługi czujnika wilgotności SYH-1S.

Ostatecznie została ona zrealizowana w oparciu o raspberry-pi z podłączonym po USB układem FT4232H (realizującym poprzez odpowiednie interfejsy linie rs485/modbus - schemat ideowy (PDF, PNG) , projekt PCB (PDF) ) oraz podłączonymi po i2c modułami:

Skrypty sterujące dla raspberry-pi:

  • run.sh - głowny plik skryptu
  • output.sh - obsługa sygnalizacji i sterowanych urządzeń
  • input.sh - obsługa wejścia

Ponaddto zamieszczam przydatne pliki, skrypty dla raspberry-pi

  • rpi-config.txt - konfig dla raspberry-pi uruchamiający go z wyjściem HDMI w full-hd nawet gdy nie ma podłączonego monitora
  • rpi-rc.local - plik startowy kontrolujący poprawność uruchomienia sieci i odpalający access point wifi
  • koncepcja_odczytu_di.c - rozważania koncepcyjne na temat odczytu DI w C

Pobierz



Copyright (c) 1999-2015, Robert Paciorek (http://www.opcode.eu.org/), BSD/MIT-type license


Redystrybucja wersji źródłowych i wynikowych, po lub bez dokonywania modyfikacji JEST DOZWOLONA, pod warunkiem zachowania niniejszej informacji o prawach autorskich. Autor NIE ponosi JAKIEJKOLWIEK odpowiedzialności za skutki użytkowania tego dokumentu/programu oraz za wykorzystanie zawartych tu informacji.

This text/program is free document/software. Redistribution and use in source and binary forms, with or without modification, ARE PERMITTED provided save this copyright notice. This document/program is distributed WITHOUT any warranty, use at YOUR own risk.

Valid XHTML 1.1 Dokument ten (URL: http://www.opcode.eu.org/usage_and_config/smart_home/centralka_alarmowa) należy do serwisu OpCode. Autorem tej strony jest Robert Paciorek, wszelkie uwagi proszę kierować na adres e-mail serwisu: webmaster@opcode.eu.org.
Data ostatniej modyfikacji artykulu: '2015-09-26 16:21:46 (UTC)' (data ta może być zafałszowana niemerytorycznymi modyfikacjami artykułu).