CMI Timer and Application Ready response

[SamS]

The IEC CD 61158-6-10 (PN-AL-protocol) defines a CMInitiatorActivityTimeout handled by the IO device.
I'm curious when this timer is started and stopped. I can find a description with state machine in chapter 5.6.3.8 for the CMSM.

The CMSM switches from state IDLE to state RUN when CMDEV is in state STARTUP (#1) and starts a timer. While in state RUN, it expects a message (CM_Read.ind, CM_Write.ind or RM_Read.ind) or a state change to DATA/ABORT within CMDEV. Otherwise, if the timer expires, the CMDEV is put into state ABORT (#10). As soon as a response was formed, the timer is started again.

I can also find a description with state machine in chapter 5.6.3.2 for the CMDEV.
The CMDEV signals state STARTUP to CMSM when connect response is conveyed (#8). It signals state DATA to CMSM when cyclic data exchange is established. For that, a "RM_Ccontrol.cnf (+)" (positive application ready response) must have been received, am I correct?

As long as the CMDEV is not in state DATA, the CMSM stays in state RUN and should monitor the communication using the CMI Timer. The only expection would be an ABORT due to release or timeout. Am I correct with these assumptions?

I know that there's a test case that checks if the IO device detminated the AR after the defined timeout if no application ready response was received.
But what should happen if a Read or Write response was received in the meanwhile?

Best regards,
Sam

[Raik.Zachmann]

The IEC CD 61158-6-10 (PN-AL-protocol) defines a CMInitiatorActivityTimeout handled by the IO device.
I'm curious when this timer is started and stopped. I can find a description with state machine in chapter 5.6.3.8 for the CMSM.

The CMSM switches from state IDLE to state RUN when CMDEV is in state STARTUP (#1) and starts a timer. While in state RUN, it expects a message (CM_Read.ind, CM_Write.ind or RM_Read.ind) or a state change to DATA/ABORT within CMDEV. Otherwise, if the timer expires, the CMDEV is put into state ABORT (#10). As soon as a response was formed, the timer is started again.

I can also find a description with state machine in chapter 5.6.3.2 for the CMDEV.
The CMDEV signals state STARTUP to CMSM when connect response is conveyed (#8). It signals state DATA to CMSM when cyclic data exchange is established. For that, a "RM_Ccontrol.cnf (+)" (positive application ready response) must have been received, am I correct?

As long as the CMDEV is not in state DATA, the CMSM stays in state RUN and should monitor the communication using the CMI Timer. The only expection would be an ABORT due to release or timeout. Am I correct with these assumptions?

I know that there's a test case that checks if the IO device detminated the AR after the defined timeout if no application ready response was received.
But what should happen if a Read or Write response was received in the meanwhile?

Best regards,
Sam

Dear Sam,
your assumptions are correct!
What do you exactly mean with "receiving a read or write response in the meanwhile"?
The CMI Timout will be activated with the Connect Response on device side, stopped with getting a write.req and started again with the corresponding write.rsp. Please have a look in Appendix A.2 "AR establishing".

[SamS]

The IEC CD 61158-6-10 (PN-AL-protocol) defines a CMInitiatorActivityTimeout handled by the IO device.
I'm curious when this timer is started and stopped. I can find a description with state machine in chapter 5.6.3.8 for the CMSM.

The CMSM switches from state IDLE to state RUN when CMDEV is in state STARTUP (#1) and starts a timer. While in state RUN, it expects a message (CM_Read.ind, CM_Write.ind or RM_Read.ind) or a state change to DATA/ABORT within CMDEV. Otherwise, if the timer expires, the CMDEV is put into state ABORT (#10). As soon as a response was formed, the timer is started again.

I can also find a description with state machine in chapter 5.6.3.2 for the CMDEV.
The CMDEV signals state STARTUP to CMSM when connect response is conveyed (#8). It signals state DATA to CMSM when cyclic data exchange is established. For that, a "RM_Ccontrol.cnf (+)" (positive application ready response) must have been received, am I correct?

As long as the CMDEV is not in state DATA, the CMSM stays in state RUN and should monitor the communication using the CMI Timer. The only expection would be an ABORT due to release or timeout. Am I correct with these assumptions?

I know that there's a test case that checks if the IO device detminated the AR after the defined timeout if no application ready response was received.
But what should happen if a Read or Write response was received in the meanwhile?

Best regards,
Sam

Dear Sam,
your assumptions are correct!
What do you exactly mean with "receiving a read or write response in the meanwhile"?
The CMI Timout will be activated with the Connect Response on device side, stopped with getting a write.req and started again with the corresponding write.rsp. Please have a look in Appendix A.2 "AR establishing".

Thank you for your response!
I misspelled and meant "read or write request".
For example, the IO Device sees the following sequence and reacts as expected:
1. Connect request from host
2. Connect response from device (CMI timer starts)
3. Write request from host (CMI timer stops)
4. Write response from device (CMI timer starts)
5. Control request (Parameter end) from host (CMI timer stops)
6. Control response from device (CMI timer doesn't start?)
7. Control request (Application ready) from device (CMI timer starts?)
8. (no Control response) from host
9. Write request from host (CMI timer is affected at all?)

In Appendix A.2, I can see the behaviour of the CMI timeout until PrmEnd.req was received. The time between one response (from device) and the next req (from host) is supervised. But I don't see this for ApplRdy.req and ApplRdy.rsp. For that, the device should check that the time between req and rsp is within the timeout (as described in chapter 5.6.3.2 for the CMDEV).

[llindemann]

The IEC CD 61158-6-10 (PN-AL-protocol) defines a CMInitiatorActivityTimeout handled by the IO device.
I'm curious when this timer is started and stopped. I can find a description with state machine in chapter 5.6.3.8 for the CMSM.

The CMSM switches from state IDLE to state RUN when CMDEV is in state STARTUP (#1) and starts a timer. While in state RUN, it expects a message (CM_Read.ind, CM_Write.ind or RM_Read.ind) or a state change to DATA/ABORT within CMDEV. Otherwise, if the timer expires, the CMDEV is put into state ABORT (#10). As soon as a response was formed, the timer is started again.

I can also find a description with state machine in chapter 5.6.3.2 for the CMDEV.
The CMDEV signals state STARTUP to CMSM when connect response is conveyed (#8). It signals state DATA to CMSM when cyclic data exchange is established. For that, a "RM_Ccontrol.cnf (+)" (positive application ready response) must have been received, am I correct?

As long as the CMDEV is not in state DATA, the CMSM stays in state RUN and should monitor the communication using the CMI Timer. The only expection would be an ABORT due to release or timeout. Am I correct with these assumptions?

I know that there's a test case that checks if the IO device detminated the AR after the defined timeout if no application ready response was received.
But what should happen if a Read or Write response was received in the meanwhile?

Best regards,
Sam

Dear Sam,
your assumptions are correct!
What do you exactly mean with "receiving a read or write response in the meanwhile"?
The CMI Timout will be activated with the Connect Response on device side, stopped with getting a write.req and started again with the corresponding write.rsp. Please have a look in Appendix A.2 "AR establishing".

Thank you for your response!
I misspelled and meant "read or write request".
For example, the IO Device sees the following sequence and reacts as expected:
1. Connect request from host
2. Connect response from device (CMI timer starts)
3. Write request from host (CMI timer stops)
4. Write response from device (CMI timer starts)
5. Control request (Parameter end) from host (CMI timer stops)
6. Control response from device (CMI timer doesn't start?)
7. Control request (Application ready) from device (CMI timer starts?)
8. (no Control response) from host
9. Write request from host (CMI timer is affected at all?)

In Appendix A.2, I can see the behaviour of the CMI timeout until PrmEnd.req was received. The time between one response (from device) and the next req (from host) is supervised. But I don't see this for ApplRdy.req and ApplRdy.rsp. For that, the device should check that the time between req and rsp is within the timeout (as described in chapter 5.6.3.2 for the CMDEV).

Hi Sam,

Appendix A.2 does not show any retirggering of the CMI timer in case of Application Ready because there is none.
The CMSM is stops the timer on Inbound requests (RM_Read.ind, CM_Reade.Ind, CM_Write.ind, CM_Control.ind) and starts the time once the response is going to be replied (xx.rsp).
Or in other words any read,write, control request from the initiator retriggers the timer.

In the timespan after PRMEnd.Res before IO data based AR surveillance starts the devices relies on "Trigger-Reads" of the initiator.

Your sequence would be as follows
...
6. Control response from device (CMI timer start)
6a) if AplRdy takes enough time trigger reads

• initiator does every CMITimeout DIV 3 (in no other activity is performed): Read(Trigger-Index ) -> (CMI timer stop) => Read.res created by CMSM (CMI timer start)

7. Control request (Application ready) from device (CMI timer no impact)
8. (no Control response) from host
9. Write request from host (CMI timer is affected see above)

• if no Read/Write/Control the initiator does every CMITimeout DIV 3: Read(Trigger-Index ) -> (CMI timer stop) => Read.res created by CMSM (CMI timer start)

with regards Lars

[SamS]

Dear Sam,
your assumptions are correct!
What do you exactly mean with "receiving a read or write response in the meanwhile"?
The CMI Timout will be activated with the Connect Response on device side, stopped with getting a write.req and started again with the corresponding write.rsp. Please have a look in Appendix A.2 "AR establishing".

Thank you for your response!
I misspelled and meant "read or write request".
For example, the IO Device sees the following sequence and reacts as expected:
1. Connect request from host
2. Connect response from device (CMI timer starts)
3. Write request from host (CMI timer stops)
4. Write response from device (CMI timer starts)
5. Control request (Parameter end) from host (CMI timer stops)
6. Control response from device (CMI timer doesn't start?)
7. Control request (Application ready) from device (CMI timer starts?)
8. (no Control response) from host
9. Write request from host (CMI timer is affected at all?)

In Appendix A.2, I can see the behaviour of the CMI timeout until PrmEnd.req was received. The time between one response (from device) and the next req (from host) is supervised. But I don't see this for ApplRdy.req and ApplRdy.rsp. For that, the device should check that the time between req and rsp is within the timeout (as described in chapter 5.6.3.2 for the CMDEV).

Hi Sam,

Appendix A.2 does not show any retirggering of the CMI timer in case of Application Ready because there is none.
The CMSM is stops the timer on Inbound requests (RM_Read.ind, CM_Reade.Ind, CM_Write.ind, CM_Control.ind) and starts the time once the response is going to be replied (xx.rsp).
Or in other words any read,write, control request from the initiator retriggers the timer.

In the timespan after PRMEnd.Res before IO data based AR surveillance starts the devices relies on "Trigger-Reads" of the initiator.

Your sequence would be as follows
...
6. Control response from device (CMI timer start)
6a) if AplRdy takes enough time trigger reads

• initiator does every CMITimeout DIV 3 (in no other activity is performed): Read(Trigger-Index ) -> (CMI timer stop) => Read.res created by CMSM (CMI timer start)

7. Control request (Application ready) from device (CMI timer no impact)
8. (no Control response) from host
9. Write request from host (CMI timer is affected see above)

• if no Read/Write/Control the initiator does every CMITimeout DIV 3: Read(Trigger-Index ) -> (CMI timer stop) => Read.res created by CMSM (CMI timer start)

with regards Lars

Dear Lars,

I had to re-check the specification again and agree that the timer is stopped with an req and started with the resp within the device, only. This is described in the CMSM state table. The timeout is set to CMInitiatorActivityTimeout. This value is communicated with the connect request and between 100 and 1000 for "DeviceAccess == 1" and "StartupMode == Advanced". This value also correlates to the "CMITimeout DIV 3" of the host you mentioned.

But there's another timeout value for the Application message (application timeout = 300s) used by the host (initiator) specifically between PrmEnd and ApplReady (see "Remote Application Ready Timeout" in IEC CD 61158-5-10).

With your explanation and with the information above, am I right to assume the following?
1. If no RM_Read.ind, CM_Reade.Ind, CM_Write.ind, CM_Control.ind is detected by the device, it shall release the AR with an alarm after CMInitiatorActivityTimeout ?
2. Will the host (initiator) continue the triggering after PrmEnd and before receiving a application ready (for 300s) ?
3. If number 2 is true, number 1 will never happen, right?
4. But why does the test case "Checking of Timeout CControl (Behaviour scenario 5)" expect an alarm after RPC timeout (fix 300s) ? According to the explanation above I would assume an alarm after CMInitiatorActivityTimeout.
5. Would it be acceptable to re-send the application ready message after CMInitiatorActivityTimeout if no response was received ?

Best regards,
Sam

[llindemann]

Thank you for your response!
I misspelled and meant "read or write request".
For example, the IO Device sees the following sequence and reacts as expected:
1. Connect request from host
2. Connect response from device (CMI timer starts)
3. Write request from host (CMI timer stops)
4. Write response from device (CMI timer starts)
5. Control request (Parameter end) from host (CMI timer stops)
6. Control response from device (CMI timer doesn't start?)
7. Control request (Application ready) from device (CMI timer starts?)
8. (no Control response) from host
9. Write request from host (CMI timer is affected at all?)

In Appendix A.2, I can see the behaviour of the CMI timeout until PrmEnd.req was received. The time between one response (from device) and the next req (from host) is supervised. But I don't see this for ApplRdy.req and ApplRdy.rsp. For that, the device should check that the time between req and rsp is within the timeout (as described in chapter 5.6.3.2 for the CMDEV).

Hi Sam,

Appendix A.2 does not show any retirggering of the CMI timer in case of Application Ready because there is none.
The CMSM is stops the timer on Inbound requests (RM_Read.ind, CM_Reade.Ind, CM_Write.ind, CM_Control.ind) and starts the time once the response is going to be replied (xx.rsp).
Or in other words any read,write, control request from the initiator retriggers the timer.

In the timespan after PRMEnd.Res before IO data based AR surveillance starts the devices relies on "Trigger-Reads" of the initiator.

Your sequence would be as follows
...
6. Control response from device (CMI timer start)
6a) if AplRdy takes enough time trigger reads

• initiator does every CMITimeout DIV 3 (in no other activity is performed): Read(Trigger-Index ) -> (CMI timer stop) => Read.res created by CMSM (CMI timer start)

7. Control request (Application ready) from device (CMI timer no impact)
8. (no Control response) from host
9. Write request from host (CMI timer is affected see above)

• if no Read/Write/Control the initiator does every CMITimeout DIV 3: Read(Trigger-Index ) -> (CMI timer stop) => Read.res created by CMSM (CMI timer start)

with regards Lars

Dear Lars,

I had to re-check the specification again and agree that the timer is stopped with an req and started with the resp within the device, only. This is described in the CMSM state table. The timeout is set to CMInitiatorActivityTimeout. This value is communicated with the connect request and between 100 and 1000 for "DeviceAccess == 1" and "StartupMode == Advanced". This value also correlates to the "CMITimeout DIV 3" of the host you mentioned.

But there's another timeout value for the Application message (application timeout = 300s) used by the host (initiator) specifically between PrmEnd and ApplReady (see "Remote Application Ready Timeout" in IEC CD 61158-5-10).

With your explanation and with the information above, am I right to assume the following?
1. If no RM_Read.ind, CM_Reade.Ind, CM_Write.ind, CM_Control.ind is detected by the device, it shall release the AR with an alarm after CMInitiatorActivityTimeout ?
2. Will the host (initiator) continue the triggering after PrmEnd and before receiving a application ready (for 300s) ?
3. If number 2 is true, number 1 will never happen, right?
4. But why does the test case "Checking of Timeout CControl (Behaviour scenario 5)" expect an alarm after RPC timeout (fix 300s) ? According to the explanation above I would assume an alarm after CMInitiatorActivityTimeout.
5. Would it be acceptable to re-send the application ready message after CMInitiatorActivityTimeout if no response was received ?

Best regards,
Sam

Hi Sam,

1. If no RM_Read.ind, CM_Reade.Ind, CM_Write.ind, CM_Control.ind is detected by the device, it shall release the AR with an alarm after CMInitiatorActivityTimeout ?

yes, the device will terminate the AR.

2. Will the host (initiator) continue the triggering after PrmEnd and before receiving a application ready (for 300s) ?

Yes

3. If number 2 is true, number 1 will never happen, right?

As along as the initiator still is operating and is able to reach the device. From device side the initiator may crash - in that case the device terminates the AR and thus frees the allocated resources.

4. But why does the test case "Checking of Timeout CControl (Behaviour scenario 5)" expect an alarm after RPC timeout (fix 300s) ? According to the explanation above I would assume an alarm after CMInitiatorActivityTimeout.

I did not check the mentioned test case but I assume it exactly the devices frees the local allocated resources by terminating the non functional AR. The "so-called" Alarm is an RTA-Error Frame indicated by the device once it terminates the AR (more less a "thank and goodbye - I'm off" message of the device)

5. Would it be acceptable to re-send the application ready message after CMInitiatorActivityTimeout if no response was received ?

No, since it does not solve the described scenario - and device will never free resources - may result in a denial of service

BR Lars