Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Titan » Additional info about the usage of the translation ports
Additional info about the usage of the translation ports [message #1782431] Fri, 23 February 2018 11:18
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 854
Registered: January 2015
Senior Member
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

Previous Topic:isbound(component_reference) == false in 6.1.0?
Next Topic:LibCommon compilanion issue
Goto Forum:
  


Current Time: Fri Nov 16 07:18:26 GMT 2018

Powered by FUDForum. Page generated in 0.03086 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top