New Approaches

1
NewApproaches Standards for Laboratory
Automation System Integration

• Gary W. Kramer
• Analytical Chemistry Division

2
Presentation Outline

• Consortium on Automated Analytical Laboratory
  Systems - CAALS
• Laboratory Equipment Control Interface Standard -
  LECIS
• Device Capability Dataset - DCD
• System Capability Dataset - SCD
• NCCLS Clinical Laboratory Automation Standards

3
Acknowledgements

• Uwe Bernhöft, NIST and WICIL
• Oliver Borchert, NIST and WICIL
• Stephane Bostyn, NIST and CNAM
• Martin J. Burns, Hypertek, Inc.
• James T. Currie, Jr., Currie and Associates
• Anthony J. Day
• James R. DeVoe, National Institute of Standards
  and Technology (ret.)
• John W. Elling, Los Alamos National Laboratory
• Lawrence G. Falkenau, E.I Dupont de Nemours
• Peter J. Grandsard, Amgen, Inc.
• J. Michael Griesmeyer, Sandia National
  Laboratories
• Franklin R. Guenther, National Institute of
  Standards and Technology
• David R. Hawk, Hewlett-Packard Co., Inc.
• Gary W. Kramer, National Institute of Standards
  and Technology
• Richard S. Lysakowski, Team Science, Inc.
• James V. Petersen, Amgen, Inc.
• Christian Piotrowski, NIST and WICIL
• Thorsten Richter, National Institute of Standards
  and Technology
• Mark F. Russo, Bristol-Myers Squibb Co.

4
What was CAALS?
Consortium on Automated Analytical Laboratory
Systems
An Industry-Government-NIST Joint Venture to
Foster the Development and Application of
Chemistry Laboratory Automation Standards
5
Who was CAALS?

• Abbott Laboratories
• ABC Laboratories, Inc.
• Air Products and Chemicals, Inc.
• Applied Analytical Industries, Inc.
• B P America
• Boehringer Mannheim Corporation
• CEM Corporation
• Digital Equipment Corporation
• Dionex Corporation
• Dupont Diagnostic Systems
• E. I. DuPont de Nemours Company
• Eastman Chemical Company

• Eastman Kodak Company
• Hewlett-Packard Company
• NIST
• Occidental Chemical Corporation
• The Perkin-Elmer Corporation
• R. J. Reynolds Tobacco Company
• Union Carbide Corporation
• U. S. Department of Energy
• U. S. Environmental Protection Agency
• W. R. Grace Company
• Zymark Corporation

6
What did CAALS wrought?

• Modular Control System Architecture
• Behaviors for Device Control
• CAALS-I Low-Level Communications Protocol
• High-Level Communication Protocol
• Common Command Set
• Device Capability Datasets

7
CAALS Modular Control System Architecture

• Defines System Roles of Modules, Controller, and
  LIMS
• Scalable
• Master-Slave, Client-Server

8
CAALS Behaviors for Device Control

• Is Remotely Controllable and Expects to be
  Controlled by an External Device
• Maintains Bi-Directional Communication in Local
  and Remote Modes
• Exhibits Atomic and Deterministic, Predictable
  Behavior
• Responds Gracefully to Any Command and to Errors
• Provides Status Externally of Internal Operations
• Provides Automated Access to Sample and Material
  Ports

9
CAALS-I Communication Specification

• Guaranteed, Error-Free Message Delivery
• Guaranteed Connectivity and Freedom from
  Communication Lock Up
• Operating System, Computing Platform, and
  Application Independence
• Support for a Variety of Both Connection-Based
  and Connectionless Physical Links
• Standardized, Fully Specified, not Negotiated,
  Message Syntax

10
CAALS High Level Communication Protocol

• Requires Minimum of Two Logical Channels
• Follows Event-Driven Model

11
CAALS Command Philosophy

• Enabling
• Minimalistic
• Simple
• Control at Device Method Level
• Module Parameters and Micro-Sequence of
  Operations within the Module are Captured in
  Device Method
• Device Methods Stored Locally in Module or
  Down-Loaded

12
CAALS Device Capability Datasets

• Describe Idiosyncratic Characteristics of Device
• Contain Static, Semi-Static, Semi-dynamic, and
  Dynamic Data
• Are Represented Using STEP/EXPRESS (ISO 10303)
• Standardize the How, not the What

13
Laboratory Equipment Control Interface
SpecificationLECIS

• ASTM E1989-98
• NIST CAALS
• Modular Architecture
• Behaviors for Device Control
• High Level Communication Protocol
• Common Command Set
• Sandia National Laboratorys
• General Equipment Interface Specification (GEIS)

14
LECIS Concept

• LECIS is a Prescriptive Control Behavior
  Specification Based on Interactions Consisting
  of
• States (Discrete Operational Equipment
  States)
• Commands (Controller Messages)
• Events (Equipment Messages)
• LECIS-defined Interactions are Common to All
  Instruments
• LECIS Interactions Define the Remote Control
  Dialogs Between the Controller and the Instrument

15
LECIS Interactions

• LECIS Distinguishes Between Required and Optional
  Interactions
• Required Interactions Must Be Supported by All
  Instruments
• Optional Interactions Can Be Used to Define
  Instrument-specific Interactions
• LECIS Defines Required Interactions Only!
  Optional Interactions are Defined by Instrument
  Manufacturers
• LECIS Further Classifies Interactions Into
  Primary and Secondary Interactions
• Primary Interactions
• Start at Power-up Time
• Never Terminate
• Occur Only in Single Instances
• Secondary Interactions
• Start and Terminate at Run Time
• Allow Multiple Instances of the Same Interaction

16
LECIS Interactions
17
Primary Interactions

• Control Flow - Regulates Instrument
  Initialization, Configuration, and Regular
  Operations
• Local/Remote Control Mode - Manages Instruments
  Local/Remote Control Mode Transitions

18
Secondary Interactions

• Processing - Allows Execution of Instrument
  Methods
• Status - Retrieves Status of Interactions from
  Instrument
• Lock/Unlock - Locks/Unlocks Instruments
  Data/Material Ports
• Abort - Aborts Interactions
• Alarm - Indicates Instrument Errors/Exceptions
• Item Available Notification - Data/Material
  Availability Notification
• Next Event Request - Requests Next Event From
  Instrument

19
LECIS Benefits

• Allows Device-Independent Remote Control
• Fosters Plug and Play of Instruments Through a
  Common Remote Control Interface
• Reduces Dependence on Single Vendor
• Is Independent of Low-Level Communication
  Protocol
• Is Independent of Computing Platform
• Is Independent of Programming Language
• Reduces Instrument Interfacing Costs and Efforts

20
Device Capability DatasetDCD

• A DCD is a Concept to Stylize the Way the Unique
  Characteristics and Attributes of a Device Are
  Represented in a Descriptive, Systematic,
  Computer-Usable Fashion
• The DCD Provides the System Controller With the
  Information It Needs to Control the Device and to
  Direct the Interaction of the Device With the
  Remainder of the System
• The DCD Concept Can Eliminate Custom Programming
  and Facilitate System Integration for Laboratory
  Automation by Stylizing the Idiosyncratic
  Characteristics of Devices

21
DCD Goals and Objectives

• Permit Product Differentiation Among
  Manufacturers
• Facilitate Integrating Different Types of Devices
  into the System
• Create a Modular Structure for Control and Device
  Software
• Provide a Standard Integration Interface
• Afford Plug-and-Play Functionality
• Enable Centralized Control and Error Handling
• Hold Device Descriptions at One Central Point

22
DCD Philosophy

• Need Standards for System Devices to Facilitate
  System Integration
• Rule-based Standards Are Applicable for the
  Characteristics That Real Devices Have in Common
  Such as Communication Behavior
• Need Another Approach for the Idiosyncratic
  Characteristics of Real Devices
• Solution Develop Standards to Describe the
  Idiosyncratic Characteristics, i.e. Standardize
  the How Not the What

23
Information Categories in the Initial CAALS DCD

• Administrative Info
• Alarms
• Commands
• Events
• Interactions
• Maintenance Records
• Physical Characteristics
• Port Descriptions
• Resources
• States
• System Variables

24
Methodology to Describe the DCD STEP/EXPRESS ISO
10303

• The Elements of a DCD Are Defined Using
  STEP/EXPRESS (STandard for the Exchange of
  Product Model Data)
• STEP Is an International Standard for the
  Computer-Interpretable Representation and
  Exchange of Product Data
• EXPRESS Is an Information Model Specification
  Language Defined in Part 11 of the STEP Standard

25
Some DCD Benefits

• By Describing the DCD With STEP/EXPRESS, the
  Concept Becomes Implementation Independent
• Once Created, Information for One Device Can Be
  Used for a Similar Device With Little or No
  Change
• The Information From the DCD That Describes the
  Metadata for the Result Data Can Used by Other
  Programs that Handle these Data
• The DCD Can Provide the Information Needed for
  Modeling and/or Simulating the Behavior of a
  Device

26
System Capability DatasetSCD

• The System Level Realization of the DCD Concept
• Logical Collection of DCDs for All Devices in
  System
• Information on System Layout, Geometry, Allowable
  Paths, Trajectories, etc.
• Information on Interactions Between Devices
• Information on Dependencies Between Devices
• Information About Resources Used by, but Not
  Owned by, Devices

27
Makeup of a System Capability Dataset
28
SCD Information Types

• Static Information - Device Characteristics That
  Do Not Change, Such As the Identification of the
  SLM
• Semi-Static Information - Information That Is
  Altered Only Occasionally During the Use of the
  System, e.g. Method Names
• Semi-Dynamic Information - Information That Is
  Commonly Altered During System Use, Such As
  Initial Reagent or Supply Fill Levels
• Dynamic Information - Process Control and
  Real-Time Data That Constantly Change During
  System Use and are Unknown Before Run Time

29
Who Creates the SCD?

• The Instrument Manufacturer Provides the
  Information That Describes the Identification,
  the Functionality, and the General Behavior of
  the Device This Forms the Core of the DCD
• The System Integrator Adds System-Specific
  Information About the Devices Role and Position
  in the System, Error Handling, Error Mapping and
  Ownership of Resources
• The Super User Configures the System for the
  Specific Application Needs and Adjoins
  Information That Describes Particular Instrument
  Methods (Macros) or Special Behavior
• The End User Supplies Information and Conditions
  for a Specific Run of the System

30
SCD Creation Timeline
Manufacturer
System Integrator
User
System
Information
Information
Information
Information
SCD
Run-time
Device Construction
System Integration
Application Integration
31
Current Activities

• LECIS Implementations - Torsten Staab, LANL
  commercial implementations CRS Robotics, Zymark,
  Tecan, Tomtec, Bristol-Myers Squibb,
• SCD Implementation - Thorsten Richter, NIST
• DCD Implementation - Thomas Tauber, NIST
• Handling Device Data via DCD - Oliver Borchert,
  NIST
• Automated Laboratory System - Reinhold Schaefer
  Group, WICIL

32
NCCLS Area Committee on Clinical Laboratory
Automation

• Subcommittee on Specimen Container/Specimen
  Carrier
• Subcommittee on Specimen Identification
• Subcommittee on Communication with Automated
  Systems
• Subcommittee on Electromechanical Interfaces
• Subcommittee on System Status

33
More Informationgary.kramer_at_nist.gov

• CAALS
• Until NIST firewall goes up
• ftp//caals.nist.gov
• Then will move to
• http//www.cstl.nist.gov/nist839/839.04/
• LECIS
• Now available at
• http//www.ergotech.com/LECIS
• Soon will move to
• www.lecis.org
• DCD and SCD
• Coming Soon to
• http//www.cstl.nist.gov/nist839/839.04/