Redundant System Reference Design for LabVIEW Real Time, LabVIEW FPGA, and CompactRIO

Publish Date: Aug 09, 2013 | 12 Ratings | 2.83 out of 5 |  PDF

Introduction

Redundancy is a common approach to improve the reliability and availability of a system.  Adding redundancy increases the cost and complexity of a system design and with the high reliability of modern electrical and mechanical components, many applications do not need redundancy in order to be successful. However, if the cost of failure is high enough, redundancy may be an attractive option.

This reference design described in this paper provides a framework for building a redundant system using National Instruments Hardware and Software.  To download the source code for this reference design, refer to the files at the end of this Developer Zone article.

National Instruments controllers provide the flexibility to create a variety of redundant designs. For a basic background into the types of redundancy that can be built into a system and examples of how to calculate how redundancy will affect system reliability, refer to the “Redundant Basic System Concepts” Developer Zone article.  To access it, visit ni.com/info and enter RedundantBasics.

Here is the reference example code, cRIO-RRD.zip.

Part 1. User Documentation - The Reference Design

This redundancy reference design demonstrates a variant of Hot Standby.  Please note that you can apply this reference design to any control and/or monitoring application. This configuration does not have a third party voter to decide which unit gets control as you would with a true Dual Modular Redundancy (DMR).  The secondary unit will make this decision, thus it plays the role of backup and voter.  There is a host computer that can interface with the system but it is optional once you have your software loaded onto the unit. The term Device Under Control (DUC) refers to the machine, the process, and so on, that is being controlled by the redundant system

This design includes features such as System Diagnostics, Real-Time System Monitoring, and Auto-Repair.  These features are valuable, but are not required when building a redundant system.

Switchover Conditions

The switchover conditions for this reference design shown in the following logic diagram.

 The secondary unit takes control when any one of these conditions are met:

  • If the secondary detects the Device Under Control (DUC) going beyond the set control limits. 

Note: This is the most basic attribute to monitor, because the purpose of your control system is to control whatever you need it to control.  Other attributes are monitored to protect you from soft failures that could creep up slowly and cause the system to behave in an unexpected way leaving your object under control in an undesirable state.  The other reason is to help diagnose common failure modes quickly and perhaps take some evasive action to protect your system.

  • If the primary’s power supply fails and the battery backup also fails.

Note: The system does NOT switch over if it detects a power supply failure and the power grid is still up.  The battery is recharged by the power grid and the battery will power the redundant system.  A warning will be sent to the host that a power supply has failed and needs to be replaced.

The system does NOT switch over if it detects a power grid outage, because the battery acts as a power grid backup and will power the redundant system as long as it is able or until the power grid outage is over.  During this time, if the battery voltage drops below an acceptable level, the system automatically shuts down.

The system switches over only if the power grid is up, the primary’s power supply has failed, and the battery has failed.  Otherwise, the primary unit will remain in control.

  • If the FPGA code is unable to communicate with the other unit.
  • If the Real-Time (RT) code is unable to communicate with the other unit.
  • If the FPGA code and the RT code on the primary unit are unable to communicate with each other.
  • If the health of the primary system starts to degrade.

Note: The concept of system health relates to attributes of a unit that can be monitored.  For example, this design monitors memory usage, CPU usage, and chassis temperature. Others attributes that could be monitored include the number of memory blocks, average size of memory blocks, CPU temperature, fan speed (if you have a fan), and so on. These vital signs help you detect a potential failure early and allow you to repair the unit before the behavior of the unit becomes unstable or a hard failure occurs.

This design also monitors the health of the secondary unit to make sure it is healthy and ready to take control if called upon.  If its health starts to degrade, it will run diagnostics and then auto-repair if needed.  During this time, the primary system will not be able to move out of the active state.  This will usually temporarily fix a software issue.

  • If the primary unit is undergoing a scheduled Diagnostics or Auto-Repair.

Note: This design has the ability to carry out scheduled maintenance on the primary and the secondary units.  Scheduling diagnostics is important to ensure the integrity of the units, because the diagnostics can detect potential problems before they become failures.  Scheduling Auto-Repair provides a way to correct software-aging issues that can take a long time to show up.  For example, if your software has a very slow memory leak that takes about three to four months to cause a failure and if you know about this issue (or even if you do not), you can work around it with a monthly Auto-Repair (a power cycle in this example) until you have the time to implement a more complete solution.  Thus, you can extend the run time and availability of your system without a software update.

For more details please refer to the example code included with this article.

How to apply your application to this reference design

You do not need to understand all the details of how this design works in order to use it.  You can use it as is with just a few configuration steps.  If you would like to use the code and add or alter its features, this paper documents many details of the design to help you.

Software & Hardware Configuration

You configure the unit to be the primary by setting the User1 DIP switch on the cRIO‑9014 controller to On.  The software on both units is exactly the same, with minor personality differences in execution, based on the switch setting.

Adding your Application to Redundancy Reference Design

The goal of the cRIO Redundancy Reference Design is to provide a framework for converting your non-redundant cRIO application into a redundant system without having to delve into the intricacies of the redundancy code.

  1. Design and test your application:
    • Get your application working by itself.
    • Test your application before integrating with the Redundancy Reference Design to make it simpler to debug issues.
  2. Determine what will be different now that your application will be running on two units:
    • What inputs will need to be read by both units?
    • What signals will need to be switched when control passes between the units?
    • Will any I/O signals need to be synchronized before switch over?
    • What data will need to be passed between the units?
  3. Design and develop code needed to synchronization your application across two units.
  4. Insert your application code into redundant reference design. In the cRIO Redundancy Reference Design code, there are blue sections that indicate where your application/modifications need to go. Some of the changes are optional.
    1. FPGA
      1. Add the FPGA section of your application to cRIO-RRD - FPGA Main.vi.
      2. In your application, set the following two variables: FPGA_UserAppReady and SysUnderCtrl Fail.
        • FPGA_UserAppReady is a Boolean variable indicates when your application has completed any initialization routines and is ready to do its job. The State Controller will not exit the WaitForUserAppReady until this Boolean variable is True.
        • SysUnderCtrl Fail is a Boolean variable is set to True when there is a failure in your application and will trigger the secondary unit to take control from the primary.
      3. State Controller
        • WaitForUserAppReady - The Redundancy Reference Design state machine will wait in this state for your code to indicate it has initialized and is ready to function. Add any code necessary here to synchronize I/O or software for your application. The exit condition for this state is when RT_UserAppReady and FPGA_UserAppReady are both True.
        • Optionally, your application can perform functions in the Auto Repair, Off-Line, and Shutdown Prep states. Descriptions of what these states do are provided in the code and later in this document.
      4. Relay Control - The cRIO Redundancy Reference Design is configured with a single switchover relay (Relay - Take Control). You may need to expand this if your application needs to switch more than one signal.
      5. Diagnostic - To minimize FPGA size, the cRIO Redundancy Reference Design includes a simple AIAO diagnostics routine to ensure the control module is working. As FPGA space allows, you can add more to check DMA transfers, IRQs, memory, and so on.
      6. Power Monitor - You will need to set A/C Limit and Battery Limit based on your system.
    2. Real-Time
      1. Add application code to cRIO-RRD - RT Main.vi
      2. State Reader
        • WaitForUserAppReady - Add the RT side of the code needed for I/O and/or code synchronization. Set RT_UserAppReady to True when sync is completed.
        • Active, Active-Repaired, and Standby are all in a single state as your application does the same operation in all these states. Add any RT-FPGA I/O code that is needed while your application is running. One option is to retrieve FPGA data needed when the other unit is in WaitForAppReady
        • Optionally, your application can perform functions in the Auto Repair, Off-Line, and Shutdown Prep states. Descriptions of what these states do are provided in the code and later in this document.
      3. Get Parameters - This state sets parameters that are needed at run time. These values should not change often or at all while the application is running.
        • Add any parameters you need to the control cRIO-RRD - Ctl Paramters.ctl.
        • The parameters are stored in an XML file on each unit. They are updated from a command on the Host VI, which is discussed later.
      4. Health Monitor - Set the limit values for Chassis Temp (degC), CPU Usage (%) and Memory usage (%). Exceeding any of these limits will trigger a health failure.
      5. RT - RT Communication - Add any variables that need to be shared between the RT controller during operation. DataSockets were used to read shared variables because they automatically handle connections to the other unit when communication is lost (for example during a scheduled reboot).
        1. Add the variable to cRIO-RRD - RT Unit Communication.lvlib.
        2. Update cRIO-RRD - RT ComClient.vi and cRIO-RRD - RT ComServer.vi with the new variables.
      6. Diagnostics - If you added any diagnostic routines, or expanded the AIAO test for multiple control outputs, you will need to update Diagnostics.vi.
      7. RT LED (optional) - You can change the state of the RT LED to indicate what state your software is in. In the cRIO Redundancy Reference Design, the LED will flash every 500 mS when the cRIO Redundancy Reference Design is running.
    3. Host
      • Update Parameters - If you added any parameters, you will need to update cRIO-RRD - Host Enter New Parameters.vi to allow users to enter them.

The Components Needed for Redundancy

Basic Software Building blocks

The software components for this reference design are shown below in the diagram and listed below.  This diagram shows where theses basic components are located within the systems. 

o   State machine

o   Voter (takes information from the monitors and makes the decision to switchover)

o   Monitoring routines

o   Real-Time network communication routines

o   FPGA communication routines (Optional)

o   Diagnostic routines (Optional)

Basic Hardware Building Blocks

The hardware components and basic wiring for this reference design shown below in the diagram and explained the following text.

o   2 Controllers (one for the primary unit and one for the secondary unit)

o   2 Chassis (one for the primary unit and one for the secondary unit)

o   2 sets of I/O modules for your control and monitoring application (one for the primary unit and one for the secondary unit)

o   Relays to switch signals from one unit to the other

o   1 NI 9474 Digital Output module to control the relays

o   Ethernet or serial communication for the RT controllers to communicate with one another.

Optional hardware for extra features

All of these features have been implemented in the example code for this reference design.  If you do not want these features, you will need to disable or remove the appropriate code from the example.

o   2 NI 9401 Digital I/O modules for FPGA to FPGA communication.

Note: The information could be passed through the Ethernet or serial ports, but it would not be as fast or deterministic.  In this design, the digital lines on the NI 9401 Digital I/O CompactRIO modules allow the FPGA to  directly access the digital lines and communicate independent of the RT system.

o   2 NI 9219 Analog Input modules so each unit can monitor the power supply of the other. (Optional)

o   4 Relays to programmatically cycle power on the units.

o   1 NI 9474 Digital Output module to control relays that cycle power.

Note: For this feature you only have to add a digital output module to the primary unit because the secondary already has a digital output module to control relay(s) that switch signals from one unit to the other.

o   1 - Battery with a charger to provide temporary, non-interruptible power backup in case of a power outage.

o   Redundant sensors, actuators, and cabling.

Part 2. Reference Documentation - Reference Design Details and Diagrams 

Hardware Wiring Diagram

 

Hardware details

The NI 9014 CompactRIO controllers support two power inputs.  If one power input experiences an outage, it automatically switches over to the backup input.  This redundancy feature is used in this example.

A battery backs up the power grid and acts as an uninterruptible power supply as well. The designated battery can power the redundant system for more than 8 hours.

In this configuration of modules, only two were needed to control and monitor the DUC (an inverted pendulum) used for the demonstration.  The NI 9263 analog output modules control the inverted pendulum and the NI 9411 digital input modules monitor its position. Obviously, your application may need a different set of modules.

You should use separate cables and sensors from the DUC to the input modules if practical, because you cannot always predict the failure mode of your input module, input cables, or sensors.   For example, if you use the same cable for both NI 9411 modules, and one of the modules fails in a low impedance state, the other good module will measure incorrect readings, thus leaving the good unit unable to control the DUC.

The remaining modules implement the redundancy features. Depending on the features implemented, all modules may not be needed.

The NI 9219 analog input modules monitor system voltage and test the NI 9263 analog out module during diagnostics.

The NI 9401 digital input/output modules communicate state information between the units and to synchronize the control code.

The NI 9474 digital output modules control the relays that switch control from one unit to the other and cycle power to reset the other unit. 

The NI 9401 and the NI 9474 could be replaced by a NI 9403 module if you can use relays or switches that can be controlled by a TTL digital signal.  The NI 9403 has enough digital lines to handle the communication between the units and control the number of relays needed.  The only potential drawn back is that transfer speed between the units may be slower. The NI 9403 has a different architecture than the NI 9401 to support the extra digital lines, which adds additional overhead when reading and writing data.

When choosing the right relay or switch for your application you need to consider the following criteria:

  • Voltage level and power loads the system will switch
  • Signal you will need to control the system
  • How you will power the system
  • Switchover times needed
  • Environment
  • Normal state
  • Powered off state

This design uses non-latching single pole double throw (SPDT) mechanical relay for their predicable state in case power fails to the relay and for the voltages needed to switch.  Because the relay must switch if the secondary unit is able to take control, the switchover relay is powered with the same power source as the secondary unit.

System Communication Architecture

The following figure shows the basic communication paths and the information that is being passed between the units and within them.

The light blue arrows show the information that is passed between a host computer and the two control units.  The types of information are:

  • Command & Data: The host can send commands to the unit to process.  In this example, the host can send two commands, as follows:
    1. Shutdown, which is used to shut down the units and DUC
    2. Manual Switch , which forces the secondary until to take control of the DUC and moves the primary to diagnostics.  The primary cannot regain control until this switch is set back to Normal mode
  • Controller State: Each until sends its current SW state to the host (refer to Unit State Diagram for details) and the host uses both of these states to determine/display the entire System State.
  • Heath Data: Each unit periodically updates the host with its current health data.  The exact data here will vary based on application.  In this example, the design  monitors CPU and RAM usage and controller temperature.
  • Diag Data:  A summary report from the last diagnostics run will be sent to the host

The purple arrows show the information that is passed between the Real-Time software systems on each control unit. The types of information are:

  • Health Data:  The primary unit will send pass/fail health data to the secondary.  The secondary controls when to take control from the primary, including times when it receives failures in the Health monitoring and from the RT-FPGA ping on the primary system.
  • Sync Offset:  This data is application specific.  In this example, the offset values are sent to ensure the encoders on both units are outputting the same value.
  • Com Ping:  This is a simple handshake to make sure each unit can see the other one.  This data will be combined with the Health and Sync offset transfers.

The green arrows show the information that is passed between the FPGAs on each control unit. The types of information are:

  • State control: This information is used by each unit to know what the state the other unit is in.  This is critical to assure that the two state machines know what state the other is in and what state it should be in.  This information is passed from one unit to the other using 2 digital lines (each way, 4 total) of the cRIO-9401 modules.  This design uses a simple serial protocol with a sync/clock and a data line to send the 8-bit state values. (The state reader and writer code could easily be modified to transmit larger data types.)
  • Sync Triggers:  The triggers are used in I/O Sync to sync encoder values.  The unit that needs to sync up sends the trigger to the other unit.  When each unit receives this trigger, the encoder values are latched into a register, and then the two values are used to generate an offset for the unit sending the trigger.
  • FPGA Ping: This is a simple watchdog ping to make sure that the other FPGA is still alive and responding.  If the ping stops for any reason, then the secondary unit will take control.

The yellow arrows show the information that is passed between the Real-Time system and the FPGA on a unit. The types of information are:

  • Ctrl State:  RT reads the current state value from the State Controller running on the FPGA. 
  • Health Failure:  All the health monitoring code runs in RT, so need to send the current status to the switch over code running on the FPGA
  • Sync Offset:  The sync offset values are passed between units on the RT side, and then need to be sent to the FPGA to be applied to the measured values
  • FPGA-RT Ping:  Simple watchdog ping to make sure RT & FPGA on each unit can still see the other side of the unit.

Software Block Diagram

The following figure shows the unit software architecture. 

 

The software is componentized to promote reuse and to provide feature flexibility to the system developer.  You could also implement this code in a Real-Time only system (a system that does not have an FPGA) with minimal effort.

The green blocks are components dedicated for implementing redundancy and are designed to be a foundation that is easy to reuse and or modify for your specific needs.  The State Controller block seen in the middle of the FPGA piece is the heart and soul of this redundant system.  The State Controller block was implemented in the FPGA because of its speed and reliability, as well as the fact that FPGAs naturally lend themselves to state machine designs.  The State Machine could have been easily implemented in the RT piece as well.

The pink blocks are general-purpose components that could be beneficial in any application.  The Health Monitoring (system monitoring) component monitors the vital signs of the unit.  Some of the monitored vital signs include CPU usage, memory usage, and chassis temperature. This component can be easily modified to add additional vital signs like CPU temperature, memory fragmentation, data traffic, hard drive accesses, interrupt exceptions, and so on.  The only caveat is that this code can often be hardware and operating system dependent.  The Diagnostics components can also be reused and easily modified for your system.  A few functions are hardware and operating system dependent, but the design offers a good foundation to build on.

The blue blocks are components that are unique to the application that you are developing, thus this is your control and monitoring code.

For more details about each of these components refer to the actual LabVIEW code.

System Software State Diagram

The following figure shows the System State Diagram for the redundant system (the primary (1) and the secondary (2) units).

The Init step initializes the system by:

  1. Powering on both units
  2. Running diagnostics on both units
  3. Synchronizing the I/O on both units
  4. Synchronizing the states between both units

The Shutdown step properly shuts down the DUC as well as the entire control system.

The Operate step of the system is made up of the states shown above.  Each system state shows the state of each unit.  Notice that the green state shows 1-Active and 2-Standby, this means that the primary (1) unit is actively controlling the DUC and the secondary (2) unit is waiting in standby mode ready to take over if a failure condition is detected.

System State Definitions:

Active:  Unit is actively controlling the DUC.

Standby:  Unit is ready to take control if needed.

Diagnostics:  Unit is conducting a self-diagnostics test.

Auto-Repair:  Programmatically repair the software and reset the hardware state of the unit.  In this example the unit is power cycled by the other unit.

Power-Down:  Unit is powered down and will remain in this state until it is manually brought back up after it is repaired.

The 1-Active/2-Standby state as show above is the normal state in which the system controls the DUC and is in a redundant state.  All the other states (the yellow and red states) have one of the units off-line and thus the system is operating in a non-redundant state.

The top half of the diagram depicts the scenario when the primary unit fails or runs scheduled diagnostics or auto-repair.  The secondary unit is actively controlling the DUC. 

The bottom half of the diagram depicts the scenario when the secondary unit has a health issue or runs scheduled diagnostics or auto-repair.  The primary unit is actively controlling the DUC. 

System State Transitions

Init to (1-Active/2-Standby)

  • After the system passes the Init step

(1-Active/2-Standby) to (1-Diagnostics/2-Active)

  • When one of the switchover conditions are met

(1-Active/2-Standby) to (1-Auto-Repair/2-Active)

  • When auto-repair is scheduled on the primary unit

(1-Active/2-Standby) to Shutdown

  • When a shutdown command is sent

(1-Active/2-Standby) to (1-Active/2- Diagnostics)

  • When diagnostics is scheduled on the secondary unit or there is a health issue on the secondary unit

(1-Active/2-Standby) to (1-Active/2-Auto-Repair)

  • When auto-repair is scheduled on the secondary unit

(1-Diagnostics/2-Active) to (1-Active/2-Standby)

  • When diagnostics passes on the primary unit

(1-Diagnostics/2-Active) to (1-Auto-Repair/2-Active)

  • When diagnostics fails on the primary unit and if the system did not just come from the (1-Auto-Repair/2-Active) state

(1-Diagnostics/2-Active) to (1-Power-Down/2-Active)

  • When diagnostics fails on the primary unit after the system just successfully passed through the (1-Auto-Repair/2-Active) state

(1-Auto-Repair/2-Active) to (1-Diagnostics/2-Active)

  • When the auto-repair is successful on the primary unit

(1-Auto-Repair/2-Active) to (1-Power-Down/2-Active)

  • When the auto-repair is not successful on the primary unit

(1-Power-Down/2-Active) to (1-Diagnostics/2-Active)

  • When an operator manually repairs the primary unit and powers it on

(1-Power-Down/2-Active) to Shutdown

  • When a shutdown command is sent to the system

(1-Active/2- Diagnostics) to (1-Active/2-Standby)

  • When diagnostics passes on the secondary unit

(1-Active/2- Diagnostics) to (1-Active/2-Auto-Repair)

  • When diagnostics fails on the secondary unit if the system did not just come from the (1-Active/2-Auto-Repair) state

(1-Active/2- Diagnostics) to (1-Active/2-Power-Down)

  • When diagnostics fails on the secondary unit after the system just successfully passed through the (1-Active /2-Auto-Repair) state

(1-Active/2-Auto-Repair) to (1-Active/2- Diagnostics)

  • When the auto-repair is successful on the secondary unit

(1-Active/2-Auto-Repair) to (1-Active/2-Power-Down)

  • When the auto-repair is not successful on the secondary unit

(1-Active/2-Power-Down) to (1-Active/2-Diagnostics)

  • When an operator manually repairs the secondary unit and powers it on

(1-Active/2- Power-Down) to Shutdown

  • When a shutdown command is sent to the system

Unit Software State Diagram

Each unit has its own state machine that has to work closely with other unit’s state machine in order to keep the system synchronized and working properly.  The following diagram is the state diagram for the unit’s state machine.

 

Unit State Definitions:

Off:  The unit is powered off

Init:  The unit is launching the Real-Time and the FPGA part of the application. All communications between it and the host, between the Real-Time application and the FPGA application, and between the units are established.

Diagnostics:  All diagnostic tests are run on the unit to ensure that it is fully functional.

Wait For User App Ready:  This state is completely application dependent.  In this example, the system is  reading the encoders of the DUC.  This reading is compared with the other units’ reading.  Offsets are then applied to ensure that both units’ readings are synchronized.

Sync Units:  Make sure the other unit is also ready to move on to Active or Standby.  The goal is to make sure both units are good before one of them starts to control the DUC. 

Off-Line:  If the unit fails diagnostics or times out during the Init, Diagnostics, Wait For User App Ready, or Sync Units states the unit will prepare to be powered off.

Auto Repair:  This state is focused on programmatically repairing the software on the unit and resetting the hardware state.  In this example, moving into this state tells the other unit to power-cycle this unit.

Active:  The unit is actively controlling the DUC.

Active Repaired:  The unit is actively controlling the DUC and the other unit has passed through the Auto-Repair state.  This different state allows the other unit to decided where to do if it fails diagnostics.  If the other until is in this state, the unit will know to move into Offline on a diagnostics failure.  If the design did not keep track of this, the system could get into an infinite loop of auto-repairing a broken unit that cannot be fixed with auto-repair.

Standby: The unit is ready to take control if needed.

Shutdown Prep: This state is application dependent.  The unit prepares itself as well as the DUC to be safely shutdown.

Unit State Transitions

(Off) to (Init)

  • The unit is powered on.

(Init) to (Diagnostics)

  • Software has successfully started; all communications between it and the other unit, and between the Real-Time and FPGA applications have been established.

(Init) to (Off-Line)

  • The initialization of the unit failed or it timeout before it could complete its tasks.

(Diagnostics) to (Wait For User App Ready)

  • The unit passed all the diagnostic tests.

(Diagnostics) to (Auto Repair)

  • The unit will move to the Auto Repair state if it passed diagnostics the previous time it was in that state.  Thus, the unit will not keep trying to Auto Repair itself if diagnostics fails twice in a row.

(Diagnostics) to (Off-Line)

  • The unit will move to the Off-Line state if diagnostics fails after it just passed thru the Auto Repair state or if diagnostics fails after it was just powered on and initialized for the first time or if it timed out before diagnostics was completed.

(Wait For User App Ready) to (Sync Units)

  • If the unit can synchronize its I/O with other unit before it times out.

(Wait For User App Ready) to (Off-Line)

  • If the unit cannot synchronize its I/O with other unit before it times out.

(Sync Units) to (Active)

  • The primary unit will move to active if the secondary unit is ready-to-proceed before the timeout.  A unit is “ready-to-proceed” if it is in the Sync Units, Active or Standby state.

(Sync Units) to (Standby)

  • The secondary unit will move to standby if the primary unit is ready-to-proceed before the timeout.  A unit is “ready-to-proceed” if it is in the Sync Units, Active or Standby state.

(Sync Units) to (Off-Line)

  • If the other unit is not ready-to-proceed before the timeout.

(Active) to (Standby)

  • The secondary unit will move back to the Standby state only when the primary unit has passed the Diagnostics state, successfully completed the Wait For User App Ready and the Sync Units states, and is ready to move back into the Active state. 

Note: Notice, that in this configuration, the primary cannot move into the Standby state, only the secondary unit can do this.  You may want to change the state machine to allow either unit it go into the Standby state, but this was not implemented because it simplified the state machine by declaring the secondary unit the official backup.

(Active) to (Active Repaired)

  • The unit moves to the Active Repaired state when it is actively controlling the DUC and the other unit has moved to the Auto Repair state.

(Active) to (Auto Repair)

  • The primary unit moves to the Auto Repair state when it is scheduled to do so.  This transition is limited to the primary unit because there is not a redundant unit if the secondary is in active.

(Active) to (Shutdown Prep)

  • The unit moves to the Shutdown Prep state when it receives a command from the host or if it running on the battery backup and it sees the batteries voltage dropping to an unacceptable level.

(Active) to (Diagnostics)

  • The primary unit will move the Diagnostics state when the secondary unit takes control.

(Active Repaired) to (Active)

  • The unit actively controlling the DUC will move from the Active Repaired state to the Active state when the other unit moves into the Sync Units or Offline state.  At that point, the other unit no longer needs to know that it went through the Auto Repair state, so it can move back into Active.

(Standby) to (Active)

  • The secondary unit will move to the Active state when any of the switchover conditions are met or if the Manual Switchover option is set from the host.

(Standby) to (Auto Repair)

  • The secondary unit moves to the Auto-Repair state when it is scheduled to do so.

(Standby) to (Shutdown Prep)

  • The secondary unit moves to the Shutdown Prep state when it receives a command for the host or if it running on the battery backup and it sees the batteries voltage dropping to an unacceptable level.

(Standby) to (Diagnostics)

  • The secondary unit will move to the Diagnostics state if it is scheduled to do so or if a system health issue is detected.

(Auto Repair) to (Off)

  • The unit will move to the Off state when it is powered off by the other unit.

(Shutdown Prep) to (Off)

  • The unit will move to the Off state when it is manually powered off.

(Off-Line) to (Off)

  • The unit will move to the Off state when it is manually powered off.

Summary

This reference design can be used as a foundation to build a redundant control and monitoring system using National Instruments products.  You can use it as-is, add features, or remove features to better meet your unique requirements.

This example is built in LabVIEW 8.2.1, LabVIEW Real-Time 8.2.1, LabVIEW FPGA 8.2.1 and NI-RIO 2.3.1.  This code can be recompiled to a newer version of LabVIEW or NI-RIO.

For more information about using National Instruments product in applications that require high reliability and or high availability, please contact your local sales engineer.  If you do not know your local sales engineer, contact National Instruments for help.

 

Back to Top

Bookmark & Share


Downloads

Attachments:

crio-rrd.zip


Ratings

Rate this document

Answered Your Question?
Yes No

Submit