Implementation

Application based on qt-creator

QtPlatz application framework is originally derived from Qt-creator 1.3.1 version. Qt-creator is designed as integrated development environment (IDE) based on plugin architecture. On IDE, user edit source code, review reference manuals, build and run application. Polymorphism with analytical instrument data system is encountered for example file open, save and save-as functions are exactly same operation and meaning. Source code edit is similar to the data processing, acquisition and process method editing is also similar to edit file, and method error check is similar to the compile.

PVC pattern onto qt-creator style plugin

From my experience worked for several analytical instrument data system software project, simple C++ programming is always successful than using lot of fancy technologies introduced from Microsoft such as ActiveX, .NET, COM and DCOM. Simple use of MFC document/view works very well too. However, in order to realize central “Business rule” layer into MFC document/view pattern with clearly isolated view organization, we also need a hierarchy of documents in a top level document.

An example, assume we are going to implement a software focusing on to GC/TOF-MS that is configured from Agilent GC with own designed TOFMS, which is controlled through own firmware equipped with Linux or RTOS. Our program has to hold a pointer to Agilent GC control software module and TOFMS communication channel for firmware. Views such as spectral real time monitoring, TOFMS hardware set and actuals, Agilent GC oven temp monitor to be placed on software.

After this software development has been completed, then if we would like to support DART ion source as a user option of GC/TOFMS system, it would be a problem because we have to add a code for DART ion source support on the document that already has Agilent GC related code. However, view has no problem because we can implement dedicated view on the same document/view architecture.

A design pattern known as Presentation Abstraction Controller Architecture (PVC), which as known as Hierarchal Model View Controller (HMVC) pattern matches this purpose well. A model class is responsible for a single feature that is a much smaller unit than our view panes such as Data Analysis, Tune and Acquisition etc., but more function (model) oriented. For example, a model class is responsible for “MS Processing”, “MS Calibration” and “MS Diagnostic” etc. Model holds data only specific to that purpose. Several models coexist in document class. A controller class hooked up to each model class is responsible for drawing (viewing) business logic, and view classes are no longer responsible for any business logic.

Hardware Abstraction Layer Components

1. Machine State Controller

• Controlling Top Level Machine State

1. Fundamental Machine Interface

• Implements fundamental machine command and reactor for machine event in order to control individual machine.

1. Concreate Machine Interface

• Actual (individual) machine interface layer.
• Implementation method might be different depend on type of instument
  • Agilent 1200 — direct TCP/IP communication based on ***Agilent protocol for LC
  • Agilent GC — direct TCP/IP and HTTP based on Agilent protocol for GC
  • An AD convertor for acquire data such as chromatogram may be using USB with delayed event signals on data stream
  • Sophisticated instrument such as Mass Spectrometer may need sophisticated communication mechanism such as CORBA

Datafile

DATA FILE DEFINITION

A data file is corresponding to a sample and is contains raw data file and processed results. Definition of the "raw" data means a series of data stream acquired from instruments. Data streams are containing spectra, voltages, UV/Vis absorption, temperature, solvent composition, pressure and many of those and are usually a function of time.

REQUIREMENTS FOR RAW DATA

Raw data portion of the file should not be able to alter after acquisition is completed. 
Raw data is recording as stream which keep the acquisition order information. — Memo: This can be realized as form of SignalObserver stream using IIOP's serialization mechanism. 
Each instrument can create more than one Signal Observer and more than one same type of instrument will consists a system, therefore simultaneous stream write operation should be supported.

REQUIREMENTS FOR PROCESSED DATA

Processed data is a set of spectra or chromatograms generated from raw data by process algorithms. 
Processed data can be altered by user using data processing function user interface interactively or by batch process. 
For regulated environment, previous data can be stored and can be reviewed when audit requested. 
For non-regulated environment, user can choose either alter data by deleting previous data or save previous data in history.

DISCUSSION FOR FILE FORMAT

Need to be consider.

1. Basic read/write performance for large data unit. TOF MS require large space for a spectrum in range of MB, and total of few GB. Modern LC peak width is less than half seconds, which require at least 25 to 40Hz spectral sampling points. Unfortunately, zip algorithm on 3GHz core i7 processor can't catch up to this speed, therefore max raw transmit rate is important. Also important that data record can be altered easily later. For example, compress data and truncate file size easily — this operation is extremely difficult if using POSIX (Windows/Unix) native file mechanism.
2. Data storage has a characteristics that is strong for many of small chunk of data access such as e-mail data storage, otherwise strong for large data access units. Most of analytical instruments are require both mixed. For example TOF-MS data acquisition require large but predictable spectral size, and additional small data chunk for event log, hardware parameters on the fly monitored and other detector signals.
3. Maximum data length. I'm expecting a data file size up to TB, but mostly sub GB or lower.
4. Data read out speed and multiple access capability. It is important for processing data quickly in high throughput mode.
5. Data portability and availability. Data files are going to be a customer's property. Patent and related regulation require at least 30 years data retention period. Data file should be able to access for coming 50 years using any computer platform will be designed in future.

Possible solutions are:

Use of Microsoft OLE file

It is free on Microsoft platform and Linux code available in open source. However, bit limitation is limited up to 4GB file size. Access speed performance is not excellent. This is hock up to Microsoft's core architecture and native file format for MS Office products.

Use of commercial product such as SolFS

This has excellent performance and C source code available. It's work with Windows, Linux and Mac. A limitation is its commercial product, which little inconvenient for source code maintenance for open source project. (And it is expensive for source code license $16,816.USD)

Use of RDBMS

Many solutions are possible. Each product has different characteristics for different metrics. In order to find good one, need to know full requirement and characteristics for our needs. (Size, access rate, applicability of compression (lossey/loss less), applicability of 21 CFR Part 11 requirement, auditing, alter data mechanism, difficulty of data file resizing and other many metrics.

Port from existing file system or design from scratch

It is extremely difficult to make it stable and reliable.

SQLite pros and cons

Pros

- Supports up to few TB size. - Complete SQL database with transaction supported (easy to rollback if operation failed). - Extremely light weight and easy to integrate to any source code project by static or dynamic. - Able to run on memory — even no disk file required. - 10% or more fast for small binary data access than Microsoft/Linux native data access. - 1.6 times faster for large binary data reading compared with native Windows API. - Auto vacuum make easy to truncate deleted file automatically - Easy or no maintenance required.

Cons

- Slow writing speed for large binary data in BLOB record. Compared Microsoft native API, large binary data writing is 10 times slower, and is improved up to 1/3 with pre-allocation. - Less concurrency. Update or Insert transaction will lock entire database, and single transaction only allows.

Machine State

MACHINE STATE

OFF

Instrument power is off or driver not loaded

Initializing

Instrument is power on initializing, driver is loading

Calibrating

Calibration is in progress on instrument

Diagnostic in progress

Power on self-diagnostic is in progress

Maintenance in progress

It is for MCP conditioning on Mass Spec., since it takes long time but we do not want to disturbing access to HPLC and MS control during it. Concrete instrument layer make sure to be safe for service engineers during this flag is set

Busy

Instrument is busy and unable to receive any command

Ready

Instrument is ready to receive any command. Statue is up to date

Preparing for Run

(A.k.a. Initial Conditioning) Instrument is preparing for run. LC pump is on at initial gradient condition, autosampler is waiting before loading sample. MS voltage and protocol functions are running as specified in method. On this state, download another method will override current method and apply for current initial condition

Ready to Run

Same above, but user can press ‘Sequence start’ button

Run

In progress Sequence is running

Acquisition in progress

Same above. Additionally data is acquiring

Warning

Independent status, telling warning

Error

Independent status, telling error on hardware

STOP

Instrument has been stopped. Make sure it safe to touch instrument for maintenance

SEQUENCE STATE

• STOP
• INITIALIZING
• RUN
• PAUSE
• URGENT