Instrument Control Language

An Instrument Control Language (ICL ) gives both power and flexihihty in operating the system. With this operators have complete control to create or customize instrument procedures, and design experiments to exactly meet laboratory needs. TTie instrument can optimize analysis by making real-time decisions during data acquisitions. 

This was probably the most difficult chapter to put together in this book. For many people who use NMR spectrometers, there will be little (or no) choice about parameters for acquisition - they will probably have been set up by a specialist to offer a good compromise between data quality and amount of instrument time used. This could make this chapter irrelevant (in which case you are welcome to skip it). But if you do have some control over the acquisition and/or processing parameters, then there are some useful hints here. This brings us on to the next challenge for the section - hardware (and software) differences. You may operate a Bruker, Varian, Jeol or even another make of NMR spectrometer and each of these will have their own language to describe key parameters. We will attempt to be vendor neutral in our discussions and hopefully you will be able to translate to your own instrument s language. 

The decision for each example is expressed as an "action-next state" pair. The "action" is a reference to executable Radial code, which consists of a sequence of Radial statements. These statements may contain references to external programs in various languages (this will be discussed further later). The "next state" describes the context to which control is to pass after the action is completed. For diagnostic expert systems, such as TOGA, the next state will usually be the "goal" state of the module. This passes control back to the calling module. For procedural expert systems, such as robotics and instrumentation control applications, the control will be transferred between several states within a module to Implement looping. 

SALT. SALT is a threaded interpretive language which is interfaced to BASIC. Thus it exhibits both the fast response of assembly language programs and the interactive character of BASIC programs. SALT was written by a researcher who emphasized the ability of instrument control. SALT supports only the TecMar LabMaster hardware. 

Before reaching the point of complete data integration as given above, there are intermediary levels of data integration that are beneficial to better analysis of data from process analyzers. The best case would be to have all the data in a human readable form that is independent of the application data format. Over the years several attempts have been made to have a universal format for spectroscopic data, including JCAMP-DX and extensible markup language (XML). Because many instrument vendors use proprietary databases, and there is not a universal standard, the problem of multiple data formats persists. This has led to an entire business of data integration by third parties who aid in the transfer of data from one source to another, such as between instruments and the plant s distributed control system (DCS). 

Instrumentation, Systems, and Automation Society, 2001, ANSI/ISA-88.02-2001 Batch Control Part 1 Data Structures and Guidelines for Languages, ISA, Research Triangle Park, USA. 

In the Fieldbus example, the Asset Management System converts the standard Fieldbus descriptor (in device descriptor language [DLL]) to a D-COM object. This is then passed to OCS where it is converted from D-COM into the OCS s own object model. This is so that the relevant parts of the Fieldbus device descriptor can be distributed to the various OCS nodes for display, trending, alarm purposes and so on. The OCS then uses its OMM to transfer the data to the OCS controller, where it is again converted to DLL format prior to sending across the Fieldbus link to the intelligent instrument. 

The next task is an analysis showing that no control system failure can cause an initiating event that can result in a hazard. If control system failure can initiate a hazardous sequence, then safety instrumented functions MUST NOT be designed into common equipment without detailed quantitative risk analysis. That language in the standard is strong and clear. Most of the time, initiating event analysis shows a problem with combined control and safety. 

---