IOT Device Architecture | مستندات پروژه‌ها

Reference: elevator_iot_diagram_codes_bundle.zip

معماری ارتباط بوردهای آسانسور با Backend پروژه IOT

این صفحه معماری دریافت و ارسال دیتا از بوردهای آسانسور به سامانه ناوگان سان/IOT را مستند می‌کند. تمرکز آن روی مسیر telemetry و event است: تابلو آسانسور، IoT Node، Gateway ساختمان، شبکه خروجی امن، MQTT Broker، سرویس ingest، ذخیره‌سازی و داشبورد/هشدار.

Elevator BoardIoT NodeBuilding GatewayMQTT/TLSBackend IngestEvent StoreFleet DashboardSafety Boundary

جهت ارتباطOutboundاز ساختمان به backend

پروتکل مرکزMQTT/TLStopic-based ingest

مدل پیامEvent + Statussequence و timestamp

مرز ایمنیRead-onlyبدون فرمان حرکت

خلاصه معماری

هر آسانسور از طریق خروجی‌های ایزوله تابلو به یک IoT Node وصل می‌شود. Node وضعیت‌ها را می‌خواند و فقط وقتی تغییر معنی‌دار رخ دهد event تولید می‌کند. چند Node داخل یک ساختمان به Gateway مشترک وصل می‌شوند؛ Gateway پیام‌ها را تجمیع، buffer و با MQTT/TLS به backend پروژه IOT ارسال می‌کند. Backend پیام‌ها را validate و normalize می‌کند، سپس state فعلی ناوگان، تاریخچه رخدادها و هشدارها را برای dashboard و APIها آماده می‌سازد.

این معماری برای مانیتورینگ و تحلیل عملیاتی طراحی شده است، نه کنترل مستقیم آسانسور. بنابراین مسیر برگشتی فقط برای تنظیمات کم‌ریسک، OTA کنترل‌شده یا acknowledgement استفاده می‌شود و نباید فرمان حرکت، توقف اضطراری یا bypass مدار ایمنی را حمل کند.

قرارداد لایه‌ها

لایه	مسئولیت	قرارداد / محدودیت
تابلو آسانسور	منبع وضعیت خام آسانسور است: run، fault، door، floor، service mode و سایر سیگنال‌های خواندنی.	خروجی‌ها باید ایزوله باشند. این لایه نباید هیچ فرمان کنترلی از سامانه IOT دریافت کند.
IoT Node	سیگنال‌های بورد را می‌خواند، نویز رله را debounce می‌کند، تغییر state را تشخیص می‌دهد و event می‌سازد.	هر پیام باید `device_id`، `building_id`، `elevator_id`، `timestamp`، `sequence` و `event_type/status` داشته باشد.
Building Gateway	چند node داخل ساختمان را تجمیع می‌کند، در قطعی اینترنت buffer نگه می‌دارد و با retry کنترل‌شده publish می‌کند.	ارتباط بیرونی فقط outbound با MQTT/TLS است؛ inbound عمومی به شبکه ساختمان لازم نیست.
MQTT Broker	مرز ingest پیام‌هاست و topicها را بر اساس building/elevator/gateway جدا می‌کند.	Topicها باید versioned و قابل اعمال ACL باشند؛ wildcard باید فقط برای سرویس‌های مجاز backend فعال باشد.
IOT Ingest Service	پیام را validate، normalize و deduplicate می‌کند و state فعلی آسانسور را از روی eventها به‌روزرسانی می‌کند.	پیام تکراری با `device_id + sequence` یا idempotency key حذف می‌شود.
Telemetry/Event Store	رخدادها، heartbeat، آخرین وضعیت و تاریخچه faultها را ذخیره می‌کند.	event خام immutable نگه داشته شود؛ projectionهای dashboard قابل بازسازی باشند.
Dashboard / Alerting	وضعیت ناوگان، سلامت gateway/node، faultهای فعال و history را نمایش می‌دهد و هشدار می‌سازد.	از این مسیر فقط configuration امن یا OTA کنترل‌شده مجاز است؛ فرمان حرکت آسانسور مجاز نیست.

قرارداد پیام

برای اینکه backend بتواند پیام‌ها را idempotent، قابل ردیابی و قابل بازپخش پردازش کند، هر payload باید metadata ثابت داشته باشد. payload خام سنسورها می‌تواند بسته به firmware تغییر کند، اما envelope پیام باید پایدار بماند.

Field	دلیل وجود	نمونه
`tenant_id`	جداسازی مالک یا شرکت بهره‌بردار	saan
`building_id`	اتصال رخداد به ساختمان	BLD-101
`elevator_id`	اتصال رخداد به آسانسور مشخص	ELEV-101-01
`device_id`	ردیابی node یا gateway تولیدکننده پیام	NODE-101-01
`event_type`	نوع رخداد یا وضعیت	door_open, fault, heartbeat
`timestamp`	زمان تولید رخداد در device یا gateway	2026-06-14T10:30:00Z
`sequence`	تشخیص ترتیب، retry و duplicate	184239
`payload`	جزئیات sensor/state	{"floor": 4, "door": "open"}
`firmware_version`	ردیابی رفتار نسخه firmware	1.8.2
`signal_quality`	تشخیص مشکل ارتباطی gateway	rssi=-72

Topicهای MQTT

Topicها باید ساختار سلسله‌مراتبی قابل ACL داشته باشند تا هر ساختمان، آسانسور و gateway جداگانه قابل کنترل، مانیتور و عیب‌یابی باشد.

Topic Pattern	کاربرد
`buildings/{building_id}/elevators/{elevator_id}/status`	آخرین وضعیت خوانده‌شده از آسانسور
`buildings/{building_id}/elevators/{elevator_id}/events`	رخدادهای edge-triggered مثل fault، تغییر طبقه، تغییر درب
`gateways/{gateway_id}/health`	heartbeat، کیفیت شبکه، وضعیت buffer و نسخه gateway
`devices/{device_id}/telemetry`	telemetry خام یا فنی برای عیب‌یابی node
`devices/{device_id}/config/accepted`	تایید دریافت تنظیمات مجاز؛ بدون فرمان عملیاتی خطرناک

نمای کلان ارتباط ناوگان با Backend IOT

Buildings, gateways, MQTT broker and IOT backend

flowchart LR
  subgraph B1["ساختمان ۱"]
    direction LR
    B1E1["تابلو<br/>+ نود IoT"]
    B1E2["تابلو<br/>+ نود IoT"]
    B1E3["تابلو<br/>+ نود IoT"]
    B1GW["Gateway ساختمان<br/>LTE/Ethernet"]
    B1E1 --> B1GW
    B1E2 --> B1GW
    B1E3 --> B1GW
  end
  subgraph B2["ساختمان ۲"]
    direction LR
    B2E1["تابلو<br/>+ نود IoT"]
    B2E2["تابلو<br/>+ نود IoT"]
    B2E3["تابلو<br/>+ نود IoT"]
    B2GW["Gateway ساختمان<br/>LTE/Ethernet"]
    B2E1 --> B2GW
    B2E2 --> B2GW
    B2E3 --> B2GW
  end
  INTERNET(("Internet<br/>4G / Fiber"))
  subgraph IOT["Backend پروژه IOT"]
    direction TB
    MQTT["MQTT Broker"]
    INGEST["Ingest / Normalizer"]
    API["Fleet API"]
    DB["Telemetry + Event DB"]
    DASH["Dashboard / Alerting"]
    MQTT --> INGEST --> DB
    DB --> API --> DASH
  end
  B1GW -- "Outbound MQTT/TLS" --> INTERNET
  B2GW -- "Outbound MQTT/TLS" --> INTERNET
  INTERNET --> MQTT
  SAFETY["مرز ایمنی: فقط خواندن وضعیت و ارسال رخداد؛ فرمان حرکت، توقف اضطراری یا bypass مدار ایمنی از این مسیر مجاز نیست."]

گراف ارتباط داخل ساختمان

Elevator boards, IoT nodes, local bus and gateway

flowchart LR
  Board1["تابلو آسانسور ۱<br/>خروجی‌های ایزوله"] --> Node1["IoT Node 1<br/>ESP32/STM32"]
  Board2["تابلو آسانسور ۲<br/>خروجی‌های ایزوله"] --> Node2["IoT Node 2<br/>ESP32/STM32"]
  Board3["تابلو آسانسور ۳<br/>خروجی‌های ایزوله"] --> Node3["IoT Node 3<br/>ESP32/STM32"]
  Node1 -- "RS-485 / Ethernet" --> BUS["شبکه داخلی ساختمان<br/>RS-485 ایزوله یا Ethernet"]
  Node2 -- "RS-485 / Ethernet" --> BUS
  Node3 -- "RS-485 / Ethernet" --> BUS
  BUS --> GW["Gateway ساختمان<br/>Buffer + Aggregation"]
  UPS["UPS / Power Supply<br/>24V/5V صنعتی"] --> GW
  GW --> Router["Router / Modem<br/>4G یا اینترنت ساختمان"]
  Router -- "MQTT/TLS" --> Backend["IOT Backend"]

جریان دریافت و ارسال دیتا

Signal read, event creation, MQTT ingest and alerting

sequenceDiagram
  autonumber
  participant Board as Elevator Board
  participant Node as IoT Node
  participant GW as Building Gateway
  participant MQTT as MQTT Broker
  participant Ingest as IOT Ingest Service
  participant DB as Telemetry/Event Store
  participant Alert as Alerting/Dashboard
  Board->>Node: isolated signals: fault/run/door/floor
  Node->>Node: debounce + state machine + event detection
  Node->>GW: event/status message with timestamp and seq
  GW->>GW: buffer when offline and batch retry
  GW->>MQTT: publish over MQTT/TLS with QoS
  MQTT->>Ingest: route by topic hierarchy
  Ingest->>DB: normalize, deduplicate, persist
  Ingest->>Alert: evaluate alarm rules
  DB-->>Alert: fleet state, history and reports

مدل شناسه‌گذاری و Topicها

Tenant, building, elevator, gateway and MQTT topic hierarchy

flowchart TB
  Tenant["Company / Tenant"]
  Tenant --> BLD101["Building ID<br/>BLD-101"]
  Tenant --> BLD102["Building ID<br/>BLD-102"]
  BLD101 --> ELEV10101["Elevator ID<br/>ELEV-101-01"]
  BLD101 --> ELEV10102["Elevator ID<br/>ELEV-101-02"]
  BLD101 --> GW101["Gateway ID<br/>GW-101"]
  ELEV10101 -. "status/events" .-> Topic1["buildings/BLD-101/elevators/ELEV-101-01/status<br/>buildings/BLD-101/elevators/ELEV-101-01/events"]
  GW101 -. "health" .-> Topic2["gateways/GW-101/health"]

رفتار در خطا و قطعی

سناریو	رفتار مورد انتظار	ریسک طراحی
قطع اینترنت ساختمان	Gateway پیام‌ها را با sequence در buffer محلی نگه می‌دارد و بعد از برگشت ارتباط batch/retry می‌کند.	نیاز به محدودیت حجم buffer و policy حذف قدیمی‌ترین پیام‌ها.
ریست شدن Node	Node بعد از boot یک health/status کامل می‌فرستد تا backend state را sync کند.	sequence باید reset قابل تشخیص داشته باشد.
پیام تکراری	Backend با idempotency key پیام تکراری را discard می‌کند.	بدون dedup آمار fault و alert نادرست می‌شود.
اختلاف ساعت device	Gateway یا backend زمان دریافت را هم کنار زمان تولید ذخیره می‌کند.	تحلیل timeline باید تفاوت device_time و received_at را نشان دهد.
ضعف سیگنال 4G	health topic شامل RSSI/latency/buffer_depth باشد.	هشدار communication degradation جدا از fault آسانسور ثبت شود.

نکات امنیت و ایمنی

ارتباط بیرونی ساختمان باید outbound باشد و با TLS و credential اختصاصی gateway برقرار شود.
ACL روی topicها باید مانع publish یا subscribe غیرمجاز بین ساختمان‌ها و tenantها شود.
مسیر IOT نباید به مدار ایمنی آسانسور فرمان عملیاتی بدهد؛ داده‌ها فقط برای مانیتورینگ، هشدار، گزارش و تحلیل استفاده می‌شوند.
هر gateway و node باید نسخه firmware و health دوره‌ای ارسال کند تا مشکل ارتباطی از fault واقعی آسانسور جدا شود.
Backend باید event خام را immutable نگه دارد و viewهای dashboard را از روی eventها/projectionها بسازد.