Лист за преговор: Central Alarm System Architecture and Communication

📋 Course Outline

1. Overall System Architecture
2. Data Structure and Configuration Table
3. Detector Initialization
4. RS485 Communication Protocol
5. Polling and Alarm Handling Engine
6. Display LCD Management
7. Persistent Storage EEPROM
8. Configuration Interface via UART
9. Main Program Loop

📖 1. Overall System Architecture

🔑 Key Concepts & Definitions

• Overall System Architecture Diagram: A visual representation of the central alarm system's components and their interactions, illustrating how hardware modules connect and communicate within the system.

• Components of the Central Alarm System: The main hardware modules that comprise the system, including the central controller, detection devices, display units, and output modules.

• Hardware Modules and Their Interactions: The physical units such as the STM32 microcontroller, UART/RS485 interface, EEPROM, LCD/OLED display, buzzer/relais, and detectors, along with the communication pathways (e.g., bus RS485) that enable data exchange and control signals among them.

📖 2. Data Structure and Configuration Table

🔑 Key Concepts & Definitions

Detector_t structure: A data structure representing each detector, containing fields such as address, type, state, description, zone, zone ID, last seen tick, alarm timestamp, last value, and enabled status. It encapsulates all necessary information for detector management and operation.

Configuration table for detectors: An array (detector_table) of Detector_t structures, with a maximum size defined by MAX_DETECTORS. It stores the configuration and current status of all detectors in the system, including their descriptions, zones, and operational states.

Data fields and their purposes in detector configuration:

• address: Unique identifier (1-127) for each detector, used for communication.
• type: Specifies the detector type (smoke, heat, flame, CO, manual call), guiding response handling.
• state: Current operational state (normal, alarm, fault, disabled, test, offline).
• description: Textual description of the detector's location or purpose.
• zone: Name of the zone where the detector is installed.
• zone_id: Numeric identifier for the zone, used for zone-specific actions.
• last_seen_tick: Timestamp of the last received sign of life, used to detect offline status.
• alarm_timestamp: Timestamp of the last alarm event.
• last_value: Last analog value read from the detector, relevant for sensors providing analog data.
• enabled: Boolean indicating whether the detector is active or deactivated.

📝 Essential Points

• The Detector_t structure consolidates all relevant data for each detector, facilitating management, status updates, and communication.
• The configuration table (detector_table) is an array of Detector_t that holds all detectors' configurations and current states.
• Each data field in the structure has a specific purpose, such as identification (address), type classification (type), operational status (state), descriptive info (description, zone), and timing info (last_seen_tick, alarm_timestamp).
• The structure supports dynamic updates during system operation, such as changing states, updating last seen times, or modifying descriptions.

💡 Key Takeaway

The Detector_t structure is the core data model for detectors, with dedicated fields for identification, status, description, and timing, stored collectively in a configuration table to enable efficient management and communication within the system.

📖 3. Detector Initialization

🔑 Key Concepts & Definitions

• Detector initialization process: The procedure of setting up detector parameters and states at system startup or during configuration, ensuring each detector's data is correctly loaded and ready for operation. It involves preparing the detector table with initial values, either from default settings or loaded from persistent storage (EEPROM/Flash).

• Configuration setup during installation: The process carried out by the installer to define the initial parameters of detectors, such as address, type, zone, description, and enabled status. This setup is typically performed once during installation and can be stored in the detector table or saved to EEPROM/Flash for persistence.

• Loading configuration from EEPROM/Flash: Retrieving previously saved detector configuration data from non-volatile memory during system startup. This process involves reading stored data, validating it (e.g., via a magic number), and populating the detector table with this data to restore system state after power cycles or resets.

📖 4. RS485 Communication Protocol

🔑 Key Concepts & Definitions

Frame format: The structure of data packets exchanged over the RS485 bus, consisting of specific fields including header, address, command, length, data, and CRC.
Defined by the format: 0xAA | ADDR | CMD | LENGTH | DATA[..] | CRC.

Command codes: Numeric identifiers used by the central unit to instruct detectors or request information.

• 0x01: Poll (interrogation of detector status)
• 0x02: Reset alarm
• 0x03: Test detector
• 0x04: Disable detector

Response codes: Numeric identifiers sent by detectors to indicate their status or data.

• 0x81: Normal state
• 0x82: Fire alarm
• 0x83: Fault (defect)
• 0x84: Analog value

CRC calculation and validation: A simple XOR-based checksum computed over the frame fields to ensure data integrity.

• Calculated by XORing header, address, command, length, and data bytes.
• Validation involves recomputing CRC and comparing it to the received CRC to verify frame authenticity.

📝 Essential Points

• The frame header is fixed at 0xAA.
• The address field uniquely identifies each detector on the bus.
• The command field specifies the action (e.g., poll, reset).
• The length indicates the number of data bytes (max 8).
• Data bytes (DATA[..]) contain variable information, such as sensor readings.
• CRC is an 8-bit XOR checksum used for error detection.
• Sending a poll involves constructing a frame with CMD=0x01, setting the address, and computing CRC before transmission.
• Reception involves reading the frame, validating the header, CRC, and length, then processing based on command and response codes.
• The protocol supports both central-to-detector commands and detector-to-central responses.

💡 Key Takeaway

The RS485 communication protocol uses a structured frame with specific command and response codes, combined with a simple XOR CRC for data integrity, enabling reliable command exchange and status reporting between the central unit and detectors.

📖 5. Polling and Alarm Handling Engine

🔑 Key Concepts & Definitions

• Polling mechanism for detectors: A process where the central system sequentially interrogates each detector on the bus by sending a poll command and awaiting a response within a specified timeout. This ensures real-time status updates for all detectors.

• Alarm processing workflow: The sequence of actions triggered when a detector reports an alarm, including updating detector state, recording the alarm in active alarms list, displaying alarm details on the LCD, activating alarm outputs (sirens, flashers), logging the event, and notifying the supervision PC via UART.

• Active alarm list management: The maintenance of a list (array) that stores details of current alarms, such as address, description, zone, timestamp, and type. New alarms are added when detected, and the list can be cleared or updated as alarms are reset or cleared.

📝 Essential Points

• The polling loop iterates over all enabled detectors, sending a poll command via RS485 and waiting for a response (with a 100ms timeout). If no response is received, the detector is considered offline after 15 seconds of no response.

• When a response indicating an alarm (RESP_ALARM) is received, the system updates the detector's state to STATE_ALARM, records the timestamp, and extracts any analog value if present.

• The alarm processing involves updating the detector's data, adding an entry to the active alarms list (if space permits), displaying alarm details on the LCD, activating sirens and flashers, logging the event, and transmitting alarm info to the supervision PC.

• The active alarms list is a fixed-size array (active_alarms) with a maximum of 32 entries, which is incremented each time a new alarm occurs. Resetting alarms clears this list.

• The polling cycle includes a small delay (HAL_Delay(5)) between interrogations to prevent bus overload.

💡 Key Takeaway

The polling and alarm handling engine systematically interrogates detectors, processes alarm signals, and manages active alarms to ensure timely and organized response to fire incidents.

📖 6. Display LCD Management

🔑 Key Concepts & Definitions

• Display_ShowAlarm: Function responsible for updating the LCD to show detailed alarm information. It displays four lines with specific alarm details, including alarm type, address, description, zone, and value.

• Display_ShowFault: Function that updates the LCD to indicate a fault detected in a detector. It shows two lines with fault status and detector description.

• Display_ScrollAlarms: Function that cycles through active alarms, updating the LCD with summarized alarm information such as alarm number, detector address, type, description, and zone. It enables scrolling through multiple alarms on the display.

• Display_Init: Function that initializes the LCD display, clears the screen, and shows an initial message indicating system initialization.

• Display_ShowNormal: Function that displays the system's normal status when no alarms are active. It shows counts of detectors, alarms, and faults, with a message indicating system normality.

• LCD_Update Procedures: Methods like LCD_SetCursor, LCD_Print, LCD_Clear, LCD_BacklightOn, and LCD_BacklightOff are used to manipulate the LCD content and backlight, ensuring proper display updates and visual cues during alarm events.

📝 Essential Points

• The display management functions are designed to provide real-time visual feedback on system status, alarms, and faults.
• Display_ShowAlarm presents detailed alarm information across four lines, including alarm type, address, description, zone, and last value, with a blinking backlight effect.
• Display_ShowFault and Display_ShowOffline show concise fault or offline messages on two lines.
• Display_ScrollAlarms enables cycling through multiple active alarms, updating the display every call to show the next alarm's summary.
• Initialization (Display_Init) sets up the LCD and displays a startup message.
• The system regularly updates the display based on system state, switching between normal and alarm views.

💡 Key Takeaway

Display management functions efficiently update the LCD to reflect system status, alarms, and faults, providing clear, real-time visual information and facilitating alarm scrolling for multiple active alarms.

📖 7. Persistent Storage EEPROM

🔑 Key Concepts & Definitions

• EEPROM storage for configuration data: Non-volatile memory used to save system configuration, such as detector settings, to ensure data persists after power-off. In the source, EEPROM (specifically AT24C256) stores a header and detector records, enabling configuration recovery at startup.

• Persistence of system settings: The ability of the system to retain configuration and operational data across power cycles. This is achieved by writing configuration data to EEPROM, which is read during system initialization to restore previous settings.

• Data read/write operations: The processes of transferring data to and from EEPROM memory. In the source, functions like EEPROM_Write() and EEPROM_Read() handle these operations, enabling saving and loading of configuration data, including headers and detector records.

📝 Essential Points

• Configuration data, including detector details and system version, are stored in EEPROM with a specific structure: a header (ConfigHeader_t) containing a magic number, detector count, and version, followed by detector records.

• Saving configuration involves writing the header and all detector records sequentially to EEPROM at a predefined base address (CONFIG_BASE_ADDR).

• Loading configuration reads the header first; if the magic number matches, it proceeds to read detector records and initialize system variables accordingly. If the magic number does not match, default configuration is used.

• Data read/write operations are performed via dedicated functions (EEPROM_Write(), EEPROM_Read()), ensuring data integrity and proper memory management.

• This persistent storage mechanism guarantees that system settings survive power loss and can be restored automatically during startup, maintaining system consistency.

💡 Key Takeaway

EEPROM storage provides a reliable, non-volatile means to save and retrieve system configuration data, ensuring persistence of settings and enabling seamless system recovery after power cycles.

📖 8. Configuration Interface via UART

🔑 Key Concepts & Definitions

UART interface for configuration: A serial communication method used to connect the central system to an external device (e.g., PC terminal) for configuring detectors. It enables sending commands and receiving responses through a UART port, facilitating user interaction with the system.

UART command protocol: A structured set of commands exchanged over UART to perform configuration tasks. Commands include actions like listing detectors, adding or modifying detector descriptions, changing zones, saving configurations, and checking status. Commands are parsed and executed by the system to modify internal data or trigger actions.

Interaction with user interface: The process by which the system communicates with the user via UART, providing feedback, displaying detector information, and accepting commands. This interaction is managed through functions that transmit strings and process received characters, enabling real-time configuration and status monitoring.

📝 Essential Points

• The UART interface is used for configuring detectors via a terminal connected to the system.
• Commands such as LIST, ADD, DESC, ZONE, DEL, SAVE, and STATUS are supported.
• Commands are received character-by-character, assembled into a buffer, and then parsed.
• Responses and feedback are sent back over UART using functions like CLI_SendString().
• The command parser (CLI_ProcessCommand()) interprets commands and executes corresponding functions, such as listing detectors or updating descriptions.
• The system maintains a command buffer (cmd_buffer) and an index (cmd_index) to handle incoming data.
• The configuration commands allow for real-time updates, which can be saved persistently in EEPROM.
• The interaction ensures user-friendly configuration and status monitoring without needing external programming tools.

💡 Key Takeaway

The UART configuration interface provides a simple, structured way for users to interact with and configure the system via serial commands, enabling efficient management of detectors and system settings through real-time communication.

📖 9. Main Program Loop

🔑 Key Concepts & Definitions

• Main Loop Operations: The continuous cycle within the main program that manages periodic tasks such as polling detectors, updating display, and handling user inputs. It ensures the system remains responsive and up-to-date by executing specific functions at defined intervals.

• Polling Cycle Timing: The scheduled interval at which the system sends interrogation (poll) commands to all detectors. In the source, detectors are polled every 2000 milliseconds (2 seconds) to check their status via the AlarmEngine_PollAllDetectors() function.

• Event Handling and System Refresh: The process of responding to external or internal events, such as user actions (e.g., pressing the reset button) or system conditions (e.g., alarm states). This includes debouncing inputs, resetting alarms, and updating the display accordingly. The main loop checks for button presses and updates the display every second or when alarms scroll.

📝 Essential Points

• The main loop runs indefinitely (while (1)), maintaining system operation.
• It uses timers (HAL_GetTick()) to control periodic tasks:
  • Polls all detectors every 2000 ms.
  • Updates the display every 1000 ms.
  • Scrolls alarms every 3000 ms if multiple alarms are active.
• The polling involves calling AlarmEngine_PollAllDetectors() to interrogate detectors via RS485.
• Display updates depend on the current alarm state:
  • Shows normal system status if no alarms are active.
  • Counts faults and offline detectors to display system health.
• The system monitors a reset button:
  • Implements debounce delay (50 ms).
  • Resets all alarms and updates display when pressed.
• The system handles UART reception via an interrupt callback (HAL_UART_RxCpltCallback) to process CLI commands asynchronously.

💡 Key Takeaway

The main program loop orchestrates periodic polling, display updates, and event handling to maintain system responsiveness and accurate status reporting, using timed checks and interrupt-driven inputs.

📊 Synthesis Tables

Aspect	Description	Key Authors / References
Overall System Architecture	Visual diagram showing system components, hardware modules, and communication pathways (e.g., STM32, UART/RS485, EEPROM, LCD, detectors).	None
Data Structure (Detector_t)	Struct containing fields: address, type, state, description, zone, zone_id, last_seen_tick, alarm_timestamp, last_value, enabled. Used for detector management.	None
Detector Initialization	Process of setting up detectors at startup, loading configuration from EEPROM/Flash, and preparing detector table for operation.	None
RS485 Frame Format	Fixed structure: `0xAA	ADDR
Polling & Alarm Handling	Sequential interrogation of detectors via RS485, updating states, managing active alarms list, and triggering outputs on alarms.	None

⚠️ Common Pitfalls & Confusions

1. Confusing detector state values (normal, alarm, fault, disabled, test, offline) and their handling.
2. Misinterpreting RS485 frame structure, especially CRC calculation and validation.
3. Overlooking the importance of last_seen_tick for offline detection.
4. Failing to differentiate between command (0x01 poll) and response (0x81, 0x82, etc.) codes.
5. Ignoring the maximum size of data (LENGTH) in RS485 frames, leading to buffer overflows.
6. Not updating detector configuration correctly during initialization or after configuration changes.
7. Mismanaging the active alarms list, such as overwriting or not clearing entries.
8. Forgetting to activate alarm outputs (buzzer, relays) when an alarm is detected.
9. Overlooking the need for persistent storage of configuration data in EEPROM or Flash.
10. Confusing the roles of the central controller and detectors in communication protocol.

✅ Exam Checklist

• Understand the overall system architecture diagram and the role of each hardware module.
• Master the Detector_t structure, including each data field's purpose and how it facilitates detector management.
• Describe the detector initialization process, including loading configuration from EEPROM/Flash.
• Know the RS485 frame format, including header, address, command, length, data, and CRC, and how CRC is calculated and validated.
• Be able to explain the command codes (0x01 poll, 0x02 reset, etc.) and response codes (0x81 normal, 0x82 alarm, etc.).
• Understand how polling is performed, including timeout handling and offline detection via last_seen_tick.
• Describe the alarm handling workflow: detection, updating detector state, adding to active alarms list, displaying info, and activating outputs.
• Know how the active alarms list is managed and its importance.
• Be familiar with the process of storing and loading detector configurations from persistent memory.
• Recognize the importance of updating detector states and configuration during system operation.
• Know authors and key concepts: System architecture, Detector_t structure, RS485 protocol, polling and alarm engine, display management, EEPROM storage, UART configuration interface, main program loop.
• Ensure understanding of the communication protocol's error detection via CRC and frame validation.
• Be able to troubleshoot common issues such as communication errors, incorrect detector states, or configuration mismatches.