System controller application example: Home Security System

Use cases

• Demonstrates the operation and internal workings of the following software design patterns:
  • Queued Message Handler with Multiple Process Loops
  • Queued State Machine to implement behavior within each process loop
  • Event-Driven Producer/Consumer State Machine design pattern to implement a responsive user interface on the PC host
• Use as a template for your own embedded control and monitoring application software architecture that promotes reliability, scalability, and maintainability

Features

• A complete example of a medium-complexity system controller modelled on an actual home security system product
• Uses virtual I/O devices so that you can experience the system immediately, but is straightforward to upgrade to physical devices from the NI Project Essentials Guide:
  • Keypad
  • LCD display using either SPI, I2C, or UART interface
  • Hall-effect sensor or photointerrupter as the door sensor
  • Sonic range finder as the motion sensor
• RT system controller includes process loops that interact with each other by passing messages through queues:
  • Command Parser
    • Accepts connection requests from PC host
    • Parses the received commands and inserts messages into the System Manager queue
    • Uses network stream communication with PC host
  • System Manager
    • Maintains the high-level operating mode of the overall system
    • Issues commands to the task loops which respond with alert messages
  • Code Validator
    • Accepts keypad input and validates the input sequence against the stored arm/disarm code
    • Ensures that complete three-digit sequence is entered within a time window
    • Issues alert when a valid code has been entered on the keypad
  • Timer
    • Countdown timer used during the pre-arm and pre-alarm steps
    • Issues an alert when the timer expires
  • Sensors
    • Polls the door and motion sensors when enabled
    • Issues an alert when the sensor changes to an active state
  • LED
    • Status indicator for user interface
    • Indicates whether the system is “on” (armed) or “off” (disarmed)
    • Blinks to indicate pre-arm step
  • Error handling loop
    • Traps errors generated anywhere in the system to avoid unexpectedly shutting down the controller
    • Responds to the error with appropriate action (at present the error handler broadcasts a “Shutdown” message to all of the process loops and stops the application, but the behavior could easily be modified to log the error and keep running)
• PC-based remote control and monitoring user interface:
  • Event-based producer/consumer queued state machine
  • Network-published shared variables (NPSVs) bound to front-panel indicators to monitor state of the RT controller application
  • Network stream for sending command messages to RT
• Illustrates best practices for reliability, scalability, and maintainability for student projects
  • Standardized process loop design with task-specific behavior located in a kernel subVI and data highway clusters
  • Named queues to minimize wiring clutter between process loops

Keep in mind

• Developing a deep understanding of the project will take time and effort, but you will learn how to use standard industry-accepted design patterns that promote reliable operation and simplicity of maintenance

Example code

• Connect your Academic RIO Device to your PC using USBLAN, Ethernet, or Wi-Fi. NOTE: Not all Academic RIO Devices have Ethernet and Wi-Fi connectivity options.
• Download and unpack the rt-pc_home-security-system.zip (for use with NI myRIO 1900) or the NIELVISIII-rt-pc_home-security-system.zip (for use with NI ELVIS III) archive, and then double-click the ".lvproj" file to open the project. NOTE: This project was written for a NI myRIO 1900 or NI ELVIS III connected by USBLAN at IP address 172.22.11.2. If you are using a different IP address or another Academic RIO Device (Example: NI myRIO 1950 or NI RIO Control Module) do the following:
  • If using the NI myRIO 1950 or NI RIO Control Module start with the NI myRIO 1900 Archive.
  • Different IP address: Right-click on the "NI myRIO 1900" Device, choose "Properties", and then enter the new IP address
  • Different device:
    • Right-click on the top of the project hierarchy, select "New Targets and Devices", keep the "Existing target or device" option, and then find and select your particular device
    • Select all of the components under the "NI myRIO 1900" device: click the first one and then shift+click the last one
    • Drag the selected components to the new device
    • Right-click the "NI myRIO 1900" device and select "Remove from project"
• Open and run “RT Main”
  • The left panel emulates physical I/O devices: keypad, LCD display, LED indicator, and door and motion sensors
  • The right side visualizes the internal state of each process loop
• Enter the keypad sequence 1-2-3 to arm and disarm the security system
• See if you can observe the following behaviors that are part of the design requirements for the system:
  • The keypad sequence must be entered within a short time window to be accepted
  • Each keypress causes a “keyclick” on the buzzer (presently indicated visually)
  • Opening the door causes a door chime on the buzzer
  • Both the door and motion sensor must be inactive to arm the system
  • The LED blinks during the pre-arm step
  • When armed, tripping the door sensor causes a countdown period to begin; enter 1-2-3 to disarm the system before the timer expires at which time the alarm activates
  • When armed, tripping the motion sensor immediately activates the alarm; enter 1-2-3 to disarm the system
• Open “PC Main” and enter the correct IP address for your device (172.22.11.2 if connected as the only device by USB cable), otherwise use NI MAX to determine the network address of your device
• Run “PC Main”
  • Observe the indicators at the top of the “Remote Monitor” panel: the green flags designate these indicators as bound to network-published shared variables (NPSVs) hosted on the RT target. When properly connected these indicators will track the indicators on the RT system controller.
  • Click “Connect” to establish the network stream connection to the system controller
  • Click each of the now-active buttons to send a message to the controller:
    • “Reset” initializes the controller regardless of its current state
    • “Valid Code” emulates a proper keypad sequence entry
    • “PANIC” sends the controller directly to the “alarm” state
  • “Disconnect” closes the network stream connection
• “RT Main” should continue to run regardless of the run state of “PC Main”: observe the “PC host connected” indicator on “RT Main” as you stop “PC Main” while connected to the RT target and then restart and reconnect
• “PC Main” depends on a good network connection to the RT target: observe the behavior of “PC Main” when you stop or disconnect the controller’s network connection while “PC Main” is connected
• Click “Manual Stop” to stop the controller – this inserts an error into the error cluster which is trapped by the error handler to cause a shutdown of the entire system

Expected results

Developer walk-through

Outline

• Review overall structure:
  • Message handling loops
    • Entire system is implemented using the Queued Message Handler with Multiple Process Loops design pattern
    • Each loop is an independent process running in parallel
    • Process loops implement behavior with queued state machines (QSMs); see the Queued State Machine page for complete details
    • Process loops transfer messages between each other through named queues
    • Queues are referenced by name much more often than by wire, therefore most of the connections between the process loops are not visually evident
  • System Manager
    • Maintains high-level operating mode of the overall system
    • Issues command messages to the task loops
    • Receives alert messages from the task loops
    • Task loops can directly message each other to reduce complexity of System Manager
  • Code Validator
    • Accepts keypad input
    • Validates the input sequence against the stored arm/disarm code
    • Ensures that complete three-digit sequence is entered within a limited period of time
    • Issues alert to System Manager when a valid code has been entered on the keypad
  • Timer
    • Countdown timer for pre-arm and pre-alarm modes
    • Issues an alert when the timer expires
  • Sensors
    • Polls the door and motion sensors when enabled
    • Issues an alert when the sensor changes to an active state
  • LED
    • Status indicator for user interface
    • Indicates whether the system is “on” (armed) or “off” (disarmed)
    • Blinks to indicate pre-arm step
  • Buzzer
    • Controls the piezo-electric buzzer on the user interface
    • Provides various feedback sounds such as keypress clicks, acknowledgements, and errors
    • Presently implemented by a visual indicator on front panel
  • Command Parser
    • Accepts connection requests from remote PC host human-machine interface (HMI), also called the user interface (UI)
    • Receives commands from PC host, parses them, and inserts messages into the System Manager queue
    • Uses network stream communication with PC host
    • PC host HMI
      • Producer loop translates button clicks into messages to send as well as “Connect” and “Disconnect” states
      • Consumer loop handles PC host side of network stream
  • Error Handler
    • All process loops forward their error messages to the error handler queue
    • On receiving an error message the error handler issues a “shutdown” message to all process loops, displays the error message, and stops the VI (useful for development and debugging)
    • A deployed production system would log the error message to a file and attempt to keep the VI running; normally the RT application should continue to run while gracefully handling error conditions
  • Manual stop button (used only for development/debugging purposes)
    • Polls the “Manual Stop” button and enqueues the “Manual stop” error message into the error handler queue
• Documentation
  • Table of QSM states and actions (Word document)
  • Visualize behavior of the QSMs interacting with each other (PowerPoint)
• Simulation of system behavior (PowerPoint slides)
  • System startup
  • System is ready, monitors sensors and waits for valid code entry on keypad
    • Self-enqueued states
    • Regenerative states
    • Messaging between QSMs
    • Sensing external input devices (door sensor and motion sensor)
  • Door opens while system is in “READY” mode
  • Homeowner arms the system by entering three-digit code
    • Direct messaging between tasks to reduce System Manager complexity
  • System moves to “PRE-ARM” state, starts count-down timer
  • System is armed
  • Motion detected, sound the alarm

For more information

1. Effective LabVIEW Programming (http://www.ntspress.com/publications/effective-labview-programming/)
   An excellent textbook by Dr. Thomas J. Bress covering all aspects of system design; Chapter 27 describes the "Event-driven Producer-Consumer State Machine" in detail. Download all of the code examples from this textbook: follow the link above, select "User Resources", and then "All VIs".
   
2. The LabVIEW Style Book (https://www.pearson.com/us/higher-education/program/Blume-Lab-VIEW-Style-Book-The/PGM219404.html)
   A comprehensive textbook by Peter A. Blume that lays out everything you need to know about best practices for LabVIEW system design.