Is it necessary to split a SLM into Main- and Sub-Units?

A reason for this discussion: In the ASTM LECIS standard, the TSC did not
know which commands can be executed in parallel and which not.

1. This is a problem for the system scheduler, because it is not
possible to plan the execution times for this device.
2. There is no information about the command dependencies. If we have
only one state diagram for all execution paths (ASTM LECIS), it is
impossible to create the following situation:
A SLM executes two commands in parallel. On command fails, the other could
finish its execution despite of the error. What is the device state, if we
have only one state diagram? Is the device in the error state, despite the
fact that only a part of it fails? Can the second execution path (that is
fully functional) still be used ...?

This situation could only be resolved, if each execution unit has its own
state diagram and executes its commands sequentially. In the real world a
device would usually have a manageable amount of execution units. For
example, a GC would have a heating unit and a detector.

This architecture complicates the device handling somewhat, but seems to
be unavoidable.


Are there any commands that must be executable at any time, independent of
running device commands?

Example: To switch on a UV-lamp, or opening/closing a shutter during the
running measurement. These are simple commands, that could be executed
while a sub-unit is already busy.
- Should we allow those operations?
- If yes, how are they handled?



Macro Execution (Device internal macros)

This is one of the major problems for this specification. Current devices
allow the definition of device internal macros, which execute a serious of
atomic operations without informing the TSC. During this time the device
behaves unpredictably.
Proposed solution:
If a device internal macro is started through a "callMacro()" operation in
the Main-Unit interface, no other sub-state interactions are allowed,
because the macro might influence all sub-units. In this case the main
state model is switching to the state MACRO, because we cannot influence
what is going to happen during the macro execution.