S14: Power efficient security door system for light-rail using CAN bus
Contents
- 1 Grading Criteria
- 2 Power efficient security door system for light-rail using CAN bus
- 2.1 Abstract
- 2.2 Objectives and Scope
- 2.3 Introduction
- 2.4 Team Members & Responsibilities
- 2.5 Schedule
- 2.6 Parts List & Cost
- 2.7 Design & Implementation
- 2.7.1 Hardware Design
- 2.7.2 Sensors and peripherals of engine (master) coach
- 2.7.3 Sensors and peripherals of follower (slave) coach
- 2.7.4 Hardware Interface
- 2.7.5 Software Design
- 2.7.6 Implementation
- 2.7.7 Algorithm for different states of master (engine)
- 2.7.8 Default Halt state:
- 2.7.9 Normal Halt state:
- 2.7.10 Algorithm for slave (followers)
- 2.8 Testing & Technical Challenges
- 2.9 Conclusion
- 2.10 References
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.
Figure 1. System block diagram
Figure 2. Schematic diagram of prototype board for master (engine)
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.
Table 1. Pin configuration for master (engine)
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.
Table 3. Format 11- bit CAN ID
The addresses of master and slaves are shown in table 4.
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.
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.
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
Conclude your project here. You can recap your testing and problems. You should address the "so what" part here to indicate what you ultimately learnt from this project. How has this project increased your knowledge?
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.
Appendix
You can list the references you used.