Colin,

Thanks for your comments. I am aware of the sections you are referring to,
it is 8.1 which in my mind links ITEM to <resources>.
I do not question the usefulness of the Item Available Notification,
although it perhaps would be more useful to classify it as an optional
rather than required secondary iteraction.

My question is whether <ITEM LIST> really provides something <ARGUMENT LIST>
does not do already. I have heard a lot of comments about the standard being
too complex; a toolkit does not necessarily become more popular with
mechanics if you add tools that have no advantage over the existing ones but
simply look different.
Perhaps the ethos of being descriptive is to some extend questionable, too,
as this is where the ambiguities and uncertainties come from that also are
one of the weak points of the standard.

Of course we are looking for consensus on this issue, there must be
arguments I am not aware of because our experience is unavoidably limited.
Perhaps if you could expand your example giving a real situation it may be
easier to understand.

Best regards,
Dorothe

      LEGAL NOTICE

      Unless expressly stated otherwise, this message is confidential and
      may be privileged. It is intended for the addressee(s) only. Access to
      this e-mail by anyone else is unauthorised. If you are not an
      addressee, any disclosure or copying of the contents of this e-mail or
      any action taken (or not taken) in reliance on it is unauthorised and
      may be unlawful. If you are not an addressee, please inform the sender
      immediately.

      Pfizer Limited is registered in England under No. 526209 with its
      registered office at Ramsgate Road, Sandwich, Kent CT13 9NJ


> -----Original Message-----
> From: Colin Read [mailto:Colin.A.Read@...]
> Sent: 24 April 2002 11:45
> To: lecis-post@yahoogroups.com
> Subject: RE: [lecis-post] use of <ITEM LIST>?
>
>
> PFIZER GLOBAL RESEARCH AND DEVELOPMENT
> ----------------------------------------------------------------
> This message and any attachment has been virus checked by the
> PGRD Sandwich Data Centre.
> ----------------------------------------------------------------
>
> Dorothe,
>
> We suggest you read the following sections in the ASTM LECIS document:
> 2.1.11, 4.6.4, 8.1 and 8.4.  Although they do not give an adequate
> explanation of what the RUN_OP <ITEM LIST> could be used for,
> they do help
> explain what an ITEM is.
>
> If you take those explanations with a bit of lateral thinking
> then we have
> the following scenarios.
>
> For synchronous processing with synchronous results:
>
> => RUN_OP <ARGUMENT LIST> produces => OP_RESULT <DATA LIST>
>
> For synchronous processing with asynchronous results:
>
> => RUN_OP <ARGUMENT LIST> produces => ITEM_AVAILABLE <ITEM>
>
> For asynchronous processing with synchronous results:
>
> => RUN_OP <ITEM LIST> produces => OP_RESULT <DATA LIST>
>
> For asynchronous processing with asynchronous results:
>
> => RUN_OP <ITEM LIST> produces => ITEM_AVAILABLE <ITEM>
>
> Or, indeed, any combination of the above.
>
> I think part of the problem is that the CAALS DCD is only
> loosely referred
> to by ASTM LECIS.  There is no item definition in the CAALS
> DCD and the only
> thing close to it is a Resource.
>
> To summarise, this is an interpretation of a standards
> document.  The whole
> ethos of LECIS is to be descriptive rather than prescriptive.
>  I believe the
> implementation should be by consensus and we should discuss and decide
> collectively on how something can or should be used rather
> than dismissing
> it unilaterally.
>
> Would this be the opportunity to agree on a definition for an
> ITEM in the
> frame work of the CAALS DCD?
>
> We provide a tool kit that implements as much of ASTM LECIS
> as we can, which
> grows in functionality with time and demand.  It is up to the
> mechanic to
> decide what and how much of the tool kit to use.
>
>
> Regards,
>
> Colin & Jon
> -----------
> The Electric Laboratory Company Limited
> Phone: 01202 398067 Fax: 08700 527 608
> Please visit us: www.e-labcompany.co.uk
>
> > -----Original Message-----
> > From: dorothe_steidinger@...
> > [mailto:dorothe_steidinger@...]
> > Sent: 23 April 2002 08:41
> > To: lecis-post@yahoogroups.com
> > Subject: [lecis-post] use of <ITEM LIST>?
> >
> >
> > Hello,
> >
> > I would greatly appreciate if someone could suggest some reasons
> > why <RUN OP MSG> contains the (optional) <ITEM LIST>.
> >
> > The difficulty I have with it is that whereas <COMMAND ARG LIST>
> > is made up by one or more <formal_argument> in the DCD, the DCD's
> > command section does not have a corresponding tag for <ITEM LIST>
> > (e.g. <required_resources> are prerequisites, not input parameters,
> > and may contain more information than just <ITEM ID>). The standard
> > does not even suggest what <ITEM LIST> should be used for, if it
> > really is a list of resources the command should act on, as some
> > suggest, surely it would be more suitable to specify it in a
> > controlled manner via <formal_argument>? In that case even allowing
> > for <ITEM LIST> in <RUN OP MSG> seems to be an undesirable
> > compliation of the standard to me.
> >
> > Please let me know if I have overlooked something.
> >
> > Thanks for your help,
> >
> > Kind regards,
> > Dorothe
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> Buy Stock for $4
> and no minimums.
> FREE Money 2002.
> http://us.click.yahoo.com/k6cvND/n97DAA/ySSFAA/PMYolB/TM
> --------------------------------------------------------------
> -------~->
>
> To view archived messages, go to:
> http://groups.yahoo.com/group/lecis-post/messages
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/



PFIZER GLOBAL RESEARCH AND DEVELOPMENT
----------------------------------------------------------------
This message and any attachment has been virus checked by the
PGRD Sandwich Data Centre.
----------------------------------------------------------------

Dorothe,

We suggest you read the following sections in the ASTM LECIS document:
2.1.11, 4.6.4, 8.1 and 8.4.  Although they do not give an adequate
explanation of what the RUN_OP <ITEM LIST> could be used for, they do help
explain what an ITEM is.

If you take those explanations with a bit of lateral thinking then we have
the following scenarios.

For synchronous processing with synchronous results:

=> RUN_OP <ARGUMENT LIST> produces => OP_RESULT <DATA LIST>

For synchronous processing with asynchronous results:

=> RUN_OP <ARGUMENT LIST> produces => ITEM_AVAILABLE <ITEM>

For asynchronous processing with synchronous results:

=> RUN_OP <ITEM LIST> produces => OP_RESULT <DATA LIST>

For asynchronous processing with asynchronous results:

=> RUN_OP <ITEM LIST> produces => ITEM_AVAILABLE <ITEM>

Or, indeed, any combination of the above.

I think part of the problem is that the CAALS DCD is only loosely referred
to by ASTM LECIS.  There is no item definition in the CAALS DCD and the only
thing close to it is a Resource.

To summarise, this is an interpretation of a standards document.  The whole
ethos of LECIS is to be descriptive rather than prescriptive.  I believe the
implementation should be by consensus and we should discuss and decide
collectively on how something can or should be used rather than dismissing
it unilaterally.

Would this be the opportunity to agree on a definition for an ITEM in the
frame work of the CAALS DCD?

We provide a tool kit that implements as much of ASTM LECIS as we can, which
grows in functionality with time and demand.  It is up to the mechanic to
decide what and how much of the tool kit to use.


Regards,

Colin & Jon
-----------
The Electric Laboratory Company Limited
Phone: 01202 398067 Fax: 08700 527 608
Please visit us: www.e-labcompany.co.uk

> -----Original Message-----
> From: dorothe_steidinger@...
> [mailto:dorothe_steidinger@...]
> Sent: 23 April 2002 08:41
> To: lecis-post@yahoogroups.com
> Subject: [lecis-post] use of <ITEM LIST>?
>
>
> Hello,
>
> I would greatly appreciate if someone could suggest some reasons
> why <RUN OP MSG> contains the (optional) <ITEM LIST>.
>
> The difficulty I have with it is that whereas <COMMAND ARG LIST>
> is made up by one or more <formal_argument> in the DCD, the DCD's
> command section does not have a corresponding tag for <ITEM LIST>
> (e.g. <required_resources> are prerequisites, not input parameters,
> and may contain more information than just <ITEM ID>). The standard
> does not even suggest what <ITEM LIST> should be used for, if it
> really is a list of resources the command should act on, as some
> suggest, surely it would be more suitable to specify it in a
> controlled manner via <formal_argument>? In that case even allowing
> for <ITEM LIST> in <RUN OP MSG> seems to be an undesirable
> compliation of the standard to me.
>
> Please let me know if I have overlooked something.
>
> Thanks for your help,
>
> Kind regards,
> Dorothe

Hello,

I would greatly appreciate if someone could suggest some reasons why <RUN OP
MSG> contains the (optional) <ITEM LIST>.

The difficulty I have with it is that whereas <COMMAND ARG LIST> is made up
by one or more <formal_argument> in the DCD, the DCD's command section does
not have a corresponding tag for <ITEM LIST> (e.g. <required_resources> are
prerequisites, not input parameters, and may contain more information than
just <ITEM ID>). The standard does not even suggest what <ITEM LIST> should
be used for, if it really is a list of resources the command should act on,
as some suggest, surely it would be more suitable to specify it in a
controlled manner via <formal_argument>? In that case even allowing for
<ITEM LIST> in <RUN OP MSG> seems to be an undesirable compliation of the
standard to me.

Please let me know if I have overlooked something.

Thanks for your help,

Kind regards,
Dorothe

      LEGAL NOTICE

      Unless expressly stated otherwise, this message is confidential and
      may be privileged. It is intended for the addressee(s) only. Access to
      this e-mail by anyone else is unauthorised. If you are not an
      addressee, any disclosure or copying of the contents of this e-mail or
      any action taken (or not taken) in reliance on it is unauthorised and
      may be unlawful. If you are not an addressee, please inform the sender
      immediately.

      Pfizer Limited is registered in England under No. 526209 with its
      registered office at Ramsgate Road, Sandwich, Kent CT13 9NJ




PFIZER GLOBAL RESEARCH AND DEVELOPMENT
----------------------------------------------------------------
This message and any attachment has been virus checked by the
PGRD Sandwich Data Centre.
----------------------------------------------------------------

April 15, 2002.

The Electric Laboratory Company Ltd is pleased to announce the release of
version 1.1 of its LECIS Shell Suite.

As well as enhancements throughout, notable features include:

- Improved session disconnect/connect handling through communications loss.
- Improved message logging.
- Improved XML DCD support and handling.
- Performance enhancements.

The LECIS Shell Suite software is now available to download for evaluation
from:
http://www.e-labcompany.co.uk/products/evaluation/

Hello all,

I'm forwarding you a recent message from Dr. Tony Parsons, Pfizer UK,
regarding the state of the OMG's LECIS standardization process. Please note
that in order to vote as a member on the OMG FTF for LECIS, your
company/institution must be an OMG member above auditing level.

Please feel free to contact Dr. Parsons (Tony_Parsons@...)
if you have any questions regarding these LECIS-related OMG activities. Thanks.

Have a nice day,
Torsten Staab


At 04:10 PM 10/19/2001 +0100, you wrote:
  >LECIS Finalization Task Force (FTF)
  >
  >The Architecture Board Technology Adoption vote for the joint revised
  >submission in response to the LECIS RFP has completed.  This submission
  >defines interfaces and device states in support of deterministic,
  >device-independent remote control of laboratory equipment. The proposal
  >builds upon the LECIS and Device Capability Dataset specifications which
are
  >existing ASTM standards.
  >
  >I have been asked to charter and chair the LECIS FTF.  The purpose of the
  >FTF is to handle and produce the first post-adoption revision of a
  >submission. Its purpose is to gather comments on the specification, respond
  >to those comments and decide whether changes are required in response to
  >those comments (see P&P Chapter 4.4.1.1)  In short it turns the "adopted"
  >specification into an "available" specification.
  >
  >Voting members of the FTF normally include a representative from each of
the
  >submitters but may consist of any OMG member above auditing level.  The
  >proposed voting list consists of ACD Labs, Creon Lab Control, European
  >Bioinformatics Institute, the Electric Laboratory Company, and Pfizer.
  >
  >Although an FTF is not a working group of the LSR DTF I am sending this
  >request to enquire if any other LSR members wish to be voting members of
the
  >FTF.  Please contact me if you want further details or alternatively
contact
  >me in Dublin.
  >
  >Apologies if you receive this more than once.
  >
  >Regards,
  >
  >Tony Parsons
  >
  >Dr.Tony Parsons,                            VOX :   + 44 1304 646596
  >Manager, Information Architecture Europe,   FAX :   + 44 1304 652118
  >Pfizer Global Research and Development,     e-mail:
  >Tony_Parsons@... <mailto:Tony_Parsons@...>
  >Sandwich Laboratories,
  >Sandwich,
  >CT13 9NJ UK
  >---------------------------------------------------------------------------
-
  >UK LEGAL NOTICE
  >
  >Unless expressly stated otherwise, this message is confidential and may be
  >privileged. It is intended for the addressee(s) only. Access to this e-mail
  >by anyone else is unauthorised. If you are not an addressee, any disclosure
  >or copying of the contents of this e-mail or any action taken (or not
taken)
  >in reliance on it is unauthorised and may be unlawful. If you are not an
  >addressee, please inform the sender immediately. Pfizer Limited is
  >registered in England under No. 526209 with it registered office at
Ramsgate
  >Road, Sandwich, Kent CT13 9NJ
  >
  >
  >PFIZER GLOBAL RESEARCH AND DEVELOPMENT
  >----------------------------------------------------------------
  >This message and any attachment has been virus checked by the
  >PGRD Sandwich Data Centre.
  >----------------------------------------------------------------

Hi,

I wanted to commend Thorsten for his efforts in advancing this specification
from the RFP last summer, to acceptance by the AB and members of the OMG
this month.

Thorsten was diligent, and eager to learn and apply the OMG process.  He was
also willing to listen and make changes to the documents as recommended by
others.

Many others have also helped along the way: co-submitters ACD, Tony Parsons
and the rest of the Pfizer team, Torsten Staab, and many others on this
list.  Thanks to all of you for your efforts thus far!

Best regards,

---Karl

Karl Konnerth
LSR Taskforce co-chair



on 7/17/01 3:25 AM, thorsten.richter@... at
thorsten.richter@... wrote:

>
> The OMG LECIS specification has been accepted by the OMG.
>
> In detail:
> The LSR (lifescience) taskforce has voted in favour of LECIS and the OMG
> Architectural Board (AB) recommended LECIS for "adoption" .
> In the next few weeks, the OMG will send all members a ballot to vote for the
> LECIS adoption. This is normally not a problem, since the AB has already
> recommended it.
> Nonetheless,the AB requires us to make some changes to the specification. This
> includes things like the IDL naming conventions, and other minor things, which
> will not change the overall concept of the specification.
> These changes can (officially) be made in a OMG Finalization Task Force (FTF).
> An FTF will be created at the next meeting.
> In the next 18 Month, we must provide an implementation for OMG LECIS.
> Otherwise the OMG will dismiss the specification. The FTF will resolve all
> problems in the spec that  will be found during the implementation. After the
> FTF is done, the LECIS specification will become a "formal" OMG specification.
>
> Everybody, who is interested in implementing the specification should contact
> me (thorsten.richter@...) to get information about the latest
> version of the specification.
>
> Currently the AB voted on the document lifesci/01-06-01 with the errata
> document lifesci/01-07-08.
> In the next few days I will provide the convienience document including the
> changes. It has the OMG document number lifesci/01-07-09.
> The documents can be found soon at:
> http://www.omg.org/techprocess/meetings/schedule/LECIS_RFP.html
>
> In the next weeks we are going to include most of the requested changes of the
> AB. This document will provide a basis for a consistent implementation, that
> will already include many changes that will (officially) be made during the
> FTF process.
>
> Regards,
> Thorsten
>
>
>
>
> Thorsten Richter,
> Product Innovation, Project Manager
> --------------------------------------------------------------
> CREON·LAB·CONTROL AG
> Postfach 4526,
> D-65035 Wiesbaden, Germany
> Tel. +49 611 5050 260 Fax. +49 611 5050576
> http://www.creonlabcontrol.com
> --------------------------------------------------------------
> To view archived messages, go to:
> http://groups.yahoo.com/group/lecis-post/messages
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
> <http://docs.yahoo.com/info/terms/> .

Hi Dorothe

> > Please do not confuse the standards requirements with individual SLM
> > implementations.  What you have described here is possible but *is*
> > implementation specific, not part of the standards state model.  The
> > state model *only* has one entry point, whether it is from a
> > 'software' or 'hard' reset, it is the same thing.
> True, and as such it has to cater for both.
> I imagine though that a hardware reset entails dropping/re-establishing
> the connection whereas a software reset may not.

The definition of a *hard reset* is when the SLM's power is switched off and
then on again (what is also sometimes called *power cycling*).

A *soft* reset is when the software is restarted.

Either way, it means to restart the SLM.

> Colin/Jon, I can hear you bring up *connectionless* protocols, but again,
> the state model should then cope with both. Apart from that, to
> me it seems the ASTM document - although independent of protocols - has
> been written with a continuous link in mind (6.1.1 ff).

This is not the case, ioho. There's nothing in 6.1.1 or elsewhere that
assumes a connection-oriented (or connectionless) protocol.

> > > I don't agree with non-accruability of NEXT EVENT being implicit, the
> > > TSC should not send more than one NEXTEVENT command if it is not ready
> > > for the responses.
> > This scenario is described in the LIG because if it is not explicitly
> > stated, (as in the ASTM document), you get people implementing the
> > NEXTEVENT interaction as a message storm not as a flow control
> > mechanism.  As you say, the TSC should not send a NEXTEVENT command
> > unless it is ready to receive the next event message.  Therefore, the
> > SLM cannot stack NEXTEVENTS if the TSC inadvertently initiates more
> > than one.
> Since I already keep demonstrating my ignorance about protocols and flow
> control etc, here is my advice to the TSC:
> If it suffers from NEXTEVENT incontinence but cannot cope with the
> implications, it could always hold back with the acknowledgement of a
> message received from an SLM until it is ready for the next one(see 5.2).

This is definitely *not* advisable, ACKS are "low-level" and all
acknowledgements *must* be timely and should therefore not be used as a flow
control mechanism.

> Besides, if a TSC deals with more than one SLM at the same time, it is
> not impossible that they all send messages to it at the same time.

Quite true.  That is why the TSC controls the flow of event messages not the
SLMs.

> > Imagine two people
> [..]
> > This is *flow control*.
> Is this not making assumptions about how many buckets A has (subunits,
> etc..) or how many customers B gets tokens from (subunits again)? Why
> constrain it that way?

Please re-read the example; it imposes the parameters you question.  LECIS
*is* a master/slave control environment. The situation would be the same no
matter how it is played out.  The numbers just get bigger and the chances of
missing something reduce.  With flow control there is *no* chance of missing
anything.  All subunits are blocking.


> > > After all, the NEXTEVENT never expires, and it is a secondary,
> > > not a primary interaction, so more than one instance of it
> > > may be active at any one time.
> > There is nothing in the ASTM document to indicate that more
> > than one NEXT EVENT interaction can exist at the same time.
> NEXTEVENT never expires (6.6.2), and it is a secondary, not a primary
> interaction (table 2), so more than one instance of it
> may be active at any one time (4.3.3).
> So far I haven't found anything that suggests it is an exception.

Although this is true, remember that the LIG was written to try and clear up
as many ambiguities and anomalies as possible.  This is just one such case.

If the ASTM document was interpreted literally it would not be easy, or even
possible, to implement it.  Please don't make the same mistake.  The LIG was
distributed to try and make it easy for people to adopt LECIS, and thus
benefit everyone (although we obviously welcome suggestions for
improvements).

> > If you look at it logically, you could only have multiple instances
> > if you tied them in with individual secondary interaction and then
> > the whole process of interaction/state management becomes far too
> > complicated.  Also, consider this, if each NEXT EVENT is tied to an
> > interaction, which could be possible for commands, how would it work
> > for events and alarms?  Of course one could create a special
> > NEXT EVENT interaction id for events, alarms, and do not forget
> > Required Primary commands that exist in the Control Flow state.  Would
> > you like to program this?  Keep it simple.  NEXT EVENT is used for flow
> > control, no more, no less.
> You are right that as a secondary interaction each of them would need an
> interaction id.
> But there is no need for a specific NEXT EVENT interaction to be
> terminated by a specific event report, all the SLM would have to do is
> indicate in its event report which instance of NEXT EVENT is used up.
> Whether this is any more complicated than, say, the ABORT interaction,
> I don't know.

With respect, we think you have missed the point here.  Each command would
need its own NEXT EVENT interaction id, which we believe would make it
unnecessarily complicated to implement.  Using a id-less NEXT EVENT permits
the SLM to send whatever Event is available (which is all that is required -
the Event message will contain the required id) and it doesn't require the
SLM (or TSC) to maintain a list of which interactions have received NEXT
EVENTs and which haven't.

Would anyone else who reads this mailing-list like to contribute? (Thanks to
Jim for already having done so.)  Whilst this is all very interesting (a) it
does take up rather a lot of our time and (b) it would be good to have some
other opinions and interpretations.

Best regards,

Colin & Jon.


--
The Electric Laboratory Company Ltd
Visit us at: www.e-labcompany.co.uk

Hello,

> Please do not confuse the standards requirements with individual SLM
> implementations.  What you have described here is possible but *is*
> implementation specific, not part of the standards state
> model.  The state
> model *only* has one entry point, whether it is from a
> 'software' or 'hard'
> reset, it is the same thing.
True, and as such it has to cater for both.
I imagine though that a hardware reset entails dropping/re-establishing the
connection whereas a software reset may not.
Colin/Jon, I can hear you bring up *connectionless* protocols, but again,
the state model should then cope with both. Apart from that, to me it seems
the ASTM document - although independent of protocols - has been written
with a continuous link in mind (6.1.1 ff).

> This is the universal problem for all connectionless
> protocols - who says
> "Hello" first.  LECIS says that the SLM should initiate
> communications. As
> you have described, there is a contradiction in the standard,
> the SLM can
> not say "Hello" until it receives a NEXTEVENT but the TSC can
> not send a
> NEXTEVENT because the because the SLM has to initiate communications.
> 'Chicken and Egg'!  Again, this is why we needed the LIG.
> These anomalies
> where discussed with Torsten Staab and the results of these
> where included
> in the LIG.
And 2.4 it imposes TSC/IP and continuous connection with no mention of
connectionless protocols or UDP.
In case there is a misunderstanding: I do not question the implementers
guide as a whole, after all, I've learned a lot from it, too.

> > I don't agree with non-accruability of NEXT EVENT being
> > implicit, the TSC
> > should not send more than one NEXTEVENT command if it is
> > not ready for the responses.
>
> This scenario is described in the LIG because if it is not explicitly
> stated, (as in the ASTM document), you get people
> implementing the NEXTEVENT
> interaction as a message storm not as a flow control
> mechanism.  As you say,
> the TSC should not send a NEXTEVENT command unless it is
> ready to receive
> the next event message.  Therefore, the SLM cannot stack
> NEXTEVENTS if the
> TSC inadvertently initiates more than one.

Since I already keep demonstrating my ignorance about protocols and flow
control etc,
here is my advice to the TSC:
If it suffers from NEXTEVENT incontinence but cannot cope with the
implications,
it could always hold back with the acknowledgement of a message received
from an SLM until it is ready for the next one(see 5.2). Besides, if a TSC
deals with more than one SLM at the same time, it is not impossible that
they all send messages to it at the same time.

>
> Imagine two people
[..]
> This is *flow control*.
Is this not making assumptions about how many buckets A has (subunits,
etc..) or how many customers B gets tokens from (subunits again)? Why
constrain it that way?

>
> > After all, the NEXTEVENT never expires, and it is a secondary,
> > not a primary interaction, so more than one instance of it
> > may be active
> > at any one time.
>
> There is nothing in the ASTM document to indicate that more
> than one NEXT
> EVENT interaction can exist at the same time.

NEXTEVENT never expires (6.6.2), and it is a secondary,not a primary
interaction (table 2), so more than one instance of it
may be active at any one time (4.3.3).
So far I haven't found anything that suggests it is an exception.

>  If you look at
> it logically,
> you could only have multiple instances if you tied them in
> with individual
> secondary interaction and then the whole process of interaction/state
> management becomes far too complicated.  Also, consider this,
> if each NEXT
> EVENT is tied to an interaction, which could be possible for
> commands, how
> would it work for events and alarms?  Of course one could
> create a special
> NEXT EVENT interaction id for events, alarms, and do not
> forget Required
> Primary commands that exist in the Control Flow state.  Would
> you like to
> program this?  Keep it simple.  NEXT EVENT is used for flow
> control, no
> more, no less.
You are right that as a secondary interaction each of them would need an
interaction id.
But there is no need for a specific NEXT EVENT interaction to be terminated
by a specific event report, all the SLM would have to do is indicate in its
event report which instance of NEXT EVENT is used up. Whether this is any
more complicated than, say, the ABORT interaction, I don't know.

> We would be more than happy to provide consultancy and
> support for LECIS
> implementations on a more formal basis.
I do apologise if I'm misusing this e-mail group in any way.

Best regards,
Dorothe

      LEGAL NOTICE

      Unless expressly stated otherwise, this message is confidential and
      may be privileged. It is intended for the addressee(s) only. Access to
      this e-mail by anyone else is unauthorised. If you are not an
      addressee, any disclosure or copying of the contents of this e-mail or
      any action taken (or not taken) in reliance on it is unauthorised and
      may be unlawful. If you are not an addressee, please inform the sender
      immediately.

      Pfizer Limited is registered in England under No. 526209 with its
      registered office at Ramsgate Road, Sandwich, Kent CT13 9NJ

		 PFIZER GLOBAL RESEARCH AND DEVELOPMENT
----------------------------------------------------------------
This message and any attachment has been virus checked by the
PGRD Sandwich Data Centre.
----------------------------------------------------------------

Dorothe,

> > > The only situation I can think off where the STATE_CHANGED
> > > (POWERED UP) message makes sense is in the transition from ESTOPPED
> > > to CONTROL FLOW/POWERED UP as this state change is initiated
> > > manually by the operator.
> >
> > There is no actual *state transition* from ESTOPPED. ("The top level
> > of the Control Flow state model provides a *one-way* transition to
> > ESTOPPED." - 7.4.9.1. and see Fig 12.) Once in ESTOPPED an SLM has
> > to be manually restarted.
>
> The standard only says that manual intervention is required. The way I
> interpreted it is as follows:
> - the 'one-way transition' means that the return option is not
> available to the TSC (has to be done manually).

Correct.

> - you may not want to power-cycle an SLM that has been estopped (damage to
> lamps etc, or if an instrument has an excessively long start-up time (even
> if they are due to operating procedures rather than the hardware's
> requirements ;-)), so a button on the local control interface to send it
back
> to POWERED UP would do. After all, depending on how you interpret 'work
cell'
> an SLM may have been estopped in response to a problem with another one.

Please do not confuse the standards requirements with individual SLM
implementations.  What you have described here is possible but *is*
implementation specific, not part of the standards state model.  The state
model *only* has one entry point, whether it is from a 'software' or 'hard'
reset, it is the same thing.

> > > The TSC would only need to do that when an SLM connects to it.
> > > And it would make it the same approach regardless whether the
> > > connection is due to a new SLM, a power-cycled SLM or connection
> > > loss. Remember:
> > > * there is no timing requirement for the SLM to send that
> > > STATE CHANGED message (if indeed it has to send it at all)
> >
> > True, but see 6.1.1 in the standard.  Once it's on, the SLM
> > is required to initiate comms with TSC.  We have to assume (for
> > workability) that this initiation is timely.
>
> If you see 'initiate communication' as what happens once the
> connection has been set up, it can't really do anything:
> there is not yet anything to acknowledge, and messages must not be sent
> until it has received a NEXTEVENT command.
> Once it has received one and has responded with an ACK, surely the
> communication is seen as initiated?

This is the universal problem for all connectionless protocols - who says
"Hello" first.  LECIS says that the SLM should initiate communications. As
you have described, there is a contradiction in the standard, the SLM can
not say "Hello" until it receives a NEXTEVENT but the TSC can not send a
NEXTEVENT because the because the SLM has to initiate communications.
'Chicken and Egg'!  Again, this is why we needed the LIG.  These anomalies
where discussed with Torsten Staab and the results of these where included
in the LIG.

If you are interested in this subject we suggest some further reading:
Computer Networks, Andrew S. Tanenbaum, ISBN: 0133499456.

Remember: ASTM LECIS *is* protocol independent.

> > > Like omitting the interaction id from the interaction
> > > NEXT EVENT and making it non-accruable?
> >
> > Omitting the sequence number from the interaction id from
> > NEXT EVENT message doesn't affect the logical functionality of the
> > standard (i.e. NEXT EVENT still performs the function the standard
> > requires) and was merely a way of simplifying implementation.
> >
> > The non-accruability of NEXT EVENT is implicit in LECIS -
> > otherwise, the SLM could queue them (if the TSC happened to send
> > more than one for some reason) and could then fire off multiple
> > EVENTS when the TSC wasn't ready for them.
> > NEXT EVENT functions as a one-time permission to send another
> > EVENT - it doesn't matter how many it receives, the SLM can only
> > send the next NEXT EVENT. Think of it as "software flow control".
>
> I don't agree with non-accruability of NEXT EVENT being implicit, the TSC
> should not send more than one NEXTEVENT command if it is not ready for the
> responses.

This scenario is described in the LIG because if it is not explicitly
stated, (as in the ASTM document), you get people implementing the NEXTEVENT
interaction as a message storm not as a flow control mechanism.  As you say,
the TSC should not send a NEXTEVENT command unless it is ready to receive
the next event message.  Therefore, the SLM cannot stack NEXTEVENTS if the
TSC inadvertently initiates more than one.

Imagine two people, person A with a 1 litre container, and person B with
lots of water in 1 litre measures.  Person A gives  person B permission to
dispense them 1 litre measures on receipt of a token.  If person A gives a
token to person B , they will receive 1 litre of water in their container.
Person A then consumes the water and gives person B another token, and so
on.  All is well.

Now consider this.  If person A gives two tokens to person B, person B now
has permission to dispense two 1 litre measures whenever they please.  This
can fall into one of two scenarios.  Scenario one: person B dispenses one 1
litre measure and person A consumes it, person B dispenses one 1 litre
measure and person A consumes it.  Again, all is well.  Scenario two: person
B dispenses one 1 litre measure and then immediately dispenses another 1
litre measure.  This time person A has not had time to consume its first
measure of water before receiving the second and so the water is spilt.
This is *flow control*.

> After all, the NEXTEVENT never expires, and it is a secondary,
> not a primary interaction, so more than one instance of it may be active
> at any one time.

There is nothing in the ASTM document to indicate that more than one NEXT
EVENT interaction can exist at the same time.  If you look at it logically,
you could only have multiple instances if you tied them in with individual
secondary interaction and then the whole process of interaction/state
management becomes far too complicated.  Also, consider this, if each NEXT
EVENT is tied to an interaction, which could be possible for commands, how
would it work for events and alarms?  Of course one could create a special
NEXT EVENT interaction id for events, alarms, and do not forget Required
Primary commands that exist in the Control Flow state.  Would you like to
program this?  Keep it simple.  NEXT EVENT is used for flow control, no
more, no less.

6.6.1 "The Next Event Interaction lets the TSC control the flow of event
reports from the SLM. The command message initiating this interaction gives
the SLM 'permission' to place the next event report into the communication
channel."

> The only question is whether NEXT EVENT REQUESTED goes to TERMINATED
> if the SLM's event report is NACKed by the TSC. The answer is probably
> 'no' since interactions that are NACKed stay in the original state, here
> NEXT EVENT REQUESTED.

Agreed.

Once again, the whole question of protocols is addressed in Tanenbaum's
classic book.

We would be more than happy to provide consultancy and support for LECIS
implementations on a more formal basis.


Regards,

Colin & Jon.

--
The Electric Laboratory Company Ltd
Visit us at: www.e-labcompany.co.uk

Colin, Jon,

> > The only situation I can think off where the STATE_CHANGED
> > (POWERED UP)
> > message makes sense is in the transition from ESTOPPED to CONTROL
> > FLOW/POWERED UP as this state change is initiated manually by the
> > operator.
>
> There is no actual *state transition* from ESTOPPED. ("The
> top level of the
> Control Flow state model provides a *one-way* transition to
> ESTOPPED." -
> 7.4.9.1. and see Fig 12.) Once in ESTOPPED an SLM has to be manually
> restarted.

The standard only says that manual intervention is required. The way I
interpreted it is as follows:
- the 'one-way transition' means that the return option is not available to
the TSC (has to be done manually).
- you may not want to power-cycle an SLM that has been estopped (damage to
lamps etc, or if an instrument has an excessively long start-up time(even if
they are due to operating procedures rather than the hardware's requirements
;-)), so a button on the local control interface to send it back to POWERED
UP would do. After all, depending on how you interpret 'work cell' an SLM
may have been estopped in response to a problem with another one.

>
> However, what you outline seems a perfect description of
> switching a device
> on - which is when the STATE_CHANGED (POWERED UP) message is
> used in the
> LIG.
See above.
>
> > The TSC would only need to do that when an SLM connects to it.
> > And it would make it the same approach regardless whether the
> > connection is due to a new SLM, a power-cycled SLM or connection
> > loss. Remember:
> > * there is no timing requirement for the SLM to send that
> STATE CHANGED
> > message (if indeed it has to send it at all)
>
> True, but see 6.1.1 in the standard.  Once it's on, the SLM
> is required to
> initiate comms with TSC.  We have to assume (for workability)
> that this
> initiation is timely.

If you see 'initiate communication' as what happens once the connection has
been set up, it can't really do anything:
there is not yet anything to acknowledge, and messages must not be sent
until it has received a NEXTEVENT command.
Once it has received one and has responded with an ACK, surely the
communication is seen as initiated?

>
> > * the TSC is not necessarily unaware of the connection loss as your
> > implementer's guide assumes (4.2.3)
>
> But the LIG doesn't assume that the TSC is "unaware" (it says, in 2.7,
> "However, during idle time the TSC should check that each SLM
> is available
> periodically"). So the TSC would, at some point, become aware.

True, sorry, I was taking my statement from the tables, most of which have
the 'TSC-raises-its-eyebrows-and-says-oha-a-new-connection" feel to them ;-)

>
> > * since the SLM never disconnects officially any loss of
> > communication looks the same to the TSC, so, except for the
> > very first connection, the TSC always should be aware of a
> > previous one (knowing about its loss or not). If the TSC was
> > to send a status request in response  to an SLM connecting
> > all scenarios are catered for, including the following:
>
> But this wouldn't cater for connectionless protocols, which
> LECIS *can* also
> use - e.g., UDP. LECIS only requires a reliable comms protocol, not a
> connection-oriented one. In such protocols, the TSC wouldn't
> know the SLM
> was up and running, since there would be no connection.  We
> chose to use TCP
> for it's reliability, not specifically because it is
> connection-oriented.

Not knowing anything about connectionless protocols I can't comment..


> > Like omitting the interaction id from the interaction
> > NEXT EVENT and making it non-accruable?
>
> Omitting the sequence number from the interaction id from
> NEXT EVENT message
> doesn't affect the logical functionality of the standard
> (i.e. NEXT EVENT
> still performs the function the standard requires) and was
> merely a way of
> simplifying implementation.
>
> The non-accruability of NEXT EVENT is implicit in LECIS -
> otherwise, the SLM
> could queue them (if the TSC happened to send more than one
> for some reason)
> and could then fire off multiple EVENTS when the TSC wasn't
> ready for them.
> NEXT EVENT functions as a one-time permission to send another
> EVENT - it
> doesn't matter how many it receives, the SLM can only send
> the next NEXT
> EVENT. Think of it as "software flow control".

I don't agree with non-accruability of NEXT EVENT being implicit, the TSC
should not send more than one NEXTEVENT command if it is not ready for the
responses. After all, the NEXTEVENT never expires, and it is a secondary,
not a primary interaction, so more than one instance of it may be active at
any one time.
The only question is whether NEXT EVENT REQUESTED goes to TERMINATED if the
SLM's event report is NACKed by the TSC. The answer is probably 'no' since
interactions that are NACKed stay in the original state, here NEXT EVENT
REQUESTED.

Best regards,
Dorothe

      LEGAL NOTICE

      Unless expressly stated otherwise, this message is confidential and
      may be privileged. It is intended for the addressee(s) only. Access to
      this e-mail by anyone else is unauthorised. If you are not an
      addressee, any disclosure or copying of the contents of this e-mail or
      any action taken (or not taken) in reliance on it is unauthorised and
      may be unlawful. If you are not an addressee, please inform the sender
      immediately.

      Pfizer Limited is registered in England under No. 526209 with its
      registered office at Ramsgate Road, Sandwich, Kent CT13 9NJ


		 PFIZER GLOBAL RESEARCH AND DEVELOPMENT
----------------------------------------------------------------
This message and any attachment has been virus checked by the
PGRD Sandwich Data Centre.
----------------------------------------------------------------

Jim,

I would be happy to go through the OMG proposal and list the differences,
liasing with ACD and Creon, as a starting point.  Although it is worth
baring in mind that OMG LECIS is a communications specific implementation
where the ASTM version was not.  The OMG discussions also raised
non-protocol specific changes to the ASTM standard, which I will include.

Let me know when you have got somewhere to store the document.  :)


Regards,

Colin.

--
Colin Read
The Electric Laboratory Company Ltd
Visit us at: www.e-labcompany.co.uk

> -----Original Message-----
> From: Jim Redman [mailto:jim@...]
> Sent: 23 July 2001 15:45
> To: lecis-post@yahoogroups.com
> Subject: Re: [lecis-post] LECIS Revisions.
>
>
> I agree and am remiss in not following the LECIS/OMG more closely.
> I would still like to get the proposed changes together so that we
> have them in one place and get the discussion started in a way that
> we save the history and logic of the decision in a form better than
> e-mail.  Let me see what's available on the LECIS site, perhaps we
> can get a simple PHP chat script or similar running that would do
> what we need.  It would be good to be able to assign topics so that
> individuals are responsible for managing different pieces.  If there's
> interest, I'll see what I can find to do this.
>
> Jim
>
> On 2001.07.23 04:32:29 -0600 Colin Read wrote:
> > Jim,
> >
> > To reiterate one of the points that Jon made earlier, ASTM LECIS does
> > have a number of ambiguities and deficiencies that we have tried to
> > cater for. The end result is that we did get it to work, 'warts and
all'.
> >
> > In recognition of the these problems we have tried to resolve
> > them in the OMG CORBA LECIS implementation, where together with
> > Advanced Chemistry Development and Creon Labcontrol, we have made
> > considerable gains.  The OMG has voted on the LECIS proposals and they
> > have been passed, but there is still opportunity for constructive input
> > to help resolve issues during implementation.
> >
> > Once the CORBA version has been ratified, the consensus among those who
> > have worked on the OMG proposals is that we revise the ASTM version of
> > LECIS to bring it inline as a superset.  I imagine this will probably
> > be in the next 12 months, but should not effect existing products.
> >
> > I think the most important thing is to implement the core standard so
> > that we can achieve interoperability.

Dorothe,

> That would create another inconsistency: the change from
> 'nothing' to 'LOCAL CONTROL' then should have been listed
> in 4.6.5 as state change that doesn't need to be anounced.
> I'm still not convinced...

True, but that's why we suggested you don't think of STATE_CHANGED (POWERED
UP) as a state change, but as an "I'm here" message.

> The only situation I can think off where the STATE_CHANGED (POWERED UP)
> message makes sense is in the transition from ESTOPPED to CONTROL
> FLOW/POWERED UP as this state change is initiated manually by the
> operator.

There is no actual *state transition* from ESTOPPED. ("The top level of the
Control Flow state model provides a *one-way* transition to ESTOPPED." -
7.4.9.1. and see Fig 12.) Once in ESTOPPED an SLM has to be manually
restarted.

However, what you outline seems a perfect description of switching a device
on - which is when the STATE_CHANGED (POWERED UP) message is used in the
LIG.

> The TSC would only need to do that when an SLM connects to it.
> And it would make it the same approach regardless whether the
> connection is due to a new SLM, a power-cycled SLM or connection
> loss. Remember:
> * there is no timing requirement for the SLM to send that STATE CHANGED
> message (if indeed it has to send it at all)

True, but see 6.1.1 in the standard.  Once it's on, the SLM is required to
initiate comms with TSC.  We have to assume (for workability) that this
initiation is timely.

> * the TSC is not necessarily unaware of the connection loss as your
> implementer's guide assumes (4.2.3)

But the LIG doesn't assume that the TSC is "unaware" (it says, in 2.7,
"However, during idle time the TSC should check that each SLM is available
periodically"). So the TSC would, at some point, become aware.

> * since the SLM never disconnects officially any loss of
> communication looks the same to the TSC, so, except for the
> very first connection, the TSC always should be aware of a
> previous one (knowing about its loss or not). If the TSC was
> to send a status request in response  to an SLM connecting
> all scenarios are catered for, including the following:

But this wouldn't cater for connectionless protocols, which LECIS *can* also
use - e.g., UDP. LECIS only requires a reliable comms protocol, not a
connection-oriented one. In such protocols, the TSC wouldn't know the SLM
was up and running, since there would be no connection.  We chose to use TCP
for it's reliability, not specifically because it is connection-oriented.

> All this seems to assume that the problem is with the SLM. Imagine the TSC
> shuts down and is re-started. It now has forgotten about previous
> connections. The SLM (still in CONTROL FLOW) reconnects.
> Obviously it won't send a STATE CHANGED message to POWERED UP.
> But according to your rules the TSC would be waiting for it,
> so nothing happens?

The TSC should be storing the SLM state model information in a *durable*
form - e.g., by writing to a dynamic version of the DCD in a database, or by
being implemented in a persistent language. Thus, when the TSC restarts it
should be able to retrieve all the information it requires to resume
operation.

> Never say never. Power-cycling the SLM is not the only way of
> sending it to POWERED UP; the transition from ESTOPPED to CONTROL
> FLOW is another one.

As mentioned before, there isn't a transition from ESTOPPED to CONTROL
FLOW - this is just the same as switching an SLM on.

> That's the theory of 24/7/365, not the LECIS...

All I meant was that Jim's idea of an SLM never being switched off is a nice
idea (in theory), but you can't guarantee it.

> Like omitting the interaction id from the interaction
> NEXT EVENT and making it non-accruable?

Omitting the sequence number from the interaction id from NEXT EVENT message
doesn't affect the logical functionality of the standard (i.e. NEXT EVENT
still performs the function the standard requires) and was merely a way of
simplifying implementation.

The non-accruability of NEXT EVENT is implicit in LECIS - otherwise, the SLM
could queue them (if the TSC happened to send more than one for some reason)
and could then fire off multiple EVENTS when the TSC wasn't ready for them.
NEXT EVENT functions as a one-time permission to send another EVENT - it
doesn't matter how many it receives, the SLM can only send the next NEXT
EVENT. Think of it as "software flow control".

> But to some extend the LECIS is asking for it: the
> ITEM AVAILABLE NOTIFICATION  is a required interaction,
> although it doesn't make sense for many SLMs...

Very true.  ITEM AVAILABLE isn't required at all. Torsten Staab himself once
commented that he didn't quite know why he had included it in the end, and
it has been omitted from the CORBA submission.

[SLM action in the event of loss of comms]
> That's not quite true, it stays where it is or it pauses.

True.

> INIT  should only be accepted if the SLM is in POWERED
> UP, from NORMAL OPERATION you'd need to send CLEAR, but
> you may not want to send it to IDLE.

Also true.

Regards,

Jon Wallis
Colin Read

--
The Electric Laboratory Company Ltd
Visit us at: www.e-labcompany.co.uk

I agree and am remiss in not following the LECIS/OMG more closely.  I would
still like to get the proposed changes together so that we have them in one
place and get the discussion started in a way that we save the history and
logic of the decision in a form better than e-mail.  Let me see what's
available on the LECIS site, perhaps we can get a simple PHP chat script or
similar running that would do what we need.  It would be good to be able to
assign topics so that individuals are responsible for managing different
pieces.  If there's interest, I'll see what I can find to do this.

Jim

On 2001.07.23 04:32:29 -0600 Colin Read wrote:
> Jim,
>
> To reiterate one of the points that Jon made earlier, ASTM LECIS does
> have a
> number of ambiguities and deficiencies that we have tried to cater for.
> The
> end result is that we did get it to work, 'warts and all'.
>
> In recognition of the these problems we have tried to resolve them in the
> OMG CORBA LECIS implementation, where together with Advanced Chemistry
> Development and Creon Labcontrol, we have made considerable gains.  The
> OMG
> has voted on the LECIS proposals and they have been passed, but there is
> still opportunity for constructive input to help resolve issues during
> implementation.
>
> Once the CORBA version has been ratified, the consensus among those who
> have
> worked on the OMG proposals is that we revise the ASTM version of LECIS
> to
> bring it inline as a superset.  I imagine this will probably be in the
> next
> 12 months, but should not effect existing products.
>
> I think the most important thing is to implement the core standard so
> that
> we can achieve interoperability.
>
>
> Regards,
>
> Colin.
>
> --
> Colin Read
> The Electric Laboratory Company Ltd
> Visit us at: www.e-labcompany.co.uk
>
>
> To view archived messages, go to:
> http://groups.yahoo.com/group/lecis-post/messages
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
--
Jim Redman
(505) 662 5156
http://www.ergotech.com

On 2001.07.23 02:46:30 -0600 dorothe_steidinger@... wrote:
> Jim Redman wrote:
> > The problem is that on loss of communication the SLM returns
> > to IDLE, not
> > POWERED UP.
> That's not quite true, it stays where it is or it pauses.

You're right, that opens up a whole new can of worms.  The spec says that
the SLM can drop information when the connection doesn't exist.  If the
communcation is lost during processing and the events don't reach the host,
the host could think that everything is fine.  This means that you can
double-process material or have an undetected error in the process and not
know it.  This is not good - there must be at least the option of the SLM
storing the information (Spooling).  This only matters for certain SLMs but
the capability must be there.


>

> >  So why force
> > every TSC through
> > these hoops for a situation that is not useful.  OR force the
> > SLM back to
> > POWERED UP on loss of communication - at least that would be
> > consistent.
>
> It would also make it quite unlikely that you can recover from a loss of
> connection, which can't be the goal.
>

You would have to monitor the actual hardware connection.  There is nothing
in the spec. that lets you reliably recover.  I had thought that the state
transistion was mandatory, but it's not.  You also might not find out the
communication link had been dropped until you try to send another command
when you might find the SLM in PAUSED instead of NORMAL.  Or you just may
never figure it out (and you may or may not care - or know that you care).

We need to fix some of these problems in the ASTM specification.  Who's
interested in pursuing this?  I would propose that we collect errors and
suggested fixes on the LECIS website and once these are finalized we
re-form the ASTM committee to re-vote it.

Jim

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

Jim,

To reiterate one of the points that Jon made earlier, ASTM LECIS does have a
number of ambiguities and deficiencies that we have tried to cater for.  The
end result is that we did get it to work, 'warts and all'.

In recognition of the these problems we have tried to resolve them in the
OMG CORBA LECIS implementation, where together with Advanced Chemistry
Development and Creon Labcontrol, we have made considerable gains.  The OMG
has voted on the LECIS proposals and they have been passed, but there is
still opportunity for constructive input to help resolve issues during
implementation.

Once the CORBA version has been ratified, the consensus among those who have
worked on the OMG proposals is that we revise the ASTM version of LECIS to
bring it inline as a superset.  I imagine this will probably be in the next
12 months, but should not effect existing products.

I think the most important thing is to implement the core standard so that
we can achieve interoperability.


Regards,

Colin.

--
Colin Read
The Electric Laboratory Company Ltd
Visit us at: www.e-labcompany.co.uk

Jim Redman wrote:
> The problem is that on loss of communication the SLM returns
> to IDLE, not
> POWERED UP.
That's not quite true, it stays where it is or it pauses.

> This means that everytime a connection is made
> from the SLM to
> the TSC the TSC must request the current state and take one
> set of action
> if in POWERED UP and a different set from IDLE.  There is the
> possibility
> of some SLMs actually needing the intervention of the TSC to
> get to IDLE,
> but it's hard to imagine, especially since the only command
> is INIT, no
> configuration, no information, just do it.

INIT  should only be accepted if the SLM is in POWERED UP, from NORMAL
OPERATION you'd need to send CLEAR, but you may not want to send it to IDLE.

>  So why force
> every TSC through
> these hoops for a situation that is not useful.  OR force the
> SLM back to
> POWERED UP on loss of communication - at least that would be
> consistent.

It would also make it quite unlikely that you can recover from a loss of
connection, which can't be the goal.

Regards,
Dorothe

      LEGAL NOTICE

      Unless expressly stated otherwise, this message is confidential and
      may be privileged. It is intended for the addressee(s) only. Access to
      this e-mail by anyone else is unauthorised. If you are not an
      addressee, any disclosure or copying of the contents of this e-mail or
      any action taken (or not taken) in reliance on it is unauthorised and
      may be unlawful. If you are not an addressee, please inform the sender
      immediately.

      Pfizer Limited is registered in England under No. 526209 with its
      registered office at Ramsgate Road, Sandwich, Kent CT13 9NJ

		 PFIZER GLOBAL RESEARCH AND DEVELOPMENT
----------------------------------------------------------------
This message and any attachment has been virus checked by the
PGRD Sandwich Data Centre.
----------------------------------------------------------------

Hello Jon,

> > and I'm not convinced that the state changed message
> > should be sent (in the same way as the entry in LOCAL
> > CONTROL doesn't need to be announced)
>
> LOCAL CONTROL is the default start-up state of the
> Local/Remote model.  The
> TSC *knows* this, because it will be hard-coded into the
> implementation.
>
> However, whilst POWERED UP is the default state of the
> CONTROL FLOW state
> model, the TSC can't know that the SLM is in that state
> unless something
> tells it that the SLM has been switched on - we considered
> that the SLM was
> the best agent for this action. Once the TSC knows that the
> SLM is *on* it
> will also "know" that it will be in LOCAL CONTROL by default.
That would create another inconsistency: the change from 'nothing' to 'LOCAL
CONTROL' then should have been listed in 4.6.5 as state change that doesn't
need to be anounced. I'm still not convinced...

>
> So, it's best to think of the POWERED UP STATE_CHANGED event
> not as a state
> change (although it is one), but as a mechanism whereby the
> SLM can announce
> its existence and availability to a TSC.

The only situation I can think off where the STATE_CHANGED (POWERED UP)
message makes sense is in the transition from ESTOPPED to CONTROL
FLOW/POWERED UP as this state change is initiated manually by the operator.
For everything else it looks to me like a mechanism is invented for each of
different types of scenario, that could all be handled (consistently) with
one (see below).

>
> Also, the POWERED UP "hello, I'm here" message should be a
> "high level" one,
> because LECIS is meant to be implementation-independent and not all
> communication protocols are connection orientated.
>
> > as at that point the SLM hasn't  really changed a state
> > in a current interaction (7.5.1).
>
> True, since there is no current interaction, but this is more of a
> *philosophical* issue really.
>
> The SLM's state *has* changed - from *null* to POWERED UP - so the
> STATE_CHANGED Event does make sense.
>
> > The TSC can always query the status of the Control Flow
> > interaction if it wants to know what state the SLM is in.
>
> True - but this would  require the TSC to then regularly
> "poll" every SLM
> that it knows about to see if it is on-line.  Instead, we
> considered it
> better to have an "interrupt" approach, whereby the SLM announces its
> "existence" to the TSC - this approach is more efficient, in
> terms of both
> comms and the TSC's processing power.

The TSC would only need to do that when an SLM connects to it. And it would
make it the same approach regardless whether the connection is due to a new
SLM, a power-cycled SLM or connection loss.
Remember:
* there is no timing requirement for the SLM to send that STATE CHANGED
message (if indeed it has to send it at all)
* the TSC is not necessarily unaware of the connection loss as your
implementer's guide assumes (4.2.3)
* since the SLM never disconnects officially any loss of communication looks
the same to the TSC, so, except for the very first connection, the TSC
always should be aware of a previous one (knowing about its loss or not). If
the TSC was to send a status request in response to an SLM connecting all
scenarios are catered for, including the following:

All this seems to assume that the problem is with the SLM. Imagine the TSC
shuts down and is re-started. It now has forgotten about previous
connections. The SLM (still in CONTROL FLOW) reconnects. Obviously it won't
send a STATE CHANGED message to POWERED UP. But according to your rules the
TSC would be waiting for it, so nothing happens?

Best regards,
Dorothe

      LEGAL NOTICE

      Unless expressly stated otherwise, this message is confidential and
      may be privileged. It is intended for the addressee(s) only. Access to
      this e-mail by anyone else is unauthorised. If you are not an
      addressee, any disclosure or copying of the contents of this e-mail or
      any action taken (or not taken) in reliance on it is unauthorised and
      may be unlawful. If you are not an addressee, please inform the sender
      immediately.

      Pfizer Limited is registered in England under No. 526209 with its
      registered office at Ramsgate Road, Sandwich, Kent CT13 9NJ


		 PFIZER GLOBAL RESEARCH AND DEVELOPMENT
----------------------------------------------------------------
This message and any attachment has been virus checked by the
PGRD Sandwich Data Centre.
----------------------------------------------------------------

Hello,

> Jim Redman wrote:
> > Except that, since the SLM never returns to the "POWERED UP"
> > state, the TSC needs to ask on each new connection whether it
> > has just turned on or has been on for a while.

Never say never. Power-cycling the SLM is not the only way of sending it to
POWERED UP;
the transition from ESTOPPED to CONTROL FLOW is another one.


Jon Wallis wrote:
> I'm not quite sure why it should need to do this. Why should
> it matter? The
> TSC only needs to know if the SLM is there, and is in the
> POWERED UP state.
> Once it does, the TSC may, at a later time send a
> REMOTE_CONTROL request,
> which the SLM may or may not grant.
>
> Jim Redman wrote:
> > I've seriously  consided not implementing POWERED UP
> > because in systems that run 24/7/365 you should see
> > that state only once in the lifetime of the device.
>
Jon Wallis wrote:
> I can see the temptation, and of course you're correct ... in theory.

That's the theory of 24/7/365, not the LECIS...


Jon Wallis wrote:
> Imho, implementations should be of the complete protocol, to
> take account of
> all possibilities - partly to be "fail-safe" to as great a degree as
> practicable, partly to be sure of "interoperabilty" between all
> implementations, and partly to be able to demonstrate/prove
> "compliance"
> (which would important in regulatory apps in pharma companies).
>
> Imho, only partly implementing the standard (even if it just
> means missing
> out one thing) is like being "partly pregnant" ;-)

Like omitting the interaction id from the interaction NEXT EVENT and making
it non-accruable?

But to some extend the LECIS is asking for it: the ITEM AVAILABLE
NOTIFICATION  is a required interaction, although it doesn't make sense for
many SLMs...

Best regards,
Dorothe

      LEGAL NOTICE

      Unless expressly stated otherwise, this message is confidential and
      may be privileged. It is intended for the addressee(s) only. Access to
      this e-mail by anyone else is unauthorised. If you are not an
      addressee, any disclosure or copying of the contents of this e-mail or
      any action taken (or not taken) in reliance on it is unauthorised and
      may be unlawful. If you are not an addressee, please inform the sender
      immediately.

      Pfizer Limited is registered in England under No. 526209 with its
      registered office at Ramsgate Road, Sandwich, Kent CT13 9NJ

		 PFIZER GLOBAL RESEARCH AND DEVELOPMENT
----------------------------------------------------------------
This message and any attachment has been virus checked by the
PGRD Sandwich Data Centre.
----------------------------------------------------------------

On 2001.07.21 14:22:27 -0600 Jon Wallis wrote:

> I (for one) have no absolutely objection to the current approach being
> changed for something "better"

How do we change it, or at least make it a mandatory option.  I can argue
technology all day, but the most convincing argument for me is that in
semiconductor you have the choice of either the equipment (SLM) making the
connection to the host (TSC) (the current LECIS design) or the TSC making
the connection to the SLM.  To the best of my knowledge EVERYONE makes the
connection from the TSC to the SLM. In pharmacuetical we are forcing an
architecture which, when given a choice no one chooses.

Let's learn from other people - everyone else is in better shape than we
are.

Jim

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

Jim Redman wrote:
> There is also a hidden scalability problem in this architecture.  Because
> the SLM makes the connection to the TSC, in an architecture with thousands
> of SLMs if there is a network glitch, all the SLMs will start to make a
> connection to the TSC, some may succeed some may fail.

Yes, I agree such a scenario is possible.

If this did happen, and connection failures occurred (which I agree is very
likely) TCP would (or should) handle such failures (which is why it was
chosen in preference to, e.g., UDP).

> The TSCs/network may well be swamped causing timeouts on the
> SLMs causing loss of communication causing the cycle to continue.
> The extra state changes/queries add to the traffic making a bad
> situation worse.

This scenario isn't really that different to 9 am in the large-scale
corporate environment, where hundreds/thousands of users boot their
networked PCs and connect to central servers.

Even if there were thousands of SLMs (which I agree there might well be),
they wouldn't all be controlled by the same TSC(s) (so one TCS would not get
swamped), they certainly wouldn't all be on the same network segment (so
there wouldn't be excessive overall network congestion), and it's unlikely
they'd all get switched on at exactly the same time - and even if they were,
even very minor differences in the power-up cycle of different devices would
prevent them all *communicating* at exactly the same time.

> I'll just add this to the list of reasons why the current (TCP/IP)
> architecture (where the initial connection is made by the SLM) is just
> wrong and hope that it's changed before the limits of it are reached an
> critical mass prevents the change.

I (for one) have no absolutely objection to the current approach being
changed for something "better" - imho, it was only ever a "means to an end"
(the "end" being a workable implementation of LECIS). Indeed, the current
OMG "CORBA" LECIS submission uses a different approach (i.e. the CORBA
Naming Service).

Regards

Jon