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.
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:
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 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 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.
Protocol Layer Classes
This section introduces the classes of protocol layer and provides the basic idea of their functionality.
This is the main class of the protocol layer. Application layer communicates with the cash flow device through this class. This class initiates the communication with the device and sends back the responses of the device to the application layer. The class also provides some utility functions for the necessity of application layer.
This class initializes the some main protocol attributes and important function definitions of the supported protocol.
Protocol layer provides an excel file named as EBDS_Command_List which contains all OPM/IMF id supported by EBDS protocol and their respective control byte, length, data bytes, extra bytes, reply value, reply value byte no and reply mask. This class initializes these attributes and reset them.
Protocol layer provides another excel file named as EBDS_UI_Mapping which contains all OPM/IMF UI name of EBDS protocol supported by application layer and their respective OPM name, IMF name, number of bits/bytes, recommended value, possible value, reserved value and field type. This class initializes these attributes and reset them.
This class parses the two excel file EBDS_Command_List and EBDS_UI_Mapping and load their values to their respective attributes those are initialized in the MeiIMF and MeiUIMapping class.
This class inherits the MeiProtocol class. The class performs EBDS protocol related specific tasks such as initializing COM port, alternating ACK/NAK bit, generating checksum, handling polling and timeout issues etc.
In the test tool currently four commands are supported for the EBDS protocol. They are:
(1) Omnibus Command (2) Auxiliary Command (3) Extended Command and (4) Calibration Command.
Command generation, sending command execution request to another class and receives device response related tasks are also handled in this class. To generate these four types of commands and parse their responses from the device the class has four partial classes. Naming of the partial classes is given according to their command name.
This is the partial class of the EBDS class. The class generates the omnibus command and parses the omnibus reply.
This is the partial class of the EBDS class. The class generates the auxiliary command and parses the auxiliary reply.
This is the partial class of the EBDS class. The class generates the extended command and parses the extended reply.
This is the partial class of the EBDS class. The class generates the calibration command and parses the calibration reply.
This class executes the requested command to send to the cash flow device and receives raw bytes reply from the device. Then it echo backs these device response to the MeiProtocolManager class.
This class defines the property of argument list’s constant key for the omnibus, auxiliary and extended commands and also defines some other constant key’s property.