Protocol Layer

From ReliSourceWiki

Revision as of 12:04, 19 September 2011 by Ymurshed (Talk | contribs)
Jump to: navigation, search

Contents

General Overview Of Protocol Layer

Protocol Layer is the mid level layer, which receives various requests from Application Layer and sends commands to the Cash Flow Device according to the requests. The Cash Flow Device then echo backs some values against the requested command to the Protocol Layer. Finally Protocol Layer sends those values to the Application Layer.

Figure-1 shows how Application Layer communicates with Protocol Layer and Protocol Layer communicates with the Cash Flow Device.

High Level Architecture Protocol Layer 1.PNG High Level Architecture Protocol Layer 2.PNG

Protocol Layer Architecture

Protocol Layer directly handles all the requests come from Application Layer and further processes them to send to the Cash Flow Device. Protocol layer provides the flexibility to select a specific Protocol out of multiple supported protocols and communicate with the device with the selected protocol. The various portion of Protocol Layer are described below:

Protocol Manager

Test Case Generator requests to the Protocol Manager for command byte information required for generating the test case XML files. Protocol Manager sends back the information with the supported method/trigger for the selected protocol to the Test Case Generator. Test Case Generator can also query the Protocol Manager to validate the command byte information while editing any existing test case file. Test Executor also queries the Protocol Manager for validation of test case files.

Protocol Manager provides support for various types of Protocol. Although current implementation only supports EBDS protocol, we are keeping flexibility to add support for additional protocol in future. Each type of protocol will be able to independently communicate with Command Byte Mapping/Validation and Command Executor portion. Protocol Manager also supports some utility functions for the usage of application layer.

EBDS Protocol

EBDS Protocol contains EBDS related basic information and then communicates with Command Byte Mapping/Validation, UI Mapping Generation and Command Executor portion.

Packet format may vary depending on different protocol. Also various types of error can occurred during the communication with the cash flow device. These communication errors may also vary depending on the usage of different types of protocol.

EBDS protocol supports following command types in the tool:

  • Omnibus Command
  • Calibration Command
  • Auxiliary Command Request
  • Extended Command

Those commands are generated here according to the application layer requests using OPM list which is the Command Byte Mapping/Validation portion. It provides support for polling and timeout issues. It also supports bad CRC and random ACK/NAK generation.

Error Handling In EBDS Protocol

Checksum Error Checking

Checksum error is one of the major communication errors which can be occurred during communication between host and cash flow device. Checksum is the last byte of the data packet which is calculated by performing XOR operation among the byte 2 through Len-2 of a data packet.

To communicate with the cash flow device host must send a command with specific packet format with correct checksum value to the cash flow device. After receiving the command, device echo back a data packet with correct checksum value to the host. If the incoming command to the device contains wrong checksum value a checksum error occurred and then no data packet are echoed back by device to the host.

ACK/NAK Bit Checking

Another type of error can be occurred related to ACK/NAK bit in the control byte. It is documented in EBDS protocol spec that ACK and NAK bit must be set alternatively in the control byte when a command is sent to device. When a command is sent with ACK bit in the control byte it is expected that in the reply ACK bit is present in the control byte. Same behavior is expected for the NAK bit. If any mismatch is found between these bits in control byte of sending and receiving command it is assumed a communication error is occurred.

Handling of this type of communication errors are supported by the EBDS protocol.

Command Byte Mapping/Validation

When Test Case Generator and Test Case Executor request to the Protocol Manger for mapping/validation, it actually passes the requested OPM/IMF to the Command Byte Mapping/Validation portion. This portion actually checks requested OPM/IMF with the EBDS_Command_List id and then sends back the mapping/validation information of the associated id reading from the list to the Test Case Generator and Test Case Executor via Protocol Manager.

UI Mapping Generation

Test Case Generator requests to the Protocol Manager to ask supported OMP/IMF information supported by the EBDS protocol. The request then passes to the UI Mapping Generation portion. Then the UI Mapping Generation portion echo backs the relevant information reading from the EBDS_UI_Mapping list to the Test Case Generator through the Protocol Manger.

Command Executor

Command Executor takes instruction from Protocol Manger that which command or a set of commands will have to be executed immediately.

Command executor executes following command types on the basis of EBDS protocol:

  • Omnibus Command
  • Calibration Command
  • Auxiliary Command Request
  • Extended Command

Depending on the requests any of the above command will be executed with the appropriate value and then passed to Cash Flow Device by Command Executor. Against the command that was executed, the incoming response from the device will be set to some predefined delegates. Protocol Manager then sends the test result through these callback/delegates.

Personal tools