Redundant. This requirement is redundant with REQ_017. Remarks:When in state COMMS, the CSL forwards all the received User message to RBC Userfunctions (when receiving from SAI the corresponding SAI_DATA indication). REQ_006 Loss of safe connection shall be detected by the CSL reading reports from the underlying SFM (SAI_DISCONNECT.indication). Rules: R16_ICSL, R16_CCSL, R1_ICSL, R1_CCSL Issues:Inconsistency: Loss of safe connection shall also be detected without reading reports of underlying SFM, i.e., by timeout. Remarks: The SAI_DISCONNECT.indication are considered the CSL only in state COMMS. In state NOCOMMS such reports are discarded. REQ_007 If a report from underlying Layers is received that safe connection is lost, the CSL shall consider the communication in state NOCOMMS. Rules: R16_ICSL, R16_CCSL Issues: no issues have been found Remarks: The CSL when receiving a SAI_DISCONNECT.indication moves from COMMS to NOCOMMS.Further effects are related to the timers mentioned in REQ_008, REQ_009. REQ_008 TTS option: after reception of report from SAI that the clock offset procedure has been completed, the CSL shall ensure that a message is sent to the partner RBC at the expiration of a configurable transmit time interval (reset at the sending of any message). If no User message needs to be sent, CSL is responsible to send a life sign message (see Figure 4);EC option: After reception of report from SAI that the EC initialisation procedure has been completed, the sending of messages is scheduled cyclically every (configurable) TC. If no request to send messages from User application is pending, a life sign is sent by CSL. If requests are pending, only one message per cycle is sent. Rules: R8_ICSL, R10_ICSL, R11_ICSL, R12_ICSL, R16_ICSL, R17_ICSL, R8_CCSL, R9_CCSL, R10_CCSL, R11_CCSL, R12_CCSL, R16_CCSL, R17_CCSL Issues:Irrelevant: The reference to SAI criteria (TTS or EC) user for initialising the connection is not relevant for the CSL.Ambiguity: For the case EC, it is not specified which of the pending messages is selected for being sent.Multiple Remarks:Life signs and user messages are sent only when CSL is in state COMMS.The send time interval is set and reset by CSL each time a new safe connection has been established, (i.e., a SAI_CONNECT.indication is received - REQ_024).After the CSL sends a life-sign message to SAI, it is responsibility of SAI to immediately forward it (TTS option) or to bufferise it and sending it at the appropriate EC cycle, but this is part of the requirements on the SAI behaviour.The send timer is reset and stopped when moving from COMMS to NOCOMMS. REQ_009 After reception of report from SAI that the clock offset procedure or EC initialisation has been completed, the condition where no valid messages are received within a configurable time shall be recognised by the CSL. This is achieved by means of a configurable receive timer (started at the reception of report from SAI on completion of initialisations and reset at the reception of any message); if no message (User or life sign) is received within such configurable receive time interval, the communication shall be considered in state NOCOMMS. Rules: R8_ICSL, R11_ICSL, R12_ICSL, R13_ICSL, R14_ICSL, R16_ICSL, R17_ICSL, R8_CCSL, R9_CCSL, R11_CCSL, R12_CCSL, R13_CCSL, R14_CCSL, R16_CCSL, R17_CCSL REQ_010 When communication is in state NOCOMMS, the CSL shall not accept/forward messages neither from its own RBC User functions nor from partner RBC; when switching to NOCOMMS, if the safe connection is still active, the CSL shall send a termination order (SAI_DISCONNECT.request). Note: when informed that the communication is in state NOCOMMS, the User functions will terminate all transactions. Rules: R1_ICSL, R4_ICSL, R17_ICSL, R1_CCSL, R4_CCSL, R17_CCSL Issues:Irrelevant: The note attached to REQ_010 does not specify any CSL behavior and is considered as an INFO.Redundant: The same behavior stated by this requirement is stated in REQ_015. Inconsistency: With respect to the wordings "if the safe connection is still active," the CSL does not need to have direct access to the current status of the SAI safe connection. The SAI_DISCONNECT.request must be sent only when moving to NOCOMM because of the expiration of the receive timer. In the other case, when CSL moves to NOCOMM because of DISCONNECT notification received from SAI, there is no need to send back to SAI the SAI_DISCONNECT.request.Multiple Remarks:Notice that, in principle, in the case of called CSL, at the SAI level the safe connection might have been already returned to active even if no indication has already arrived. REQ_011 CSL can switch the communication from state NOCOMMs to state COMMS only when underlying Layers confirm the re-establishment of a safe connection. Issues:
Appears in 1 contract
Samples: openportal.isti.cnr.it
Redundant. This requirement is redundant with REQ_017. Remarks:When a duplication of REQ_005.Irrelevant: The forwarding occurs when the CSL is in state COMMS, with no relation with the CSL forwards all the received User message to RBC Userfunctions (when receiving from current SAI the corresponding SAI_DATA indication). REQ_006 Loss of safe connection shall be detected by the state.Multiple REQ_018 The CSL is responsible of reading reports from the underlying SFM (SAI_DISCONNECT.indication)SFM. Rules: R2_ICSL, R3_ICSL, R8_ICS, R15_ICSL, R16_ICSL, R16_CCSLR2_CCSL, R1_ICSLR3_CCSL, R1_CCSL R8_CCSL, R9_CCSL, R15_CCS, R16_CCSL Issues:InconsistencyRedundant: Loss The meaning and required effect of safe connection shall also be detected without reading reports from SAI is defined by the other requirements.Incomplete: No requirements state the effect of underlying SFM, i.e., by timeoutreading SAI Error Reports. Remarks: The SAI_DISCONNECT.indication are considered the CSL only in state COMMS. :In state NOCOMMS such all SAI reports are discarded. REQ_007 If a report from underlying Layers is received that safe connection is lost, discarded with the CSL shall consider the communication in state NOCOMMS. Rules: R16_ICSL, R16_CCSL Issues: no issues have been found Remarks: The CSL when receiving a SAI_DISCONNECT.indication moves from COMMS to NOCOMMS.Further effects are related to the timers mentioned in REQ_008, REQ_009. REQ_008 TTS option: after reception exception of report from SAI that the clock offset procedure has been completed, the CSL shall ensure that a message is sent to the partner RBC at the expiration of a configurable transmit time interval SAI_CONNECT.indication (reset at the sending of any messagecalled CSL) or SAI_CONNECT_confirmation (calling CSL). If no User message needs to be sent, REQ_019 The CSL is responsible of sending reports to send a life sign message RBC User functions about state of communication (see Figure 4);EC option: After reception of report from SAI that the EC initialisation procedure has been completed, the sending of messages is scheduled cyclically every (configurableCOMMS/NOCOMMS) TC. If no request to send messages from User application is pending, a life sign is sent by CSL. If requests are pending, only one message per cycle is sent. Rules: R8_ICSL, R10_ICSL, R11_ICSL, R12_ICSL, R16_ICSL, R17_ICSL, R8_CCSL, R9_CCSL, R10_CCSL, R11_CCSL, R12_CCSL, R16_CCSL, R17_CCSL Issues:IrrelevantRedundant: The reference This requirement partly overlaps with the note inside REQ_011.Inconsistency: Reports are not sent to SAI criteria (TTS or EC) the user for initialising the connection is not relevant for the CSL.Ambiguity: For the case EC, it is not specified which of the pending messages is selected for being sent.Multiple Remarks:Life signs and user messages are sent only when CSL is in state COMMS.The send time interval is set and reset by CSL each time a new safe connection has been established, (i.e., a SAI_CONNECT.indication is received - REQ_024).After the CSL sends a life-sign message to SAI, it is responsibility of SAI to immediately forward it (TTS option) or to bufferise it and sending it at the appropriate EC cycle, but this is part of the requirements on the SAI behaviour.The send timer is reset and stopped when moving from COMMS to NOCOMMS. REQ_009 After reception of report from SAI that the clock offset procedure or EC initialisation has been completed, the condition where no valid messages are received within a configurable time shall be recognised by the CSL. This is achieved by means of a configurable receive timer (started at the reception of report from SAI on completion of initialisations and reset at the reception of any message); if no message (User or life sign) is received within such configurable receive time interval, the communication shall be considered in state NOCOMMS. RulesRemarks: R8_ICSL, R11_ICSL, R12_ICSL, R13_ICSL, R14_ICSL, R16_ICSL, R17_ICSL, R8_CCSL, R9_CCSL, R11_CCSL, R12_CCSL, R13_CCSL, R14_CCSL, R16_CCSL, R17_CCSL REQ_010 When communication is in state NOCOMMS, the CSL shall not accept/forward messages neither from its own Reports to RBC User functions nor from partner RBC; when switching to NOCOMMS, if the safe connection is still active, the CSL shall send a termination order (SAI_DISCONNECT.request). Note: when informed that the about state of communication is in state NOCOMMS, the User functions will terminate all transactions. Rules: R1_ICSL, R4_ICSL, R17_ICSL, R1_CCSL, R4_CCSL, R17_CCSL Issues:Irrelevant: The note attached to REQ_010 does not specify any CSL behavior and is considered as an INFO.Redundant: The same behavior stated by this requirement is stated in REQ_015. Inconsistency: With respect to the wordings "if the safe connection is still active," the CSL does not need to have direct access to the current status of the SAI safe connection. The SAI_DISCONNECT.request must be are sent only when moving to NOCOMM because of the expiration of the receive timer. In the other case, when each time CSL moves from COMMS to NOCOMM because of DISCONNECT notification received NOCOMMS and from SAI, there is no need NOCOMMS to send back to SAI the SAI_DISCONNECT.request.Multiple Remarks:Notice that, in principle, in XXXXX.Xx the case of called CSL, at report on new connection is sent even without state change (COMMS). The following requirements do not mandate any additional CSL behaviour, but they map logical events to specific interface signals (e.g., SAI_DATA.request). This mapping is partially provided by the SAI level previous requirements. They should have the role of info and summary of the exchanged messages, notifications, orders, reports, between the system components. REQ_020 CSL shall receive from User functions the messages to be forwarded to peer RBC User when in state COMMS.Rules: not applicable Issues: Redundant with REQ_016. REQ_021 CSL shall forward to User functions the forwarding of messages received from communication partner. Rules: not applicable Issues: Redundant: with REQ_017. REQ_022 CSL shall send to User functions the reports on loss of communication (missing life sign - state NOCOMMS). Rules: not applicable Issues: Redundant: this requirement is a sub-case of REQ_019. REQ_023 CSL shall send to User functions the reports on state of safe connection might have been already returned state change (COMMS/NOCOMMS). Rules: not applicable Issues:Redundant: this requirement is a sub-case of REQ_019. REQ_024 • SAI_CONNECT.request shall be used by initiator CSL to active even if no indication has already arrived. REQ_011 CSL can switch command the communication from state NOCOMMs to state COMMS only when underlying Layers confirm the re-establishment of a safe connection• SAI_CONNECT.indication shall be used by called SAI to notify to the CSL the connection establishment request• SAI_CONNECT.response shall be used by called CSL to accept the connection request.• SAI_CONNECT.confirm shall be used by the initiator SAI entity to inform the CSL about the successful establishment of the safe connection. Rules: not applicable IssuesRedundant: first bullet with REQ_012, second bullet with REQ_014, fourth bullet with REQ_013.Irrelevant: the third bullet is not useful for the modelling phase.Multiple REQ_025 • SAI_DATA.request shall be used by CSL to transmit data to the peer entity.• SAI_DATA.indication shall be used to indicate to the CSL that data have been received successfully from the peer entity. Rules: R10_ICSL,R12_ICSL,R13_ICSL, R10_CCSL,R12_CCSL, R13_CCSL,R14_CCSL IssuesMultiple REQ_026 • SAI_DISCONNECT.request shall be used by the CSL to enforce a release of the safe connection.• SAI_DISCONNECT.indication shall be used to inform the CSL about a safe connection release. Rules: R16_ICSL,R16_CCSL IssuesRedundant: first bullet with REQ_015.Ambiguity: other requirements mention loss of safe connection.Multiple REQ_027 SAI Error Report shall be sent from SAI to CSL in case of errors detection by SAI (deletion, resequencing, delay, repetition). Rules: not applicable Issues:Irrelevant: This requirement is related to SAI. REVERSE MAPPING FROM MODEL RULES TO REQUIREMENTS R1_ICSL REQ_004, REQ_006, REQ_010, R2_ICSL REQ_018, R3_ICSL REQ_018, R4_ICSL REQ_004, REQ_010, R6_ICSL REQ_001, REQ_002, REQ_013, R7_ICSL REQ_002, R8_ICSL REQ_002, REQ_008, REQ_009, REQ_011, REQ_013, REQ_018, REQ_019, R10_ICSL REQ_008, REQ_016, REQ_025 R11_ICSL REQ_008, REQ_009, R12_ICSL REQ_008, REQ_009, REQ_012, REQ_025 R13_ICSL REQ_005, REQ_009, REQ_017, REQ_025 R14_ICSL REQ_009, REQ_025 R15_ICSL REQ_018, R16_ICSL REQ_006, REQ_007, REQ_008, REQ_009, REQ_018, REQ_019, REQ_026 R17_ICSL REQ_008, REQ_009, REQ_010, REQ_015, REQ_019, R1_CCSL REQ_004, REQ_006, REQ_010, R2_CCSL REQ_018, R3_CCSL REQ_018, R4_CCSL REQ_004, REQ_010, R7_CCSL REQ_003, REQ_014, R8_CCSL REQ_008, REQ_009, REQ_014, REQ_018, REQ_019, R9_CCSL REQ_008, REQ_009, REQ_011, REQ_018, REQ_019, R10_CCSL REQ_008, REQ_016, REQ_025 R11_CCSL REQ_008, REQ_009, R12_CCSL REQ_008, REQ_009, REQ_025 R13_CCSL REQ_005, REQ_009, REQ_017, REQ_025 R14_CCSL REQ_009, REQ_025 R15_CCSL REQ_018, R16_CCSL REQ_006, REQ_007, REQ_008, REQ_009, REQ_018, REQ_019, REQ_026 R17_CCSL REQ_008, REQ_009, REQ_010, REQ_015, REQ_019, Appendix C - UMC encoding of I_CSL ----------------------------------------------- Cl ass I _CSL i s ----------------------------------------- ------ Si gnal s SAI _CONNECT_c onf i r m; SAI _DI SCONNECT_i ndi cat i on; SAI _Er r or _r epor t ; SAI _DATA_i ndi cat i on( nr bc_ms g) ; RBC_Us er _Dat a_r equest ( nr bc_ms g) ; -- -- SAI CONNECTI ONS ARE AUTONUMOUS, not r equst ed by RBC_Us er -- OUTGOI NG si gnal s -- SAI _CONNECT_r equest ; -- SAI _DI SCONNECT_r equest ; -- SAI _DATA_r equest ( nr bc_ms g) ; -- RBC_Us er _Connec t _i ndi cat i on; -- RBC_Us er _Di sconnect _i ndi cat i on; -- RBC_Us er _Dat a_i ndi cat i on( nr bc_ms g) ; Var s RBC_Us er : obj ; SAI : obj ; r ecei ve_t i mer : = 0; send_t i mer : = 0; ------------- max _r ecei ve_t i mer : = 2; -- XXXXX XXXXXX ON PARAM max _send_t i mer : = 1; -- CONFI GURATI ON PARAM max _connect _t i mer : = 3; -- XXXXX XXXXXX ON PARAM connect _t i mer : = 3; -- SAME VALUE of max _connect _t i mer connect i ng: bool : = Fal se; ------------- Behavi our ------------------------------------------------------------- -- when di sconnet t xx x xxxx e NRBC_MSGs and SAI _Not i f i cat i ons, ------------------------------------------------------------- R1_I CSL_di scar d_user dat a: NOCOMMS - > NOCOMMS { RBC_Us er _Dat a_r equest ( nr bc_ms g) } R2_I CSL_di scar d_di sconnect i ndi cat i on: NOCOMMS - > NOCOMMS { SAI _DI SCONNECT_i ndi cat i on } R3_I CSL_di scar d_er r or r epor t : NOCOMMS - > NOCOMMS { SAI _Er r or _r epor t } R4_I CSL_di scar d_dat ai ndi cat i on: NOCOMMS - > NOCOMMS { SAI _DATA_i ndi cat i on( nr bc_ms g) } ------------------------------------------------------------- -- est abl i shi ng connect i ons ------------------------------------------------------------ - -- when di sconnect ed i ssue new SAI connect i on r equest -- R6_I CSL_Ti mer _oki csl _I SAI _connect r equest : NOCOMMS - > NOCOMMS { i csl _t i ck [ connect _t i mer = max _connect _t i mer ] / connect _t i mer : = 0; _Ti mer . ok_i csl ; SAI . SAI _CONNECT_r equest ; } -- when connect i ng handl e xx xxx cycl es -- and i gnor e al l ot her event s but connect i on conf i r mat i ons R7_I CSL_Ti mer _oki csl : NOCOMMS - > NOCOMMS
Appears in 1 contract
Samples: www.4securail.eu
Redundant. This requirement is redundant with REQ_017. Remarks:When in state COMMS, the CSL forwards all the received User message to RBC Userfunctions User functions (when receiving from SAI the corresponding SAI_DATA indication). REQ_006 Loss of safe connection shall be detected by the CSL reading reports from the underlying SFM (SAI_DISCONNECT.indication). Rules: R16_ICSL, R16_CCSL, R1_ICSL, R1_CCSL Issues:Inconsistency: Loss of safe connection shall also be detected without reading reports of underlying SFM, i.e., by timeout. Remarks: The SAI_DISCONNECT.indication are considered the CSL only in state COMMS. In state NOCOMMS such reports are discarded. REQ_007 If a report from underlying Layers is received that safe connection is lost, the CSL shall consider the communication in state NOCOMMS. Rules: R16_ICSL, R16_CCSL Issues: no issues have been found Remarks: The CSL when receiving a SAI_DISCONNECT.indication moves from COMMS to NOCOMMS.Further NOCOMMS. Further effects are related to the timers mentioned in REQ_008, REQ_009. REQ_008 TTS option: after reception of report from SAI that the clock offset procedure has been completed, the CSL shall ensure that a message is sent to the partner RBC at the expiration of a configurable transmit time interval (reset at the sending of any message). If no User message needs to be sent, CSL is responsible to send a life sign message (see Figure 4);EC option: After reception of report from SAI that the EC initialisation procedure has been completed, the sending of messages is scheduled cyclically every (configurable) TC. If no request to send messages from User application is pending, a life sign is sent by CSL. If requests are pending, only one message per cycle is sent. Rules: R8_ICSL, R10_ICSL, R11_ICSL, R12_ICSL, R16_ICSL, R17_ICSL, R8_CCSL, R9_CCSL, R10_CCSL, R11_CCSL, R12_CCSL, R16_CCSL, R17_CCSL Issues:Irrelevant: The reference to SAI criteria (TTS or EC) user for initialising the connection is not relevant for the CSL.Ambiguity: For the case EC, it is not specified which of the pending messages is selected for being sent.. Multiple Remarks:Life signs and user messages are sent only when CSL is in state COMMS.The send time interval is set and reset by CSL each time a new safe connection has been established, (i.e., a SAI_CONNECT.indication is received - REQ_024).After REQ_024). After the CSL sends a life-sign message to SAI, it is responsibility of SAI to immediately forward it (TTS option) or to bufferise it and sending it at the appropriate EC cycle, but this is part of the requirements on the SAI behaviour.The send timer is reset and stopped when moving from COMMS to NOCOMMS. REQ_009 After reception of report from SAI that the clock offset procedure or EC initialisation has been completed, the condition where no valid messages are received within a configurable time shall be recognised by the CSL. This is achieved by means of a configurable receive timer (started at the reception of report from SAI on completion of initialisations and reset at the reception of any message); if no message (User or life sign) is received within such configurable receive time interval, the communication thecommunication shall be considered in state NOCOMMS. Rules: R8_ICSL, R11_ICSL, R12_ICSL, R13_ICSL, R14_ICSL, R16_ICSL, R17_ICSL, R8_CCSL, R9_CCSL, R11_CCSL, R12_CCSL, R13_CCSL, R14_CCSL, R16_CCSL, R17_CCSL Issues:Irrelevant: The reference to SAI criteria (TTS or EC) user for initialising the connection is not relevant for CSL.Multiple Remarks: The receive time interval is set and reset by CSL each time a new safe connection has been established, (i.e., a SAI_CONNECT.indication is received - REQ_024).Further effects of the expiration of the receive timer are stated in REQ_015.The receive timer is reset and stopped when moving from COMMS to NOCOMMS. REQ_010 When communication is in state NOCOMMS, the CSL shall not accept/forward messages neither from its own RBC User functions nor from partner RBC; when switching to NOCOMMS, if the safe connection is still active, the CSL shall send a termination order (SAI_DISCONNECT.request). Note: when informed that the communication is in state NOCOMMS, the User functions will terminate all transactions. Rules: R1_ICSL, R4_ICSL, R17_ICSL, R1_CCSL, R4_CCSL, R17_CCSL Issues:Irrelevant: The note attached to REQ_010 does not specify any CSL behavior and is considered as an INFO.Redundant: The same behavior stated by this requirement is stated in REQ_015. Inconsistency: With respect to the wordings "if the safe connection is still active," the CSL does not need to have direct access to the current status of the SAI safe connection. The SAI_DISCONNECT.request must be sent only when moving to NOCOMM because of the expiration of the receive timer. In the other case, when CSL moves to NOCOMM because of DISCONNECT notification received from SAI, there is no need to send back to SAI the SAI_DISCONNECT.request.Multiple Remarks:Notice that, in principle, in the case of called CSL, at the SAI level the safe connection might connectionmight have been already returned to active even if no indication has already arrived. REQ_011 CSL can switch the communication from state NOCOMMs to state COMMS only when underlying Layers confirm the re-establishment of a safe connection. Issues:Note: communication in state COMMS is communicated to User functions, that will be able to restart management of transactions. Rules: R8_ICSL, R8_CCSL
Appears in 1 contract
Samples: www.4securail.eu
Redundant. This requirement is redundant with REQ_017. Remarks:When a duplication of REQ_005.Irrelevant: The forwarding occurs when the CSL is in state COMMS, with no relation with the CSL forwards all the received User message to RBC Userfunctions (when receiving from current SAI the corresponding SAI_DATA indication). REQ_006 Loss of safe connection shall be detected by the state.Multiple REQ_018 The CSL is responsible of reading reports from the underlying SFM (SAI_DISCONNECT.indication)SFM. Rules: R2_ICSL, R3_ICSL, R8_ICS, R15_ICSL, R16_ICSL, R16_CCSLR2_CCSL, R1_ICSLR3_CCSL, R1_CCSL R8_CCSL, R9_CCSL, R15_CCS, R16_CCSL Issues:InconsistencyRedundant: Loss The meaning and required effect of safe connection shall also be detected without reading reports from SAI is defined by the other requirements.Incomplete: No requirements state the effect of underlying SFM, i.e., by timeoutreading SAI Error Reports. Remarks: The SAI_DISCONNECT.indication are considered the CSL only in state COMMS. :In state NOCOMMS such all SAI reports are discarded. REQ_007 If a report from underlying Layers is received that safe connection is lost, discarded with the CSL shall consider the communication in state NOCOMMS. Rules: R16_ICSL, R16_CCSL Issues: no issues have been found Remarks: The CSL when receiving a SAI_DISCONNECT.indication moves from COMMS to NOCOMMS.Further effects are related to the timers mentioned in REQ_008, REQ_009. REQ_008 TTS option: after reception of report from SAI that the clock offset procedure has been completed, the CSL shall ensure that a message is sent to the partner RBC at the expiration of a configurable transmit time interval exception ofSAI_CONNECT.indication (reset at the sending of any messagecalled CSL) or SAI_CONNECT_confirmation (calling CSL). If no User message needs to be sent, REQ_019 The CSL is responsible of sending reports to send a life sign message RBC User functions about state of communication (see Figure 4);EC option: After reception of report from SAI that the EC initialisation procedure has been completed, the sending of messages is scheduled cyclically every (configurableCOMMS/NOCOMMS) TC. If no request to send messages from User application is pending, a life sign is sent by CSL. If requests are pending, only one message per cycle is sent. Rules: R8_ICSL, R10_ICSL, R11_ICSL, R12_ICSL, R16_ICSL, R17_ICSL, R8_CCSL, R9_CCSL, R10_CCSL, R11_CCSL, R12_CCSL, R16_CCSL, R17_CCSL Issues:IrrelevantRedundant: The reference This requirement partly overlaps with the note inside REQ_011.Inconsistency: Reports are not sent to SAI criteria (TTS or EC) the user for initialising the connection is not relevant for the CSL.Ambiguity: For the case EC, it is not specified which of the pending messages is selected for being sent.Multiple Remarks:Life signs and user messages are sent only when CSL is in state COMMS.The send time interval is set and reset by CSL each time a new safe connection has been established, (i.e., a SAI_CONNECT.indication is received - REQ_024).After the CSL sends a life-sign message to SAI, it is responsibility of SAI to immediately forward it (TTS option) or to bufferise it and sending it at the appropriate EC cycle, but this is part of the requirements on the SAI behaviour.The send timer is reset and stopped when moving from COMMS to NOCOMMS. REQ_009 After reception of report from SAI that the clock offset procedure or EC initialisation has been completed, the condition where no valid messages are received within a configurable time shall be recognised by the CSL. This is achieved by means of a configurable receive timer (started at the reception of report from SAI on completion of initialisations and reset at the reception of any message); if no message (User or life sign) is received within such configurable receive time interval, the communication shall be considered in state NOCOMMS. RulesRemarks: R8_ICSL, R11_ICSL, R12_ICSL, R13_ICSL, R14_ICSL, R16_ICSL, R17_ICSL, R8_CCSL, R9_CCSL, R11_CCSL, R12_CCSL, R13_CCSL, R14_CCSL, R16_CCSL, R17_CCSL REQ_010 When communication is in state NOCOMMS, the CSL shall not accept/forward messages neither from its own Reports to RBC User functions nor from partner RBC; when switching to NOCOMMS, if the safe connection is still active, the CSL shall send a termination order (SAI_DISCONNECT.request). Note: when informed that the about state of communication is in state NOCOMMS, the User functions will terminate all transactions. Rules: R1_ICSL, R4_ICSL, R17_ICSL, R1_CCSL, R4_CCSL, R17_CCSL Issues:Irrelevant: The note attached to REQ_010 does not specify any CSL behavior and is considered as an INFO.Redundant: The same behavior stated by this requirement is stated in REQ_015. Inconsistency: With respect to the wordings "if the safe connection is still active," the CSL does not need to have direct access to the current status of the SAI safe connection. The SAI_DISCONNECT.request must be are sent only when moving to NOCOMM because of the expiration of the receive timer. In the other case, when each time CSL moves from COMMS to NOCOMM because of DISCONNECT notification received NOCOMMS and from SAI, there is no need NOCOMMS to send back to SAI the SAI_DISCONNECT.request.Multiple Remarks:Notice that, in principle, in XXXXX.Xx the case of called CSL, at report on new connection is sent even without state change(COMMS). The following requirements do not mandate any additional CSL behaviour, but they map logical events to specific interface signals (e.g., SAI_DATA.request). This mapping is partially provided by the SAI level previous requirements. They should have the safe connection might have been already returned role of info and summary of the exchanged messages, notifications, orders, reports, between the system components. REQ_020 CSL shall receive from User functions the messages to active even if no indication has already arrivedbe forwarded to peer RBC User when in state COMMS. REQ_011 CSL can switch the communication from state NOCOMMs to state COMMS only when underlying Layers confirm the re-establishment of a safe connection. Issues:Rules: not applicable
Appears in 1 contract
Samples: openportal.isti.cnr.it
