Dear all,
the translation port described in the standard (ETSI ES 202 781 V1.5.1 (2017-05) ) is a more complete and sophisticated solution to the problem previously solved with dual-faced ports; however it presents some difficulties in its' usage that may go against habits developed when using legacy simple or dual-faced ports so I believe some clarifications are in order.
First, let's examine the example from the standard:
"Ports with translation capability can work in two different modes: normal and translation mode. In normal mode, the port behaves as a standard message port .... In translation mode,the port uses rules described in the following clauses of the present document to convert messages and addresses when communicating with linked ports."
testcaseTCrunsonTestComponentsystemSystemComponent{
if(PX_TRANSPORT_USED){
//activatetranslationmode(TransportPortisimplicitlyreferencedviatransportPort//inthemapoperation)map(mtc: dataPort,
system: transportPort);
}else{
//activatenormalmode(TransportPortisnotreferencedinthemapoperation)map(mtc: dataPort,
system: dataPort);
}
}
In order to satisfy the possibility of mapping during runtime to two different system ports , and as Titan during compilation tries to bind to the C++ test port code , this means that we will need two pieces of code to be present during compilation: the code of translation port and the code of direct port.
In the (more likely) case the direct port is not being used, the code of the direct port can be an empty skeleton generated by Titan.
However this scenario generates an ambiguity that was not present before; decision to map to one port or the other will be taken during runtime (ports can be mapped, unmapped and remapped during runtime) so Titan will need a clear indication of how to proceed.
This clarity is unnecessary if a translation port is not being used: a (simple of dual-faced) port of a certain type will always bind to the system port of the same type;
for translation ports it can bind either to the direct or the translated port.
As a consequence, while with simple and dual-faced ports Titan is quite relaxed about system component declarations and system clauses of functions, test cases etc., for translation ports a strictness appears that may put off the unsuspecting user.
I. the criticality of system clause for translation ports
Let's consider the following example:
type port OneM2MPort message map to IPL4asp_PT {
out
MsgOut to ASP_Send with f_enc_M2MPrimitive_to_ASPSend()
in
MsgIn from ASP_RecvFrom with f_dec_ASPRecvFrom_to_M2MPrimitive(),
ASP_Event
}
type component Tester {
port AdapterControlPort acPort;
port InfoPort infoPort;
port UpperTesterPort utPort;
:
};
type component AeSimu extends Tester {
:
port OneM2MPort mcaPort;
port OneM2MPort mcaPortIn;
:
};
type component CseSimu extends Tester {
port OneM2MPort mcaPort;
port OneM2MPort mcaPortIn;
port OneM2MPort mccPort;
port OneM2MPort mccPortIn;
:
};
type component AeSystem {
port OneM2MPort mcaPort;
port OneM2MPort mcaPortIn;
port AdapterControlPort acPort;
port UpperTesterPort utPort;
}
type component CseSystem {
port OneM2MPort mcaPort;
port OneM2MPort mcaPortIn;
port OneM2MPort mccPort;
port OneM2MPort mccPortIn;
port AdapterControlPort acPort;
port UpperTesterPort utPort;
}
testcase TC_CSE_GEN_CRE_002_CSR() runs on AeSimu system CseSystem {
// Local variables
var AeSimu v_ae1 := AeSimu.create("AE1") alive;
v_ae1.start(f_CSE_GEN_CRE_002(e_cseRelative));
v_ae1.done;
}
function f_CSE_GEN_CRE_002(in PrimitiveScope p_primitiveScope) runs on AeSimu system CseSystem{
:
// Test component configuration
f_cf01Up();
:
// Tear down
f_cf01Down();
}//end f_CSE_GEN_CRE_002
function f_cf01Up(in boolean p_auxiliaryAe2Required := false) runs on AeSimu system CseSystem {
:
// Map
map(self:mcaPort, system:mcaPort);
map(self:mcaPortIn, system:mcaPortIn);
map(self:acPort, system:acPort);
:
} // end f_cf01Up
As we can deduce, there are two component types running test cases, the AE simulator which has CSEsystem as system component and the CSE simulator which has AEsystem as system component.
The test case TC_CSE_GEN_CRE_002_CSR which runs on AeSimu calls the function f_CSE_GEN_CRE_002 which calls f_cf01Up;
If this chain does not have the "runs on" and especially "system" declarations in place (they are missing or wrong), the translation ports involved will not work ( will not be able to receive or send) as there is no clear indication where they should bind to.
If one migrates from a dual-faced setup this may come as an unpleasant surprise , as it worked perfectly well before.
II. system component in cfg files
As a side-effect of the above, the system component has to be referred explicitly in the configuration files:
This works well for the dual-faced port:
//mcaPort
*.mcaPort.defaultListeningPort := "0" // Allow to use specific port number
*.mcaPort.map_behavior := "connect"
*.mcaPort.RemotePort := "7579" //SUT - Port
*.mcaPort.RemoteHost := "10.10.202.176" //SUT - IP
*.mcaPort.lazy_conn_id_handling := "yes"
*.mcaPort.debug := "yes"
but for translation port this will be needed:
//mcaPort
system.mcaPort.defaultListeningPort := "0" // Allow to use specific port number
system.mcaPort.map_behavior := "connect"
system.mcaPort.RemotePort := "7579" //SUT - Port
system.mcaPort.RemoteHost := "192.168.0.153" //SUT - IP
system.mcaPort.lazy_conn_id_handling := "yes"
system.mcaPort.debug := "yes"
III. extension internal vs skeleton
Instead of adding empty skeletons one can also use the 'with {extension "internal"}' clause against the port with the same result.
type port OneM2MPort message map to IPL4asp_PT {
out
MsgOut to ASP_Send with f_enc_M2MPrimitive_to_ASPSend()
in
MsgIn from ASP_RecvFrom with f_dec_ASPRecvFrom_to_M2MPrimitive(),
ASP_Event
} with {extension "internal"}
IV. discarding messages
The standard does not explicitly discuses the scenario when a message originating in the southern interface has to be discarded.
The following semantics, although it may appear it will discard ASP_Event, it will not do that:
type port OneM2MPort message map to IPL4asp_PT {
out
MsgOut to ASP_Send with f_enc_M2MPrimitive_to_ASPSend()
in
MsgIn from ASP_RecvFrom with f_dec_ASPRecvFrom_to_M2MPrimitive(),
ASP_Event
}
"If no InFunction is specified for the given InnerInType, the translation procedure checks, if the top item of the outer queue is of InnerInType (i.e. invokes the normal decoding algorithm, and the check is successful if the decoding is successful). If the result of the check is positive, the message is moved from the outer queue into the inner queue (i.e. the port will relay the message from the outer port to the inner port transparently) and
iteration ends."
Discarding ASP_Event will have to be done explicitly with a dummy function as below:
type port OneM2MPort message map to IPL4asp_PT {
out
MsgOut to ASP_Send with f_enc_M2MPrimitive_to_ASPSend()
in
MsgIn from ASP_RecvFrom with f_dec_ASPRecvFrom_to_M2MPrimitive(),
ASP_Event from ASP_Event with f_discardASPEvent()
} with {extension "internal"}
where:
function f_discardASPEvent(in ASP_Event p_aspEventIn, out ASP_Event p_aspEventOut)
{
port.setstate(4);
}
The standard specifies the below permitted values for setstate:
- 0 (meaning translated)
- 1 (meaning not translated)
- 2 (meaning fragmented)
- 3 (meaning partially translated)
Based on the success/failure of decoding the incoming buffer , this will have to be emptied, or saved partially or totally, and port state set accordingly. We have introduced a new value ,
- 4 (meaning discarded message)
for setstate signifying message discard; in this scenario the message buffer can also be discarded.
I hope this info will ease the pains of migrating to the translation port or writing a configuration form scratch.
Best regards
Elemer
[Updated on: Fri, 23 February 2018 13:24]
Report message to a moderator
] 
Search
Help
Register
Login
Home
