Case Study: Automated Blood Tube Labeler

Human errors can be catastrophic in a diagnostics lab environment. One potential cause of human error, would be mis-labelling or improper labelling a blood sample collected from a patient. The Automated Blood Tube Labeler is a lab equipment designed to reduce the possibility of human errors, when collecting blood samples.

The Automated Blood Tube Labeler can connect to the Laboratory Information System (LIS) and retreive patient details and the tests to be performed by scanning a patient’s barcode. It then requests the user to insert the correct hematology tube, by displaying the color code of the tube. Once the tube is inserted into the Automated Blood Tube Labeler, the Automated Blood Tube Labeler prints a tube label, with the patient details, and then pastes the label on the tube. While pasting the label the Automated Blood Tube Labeler ensures that the pasted label does not obstruct the sample measurement window, on the tube.

The customer had in-house capability for designing the hardware for the Automated Blood Tube Labeler. The software is complicated by the fact that it has to deal with multiple IO interfaces, all the while implementing the application logic.

An embedded software application was required that accesses the various interfaces and provides a highly configurable, convenient and fluid interface to the user.

The hardware platform developed by the customer is based on the Toradex Colibri T20 module, powered by the Nvidia Tegra 2 SoC. The BSP is based on Angstrom distribution from the Open Embedded build system, provided by Toradex.

The software was built using Python, the Kivy UI framework, Twisted Networking framework, and Sismic statechart framework. The screens are defined in Kivy. And the statechart states, events and transitions are described using Sismic. There is a one-to-one correspondence between screens and states in the statechart.

This application design is based on event-state-action paradigm. When OK button is pressed on a screen, an event is sent to statechart interpreter. The statechart interpreter depending on the current state and event determines the transition to be taken, executes the corresponding action, and transitions to the next state. The actions triggered by the statechart could be blocking or non-blocking. If there are blocking actions then additional intermediate states are required to complete the action, before proceeding to the next screen.