ASTM E1989-98
(Specification)Standard Specification for Laboratory Equipment Control Interface (LECIS)
Standard Specification for Laboratory Equipment Control Interface (LECIS)
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.
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: E 1989 – 98
Standard Specification for
Laboratory Equipment Control Interface (LECIS)
This standard is issued under the fixed designation E 1989; 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 (e) indicates an editorial change since the last revision or reapproval.
1. Scope Modules (SLMs) (5). These requirements are described in
detail in Refs (3, 4). The requirements are:
1.1 This specification covers deterministic remote control of
1.4.1 Predictable, deterministic behavior,
laboratory equipment in an automated laboratory. The labor-
1.4.2 Ability to be remotely controlled through a standard
intensive process of integrating different equipment into an
bidirectional communication link and protocol,
automated system is a primary problem in laboratory automa-
1.4.3 Maintenance of remote communication even under
tion today. Hardware and software standards are needed to
local control,
facilitate equipment integration and thereby significantly re-
1.4.4 Single point of logical control,
duce the cost and effort to develop fully automated laborato-
1.4.5 Universal unique identifier,
ries.
1.4.6 Status information available at all times,
1.2 This Laboratory Equipment Control Interface Specifica-
1.4.7 Use of appropriate standards including the standard
tion (LECIS) describes a set of standard equipment behaviors
message exchange in this LECIS,
that must be accessible under remote control to set up and
1.4.8 Autonomy in operation (asynchronous operation with
operate laboratory equipment in an automated laboratory. The
the TSC),
remote control of the standard behaviors is defined as standard
1.4.9 Perturbation handling,
interactions that define the dialogue between the equipment
1.4.10 Resource management,
and the control system that is necessary to coordinate opera-
1.4.11 Buffered inputs and outputs,
tion. The interactions are described with state models in which
1.4.12 Automated access to material ports,
individual states are defined for specific, discrete equipment
1.4.13 Exception monitoring and reporting,
behaviors. The interactions are designed to be independent of
1.4.14 Data exchange via robust protocol,
both the equipment and its function. Standard message ex-
1.4.15 Fail-safe operation,
changes are defined independently of any specific physical
1.4.16 Programmable configurations (for example, I/O
communication links or protocols for messages passing be-
ports),
tween the control system and the equipment.
1.4.17 Independent power-up order, and
1.3 This specification is derived from the General Equip-
1.4.18 Safe start-up behavior.
ment Interface Definition developed by the Intelligent Systems
and Robotics Center at Sandia National Laboratory, the Na-
2. Terminology
tional Institute of Standards and Technologies’ Consortium on
2.1 Definitions of Terms Specific to This Standard:
Automated Analytical Laboratory Systems (CAALS) High-
2.1.1 command message—communication from the TSC to
Level Communication Protocol, the CAALS Common Com-
2 the SLM that is being controlled. Receipt of this message
mand Set, and the NISTIR 6294 (1-4). This LECIS specifi-
causes a state transition in an interaction.
cation was written, implemented, and tested by the Robotics
2.1.2 device capability dataset—data file that contains all of
and Automation Group at Los Alamos National Laboratory.
the SLM-specific information required for the TSC to interact
1.4 Equipment Requirements—LECIS defines the remote
with the SLM (2). This includes definitions of the arguments of
control from a Task Sequence Controller (TSC) of devices
the standard commands and events, estimates of processing
exhibiting standard behaviors of laboratory equipment that
times in states, and SLM specific interactions. Material input
meet the NIST CAALS requirements for Standard Laboratory
and output ports and support services are also defined.
2.1.3 error—infrequent, unplanned event that makes the
This specification is under the jurisdiction of ASTM Committee E01 on current goal of the SLM unachievable given the system
Analytical Chemistry for Metals, Ores and Related Materials and is the direct
resources, the state of the system, or the absence of a
responsibility of Subcommittee E01.25 on Laboratory Data Interchange and
guaranteed, alternative plan. (This definition is distinct from
Information Management.
any other ASTM standard definition of error.)
Current edition approved Oct. 10, 1998. Published March 1999.
The boldface numbers in parentheses refer to the list of references at the end of
this standard.
Copyright © ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959, United States.
E1989–98
2.1.4 event—change in the operational state of the SLM that
→ Event message acknowledgment from the TSC to the SLM
← Command message acknowledgement from the SLM to the
must be reported to the TSC.
TSC
2.1.5 event report—communication from the SLM to the
3.2 General Message Syntax—The messages in this speci-
TSC indicating an event.
2.1.6 exception—off-normal change in the operational state fication are defined in Extended Backus Naur Form (EBNF)
(6). A description of the symbols used in the message definition
of the SLM that prevents the goal from being achieved through
the normal sequence of state transitions in an interaction. is provided in Table 1. The EBNF definition of all data types
used with the message definitions is provided in Annex A1.
Alternative sequences of state transitions in an interaction are
The message definitions in Annex A1 use a Arial font to denote
provided as part of the interaction definition in order to handle
definitions in EBNF data types and bold Courier font to denote
an exception. Occurrence of an exception invokes an action
the exact ASCII string that is used in the message. Throughout
that is simply an alternative in the course of normal processing.
the text of this specification, EBNF data types appear in the
It causes suspension of normal operation and initiates a defined
text font. Boldface is used to denote the exact ASCII string. For
alternative operation.
example, the EBNF
2.1.7 interaction—standard exchange of messages between
data type is defined to be the REMOTE_CTRL_ACCEPTED
the TSC and SLM that synchronizes the execution of a series
of standard SLM behaviors. State models are used to describe string.
3.3 Although this specification defines commands and event
the standard interactions.
2.1.8 material—any input being processed by the SLM or reports in upper case characters, the TSC and SLM message
handlers should treat messages as case-insensitive. For ex-
output produced by the SLM, including samples, consumables,
and data. ample, this specification defines the emergency stop command,
transmitted from the TSC to the SLM, as ESTOP. 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 the TSC to the SLM. (2) Event reports are
4.1 Control Principle—Fig. 1 illustrates the laboratory au-
initiated by the SLM to the TSC.
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. The TSC 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. A single 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
the purposes of remote control that may correspond to a logical
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 state model—graphical illustration of the states in the
message exchange protocol. However, the communication link
standard interactions. Transitions between states in the inter-
chosen shall meet the following requirements in order to be
action, indicated by arrows, are initiated and tracked with
compliant with this LECIS.
messages.
4.2.1 The physical communication links must ensure accu-
2.1.16 task sequence controller (TSC)—software system
rate messaging by providing a low-level communication check
that orchestrates the execution of tasks (steps in sample
of the accuracy of message transmission (parity checking,
processing) by assigning them to the appropriate SLM and
checksums, etc.).
coordinating material and data movement to and from the SLM
selected for particular tasks.
TABLE 1 EBNF Message Definition Symbols
non-terminal string
3. Notation and General Message Syntax
::= is defined as
3.1 Notation—In the discussions of the messages between
? choice of either field on each side
[] optional one or none
the TSC and SLM, the following arrow symbols are used to
{} 0 or more repetitions
indicate the nature of the message. These symbols are provided
y
{}x at least x, maximal y repetitions
as a guide to the reader; they are not part of the message
(MSB) this field is most significant bit or byte in multi bit or byte
sequence
definition.
BOLD terminal ASCII or hex symbol, in bold
Symbol Description
Xx . yy terminal range from xx to yy
⇒ Command from the TSC
9STRING9 literal insertion of string (without quotes)
⇐ Event from the SLM
E1989–98
FIG. 1 Simplified, Local Control Architecture
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
provide channel multiplexing or separate communication links. 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 (secondary) interactions may exist simultaneously. The inter-
type of laboratory equipment. SLMs shall implement the action identifier is attached to all command and event report
required interactions. Additional optional interactions can be messages. This enables the TSC and SLM to associate the
defined by the SLM manufacturer to provide remote control of commands and event reports with the appropriate interaction
SLM-specific behaviors. These interactions are not the subject instance. The interaction identifier generated by a specific SLM
of this specification. Fig. 2 shows a breakdown of the interac- is only required to be unique for that SLM.
tion classes and types. 4.4.2 The interaction identifier is generated for the first
4.3.3 There are two types of interactions—primary and message in the interaction. If the first message is a command,
secondary. Primary interactions are permanently active and the TSC generates the interaction identifier. If the first message
there can only be one instance of each primary interaction is an event report, the SLM generates the interaction identifier.
active at any time. Secondary interactions, by contrast, are Once created, the interaction identifier remains the same
FIG. 2 Interaction Categories
E1989–98
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
throughout the lifetime of the interaction instance and is used
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
tion identifier is generated. Any unique integer identifier can be 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 hierarchical state
interaction identifier be generated from a date and time model that represents the primary Control Flow interaction is
combination. For example, from August 10, 1996, 14:22:10.33 discussed in 7.2.
we could generate the following interaction identifier: 4.5.4 If an error occurs in the execution of a state transition
1996081014221033 (YYYYMMDDHHMMSSSS). Howeve
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.