ASTM E1989-98(2004)
(Specification)Standard Specification for Laboratory Equipment Control Interface (LECIS) (Withdrawn 2009)
Standard Specification for Laboratory Equipment Control Interface (LECIS) (Withdrawn 2009)
ABSTRACT
This specification describes the Laboratory Equipment Control Interface Specification (LECIS). This is a set of standard equipment behaviors that must be accessible under remote control to set up and operate laboratory equipment in an automated laboratory. Discussed intensively herein are the equipment requirements, notations and general message syntaxes, control paradigms, message transactions, communication maintenance and locus of control, operational management, sample loading and processing, and error and exception handling.
SCOPE
1.1 This specification covers deterministic remote control of laboratory equipment in an automated laboratory. The labor-intensive process of integrating different equipment into an automated system is a primary problem in laboratory automation today. Hardware and software standards are needed to facilitate equipment integration thereby significantly reduce the cost and effort to develop fully automated laboratories.
1.2 This Laboratory Equipment Control Interface Specification (LECIS) describes a set of standard equipment behaviors that must be accessible under remote control to set up and operate laboratory equipment in an automated laboratory. The remote control of the standard behaviors is defined as standard interactions that define the dialogue between the equipment and the control system that is necessary to coordinate operation. The interactions are described with state models in which individual states are defined for specific, discrete equipment behaviors. The interactions are designed to be independent of both the equipment and its function. Standard message exchanges are defined independently of any specific physical communication links or protocols for messages passing between the control system and the equipment.
1.3 This specification is derived from the General Equipment Interface Definition developed by the Intelligent Systems and Robotics Center at Sandia National Laboratory, the National Institute of Standards Technologies' Consortium on Automated Analytical Laboratory Systems (CAALS) High-Level Communication Protocol, the CAALS Common Command Set, and the NISTIR 6294 (1-4). This LECIS specification was written, implemented, and tested by the Robotics and Automation Group at Los Alamos National Laboratory.
1.4 Equipment Requirements-LECIS defines the remote control from a Task Sequence Controller (TSC) of devices exhibiting standard behaviors of laboratory equipment that meet the NIST CAALS requirements for Standard Laboratory Modules (SLMs) (5). These requirements are described in detail in Refs (3, 4). The requirements are:
1.4.1 Predictable, deterministic behavior,
1.4.2 Ability to be remotely controlled through a standard bidirectional communication link and protocol,
1.4.3 Maintenance of remote communication even under local control,
1.4.4 Single point of logical control,
1.4.5 Universal unique identifier,
1.4.6 Status information available at all times,
1.4.7 Use of appropriate standards including the standard message exchange in this LECIS,
1.4.8 Autonomy in operation (asynchronous operation with the TSC),
1.4.9 Perturbation handling,
1.4.10 Resource management
1.4.11 Buffered inputs an outputs,
1.4.12 Automated access to material ports,
1.4.13 Exception monitoring and reporting,
1.4.14 Data exchange via robust protocol,
1.4.15 Fail-safe operation,
1.4.16 Programmable configurations (for example, I/O ports),
1.4.17 Independent power-up order, and
1.4.18 Safe start-up behavior.
WITHDRAWN RATIONALE
This specification covers deterministic remote control of laboratory equipment in an automated laboratory.
Formerly under the jurisdiction of Committee E13 on Molecular Spectroscopy and Chromatography, this specification was withdrawn in 2009. This standard was withdrawn without replacement because it has become obsolete to the industry and is not being used.
General Information
Relations
Standards Content (Sample)
NOTICE: This standard has either been superseded and replaced by a new version or withdrawn.
Contact ASTM International (www.astm.org) for the latest information.
Designation: E1989 – 98 (Reapproved 2004)
Standard Specification for
Laboratory Equipment Control Interface (LECIS)
This standard is issued under the fixed designation E1989; the number immediately following the designation indicates the year of
original adoption or, in the case of revision, the year of last revision. A number in parentheses indicates the year of last reapproval. A
superscript epsilon (´) indicates an editorial change since the last revision or reapproval.
1. Scope 1.4 Equipment Requirements—LECIS defines the remote
control from a Task Sequence Controller (TSC) of devices
1.1 Thisspecificationcoversdeterministicremotecontrolof
exhibiting standard behaviors of laboratory equipment that
laboratory equipment in an automated laboratory. The labor-
meet the NIST CAALS requirements for Standard Laboratory
intensive process of integrating different equipment into an
Modules (SLMs) (5). These requirements are described in
automated system is a primary problem in laboratory automa-
detail in Refs (3, 4). The requirements are:
tion today. Hardware and software standards are needed to
1.4.1 Predictable, deterministic behavior,
facilitate equipment integration and thereby significantly re-
1.4.2 Ability to be remotely controlled through a standard
duce the cost and effort to develop fully automated laborato-
bidirectional communication link and protocol,
ries.
1.4.3 Maintenance of remote communication even under
1.2 This Laboratory Equipment Control Interface Specifica-
local control,
tion (LECIS) describes a set of standard equipment behaviors
1.4.4 Single point of logical control,
that must be accessible under remote control to set up and
1.4.5 Universal unique identifier,
operate laboratory equipment in an automated laboratory. The
1.4.6 Status information available at all times,
remote control of the standard behaviors is defined as standard
1.4.7 Use of appropriate standards including the standard
interactions that define the dialogue between the equipment
message exchange in this LECIS,
and the control system that is necessary to coordinate opera-
1.4.8 Autonomy in operation (asynchronous operation with
tion. The interactions are described with state models in which
the TSC),
individual states are defined for specific, discrete equipment
1.4.9 Perturbation handling,
behaviors. The interactions are designed to be independent of
1.4.10 Resource management,
both the equipment and its function. Standard message ex-
1.4.11 Buffered inputs and outputs,
changes are defined independently of any specific physical
1.4.12 Automated access to material ports,
communication links or protocols for messages passing be-
1.4.13 Exception monitoring and reporting,
tween the control system and the equipment.
1.4.14 Data exchange via robust protocol,
1.3 This specification is derived from the General Equip-
1.4.15 Fail-safe operation,
ment Interface Definition developed by the Intelligent Systems
1.4.16 Programmable configurations (for example, I/O
and Robotics Center at Sandia National Laboratory, the Na-
ports),
tional Institute of Standards and Technologies’ Consortium on
1.4.17 Independent power-up order, and
Automated Analytical Laboratory Systems (CAALS) High-
1.4.18 Safe start-up behavior.
Level Communication Protocol, the CAALS Common Com-
mand Set, and the NISTIR 6294 (1-4). This LECIS specifi-
2. Terminology
cation was written, implemented, and tested by the Robotics
2.1 Definitions of Terms Specific to This Standard:
and Automation Group at Los Alamos National Laboratory.
2.1.1 command message—communication from the TSC to
the SLM that is being controlled. Receipt of this message
causes a state transition in an interaction.
This specification is under the jurisdiction of ASTM Committee E13 on
2.1.2 device capability dataset—data file that contains all of
Molecular Spectroscopy and Chromatography and is the direct responsibility of
the SLM-specific information required for the TSC to interact
Subcommittee E13.15 on Analytical Data.
Current edition approved April 1, 2004. Published May 2004. Originally
withtheSLM(2).Thisincludesdefinitionsoftheargumentsof
approved in 1998. Last previous edition approved in 1998 as E1989 - 98. DOI:
the standard commands and events, estimates of processing
10.1520/E1989-98R04.
2 times in states, and SLM specific interactions. Material input
The boldface numbers in parentheses refer to the list of references at the end of
this standard. and output ports and support services are also defined.
Copyright © ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959, United States.
E1989 – 98 (2004)
2.1.3 error—infrequent, unplanned event that makes the indicatethenatureofthemessage.Thesesymbolsareprovided
current goal of the SLM unachievable given the system as a guide to the reader; they are not part of the message
resources, the state of the system, or the absence of a definition.
guaranteed, alternative plan. (This definition is distinct from
Symbol Description
⇒ Command from the TSC
any other ASTM standard definition of error.)
⇐ Event from the SLM
2.1.4 event—changeintheoperationalstateoftheSLMthat
→ Event message acknowledgment from the TSC to the SLM
must be reported to the TSC. ← Command message acknowledgement from the SLM to the
TSC
2.1.5 event report—communication from the SLM to the
TSC indicating an event.
3.2 General Message Syntax—The messages in this speci-
2.1.6 exception—off-normal change in the operational state
fication are defined in Extended Backus Naur Form (EBNF)
of the SLM that prevents the goal from being achieved through
(6).Adescriptionofthesymbolsusedinthemessagedefinition
the normal sequence of state transitions in an interaction.
is provided in Table 1. The EBNF definition of all data types
Alternative sequences of state transitions in an interaction are
used with the message definitions is provided in Annex A1.
provided as part of the interaction definition in order to handle
The message definitions inAnnexA1 use aArial font to denote
an exception. Occurrence of an exception invokes an action
definitions in EBNF data types and bold Courier font to denote
thatissimplyanalternativeinthecourseofnormalprocessing.
the exactASCII string that is used in the message. Throughout
Itcausessuspensionofnormaloperationandinitiatesadefined
the text of this specification, EBNF data types appear in the
alternative operation. textfont.BoldfaceisusedtodenotetheexactASCIIstring.For
2.1.7 interaction—standard exchange of messages between
example, the EBNF
the TSC and SLM that synchronizes the execution of a series datatypeisdefinedtobetheREMOTE_CTRL_ACCEPTED
of standard SLM behaviors. State models are used to describe
string.
the standard interactions. 3.3 Although this specification defines commands and event
2.1.8 material—any input being processed by the SLM or reports in upper case characters, the TSC and SLM message
output produced by the SLM, including samples, consumables, handlers should treat messages as case-insensitive. For ex-
and data. ample, this specification defines the emergency stop command,
transmittedfromtheTSCtotheSLM,asESTOP.However,the
2.1.9 message—event or command that is passed between a
TSC and an SLM. messages “EStop,” “Estop,”“ estop,” or any other combination
of upper and lower case should be interpreted as ESTOP.
2.1.10 message transaction—synchronized exchange of a
message and its acknowledgment. There are two types of Message parameters, however, are case-sensitive.
message transactions: (1) Command transactions are initiated
4. Control Paradigm
by a command from theTSC to the SLM. (2) Event reports are
initiated by the SLM to the TSC. 4.1 Control Principle—Fig. 1 illustrates the laboratory au-
tomation control architecture to which this specification is
2.1.11 port—physical or logical location in the SLM that
designed (7). An SLM can only be controlled by one TSC at
accepts or provides material or data. Physical ports are used to
any given time. An SLM may not communicate directly with
transfer items such as samples and supplies. Logical or data
another SLM.TheTSC sends command messages to the SLM,
ports are used to transfer data to and from the SLM.
and the SLM sends event reports to the TSC. The communi-
2.1.12 port index—ports may have multiple internal loca-
cation channel between the TSC and SLM is logically separate
tions. These internal locations are tracked with the Port Index.
for each SLM but need not be physically separate. For
2.1.13 standard laboratory module (SLM)—laboratory
example, a TCP/IP network will allow multiple devices on a
equipment that satisfies the NIST CAALS physical and behav-
single physical link.Asingle logical link between the TSC and
ior requirements (5).
SLM is also not required in this specification. The (single or
2.1.14 state—standard logical configuration of the SLM for
multiple) physical links between the TSC and SLM can be
thepurposesofremotecontrolthatmaycorrespondtoalogical
multiplexed into multiple logical channels.
or hardware configuration or both. Specific behaviors and
4.2 Communication Requirements—The interface described
operations of the SLM are allowed in each state.
here is independent of the physical communication link and
2.1.15 statemodel—graphicalillustrationofthestatesinthe
message exchange protocol. However, the communication link
standard interactions. Transitions between states in the inter-
action, indicated by arrows, are initiated and tracked with
messages.
TABLE 1 EBNF Message Definition Symbols
2.1.16 task sequence controller (TSC)—software system
non-terminal string
::= is defined as
that orchestrates the execution of tasks (steps in sample
? choice of either field on each side
processing) by assigning them to the appropriate SLM and
[] optional one or none
coordinatingmaterialanddatamovementtoandfromtheSLM
{} 0 or more repetitions
y
{}x at least x, maximal y repetitions
selected for particular tasks.
(MSB) this field is most significant bit or byte in multi bit or byte
sequence
3. Notation and General Message Syntax BOLD terminal ASCII or hex symbol, in bold
Xx . yy terminal range from xx to yy
3.1 Notation—In the discussions of the messages between
9STRING9 literal insertion of string (without quotes)
the TSC and SLM, the following arrow symbols are used to
E1989 – 98 (2004)
FIG. 1 Simplified, Local Control Architecture
chosen shall meet the following requirements in order to be of this specification. Fig. 2 shows a breakdown of the interac-
compliant with this LECIS. tion classes and types.
4.2.1 The physical communication links must ensure accu-
4.3.3 There are two types of interactions—primary and
rate messaging by providing a low-level communication check
secondary. Primary interactions are permanently active and
of the accuracy of message transmission (parity checking,
there can only be one instance of each primary interaction
checksums, etc.).
active at any time. Secondary interactions, by contrast, are
4.2.2 The communication link cannot be blocked while the
created and terminated as needed. For example, an instance of
SLM performs a task. To prevent blocking, the SLM may
the Processing secondary interaction is created when the TSC
providechannelmultiplexingorseparatecommunicationlinks.
wants the SLM to perform an operation on an input material.
4.2.3 Both the TSC and SLM must periodically validate
The interaction instance is terminated once the operation is
communication integrity.
completed. There is no limit in this specification to the number
4.2.4 Messages from and to instruments must be uniquely
of instances of any secondary interaction that can be active
identifiable.
simultaneously. Note that creating multiple instances of a
4.3 Interaction:
secondary interaction is a way to implement command stack-
4.3.1 All communications between the TSC and an SLM in
ing. Table 2 lists the required primary and secondary interac-
an automated laboratory are modeled as interactions. These
tions.
interactions define the standard behaviors of SLMs and the
4.4 Interaction Identifier:
standard message exchange needed to control the behaviors.
4.4.1 The interaction identifier allows the TSC and SLM to
4.3.2 LECIS distinguishes between required and optional
identify a specific instance of an interaction. A session-unique
interactions and defines the required interactions. The required
interaction identifier is required since multiple instances of
interactions provide basic remote control functionality for any
type of laboratory equipment. SLMs shall implement the (secondary) interactions may exist simultaneously. The inter-
action identifier is attached to all command and event report
required interactions. Additional optional interactions can be
defined by the SLM manufacturer to provide remote control of messages. This enables the TSC and SLM to associate the
SLM-specific behaviors. These interactions are not the subject commands and event reports with the appropriate interaction
FIG. 2 Interaction Categories
E1989 – 98 (2004)
TABLE 2 Required Interactions TABLE 3 Harel State Chart Symbols
Type of Interaction Interaction State
Primary Local/Remote Control
Control Flow
Transition
Secondary Processing
Status
Lock/Unlock Default Entry Point
Abort
Alarm
Item Available Notification History Selector
Next Event
instance.TheinteractionidentifiergeneratedbyaspecificSLM
is only required to be unique for that SLM. history selector indicates that the system is to return to the
4.4.2 The interaction identifier is generated for the first substate that was active at the last transition out of the parent
message in the interaction. If the first message is a command, state. Transitions themselves are unidirectional, but separate
theTSC generates the interaction identifier. If the first message transitions can be used to toggle between states. Concurrent
is an event report, the SLM generates the interaction identifier. interactions are independent and, with two exceptions in this
Once created, the interaction identifier remains the same specification,donotdirectlycausetransitionsineachother,but
throughout the lifetime of the interaction instance and is used they do share common context. They can be thought of as
to label each additional message in that interaction. This weakly interacting subsystems. The use of concurrent states
specification does not place a requirement on how the interac- allows modularity of the model and greatly simplifies the
tionidentifierisgenerated.Anyuniqueintegeridentifiercanbe individual state models. All the interactions defined in this
used as an interaction identifier. We suggest that a unique specification may be active concurrently.The hier
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.