Protocol Layer

From ReliSourceWiki

Revision as of 12:00, 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.

Personal tools