S14: Power efficient security door system for light-rail using CAN bus

From Embedded Systems Learning Academy
Revision as of 00:20, 23 May 2014 by Proj user2 (talk | contribs) (Conclusion)

Jump to: navigation, search

Grading Criteria

  • How well is Software & Hardware Design described?
  • How well can this report be used to reproduce this project?
  • Code Quality
  • Overall Report Quality:
    • Software Block Diagrams
    • Hardware Block Diagrams
      Schematic Quality
    • Quality of technical challenges and solutions adopted.

Power efficient security door system for light-rail using CAN bus

Abstract

This project is about controlling the operations of doors and sensors in a light rail train, such that they are operated only when required, thus reducing power consumption. Currently, when a light rail halts at a station the driver opens all the doors of all the coaches. However, except for peak hours and especially during weekends and holidays, the number of people entering and exiting a train at a particular station is comparatively very low. Sometimes, only 2-3 people enter or exit a train and that too they use only 1 or 2 doors of the train. In such cases, operating all the doors is simply a waste of power. Our project provides a solution to this problem by allowing the driver to operate only selected doors as per the requirement. It senses from which coach the stop request was pressed or in front of which door the passengers are standing on a station to enter the train. Accordingly to these inputs it selectively operates only those particular doors. The rest are not operated and thus we not only save power but the reduced wear and tear of moving parts of doors enhances their lifetime. This project is based on the concept of CAN bus which is used for communication between sensors, switches and lights of different coaches of the train.

Objectives and Scope

The primary objective is to understand and implement CAN bus communication between two or more SJOne boards, such that any node can send message to any node and upon receiving a CAN message take a desired action immediately. Our secondary objective is to use CAN protocol in real time application such as to control doors, sensors and switches of different coaches of a light-rail train. This application aims at operating the doors of a train selectively as per the requirement, rather than operating all the doors. This will reduce the power consumption and increase the lifetime of the doors.

The scope of the project is:

  • Successfully communicate between two or more nodes over CAN bus
  • Interface a DC motor, stepper motor, smoke sensor, switches and LEDs as peripherals to SJOne board
  • Develop and implement the logic to operate doors selectively as per requirement and be able to communicate between the above peripherals over three nodes

Introduction

The project insists to have LPC1758 (SJOne) controller board in each coach, which will control doors, emergency windows, indicator lights and sensors of that coach. All these SJOne boards will communicate with each other through CAN bus protocol. Whenever some event takes place like start the train, open the doors, etc. a CAN message will be sent over the bus from one board to another and it will cause the hardware to take appropriate actions. To save power consumption of the train, when a stop request switch is pressed by a passenger in one of the coach, only the doors of that coach will open at next station, while doors of other coaches will remain closed. If passengers in other coach need to exit one of them needs to press a stop request switch from that coach in order to open its doors. On the other hand, if there are passengers on the platform standing in front of the coach whose doors are closed, then they will have to press a manual switch placed near each door outside the coach, to enter the train. An alternative to this can be using a motion sensor to detect the passengers on the platform and open the door nearer to the passenger automatically. But the project first aims at implementing the CAN functionality successfully and then add other features.

Team Members & Responsibilities

  • Ashish
    • Concept and logic development, developing algorithm and hardware interface
  • Anitha
    • FreeRTOS software design, code development, verifying test cases
  • Hasan
    • Sensor, peripheral interface and testing of software code

Schedule

Show a simple table or figures that show your scheduled as planned before you started working on the project. Then in another table column, write down the actual schedule so that readers can see the planned vs. actual goals. The point of the schedule is for readers to assess how to pace themselves if they are doing a similar project.

Week# Date Task Actual
1 02/27/2014 Finalized scope of the project and ordered CAN transceiver TJA1040 Completed. Deciding which tranceiver is compatible to SJone board
2 03/06/2014 Prepare complete block diagram with all components needed and draw the state diagram Block diagram completed. State diagram finalization pending. Need to think more on different possibilities of event occurance when switching between states
3 03/13/2014 Complete state diagram and gather BOM of rest of the parts Completed state diagram on book, but pending to draw in paint and upload on wikipage. BOM parts received.
4 03/20/2014 Prepare the hardware prototype boards for all three coaches Task completed except for sensors, relays and motor interface (to be decided at the end after testing CAN functionality successfully)
5 03/27/2014 Read on CAN bus protocol and transceiver from datasheet Task completed
6 04/03/2014 Check the transceiver along with SJone board and build basic driver to run CAN bus Testing could not be completed successfully, understanding and testing of CAN code is in progress.
7 04/10/2014 Perform testing of CAN driver. Develop logic for the project and implement it on CAN bus. Self test loop for CAN driver failed. Debugging it is in progress. (Running behind the schedule by 1 week, Need to work hard to cope-up and complete the project on time.)
8 04/17/2014 Testing the CAN protocol and verifying the logic. Self test for CAN was successful, Tx and Rx between two CAN controllers was tested successfully.
9 04/24/2014 Interface sensors, motors and test with CAN bus protocol. Interface of fire sensor, stepper motor was tested successfully, however DC motor is pending. CAN test for hardware level address filtering is still failing and its diagnosis is in progress
10 05/01/2014 Testing and debug of the prototype boards and code. Completed DC motor interface. Successfully implemented CAN communication between all nodes using hardware level filtering
11 05/08/2014 Modifying the code and verifying for different test cases Few test cases are failing. Need to fix them.
12 05/15/2014 Final touch-up on the design, code and prepare wikipage Fixed the failing test cases and bugs in hardware board and the code. Wikipage is pending.
13 05/22/2014 Final demonstration

Parts List & Cost

Give a simple list of the cost of your project broken down by components. Do not write long stories here.

Design & Implementation

Hardware Design

The project uses three SJOne boards and three identical prototype boards connected to each other. The prototype boards are used to interface peripherals to SJOne board. A pair of SJOne board and prototype board is considered as one node and it resembles one coach of the train. Thus, we have a train that has three coaches and we control the operation of their doors, switches and sensors. Among these three coaches, one acts as a master or engine, which will be operated by the driver and the other two works as slaves or followers of the engine. The different peripherals connected to the SJOne boards are as under.

Sensors and peripherals of engine (master) coach

An engine consists of the following peripherals:

  • DPS1: It is a SPDT toggle switch to be operated by the driver, to “START” or “STOP” the train i.e. a DC motor
  • DPS2: It is a SPDT toggle switch to be operated by the driver, to “OPEN” or “CLOSE” the doors of the train i.e. to operate a stepper motor
  • DPS3: It is a SPDT toggle switch to be operated by the driver, to select whether to operate “ALL DOORS” or “SELECTED DOORS” of the train
  • PB1 or OD1: It is a push button switch to be operated by passengers in the train, to request a stop
  • PB2 or SR1: It is a push button switch to be operated by passengers on a station, to request opening of doors to enter the train, if the doors are closed.
  • SLED: It is a red color LED that glows in response to a stop requested by a passenger
  • YLED: It is a yellow color LED that glows if doors of that coach are opened
  • RLED: It is a red color LED that flashes indicating it is an emergency but not safe to exit at that time
  • GLED: It is a green color LED that flashes to indicate safe exit during emergency
  • WLED: It is a yellow color LED that glows to indicate the driver about a open door request pressed by a passenger on the station
  • Smoke sensor: To detect smoke and ring alarm indicating an emergency situation

Sensors and peripherals of follower (slave) coach

In order to save the cost of identical hardware components, a slave coach does not have all the peripherals as that of a master coach. A slave consists of the following peripherals:

  • PB1 or OD2/3: It is a push button switch to be operated by passengers in the train, to request a stop
  • PB2 or SR2/3: It is a push button switch to be operated by passengers on a station, to request opening of doors to enter the train, if the doors are closed.
  • SLED: It is a red color LED that glows in response to a stop requested by a passenger
  • YLED: It is a yellow color LED that glows if doors of that coach are opened
  • RLED: It is a red color LED that flashes indicating it is an emergency but not safe to exit at that time
  • GLED: It is a green color LED that flashes to indicate safe exit during emergency

The block diagram of the complete system resembling a train having three coaches is as shown in figure 1. The schematic diagram of prototype board for master is shown in figure 2 and the schematic diagram of prototype board for slave is shown in figure 3.

CmpeE244 S14 T2 block diagram.jpg

Figure 1. System block diagram

CmpeE244 S14 T2 master schematic.jpg

Figure 2. Schematic diagram of prototype board for master (engine)

CmpeE244 S14 T2 slave schematic.jpg

Figure 3. Schematic diagram of prototype board for slave (followers)

Hardware Interface

The table 1 defines the specific port pins used to interface peripherals to SJOne board for master (engine) node. The table 2 defines the specific port pins used to interface peripherals to SJOne board for slave (follower) node.

CmpeE244 S14 T2 master pin configuration.jpg

Table 1. Pin configuration for master (engine)

CmpeE244 S14 T2 slave pin configuration.jpg

Table 2. Pin configuration for slave (followers)

As mentioned earlier, we communicate between different coaches using CAN bus protocol. We are using CAN1 (P0.0 and P0.1) on SJOne board using 11-bit CAN IDs. This ID consists of three fields, viz. source address, destination address, and message ID as shown in table 3.

CmpeE244 S14 T2 can id format.jpg

Table 3. Format 11- bit CAN ID

The addresses of master and slaves are shown in table 4.

CmpeE244 S14 T2 device id.jpg

Table 4. Device IDs

The different CAN messages used in the project are shown in table 5. For simplicity in understanding, we have used different color for messages intended for different devices.

CmpeE244 S14 T2 can messages.jpg

Table 5. Different CAN messages used in the project

Software Design

The software needs to drive the hardware through different states. The software is build over five basic states as follows.

  • Default Halt- the train is at the final station and ready for next trip
  • Normal Running- the train is running normally without any emergency situation
  • Normal Halt- the train stops at the station as per trip schedule
  • Emergency Running- Emergency situation occurred while running
  • Emergency Halt- the train stops after the emergency situation

The state transition diagram is shown in figure 4.

CmpeE244 S14 T2 state diagram.jpg

Figure 4. State diagram

With reference to the figure 4 when the train have reached in the final destination station and ready for the next trip then it is in the default halt. At this state all doors are opened. The driver can close all of the doors anytime and get ready to start the next trip or close the doors for no operation. Any reset operation from halt state takes operation to this state.

The default halt state moves to normal running state when driver closes all doors and turn ON start switch. Start switch will not work if the doors are open. In normal running state, passengers can press stop request. The operation state comes to normal halt when drive stops the train at the station. Driver can opens all the doors, or open only the selected coach door as requested by the passengers. Yellow light will turn on when doors are open. With the door closed, driver can start the train and the operation gets into normal running state again.

In case of any emergency such as fire breaks out in running states in any of the coach and smoke detector detects the fire smoke then operation automatically moves to emergency running state. Red emergency light starts flashing; drive knows emergency situation has occurred. He will slow down the train and stop the train in next station and all of the doors will open automatically. Green light will be flashing to indicate passengers can safely exit the train. The train will be in emergency halt state. The driver has to reset the system to get back to normal halt and can operate the train again after the emergency situation resolved.

Implementation

Before going to the algorithm for master and slave let us have a clear idea of the inputs and interrupts to the microcontroller and outputs from the microcontroller

Manual inputs given to microcontroller, by driver of the train

  • Select a position for switch DPS1 to select whether to START or STOP the train
  • Select a position for switch DPS2 to select whether to OPEN or CLOSE the doors
  • Select a position for switch DPS3 to select whether to OPERATE ALL DOORS or OPERATE SELECTED DOORS for input from DPS2

Manual inputs given to microcontroller, by passengers inside the train

  • Press PB1 in any of the coaches for stop request at next station, while the train is in running state

Manual inputs given to microcontroller, by passengers on the station

  • Press PB2 of any of the coaches to request for opening of the door to enter the train

Events that will give interrupts to microcontroller

  • Smoke detection by smoke sensor
  • Stop request switch pressed by a passenger in any of the coach
  • Open door request switch pressed by any passenger on the station to enter the train
  • Open door switch pressed by driver of the train
  • Close door switch pressed by driver of the train
  • Start train switch pressed by driver of the train
  • Stop train switch pressed by driver of the train

Outputs from the microcontroller

  • Glow stop request SLED to indicate that a stop is requested
  • Glow open door YLED to indicate that the door is open
  • Flash emergency RLED to indicate smoke is detected
  • Flash safety exit GLED to indicate safety exit in emergency
  • Glow open door request WLED to alert driver about the open door request

Default outputs when a coach is in different states: Normal Running state:

  • All LEDs are OFF

Emergency Running state:

  • All stop request LEDs are ON
  • Emergency Red LEDs are ON
  • All open door LEDs are OFF
  • All safety exit LEDs are OFF

Normal Halt state:

  • All stop request LEDs are OFF
  • All emergency red LEDs and safety exit green LEDs are OFF
  • Open door LEDs may be ON/OFF depending on whether internal stop request interrupt flag was set or reset before arriving into this state

Emergency Halt state:

  • All open door LEDs are ON
  • All safety exit green LEDs are ON
  • All stop request LEDs are OFF
  • All emergency red LEDs are OFF

Default Halt state:

  • All LEDs are OFF except all open door LEDs

Algorithm for different states of master (engine)

Default Halt state:

  • Initialise default output for this state
  • Reset door closed flag and reset wait LED flag
  • Reset master’s open door and stop request flags
  • The table 6 shows enabling and disabling of different interrupts

Table 6. Enabling/disabling of interrupts for default halt state

1. If driver presses close doors switch

     {
     Close door of master and turn OFF open door LED of master
     Send message close door 0x725 and 0x745 to slaves 1 and 2 respectively
     Set a door closed flag
     Enable open door interrupt
     }

2. If driver presses open doors switch

   {
        If door closed flag is set 
        {
        //this is not the first time we are opening the doors in this state
              If wait LED flag is set and wait LED is blinking
              {
             Turn OFF wait LED and reset wait LED flag
              }
        }
        If internal open door flag of master was set
        {
        Open doors of the master 
        Turn ON open door LED of master
        }
        If door selection switch is at “Selected doors” position
        {
        Send conditionally open door message 0x726, 0x746 to slaves 1 and 2 
        respectively 
        }
        else if door selection switch is at “All doors” position
        {
        Send open all doors message 0x724, 0x744 to slaves 1 and 2 
        respectively
        }
   Enable close door interrupt
   }

3. If some passenger on the station presses open door switch

   {
          If door closed flag is set
          {
          (This is useful, if someone presses this switch after the doors are closed and before the train starts)
          Set internal flag for this open door interrupt of master
          Set wait LED flag and start blinking wait LED
          }
          else
          {
          Reset master’s open door interrupt flag
          do nothing
          // since the door is already opened
          }
   }

4. If master receives open door request 0x1EB / 0x2EB message from slave 1 / 2 respectively

     {
     Set wait LED flag and start blinking wait LED
     //this indicates open door s/w in slave coach is pressed by passenger on platform, after closing the doors and before the train is started 
     }

5. If some passenger from within the train presses stop request switch

   {
       If door closed flag is set
       {
       Set master’s stop request interrupt flag
       Transfer stop request to next transitioning state
       }
       else
       {
       Reset master’s stop request interrupt flag
       do nothing
       // since the door is already opened
       }
   }

6. If master receives stop request message 0x1E7 / 0x2E7 from slave 1 / 2 respectively

     {
     Transfer this stop request to next transitioning state
     }

7. If start train switch is pressed

  {
       If driver’s open/close switch is at close door position
       {
       Start the DC motor        
       Master sends train started message 0x729 and 0x749 to slaves 1 and 2 
       respectively.        
       Master switches to normal running state.
       }
       else
       {
       Do nothing
       }   
   }

8. If stop train switch is pressed by driver

     {
     Do nothing, as the train is already at halt
     }

9. If smoke is detected

  {
     If smoke detected flag is reset //smoke is detected for first time
     {
     Set smoke detected flag
        If doors are opened
        {
        Send safe exit message 0x723 and 0x743 to slaves 1 and 2 respectively    
        Master itself will switch to emergency halt state (This will open the doors of  master by default)
        }
        Else if doors are closed
        {
        Send emergency signal 0x722 and 0x742 to slaves 1 & 2 respectively
        Master will glow its stop request LED and start flashing emergency LED
        }
     }
     else
     {
     Do nothing
     // Ignore multiple smoke detection interrupts
     }
  }

Normal Halt state:

  • Initialise default output for this state
  • Reset door closed flag and reset wait LED flag



1. If driver presses close doors switch

  {
  Close door of master and turn OFF open door LED of master
  Send close doors message 0x725 and 0x745 to slaves 1 and 2 respectively
  Set a door closed flag
  Enable open door interrupt
  }

2. If driver presses open doors switch

     {
        If door closed flag is set 
        {
        //this is not the first time we are opening the doors in this state
              If wait LED flag is set and wait LED is blinking
              {
             Turn OFF wait LED and reset wait LED flag
              }
        }
        If internal open door flag of master was set
        {
        Open doors of the master 
        Turn ON open door LED of master
        }
        If door selection switch is at “Selected doors” position
        {
        Send conditionally open door message 0x726, 0x746 to slaves 1 and 2 
        respectively 
        }
        else if door selection switch is at “All doors” position
        {
        Send open all doors message 0x724, 0x744 to slaves 1 and 2 
        respectively
        }
   Enable close door interrupt
   }

3. If some passenger on the station presses open door switch

  {
     If door closed flag is set 
     {
     //It means s/w is pressed after closing doors and before starting the train
     Set internal flag for this open door interrupt of master
     Set wait LED flag and start blinking wait LED
     }
     else if door closed flag is reset
     {
     //It means train is at halt on station and door is closed 
     Reset master’s open door interrupt flag
     Open the door and turn ON open door LED
     }
  }

4. If master receives open door request message 0x1EB / 0x2EB message from slave 1 / 2 respectively

   {
   Set wait LED flag and start blinking wait LED
   //this indicates open door s/w in slave coach is pressed by passenger on platform, after closing the doors and before the train is started
   }

5. If some passenger from within the train presses stop request switch

  {
     If door closed flag is set
     {
     Set master’s stop request interrupt flag
     Transfer this stop request to next transitioning state
     }
     else if door closed flag is reset
     {
     Reset master’s stop request interrupt flag
     open the door and turn ON open door LED
     }
  }

6. If master receives stop request message 0x1E7 / 0x2E7 message from slave 1 / 2 respectively

     {
     Transfer stop request to next transitioning state
     }

7. If start train switch is pressed

  {
     If driver’s open/close switch is at close door position
     {
     Start the DC motor        
     Master sends train started message 0x729 and 0x749 to slaves 1 and 2 respectively.        
     Master switches to normal running state.
     }
     else
     {
     Do nothing
     }   
  }

8. If stop train switch is pressed by driver

     {
     Do nothing, as the train is already at halt
     }

9. If smoke is detected

  {
     If smoke detected flag is reset //smoke is detected for first time
     {
     Set smoke detected flag
         If doors are opened
         {
         Send safe exit message 0x723 and 0x743 to slaves 1 and 2 respectively    
         Master itself will switch to emergency halt state (This will open the doors of master by default)
         }
         Else if doors are closed
         {
         Send emergency signal 0x722 and 0x742 to slaves 1 & 2 respectively
         Master will glow its stop request LED and start flashing emergency LED
         }
     }
     else
     {
     Do nothing
     // Ignore multiple smoke detection interrupts
     }
  }

Algorithm for slave (followers)

Testing & Technical Challenges

Describe the challenges of your project. What advise would you give yourself or someone else if your project can be started from scratch again? Make a smooth transition to testing section and described what it took to test your project.

Include sub-sections that list out a problem and solution, such as:

My Issue #1

Discuss the issue and resolution.

Conclusion

This project was a great learning experience for all of the team members. The CAN filter design for multi-node operation was successfully developed, implemented and tested. The relevant hardware circuits were also built to demo the operation. The project can be further improved by adding more features and operations.

Project Video

Upload a video of your project and post the link here.

Project Source Code

Send me your zipped source code and I will upload this to SourceForge and link it for you.

References

Acknowledgement

Any acknowledgement that you may wish to provide can be included here.

References Used

List any references used in project.

  1. Preetpal Kang, Lecture notes of CMPE 244, Computer Engineering,San Jose StateUniversity, Feb-May 2014.
  2. http://www.socialledge.com/sjsu/
  3. Project setup provided by Prof. Preetpal Kang.
  4. LPC1758 User Manual
  5. MCP2551 schematic: http://www.fischl.de/arm/can_bus_interface_for_stellaris_launchpad/

Appendix

You can list the references you used.