Actually, all there is at OMG at the moment, is a requirements
document (a Request for Proposal).  There is no OMG LECIS standard
yet.  I do believe that Jim is correct in that at least one proposal
that will be submitted in response to this RFP will be heavily
influenced by work that has been done at NIST and WICIL.  This
needn't be the only proposal, however.  I also think that such a
proposal differs from Torsten's original intent.  Torsten?

Evan K. Wallace
Manufacturing Systems Integration Division
NIST
ewallace@...

Jim Redman wrote:
>John,
>
>I think that the OMG standard is closer to the NIST efforts than to the
>LECIS standard.  Almost by definition it is incompatible with existing
>LECIS standard and bears only a passing resemblance to it.
>
>Since this is the case, my goal is to avoid confusion and have the two
>standards named differently.
>
>Jim
>
>On 25 Jun, John Elling wrote:
>> I don't think LECIS is trademarked, but I'll check with ASTM.  The
>> standard document itself is certainly copywritten.  I hope that the
>> CORBA standard is directly mapped to the LECIS standard
>> or we will loose the benefit of any standardization!
>>
>> John Elling

John,

I think that the OMG standard is closer to the NIST efforts than to the
LECIS standard.  Almost by definition it is incompatible with existing
LECIS standard and bears only a passing resemblance to it.

Since this is the case, my goal is to avoid confusion and have the two
standards named differently.

Jim


On 25 Jun, John Elling wrote:
> I don't think LECIS is trademarked, but I'll check with ASTM.  The
> standard document itself is certainly copywritten.  I hope that the
> CORBA standard is directly mapped to the LECIS standard
> or we will loose the benefit of any standardization!
>
> John Elling
>
>
>
> At 05:37 PM 6/22/00 -0400, you wrote:
>
>>Jim Redman wrote:
>>
>> >I do strongly object to the use of the name "LECIS" for what is being
>> >created at OMG.  LECIS is a defined standard of ASTM (and I suspect is
>> >copyright to them).  What is being created is an object standard
>> >loosely based on the concepts of the ASTM standard.  It is not
>> >compliant with the standard and bears only a passing resemblance to it.
>> >It is a standard in its own right.  As such, it should have a name of
>> >its own, perhaps one that acknowledges the LECIS heritage, but one that
>> >does not allow confusion amongst the standards.
>>
>>This is a good point, given that this is an RFP and not an RFC.  This
>>means that the relationship between a response to this RFP and the ASTM
>>LECIS spec could be merely that they address a very similar set of
>>functionality.  Futhermore, it is common for OMG technologies developed
>>in response to an RFP, to carry a different moniker than the RFP itself.
>>
>>It's really up to the responders to the RFP to name their response.
>>However, if there is a legal issue, it could easily stop the adoption
>>of the response at any of a number of places (gates) in the approval
>>process such as the LSR DTF, the Architecture Board, or the Board of
>>Directors.
>>
>>-Evan
>>
>>Evan K. Wallace
>>Manufacturing Systems Integration Division
>>NIST
>>ewallace@...
>>
>>
>>


--

Jim Redman
(505) 662 5156
http://www.ergotech.com

I don't think LECIS is trademarked, but I'll check with ASTM.  The
standard document itself is certainly copywritten.  I hope that the
CORBA standard is directly mapped to the LECIS standard
or we will loose the benefit of any standardization!

John Elling



At 05:37 PM 6/22/00 -0400, you wrote:

>Jim Redman wrote:
>
> >I do strongly object to the use of the name "LECIS" for what is being
> >created at OMG.  LECIS is a defined standard of ASTM (and I suspect is
> >copyright to them).  What is being created is an object standard
> >loosely based on the concepts of the ASTM standard.  It is not
> >compliant with the standard and bears only a passing resemblance to it.
> >It is a standard in its own right.  As such, it should have a name of
> >its own, perhaps one that acknowledges the LECIS heritage, but one that
> >does not allow confusion amongst the standards.
>
>This is a good point, given that this is an RFP and not an RFC.  This
>means that the relationship between a response to this RFP and the ASTM
>LECIS spec could be merely that they address a very similar set of
>functionality.  Futhermore, it is common for OMG technologies developed
>in response to an RFP, to carry a different moniker than the RFP itself.
>
>It's really up to the responders to the RFP to name their response.
>However, if there is a legal issue, it could easily stop the adoption
>of the response at any of a number of places (gates) in the approval
>process such as the LSR DTF, the Architecture Board, or the Board of
>Directors.
>
>-Evan
>
>Evan K. Wallace
>Manufacturing Systems Integration Division
>NIST
>ewallace@...
>
>
>
>
>
>
>------------------------------------------------------------------------
>Start Saving On Long Distance Calls Today! Click Here!
>http://click.egroups.com/1/5058/3/_/911067/_/961710941/
>------------------------------------------------------------------------
>
>To view archived messages, go to:
>http://www.onelist.com/messages/lecis-post

Jim Redman wrote:

>I do strongly object to the use of the name "LECIS" for what is being
>created at OMG.  LECIS is a defined standard of ASTM (and I suspect is
>copyright to them).  What is being created is an object standard
>loosely based on the concepts of the ASTM standard.  It is not
>compliant with the standard and bears only a passing resemblance to it.
>It is a standard in its own right.  As such, it should have a name of
>its own, perhaps one that acknowledges the LECIS heritage, but one that
>does not allow confusion amongst the standards.

This is a good point, given that this is an RFP and not an RFC.  This
means that the relationship between a response to this RFP and the ASTM
LECIS spec could be merely that they address a very similar set of
functionality.  Futhermore, it is common for OMG technologies developed
in response to an RFP, to carry a different moniker than the RFP itself.

It's really up to the responders to the RFP to name their response.
However, if there is a legal issue, it could easily stop the adoption
of the response at any of a number of places (gates) in the approval
process such as the LSR DTF, the Architecture Board, or the Board of
Directors.

-Evan

Evan K. Wallace
Manufacturing Systems Integration Division
NIST
ewallace@...

Torsten et al.

I think that the effort to standardize an object interface for
equipment control is a good one and that the work underway at OMG is
valuable.

I do strongly object to the use of the name "LECIS" for what is being
created at OMG.  LECIS is a defined standard of ASTM (and I suspect is
copyright to them).  What is being created is an object standard
loosely based on the concepts of the ASTM standard.  It is not
compliant with the standard and bears only a passing resemblance to it.
It is a standard in its own right.  As such, it should have a name of
its own, perhaps one that acknowledges the LECIS heritage, but one that
does not allow confusion amongst the standards.

In the long run, removing this ambiguity will be advantageous to both
standards.  I think that now, while the standard is still in the RFP
stage is the time for OMG to make that change.

Jim

On 20 Jun, Torsten Staab wrote:
> Hello all,
>
>     I just would like to let you know that the OMG (Object Management
> Group, www.omg.org) issued the LECIS RFP (Request for Proposal) at their
> technical meeting in Oslo, Norway, last week! I highly encourage you to
> read over the LECIS RFP document. This document defines the mandatory and
> optional requirements for future instrument control interfaces. The
> download information is attached.
>
>>Hello all,
>>
>>
>>the LECIS RFP has been posted to the OMG server and is now available from URL
>>http://www.omg.org/techprocess/meetings/schedule/LECIS_RFP.html
>>
>>Thanks,
>>
>>
>>
>>-Juergen
>>================================================================
>>
>>Juergen Boldt
>>Senior Member of Technical Staff
>>
>>Object Management Group         Tel. +1-781 444 0404  ext. 132
>>250 First Avenue, Suite 201             Fax: +1-781 444 0320
>>Needham, MA 02494, USA          Email: juergen@...
>>
>>================================================================

--

Jim Redman
(505) 662 5156
http://www.ergotech.com

-----Original Message-----
From: Torsten Staab [mailto:tstaab@...]
Sent: Monday, June 19, 2000 11:30 PM
To: lecis-post@egroups.com
Subject: [lecis-post] 6-19-00: official OMG LECIS RFP now available!

Hello all,

   I just would like to let you know that the OMG (Object Management Group, www.omg.org) issued the LECIS RFP (Request for Proposal) at their technical meeting in Oslo, Norway, last week! I highly encourage you to read over the LECIS RFP document. This document defines the mandatory and optional requirements for future instrument control interfaces. The download information is attached.

Hello all,


the LECIS RFP has been posted to the OMG server and is now available from URL
http://www.omg.org/techprocess/meetings/schedule/LECIS_RFP.html

Thanks,



-Juergen
================================================================

Juergen Boldt
Senior Member of Technical Staff

Object Management Group         Tel. +1-781 444 0404  ext. 132
250 First Avenue, Suite 201             Fax: +1-781 444 0320
Needham, MA 02494, USA          Email: juergen@...

================================================================

I would like to take this opportunity to thank Thorsten Richter (formerly WICIL, now Creon Software) and the members of the OMG Life Science Research Domain Task Force (LSR DTF) for making it happen last week in Oslo. Although we have reached a very important first milestone last week, the real work still lies ahead of us. We now need to define CORBA IDL (Interface Definition Language) code that meets the requirements outlined by the LECIS RFP document. The OMG expects initial IDL submissions (either joint or individual) by November 20, 2000. Companies that intent to provide a commercial implementation of the new CORBA LECIS technology should submit an LOI (Letter of Intent) by September 22, 2000. Please keep in mind that the OMG cannot consider submissions that are not accompanied by at least one LOI (to ensure that the new standard will be implemented and commercially available within 12 months of adoption). For more information on the OMG Technology Processes visit http://www.omg.org/techprocess/faq_process.html

By the way, there is still time for you to get involved in the CORBA LECIS standardization. Please drop me a note at tstaab@... if you would like to have more information on how to participate in this OMG/ISO standardization process.

Have a nice day,
Torsten Staab

---

---

To view archived messages, go to:
http://www.onelist.com/messages/lecis-post

Hello all,

FYI, the NEWS, UPCOMING EVENTS, and CURRENT DEVELOPMENTS sections on the
LECIS website (www.lecis.org) have been updated on June 20, 2000.

Torsten

Hello all,


the LECIS RFP has been posted to the OMG server and is now available from URL
http://www.omg.org/techprocess/meetings/schedule/LECIS_RFP.html

Thanks,



-Juergen
================================================================

Juergen Boldt
Senior Member of Technical Staff

Object Management Group         Tel. +1-781 444 0404  ext. 132
250 First Avenue, Suite 201             Fax: +1-781 444 0320
Needham, MA 02494, USA          Email: juergen@...

================================================================

FYI.

>Date: Mon, 22 May 2000 17:37:55 -0400
>To: lifesciences@..., mfg@...,
>         corbamed@...
>From: Juergen Boldt <juergen@...>
>Subject: LECIS RFP available
>Mime-Version: 1.0
>Content-Type: text/plain; charset="us-ascii"; format=flowed
>
>Hello all,
>
>the UPDATED LECIS RFP (draft) has been posted to the OMG server with the
>document number lifesci/2000-05-05
>at URL
>http://www.omg.org/cgi-bin/doc?lifesci/2000-05-05
>
>Best Regards
>
>-Juergen
>================================================================
>
>Juergen Boldt
>Senior Member of Technical Staff
>
>Object Management Group         Tel. +1-781 444 0404  ext. 132
>250 First Avenue, Suite 201             Fax: +1-781 444 0320
>Needham, MA 02494, USA          Email: juergen@...
>
>================================================================

Something for device manufacturers and integrators:

The Embedded Linux Expo & Conference (ELEC).
http://www.rtcgroup.com/elinuxexpo/index2.html

From the website:
ELEC is directed towards engineers, project managers, and design teams that
are developing a broad range of embedded systems incorporating the Linux
operating system and related technologies. Typical applications span the
gamut from moderate to high performance fixed and mobile computing needs,
and include: smart appliances, gaming, set-top boxes, medical equipment,
defense/aerospace systems, industrial control/automation, transportation
systems, instrumentation, and data acquisition.


In this environment it should be possible to implement embedded CORBA
systems for device interfacing.
The growing market of web appliances will open the door for many new
developments that can be used also for our purposes.

Regards,
Thorsten :)

Following last weeks discussion I would like to suggest a device CORBA
interface (in attachment).

This proposal, and all other proposals from the WICIL development group,
apply only to the next generation CORBA device interface standard. In June,
a Request for Proposal (RFP)for this Standard is made at the OMG meeting in
Oslo.

The proposed device interface consists of five different CORBA interfaces,
catagorized after functionality.

It is a requirement to have a multithreaded CORBA server implementation,
because the controller can call control functions in IInteractionManager, or
make status requests while the device is busy with a measuremnt.

Remark: None of the Interfaces contains a RunOp() function. CORBA allows to
make dynamic requests over the Dynamic Invocation Interface (DII). That
makes the old RunOp() function pointless. Device manufacturers could
implement all interfaces as they like, except the exactly specified
IInteractionManager.The controller gets the interface information from the
CORBA Interface Repository or the SCD.

The attached file is in PDF Format.

Regards,
Thorsten Richter

On  3 May, To: lecis-post@egroups.com wrote:
> Here are some quick thoughts and ideas.
>
> On  3 May, Thorsten Richter wrote:
>> Security is an important feature of a modern system architecture.
>
> Security can mean many things.  Device access is probably best
> delegated to the middleware component.  However, there is also the
> issue of who can run which RUN_OP, and that may be better at the
> instrument level.  For example, it may take one level of technician to
> run samples, and another to calibrate, correct errors, etc.  This might
> be best defined at the DCS level.
                     ^^^^ DCD ^^^^

  (typo, sorry for the confusion)

Jim


--

Jim Redman
(505) 662 5156
http://www.ergotech.com

Here are some quick thoughts and ideas.

On  3 May, Thorsten Richter wrote:
> Security is an important feature of a modern system architecture.

Security can mean many things.  Device access is probably best
delegated to the middleware component.  However, there is also the
issue of who can run which RUN_OP, and that may be better at the
instrument level.  For example, it may take one level of technician to
run samples, and another to calibrate, correct errors, etc.  This might
be best defined at the DCS level.

>
> 2. Support for multipart messages
>
> In our understanding a device could send its measurement results in several
> parts. We would need a sequence counter and an Endflag in the data event
> structure of the device.
>

I don't think that this needs to be part of the spec.  It should either
be in the communications layer (for example you may want to limit
packet size on some protocols), and/or a function of the instrument.

>
> 3.The current TSC ID.
>
> The current TSC-ID is something we were already discussing for some time. In
> our system architecture more than one TSC can use a device. In the normal
> control flow only one TSC is controlling it, but under certain circumstances
> other system modules can call device funtions as well. It would be a problem
> to grant only one TSC access. On the other hand it is a problem if everyone
> can use it at the same time.
> There is probably no final solution. The security policy could determine the
> clients who have access to the device. To avoid access collisions , the
> system architecture would need some intelligent control flow handling.
>

This is a problem that is larger the pharmaceuticals.  One thing about
LECIS is that it is impossible to have two TSCs and change state, you
cannot do it without violating the spec.  There are no good solutions
from other industries, and it is, in part a security issue.  In
the semiconductor SECS protocol, it is, in principle, possible to have
a connection that is allows to "control" and others that have limited
message sets and only collect data.  You could (possibly) do this in
LECIS, but not conveniently.  That is, you could have one connection
that runs RUN_OPS and a number of connections that just receive the
events.  More likely, you would resort to the less than optimal
solution used in Semicon, snooping the entire conversation.  You can do
some fun things with this approach (see
http://www.secsandgem.com/orgi.html), but it would be good to have some
support for these concepts in the specification.

Jim

--

Jim Redman
(505) 662 5156
http://www.ergotech.com

This is a posting from the WICIL development group at the University of
Applied Sciences in Wiesbaden, Germany.

We comment last weeks posting from Greg Bobrowski.

1. Greg proposed a few security mechanisms :

>  - user authentication
>  - multiple levels of user permissions
> 	 - remote operator
> 	 - remote reconfiguration
> 	 - remote observation
> 	 - authorized observation
>
>  - multiple levels of maintenance permissions
> 	 - software updates
> 	 - permission allocation (creating users)
> 	 - read only
> 	 - edit
> 	 - minimal TSC permission
> 	 - current TSC permission when under control
> All data exchange should happen transparently to the user via trusted
>transport.

Security is an important feature of a modern system architecture. Future
labs could be managed from a control center somewhere in the network. In
addition a lab could be part of a bigger network (even a WAN). That makes it
neccessary to implement some kind of security policy.
But it does not only concern the instruments, but the rest of the
controlling architecture as well. Therefore the security policy should be
part of the system, and not part of the device control interface.

The question is: How do you enforce a security policy without implement one
in the device?

One possible solution : The CORBA Security Service. It provides a complete
security model for CORBA. This is one of the advantages of implementing the
device interface in CORBA. You get solutions for certain problems from the
shelf.

I quote the CORBA Security Spec:
"Applications will often not be aware of security at all, but will still be
subject to security policy, as the ORB will enforce the policies for them.
Security
policy is enforced automatically by the ORB both when an object invokes
another and
when it creates another object."

For detailed information:  CORBA Services Specification,
http://www.omg.org/library/csindx.html

One thing you need is an administration tool, that defines the security
policies in the system. But this can be provided by the ORB vendor or from
another software company that is providing the controlling architecture.


2. Support for multipart messages

In our understanding a device could send its measurement results in several
parts. We would need a sequence counter and an Endflag in the data event
structure of the device.


3.The current TSC ID.

The current TSC-ID is something we were already discussing for some time. In
our system architecture more than one TSC can use a device. In the normal
control flow only one TSC is controlling it, but under certain circumstances
other system modules can call device funtions as well. It would be a problem
to grant only one TSC access. On the other hand it is a problem if everyone
can use it at the same time.
There is probably no final solution. The security policy could determine the
clients who have access to the device. To avoid access collisions , the
system architecture would need some intelligent control flow handling.


Regards
Thorsten :)

I think that the answer is simple, stupidity on my part.

I shouldn't go web surfing, when I'm thinking about just leaving the
office.  I shouldn't send e-mail either, I never intended to write that
message to the list.

My apologies to Torsten and to the list for wasted bandwidth.

Jim

On 29 Apr, Torsten Staab wrote:
>
> Jim Redman wrote:
>>>Torsten,
>>>
>>>I think that Pfizer have published their "LECIS Implementers Guide"
>>>which is  LECIS over sockets.  I can't find it on the website.  Can you
>>>please put it in the "Downloads" section.
>>>
>>>Thanks,
>>>
>>>Jim
>
> I don't know why you can't find Pfizer's LECIS TCP/IP Implementers Guide on
> the LECIS web site. It has been in the Download section at www.lecis.org
> for months. The entry looks like this:
>
> LECIS TCP/IP Implementers Guide 2.01
> Pfizer's LECIS TCP/IP Implementers Guide version 2.01 is now available for
> download.
> Download Formats:
> Word97/2000 [215KB]
> PDF [100KB]
>
> Please let me know if you can't find it.
>
> Torsten
--

Jim Redman
(505) 662 5156
http://www.ergotech.com

Torsten,

I think that Pfizer have published their "LECIS Implementers Guide"
which is  LECIS over sockets.  I can't find it on the website.  Can you
please put it in the "Downloads" section.

Thanks,

Jim

--

Jim Redman
(505) 662 5156
http://www.ergotech.com

I think that some of Greg's proposals would also be helpful responses
to some of Thorsten issues posted to the list a while ago.

In LECIS it would be desirable to allow connection that cannot, for
example, change the state of a primary interaction, or can run certain
RUN OPs, but not all.

It would also be desirable to have "listening" connections that can
register to see the transactions, but not perform any.  For example, if
the TSC is running through commands, it may be useful to display the
output (on a webpage, of course) at a remote location.  The system could
be started and left running, and the technician could monitor from
outside the lab, even across the net, without the danger of interfering
with the process.

As an aside, this is a serious problem in semiconductor.  The analogous
protocol SECS does not officially permit "listening" connections.  You
can create "unofficial" solutions, such as our ORGi product
http://www.secsandgem.com/orgi.html, but it would be better to have
this defined as part of the specification.


Jim

On 26 Apr, Torsten Staab wrote:
> Hello,
>
>    I've attached some comments from Greg Bobrowski [CIMTEK Automation
> Systems] on the new OMG (Object Management Group) LECIS CORBA RFP
> (Request for Proposal). FYI, go to www.lecis.org. for more info on
> how to download the RFP document.  The NEWS section on the LECIS web
> page contains a link to the RFP document.
>
> Greg Bobrowski wrote on 4/26/00:
> ----------
> Hello all:
>
> Current draft already mentions that it is required to comment on
> distributed
> environment operation.
>
> However, I think it is important to encourage the submitters to take
> stand
> on this issues much stronger.
>
> Namely, I would like to bring to your attention the possibility of
> inclusion
> of the following functionalities:
>
> 1.  - user authentication
> 	 - multiple levels of user permissions
> 		 - remote operator
> 		 - remote reconfiguration
> 		 - remote observation
> 		 - authorized observation
>
> 	 - multiple levels of maintenance permissions
> 		 - software updates
> 		 - permission allocation (creating users)
> 		 - read only
> 		 - edit
>
> 2. Support for multipart messages
>
> 3. Distinction between commands and routine  (schedule)) downloads
>
> 4. Support for network-architecture-ignorant-multi-controller
> scenarios.
>  Namely Instrument may be obliged to reserve a space (may be a
> part
> of status) for info like:
> 		 - minimal TSC permission
> 		 - current TSC permission when under control
> 		 - current TSC ID.
> 5. Support for external private services:
>    What I mean here is a reference to the following scenario
> contemplated
> during my work for Zellweger Uster,
>    a manufacturer of laboratory equipment for textile industry:
> Certain
> methods of evaluating of acquired data
>   may be an object of on-going patent registration,  a commercial
> secret, or
> just too complex for average
>   instrument to compute. Manufacturer may desire to repetitively
> upload
> acquired vectors for evaluation on
>  dedicated mainframe and   repetitively  download the results for
> display on
> instrument's CRT or printer.
>  All data exchange should happen transparently to the user via trusted
> transport.
>  LECIS could provide for such a special channel of access. This is
> not going
> via TSC. This is instrument
> being distributed itself and TSC eventually dealing with all parts of
> it.
>
> Additionally, I suggest that submitters should make clear references
> to OSI
> model even if their proposal
> covers (most likely) only part of layer (7).
>
> Details I mention may be too specific to place in a RFP but I hope
> you will
> find that this direction of thinking
> is converging with your vision and may be worth considering by the
> community.
>
> I would appreciate your comments even if you decide not to use any
> part of
> my comments in RFP.
>
> With kind regards,
>
> Greg Bobrowski
> Software Integrator
> Phone:   (905)331-6338x275
> Fax:       (905)331-6339
> Internet: gbobrowski@...
>
> Computer Integrated Manufacturing Technologies
> CIMTEK Automation Systems
> 5328 John Lucas Drive
> Burlington, Ontario
> Canada L7L 6A6


--

Jim Redman
(505) 662 5156
http://www.ergotech.com

Hello,

    I've attached some comments from Greg Bobrowski [CIMTEK Automation
Systems] on the new OMG (Object Management Group) LECIS CORBA RFP
(Request for Proposal). FYI, go to www.lecis.org. for more info on
how to download the RFP document.  The NEWS section on the LECIS web
page contains a link to the RFP document.

Greg Bobrowski wrote on 4/26/00:
----------
Hello all:

Current draft already mentions that it is required to comment on
distributed
environment operation.

However, I think it is important to encourage the submitters to take
stand
on this issues much stronger.

Namely, I would like to bring to your attention the possibility of
inclusion
of the following functionalities:

1.  - user authentication
		 - multiple levels of user permissions
			 - remote operator
			 - remote reconfiguration
			 - remote observation
			 - authorized observation

		 - multiple levels of maintenance permissions
			 - software updates
			 - permission allocation (creating users)
			 - read only
			 - edit

2. Support for multipart messages

3. Distinction between commands and routine  (schedule)) downloads

4. Support for network-architecture-ignorant-multi-controller
scenarios.
	 Namely Instrument may be obliged to reserve a space (may be a
part
of status) for info like:
			 - minimal TSC permission
			 - current TSC permission when under control
			 - current TSC ID.
5. Support for external private services:
    What I mean here is a reference to the following scenario
contemplated
during my work for Zellweger Uster,
    a manufacturer of laboratory equipment for textile industry:
Certain
methods of evaluating of acquired data
   may be an object of on-going patent registration,  a commercial
secret, or
just too complex for average
   instrument to compute. Manufacturer may desire to repetitively
upload
acquired vectors for evaluation on
  dedicated mainframe and   repetitively  download the results for
display on
instrument's CRT or printer.
  All data exchange should happen transparently to the user via trusted
transport.
  LECIS could provide for such a special channel of access. This is
not going
via TSC. This is instrument
being distributed itself and TSC eventually dealing with all parts of
it.

Additionally, I suggest that submitters should make clear references
to OSI
model even if their proposal
covers (most likely) only part of layer (7).

Details I mention may be too specific to place in a RFP but I hope
you will
find that this direction of thinking
is converging with your vision and may be worth considering by the
community.

I would appreciate your comments even if you decide not to use any
part of
my comments in RFP.

With kind regards,

Greg Bobrowski
Software Integrator
Phone:   (905)331-6338x275
Fax:       (905)331-6339
Internet: gbobrowski@...

Computer Integrated Manufacturing Technologies
CIMTEK Automation Systems
5328 John Lucas Drive
Burlington, Ontario
Canada L7L 6A6

From: Bob Leif, Ph.D.
To: Torseten Staab, Ph.D. et al.

There already exists an instrument markup language. It would make sense to
express Lecis in this syntax.

Please visit
AML (Astronomical Markup Language) Page
http://monet.astro.uiuc.edu/~dguillau/these/

AML, "Astronomical Markup Language", is an XML language, aimed at being a
standard exchange format for metadata in astronomy. AML now supports the
following objects (in the object-oriented sense): astronomical object,
article, table, set of tables, image, person, and project. This means that
all these objects can be described with the same language, allowing easier
establishing of links between them, and the creation of programs handling
all these objects with the same user interface.

Astronomical Instrument Markup Language
http://pioneer.gsfc.nasa.gov/public/aiml/
AIML is an instrument description that encompasses instrument
characteristics, control commands, data stream descriptions (including image
and housekeeping data), message formats, communication mechanisms, and
pipeline algorithm descriptions. AIML also supports role-specific
documentation and GUI component generation. Dialects such as PAML (Pipeline
Algorithm ML) and IGS (Instrument GUI Stylesheet [XSL]) will be added in the
near future.

-----Original Message-----
From: Torsten Staab [mailto:tstaab@...]
Sent: Friday, April 21, 2000 2:06 PM
To: lecis-post@egroups.com
Subject: [lecis-post] OMG's LECIS RFP draft available


Hello all,

    I would like to let you know that the OMG (Object Management
Group, www.omg.org) just posted the first LECIS CORBA RFP (Request
for Proposal) on their web site. The draft is now available for
download in a number of different formats at the following URL:

http://www.omg.org/cgi-bin/doc?lifesci/2000-04-02

I would like to take this opportunity to thank the WICIL team from
the University of Applied Sciences (FHW), Germany, and ReTiSoft,
Canada, for their valuable contributions to the LECIS RFP draft.

Please note that the LECIS RFP is still a draft, which means that YOU
can still contribute! The OMG Life Sciences Research Domain Taskforce
is planning on issuing this RFP at their next technical meeting in
Oslo, Norway (June 12-16, 2000). Therefore, the final RFP document
must be on the OMG server by May 22, 2000. So please send your RFP
comments to tstaab@... no later than May 15. Thanks.

Have a nice weekend,
Torsten Staab


------------------------------------------------------------------------
GET WHO WANTS TO BE A MILLIONAIRE FREE!  GET THE OFFICIAL COMPANION
TO TELEVISION'S HOTTEST GAME SHOW PHENOMENON PLUS 5 MORE BOOKS FOR
$2.  Click for details.
http://click.egroups.com/1/3014/2/_/911067/_/956351184/
------------------------------------------------------------------------

To view archived messages, go to:
http://www.onelist.com/messages/lecis-post

Hello all,

    I would like to let you know that the OMG (Object Management
Group, www.omg.org) just posted the first LECIS CORBA RFP (Request
for Proposal) on their web site. The draft is now available for
download in a number of different formats at the following URL:

http://www.omg.org/cgi-bin/doc?lifesci/2000-04-02

I would like to take this opportunity to thank the WICIL team from
the University of Applied Sciences (FHW), Germany, and ReTiSoft,
Canada, for their valuable contributions to the LECIS RFP draft.

Please note that the LECIS RFP is still a draft, which means that YOU
can still contribute! The OMG Life Sciences Research Domain Taskforce
is planning on issuing this RFP at their next technical meeting in
Oslo, Norway (June 12-16, 2000). Therefore, the final RFP document
must be on the OMG server by May 22, 2000. So please send your RFP
comments to tstaab@... no later than May 15. Thanks.

Have a nice weekend,
Torsten Staab

The administrators of the LECIS.ORG web site are in the process of moving the
domain to a different web host. This is already underway. There should not be
any interruption in service, but the DNS switch process is out of our hands at
the moment.

LECIS.ORG Webmaster

Hello all,

     I just wanted to let you know that the LECIS web site has been updated
slightly. There is now a 30 second long RealVideo clip of the Twister LECIS
CORBA prototype system available. The LECIS Special Interest Group (SIG)
member list has been updated as well.

I would like to encourage you to contribute to the LECIS web site's current
development section. I know from a couple of people that they are working
on LECIS-related automation projects and commercial implementations. It
would be nice if those people could share some of their plans or ideas with
the LECIS community. LECIS-related product announcements are also very
welcome. That's free advertisement for your organization! So please make
use of it. You can e-mail your text and images to tstaab@.... I'll
then post them on the LECIS web site. Thanks.

Torsten Staab
LECIS Web Administrator

From: Bob Leif
Newport Instruments

To: Tim Sherrill et al.

CORBA IDL is a good choice except for the possibility of true dual
inheritance, which should be avoided. It should be noted, that although IDL
is syntactically related to the C family of languages, IDL semantics are
similar to an Ada specification. In fact, if you want a fast real-time ORB,
you might consider Objective Interface Systems   http://www.ois.com

"Objective Interface provides software developers tools for building
reliable, mission-critical systems.  These tools include CORBA compliant
Object Request Brokers, training and support to implement software systems
in a cost-effective and reliable manner.  Our primary focus and expertise is
high performance solutions for real-time and/or embedded applications."

-----Original Message-----
From: Tim Sherrill [mailto:Tim.Sherrill@...]
Sent: Wednesday, April 05, 2000 8:58 AM
To: lecis-post@egroups.com
Subject: [lecis-post] Re: LECIS CORBA/DCOM


The trend is definitely towards component-based development.  This movement
is analogous to inter-changeable parts for mechanical manufacturing.  The
programming interface to components should be similar (IDL specifies what
this will look like--it stands for Interface Definition Language where
interface means a programming interface) and both COM and CORBA use a nearly
identical IDL, so a standard specifying the IDL makes a lot of sense.  All
of this makes writing client programs which use a device much simpler and
quicker--the client shouldn't have to know about the communications protocol
going back and forth to the device, just how to get it to do its work and
report errors when they occur.

At SAGIAN, we'd prefer to spend our time on improving ease-of-use and
throughput of our systems and feel that messing with all the different
device protocols not a value-added task.  On the other hand, when we have a
COM control such as the Wallac VICTOR, integration is quick, and we're able
to offer more of the device's capability for the same development effort.
By going through the COM control, Wallac retains control of configuration of
the instrument and they do a much better job of that than an integrator
would.

Aside (for illustration/persuasion): Wallac provides 2 important COM
controls--an instrument control and a 'browser' tree-control which shows the
protocols in the database.  SAGIAN device modules are separated into two
independent halves (although they're in the same process): configuration and
run-time control.  The browser makes configuration easy, we 'host' the
control on our form, and the user clicks on the protocol.  The module
doesn't need to know anything more than the ID of the protocol (which the
module gets from the browser whenever the user clicks on a protocol) so it
can be passed to the run-time portion appropriately.  The run-time part just
needs to VICTOR.LoadServer and VICTOR.StartAssay(id) to start a read.  The
module doesn't need to worry about database access to enumerate the
protocols and ID's or learn ARCNET and send packets back and forth to the
instrument.  I could write a fairly complete module to integrate the VICTOR
in less than an hour.

If device manufacturers can be trusted to write software which adequately
controls their instrument (I know, quit laughing--we make this assumption
whenever discussing a standard, though), then the appropriate division of
labor is to have integrators working at a much higher level than currently
happens, and I think that separation should be made at the component level
and specified in IDL.  (My bias as an integrator is showing, I realize,
standardizing lower-level interactions would be helpful for others.)

To argue the other side for a moment, IDL/COM/CORBA are strong standards in
themselves.  Standardizing the (programming) interfaces specified in these
technologies as well may be overkill, however, if successful, I agree that
it's a good thing.  At the very least, it raises issues that would be
overlooked by an inexperienced development team and provides a road map for
good component development for device manufacturers.

Tim Sherrill
Beckman Coulter, Inc. -- SAGIAN


------------------------------------------------------------------------
Special Offer-Earn 300 Points from MyPoints.com for trying @Backup
Get automatic protection and access to your important computer files.
Install today:
http://click.egroups.com/1/2344/2/_/_/_/954950880/
------------------------------------------------------------------------

To view archived messages, go to:
http://www.onelist.com/messages/lecis-post

-----Original Message-----
From: Torsten Staab [mailto:tstaab@...]
Sent: Wednesday, April 05, 2000 12:05 PM
To: lecis-post@egroups.com
Subject: [lecis-post] Is LECIS CORBA/DCOM standardization really overkill?

At 10:57 AM 4/5/2000 -0500, Tim Sherrill [Sagian] wrote:

...To argue the other side for a moment, IDL/COM/CORBA are strong standards in
themselves.  Standardizing the (programming) interfaces specified in these
technologies as well may be overkill, however, if successful, I agree that
it's a good thing.

I agree with Tim to a certain degree. CORBA and COM are strong standards that allow you to do pretty much anything you want with respect to object-oriented, distributed computing. However, I think that you really need to provide a standard IDL in order to get to real plug-and-play. Having the operator manually choose "introspected" methods and protocols (although this may be a one-time operation) should not be necessary. Without a standardized (IDL) interface you'll get a lot of ambiguity problems. This also limits your software reusability.

Let me give you a simple example. The COM or CORBA control object of instrument A may provide a method that is called HALT for pausing operations temporarily. On instrument B, the equivalent method may be called PAUSE. So the controller would need to know that HALT on instrument A and PAUSE on instrument B are basically equivalent. This device-specific knowledge would need to be added to your system/controller. If, however, there would be a standard method called PAUSE that every device would support, then there wouldn't be a need for method association/mapping. This would simplify the system development and integration. It also allows you to integrate new instruments on-the-fly without user interaction.

Torsten Staab [Los Alamos National Laboratory]

...To argue the other side for a moment, IDL/COM/CORBA are strong standards in
themselves.  Standardizing the (programming) interfaces specified in these
technologies as well may be overkill, however, if successful, I agree that
it's a good thing.

The trend is definitely towards component-based development.  This movement
is analogous to inter-changeable parts for mechanical manufacturing.  The
programming interface to components should be similar (IDL specifies what
this will look like--it stands for Interface Definition Language where
interface means a programming interface) and both COM and CORBA use a nearly
identical IDL, so a standard specifying the IDL makes a lot of sense.  All
of this makes writing client programs which use a device much simpler and
quicker--the client shouldn't have to know about the communications protocol
going back and forth to the device, just how to get it to do its work and
report errors when they occur.

At SAGIAN, we'd prefer to spend our time on improving ease-of-use and
throughput of our systems and feel that messing with all the different
device protocols not a value-added task.  On the other hand, when we have a
COM control such as the Wallac VICTOR, integration is quick, and we're able
to offer more of the device's capability for the same development effort.
By going through the COM control, Wallac retains control of configuration of
the instrument and they do a much better job of that than an integrator
would.

Aside (for illustration/persuasion): Wallac provides 2 important COM
controls--an instrument control and a 'browser' tree-control which shows the
protocols in the database.  SAGIAN device modules are separated into two
independent halves (although they're in the same process): configuration and
run-time control.  The browser makes configuration easy, we 'host' the
control on our form, and the user clicks on the protocol.  The module
doesn't need to know anything more than the ID of the protocol (which the
module gets from the browser whenever the user clicks on a protocol) so it
can be passed to the run-time portion appropriately.  The run-time part just
needs to VICTOR.LoadServer and VICTOR.StartAssay(id) to start a read.  The
module doesn't need to worry about database access to enumerate the
protocols and ID's or learn ARCNET and send packets back and forth to the
instrument.  I could write a fairly complete module to integrate the VICTOR
in less than an hour.

If device manufacturers can be trusted to write software which adequately
controls their instrument (I know, quit laughing--we make this assumption
whenever discussing a standard, though), then the appropriate division of
labor is to have integrators working at a much higher level than currently
happens, and I think that separation should be made at the component level
and specified in IDL.  (My bias as an integrator is showing, I realize,
standardizing lower-level interactions would be helpful for others.)

To argue the other side for a moment, IDL/COM/CORBA are strong standards in
themselves.  Standardizing the (programming) interfaces specified in these
technologies as well may be overkill, however, if successful, I agree that
it's a good thing.  At the very least, it raises issues that would be
overlooked by an inexperienced development team and provides a road map for
good component development for device manufacturers.

Tim Sherrill
Beckman Coulter, Inc. -- SAGIAN

Forwarded on behalf of  Torsten Staab [mailto:tstaab@...]  :

At 01:42 PM 4/4/2000 +0100, Jon Wallis (Pfizer) wrote:

> Hi everyone
>
> Jim recently mentioned that the committee at ASTM that controlled the
LECIS
> standard is no more  - but the ASTM website still lists the committee and
> sub-committee, and still lists the LECIS standard as the sub-committee's
> only activity.  What is the full story on all this?

To my knowledge, LECIS was the only specification this particular ASTM
subcommittee was working on. So after LECIS became a standard, their work
was done. That's why the subcommittee does not exist anymore. To me, this
seems to be a pretty reasonable and logical step within ASTM. Nevertheless,
LECIS is and will  remain an ASTM standard. I'm sure that ASTM could
re-enact the subcommittee if there would be a need for a revision. So I
don't really understand why we should look for a new "home"?
(Gary/Rich/John: please correct me if I'm wrong)

> I only ask because of a couple of things about the website occured to me:
>
> i) the "splash page" features "ASTM" very prominently - is it still
> appropriate/relevent if the ASTM don't really control it anymore?
> (Nice photo, BTW - Torsten's work, I assume).

I'm glad you liked the picture. It's a picture of a LANL-made stacking
robot, which I used in the very first LECIS TCP/IP prototype system. Now,
getting back to your question. As I said before, LECIS is still an ASTM
standard. That won't change, no matter what. That's why we still show the
ASTM number on the webpage.

> Since ASTM own the copyright on LECIS does that complicate finding a "new
> home" for LECIS, as has been suggested?  What if we want LECIS to be "Open
> Source"?

I'm not sure about the copyright issue. As far as I know, nobody owns a
copyright on LECIS. John Elling and I coined this term in 1996. It has been
in the public domain ever since. So by now it is impossible for anyone to
trademark the term LECIS, which is a good thing I think. John and I wrote
the original specification with the help of many others. The only copyright
that ASTM owns is the copyright on their official standard document.
Therefore, I would assume that LECIS source code is not subject to any ASTM
copyrights.

Torsten
			 PFIZER CENTRAL RESEARCH
----------------------------------------------------------------
This message and any attachment has been virus checked by the
Pfizer Research Sandwich Data Centre.
----------------------------------------------------------------

This is a reply from Torsten Staab (Los Alamos National Laboratory) to Jim
Redman's LECIS CORBA/COM e-mail from 3/29/2000.

While I was writing this I've received a number of related e-mails which I
haven't read yet. So I apologize if some of this is already obsolete or
redundant.

>Date: Wed, 29 Mar 2000 07:24:36 -0700 (MST)
>From: Jim Redman <jim@...>
>Subject: LECIS CORBA/DCOM
>To: post@...
>X-Loop: one
>...
>By and large, CORBA/DCOM are not implementable on instruments or small
>scale embedded systems.

I think the trend is clearly going towards component-based controls.
HP/Agilent, Zymark, Beckman-Coulter, to name just a few, are all providing
object-level (mostly ActiveX) controls for their equipment. Are they all
wrong? I doubt it. If a system integrator has the choice between a
COM/CORBA object or a native RS-232 or TCP/IP "wire" interface for doing
instrument control, then which one would (s)he most likely choose? The
answer should be obvious.

It is much easier for an instrument manufacturer to provide a COM or CORBA
object with a standardized interface for their equipment then it is for
them to redesign their wire-level protocols and firmware. They only need to
wrap their proprietary protocols in an object, which allows them to make
existing hardware standard compliant in basically no time. Their customers
would also appreciate this, because they would not have to buy new
equipment in order to get standard compliant instruments.

There are other reasons For for doing instrument control at the application
layer (i.e., object-level). For example, you are transport protocol
independent. Furthermore, RAD (Rapid Application Development) IDE
(Integrated Development Environments) such as Visual Basic, Visual C++,
JBuilder, Delphi, etc., can directly import COM/CORBA control objects,
which reduces the development and integration time tremendously. This is
not possible if you control instruments at the data link layer.

>If this is the case, the puts to rest one of my fears, that the
>standard is about to be put into the hands of so many standards bodies
>that it ceases to be a useful standard.  In other words, OMG will have
>an "Instrument Communcications Standard" that looks a little like
>LECIS, but which is not tied intimately to the spec.
>
>Similarly with DCOM.

Yes, kind of. Although a one-to-one mapping of the current standard to
CORBA/COM is possible (as I've successfully demonstrated with the Twister
prototype system), it does not make a lot of sense. The revised LECIS CORBA
IDL will be based on the original standard. However, there will have to be
some changes with respect to the event handling and interactions in order
to harvest of the real power of CORBA. Thorsten Richter already pointed
that out in his last e-mail. The same changes should apply to the COM world
I think. One of the design goals of the LECIS CORBA IDL is, despite of some
deviations from the original LECIS standard, to maintain "backward
compatibility" to the original standard. With that I mean that it should be
fairly simple to wrap a "LECIS 1" TCP/IP or RS-232-based instrument with a
"LECIS 2" CORBA object.

The OMG LECIS IDL document will be treated as a standalone document.
Changes to the OMG spec will not require changes to the original standard
and vice versa. Of course, at some point we could review both documents for
mutual revisions.

>If I'm correct then I don't see a conflict between CORBA/DCOM and
>Socket/RS232.  An instrument could implement LECIS, a host could
>communicate to that, and present a standard DCOM/CORBA interface to that
>raw LECIS communication.

Yes.

>If the instrument does not implement LECIS then the developer of the
>DCOM/CORBA code could implement the proprietary protocol of the
>instrument.  However, it seems to me that the goal is plug-and-play _at
>the instrument level_.  I should be able to substitute an instrument for
>another instrument of the same type, but from a different manufacturer.

Well, I see this as plug-and-play at either the application- or wire-level.
If you have a CORBA or COM instrument, then you need to have a CORBA or COM
controller. If you have a RS-232 or TCP/IP type of control, then your
controller needs to support RS-232 or TCP/IP. Either way, the control will
be standardized.

Torsten Staab

Hello all,

    I just wanted to let you know that we have transferred all LECIS
subscribers to a new mailing service today. If you have received this
e-mail, then you know that you are on the new system. So you don't
need to do anything. The list server switch was necessary, because we
have experienced some technical difficulties with the old list server
over the last two weeks.

The new mailing service is far more advanced and finally provides a
web-based message archive. :) Many thanks to Andy Zaayenga for
setting up the new LECIS mailing list for us!

Please visit the LECIS mailing list web page at
http://www.egroups.com/group/lecis-post to learn more about this
mailing service. For example, at this web site you can configure your
subscription to receive individual messages or a daily digest. You
can also turn off message delivery temporarily and read past postings
in the message archive section.

Please note that the e-mail address for LECIS postings changed to
lecis-post@egroups.com. Updated instructions on how to unsubscribe
and post can be found at www.lecis.org and
www.egroups.com/group/lecis-post.

Please let me know if you have any questions regarding the new list
server. Thanks.

Torsten Staab