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

From Embedded Systems Learning Academy
Revision as of 23:44, 6 August 2014 by Preet (talk | contribs) (Project Source Code)

Jump to: navigation, search

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
    • Development of the concept, logic, state diagram, algorithm and hardware prototype board
  • 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 Completed successfully

Parts List & Cost

List of parts are given in the following table:

           CmpeE244 S14 T2 interrupts 1.jpg

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

CmpeE244 S14 T2 interrupt 1.jpg

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

CmpeE244 S14 T2 interrupt 2.jpg

Table 7. Enabling/disabling of interrupts for normal halt state

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
     }
  }

Emergency Halt state:

  • Initialise default output for this state
  • Disable all interrupts of driver’s and passengers’ switches in master coach

Note: Only hardware reset of all coaches will cause this state to change to default halt state. Any other events or actions will not have any effect and this state will not be changed.

Emergency Running state:

  • Initialise default output for this state

Note: This state can only switch to emergency halt state

1. If stop train switch is pressed by driver

     {
     Stop the DC motor
     Send safety exit message 0x723 and 0x743 to slaves 1 and 2 respectively
     Switch master itself to emergency halt state
     }

Normal Running state:

  • Initialise default output for this state

CmpeE244 S14 T2 interrupts 3.jpg

Table 8. Enabling/disabling of interrupts for normal running state

1. If stop train switch is pressed by driver

    {
    Stop the DC motor 
    Send train has stopped message 0x72A and 0x74A to slaves 1 and 2 respectively
    Switch master itself to normal halt state
    }

2. If stop request switch is pressed by passenger in master’s coach

    {
    Send stop request acknowledge message 0x728 and 0x748 to slaves 1 and 2 respectively
    Master will glow both of its stop request LEDs
    }

3. If master receives stop request message 0x1E7 or 0x2E7 from slave 1 or 2 respectively

    {
    Send stop request acknowledge message 0x728 and 0x748 to slaves 1 and 2 respectively
    Master will glow both of its stop request LEDs
    }

4. If smoke is detected

    { 
    Send emergency message 0x722 and 0x742 to slaves 1 and 2 respectively
    Master switches itself to emergency running state
    }

Algorithm for different states of slave (followers)

Default Halt state:

  • Initialize default output for this state
  • Reset open door flag and reset stop request flag
  • Reset door closed flag //This flag (in slave) is set only if it receives close door message from master
  • Enable all interrupts from passenger’s’ switches

1. If master sends close door messages, 0x725 and 0x745 to slaves 1 and 2 respectively

   {
   Reset slave’s internal open door interrupt flag
   Set slave’s internal door closed flag
   Turn OFF the open door LEDs of the slaves
   }

2. If master sends conditionally open door message 0x726, 0x746 to slaves 1 & 2 respectively

  {
    If the slave had set its internal open door interrupt flag 
    {
    Reset slave’s internal open door interrupt flag
    Turn ON open door LED of that slave
    }
  }

3. If master sends open all doors message 0x724, 0x744 to slaves 1 & 2 respectively

  {
  Reset slave’s internal open door interrupt flag
  All slaves will turn ON its open door LEDs
  }

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

  {
  Set slave’s internal open door interrupt flag
     If slave’s internal door closed flag is set
     {
     //It means this open door s/w is pressed after closing the doors
     Slave 1/2 will send open door request message 0x1EB / 0x2EB respectively to the master
     }
     else
     {
     //if the driver had never closed doors after switching to this state
     Reset slave’s internal open door interrupt flag
     Turn ON open door LED of the slave
     } 
  }

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

   {
   Set slave’s internal stop request interrupt flag
       If slave’s internal door closed flag is set
       {
       //it means this switch was pressed after closing the doors
       Slave 1/2 will send stop request message 0x1E7 / 0x2E7 respectively to the master
       This stop request has to be transferred to the next transitioning state
       }
       else
       {
       Reset slave’s internal stop request interrupt flag
       Turn ON open door LED of the slave
       }
   }

6. If master sends train started message 0x729 and 0x749 to slave 1 & 2 respectively

     {
     Switch to normal running state
     }

7. If master sends safety exit message 0x723 and 0x743 to slaves 1 and 2 respectively

     {
     Switch to emergency halt state
     }

8. If master sends emergency message 0x722 and 0x742 to slaves 1 and 2 respectively

     {
     Turn ON stop request LED of slave and start blinking emergency red LED
     }

Normal Halt state:

  • Initialise default output for this state
  • Reset open door flag and reset stop request flag
  • Reset door closed flag //This flag (in slave) is set only if it receives close door message from master
  • Enable all interrupts from passenger’s’ switches

1. If master sends close door messages, 0x725 and 0x745 to slaves 1 and 2 respectively

   {
   Reset slave’s internal open door interrupt flag
   Set slave’s internal door closed flag
   Turn OFF the open door LEDs of the slaves
   }

2. If master sends conditionally open door message 0x726, 0x746 to slaves 1 & 2 respectively

  {
    If the slave had set its internal open door interrupt flag 
    {
    Reset slave’s internal open door interrupt flag
    Turn ON open door LED of that slave
    }
  }

3. If master sends open all doors message 0x724, 0x744 to slaves 1 & 2 respectively

   {
   Reset slave’s internal open door interrupt flag
   All slaves will turn ON its open door LEDs
   }

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

   {
   Set slave’s internal open door interrupt flag
      If slave’s internal door closed flag is set
      {
      //It means this open door s/w is pressed after closing the doors
      Slave 1/2 will send open door request message 0x1EB / 0x2EB respectively to the master
      }
      else
      {
      //if the driver had never closed doors after switching to this state
      Reset slave’s internal open door interrupt flag
      Turn ON open door LED of the slave
      } 
   }

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

   {
   Set slave’s internal stop request interrupt flag
       If slave’s internal door closed flag is set
       {
       //it means this switch was pressed after closing the doors
       Slave 1/2 will send stop request message 0x1E7 / 0x2E7 respectively to the master
       This stop request has to be transferred to the next transitioning state
       }
       else
       {
       Reset slave’s internal stop request interrupt flag
       Turn ON open door LED of the slave
       }
    }

6. If master sends train started message 0x729 and 0x749 to slave 1 & 2 respectively

    {
    Switch to normal running state
    }

7. If master sends safety exit message 0x723 and 0x743 to slaves 1 and 2 respectively

   {
   Switch to emergency halt state
   }

8. If master sends emergency message 0x722 and 0x742 to slaves 1 and 2 respectively

   {
   Turn ON stop request LED of slave and start blinking emergency red LED
   }


Emergency Halt state:

  • Initialise default output for this state
  • Disable all interrupts from passenger’s’ switches

Note: Only hardware reset of all coaches will cause this state to change to default halt state. Any other events or actions will not have any effect and this state will not be changed.

Emergency Running state:

  • Initialise default output for this state
  • Disable all interrupts from passenger’s’ switches

Note: This state can only switch to emergency halt state

1. If master sends safety exit message 0x723 / 0x743 to slaves 1 / 2 respectively

  {
  Switch to emergency halt state
  }


Normal Running state:

  • Initialise default output for this state

1. If master sends train has stopped message 0x72A and 0x74A to slaves 1 and 2 respectively

   {
   Switch the slave to normal halt state
   }

2. If master sends stop request acknowledge message 0x728 and 0x748 to slaves 1 and 2 respectively

   {
   Turn ON stop request LED for the slave
   }

3. If stop request switch is pressed by the passenger in slave’s coach

   {
   Slave 1 / 2 will send stop request message 0x1E7 / 0x2E7 respectively to the master
   }

4. If master sends emergency message 0x722 and 0x742 to slaves 1 and 2 respectively

   {
   Switch the slave to emergency running state
   }

Testing & Technical Challenges

The challenges that we faced in the project are listed below

1. CAN self test mode

To ensure that the CAN bus communication is working, CAN self test mode was checked. For this, Master project team that comprises of Soumya Roy, Candida Bayross and Pratibha S shared their self test code with us. They shared information on what exact termination resistor values need to be used for setting up the CAN bus self test mode. Microchip's MCP2551 was used as the CAN bus driver. The CAN bus started working when we used an external biasing resistor of 1k with the MCP2551 as per Soumya's team's instructions. We thank Soumya's team for helping us cross this hurdle.

2. CAN communication between more than 2 nodes using Acceptance Filter.

Our project requires that CAN bus communication be set up between more than 2 nodes and be implemented using Hardware Acceptance filter. The datasheet that was received with the LPC1758 software provided by Preet was old and quite misleading in terms of information on CAN Bus Acceptance filtering. Hence the latest version of the datasheet of LPC1758 (Rev 3.1) was referred. Hardware filtering code logic was borrowed from NXP's application note titled "AN10674 NXP LPC2000 CAN driver with FullCAN mode" and corrected as per the information received from datasheet.

3. Configuring one single GPIO pin for both rising and falling edge interrupt without polling/modifying the pin continuously.

Due to lack of interrupt enabled GPIO port pins, toggle switches were used instead of push button switches, for giving high and low inputs to the micro-controller. Whenever a switch toggles the machine changes its state. Now the challenge was to configure a single GPIO pin of the micro-controller as input pin which should accept both rising edge and falling edge interrupts. Further more the pin has to be configured only once in one particular state and then it could not be polled or modified due to other logic restrictions. If a transition is made from low-to-high state (rising edge) one ISR needs to be called and if a transition is made from high-to-low state (falling edge) another ISR needs to be called. The issue was solved by reading the current input level (low or high) of the switch and accordingly configuring the GPIO pin for the opposite edge interrupt. For example, if the switch is in HIGH state, then the GPIO pin is configured for the falling edge interrupt.

4. Code Structure

In the early stages of the project, the code was being developed without any proper structure in mind. This led to lot of confusion regarding how the engine's code and how the coach's code should perform in various scenarios. Switching to a state machine format in the code structure greatly enhanced the code quality and also helped in the faster development of code.


Testing

The code logic has been implemented as a state machine. Following are the 5 different states that the train goes through.

1. default halt

2. normal running

3. emergency running

4. emergency halt

5. normal halt

Test cases were written for each state and verified. Each test case for each state defines the detailed step by step instruction on how to perform the test. The success or failure of the test was noted down and marked as PASS or FAIL. Each test case was checked by first resetting all the boards. The screenshots of the test cases are shown below.

Below is the screenshot of the test cases for Reset. CmpeE244 S14 T2 Reset Tests 1.jpg


Below is the screenshot of the test cases for Default Halt state of the train. CmpeE244 S14 T2 Default Halt Tests 2.jpg


Below is the screenshot of the test cases for Normal Running state of the train. CmpeE244 S14 T2 Normal Running Tests 3.jpg


Below is the screenshot of the test cases for Emergency Running state of the train. CmpeE244 S14 T2 Emergency Running Tests 4.jpg


Below is the screenshot of the test cases Emergency Halt state of the train. CmpeE244 S14 T2 Emergency Halt Tests 5.jpg


Below is the screenshot of the test cases Normal Halt state of the train. CmpeE244 S14 T2 Normal Halt Tests 6.jpg

Future scope of the project

The project needs to be upgraded in terms of being able to self configure itself, when different nodes (coaches) are connected together. The self configuration means that the nodes should be able to decide among themselves as who will be the master and who all will be slaves. This is very important because in real time, different coaches can be connected together to form a two coach or a three coach train. And then depending on the direction of motion of the train the masters and slaves have to be decided. Besides this, we can add motion sensors so that as soon as the passenger stands in front of the door and if the train is at halt on a station, the doors will open up automatically. This also needs adding of ultrasonic or IR sensors to detect the station. Using wireless sensor networks, the feature of auto phone call to the nearest fire brigade station, in case of emergency, can also be incorporated. Turning off the internal lights in the train in the absence of the passengers in a particular section can further reduce the power consumption.

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

A short video of the demo can be found at https://www.youtube.com/watch?v=Z42hIPN_gUU&feature=youtu.be

Project Source Code

References

Acknowledgement

The team highly appreciates the help from Prof. Preetpal Kang regarding CAN filter design issues. We are thankful to Mr. Soumya Roy, Ms. Candida Bayross and Ms. Pratibha S for helping us getting started with CAN bus communication. We are thankful to Mr. Sai Prashanth Chinnapalli for lending us a CAN bus protocol analyzer that helped us debug our CAN bus communication issues. We are thankful to Yash Parulekar for lending us MCP2551 transceivers ICs in DIP package. This solved the problem of soldering the SMD transceivers that we had. We are also thankful to other class members for their help specially the other CAN related teams.

References Used

  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.