5.3 Test architecture

The approach for the implementation of an Abstract Protocol Tester selected in oneM2M follows the recommendation of the oneM2M Testing Framework oneM2M TS-0015 [i.2] where the TTCN-3 language and its architecture are recommended.

Following this recommendation the oneM2M tester architecture comprises a non-platform dependent Test Suite, and a platform dependent part.

Figure 5.3-1: High level oneM2M Test Architecture

Note

However, it can be implemented in a semi-independent manner, which will minimize the dependency to those elements.

Figure 5.3-1: High level oneM2M Test Architecture

  • oneM2M TTCN -3 Abstract Test Suite: the test suite is platform independent, and it is the cornerstone of the architecture. It allows a complete decoupling between the test suite and the rest of the test system. The test suite is composed of a complete set of test cases covering oneM2M requirements specified by oneM2M TS0001 [1] and oneM2M TS-0004 [2].
  • oneM2M System Adaptor : this is the platform dependent part that includes adaptors and codecs (out of the scope of the present document). This part of the architecture definition depends on the specific platform (e.g. Windows or Linux) and test tool on which the tester is going to run.

Figure 5.3-2 shows the oneM2M TTCN-3 test architecture design used for the oneM2M ATS. The Test Suite needs to interact with the System Adaptor to implement the collection of TTCN-3 test cases that are intended to be used to test the oneM2M IUTs.

The oneM2M TTCN-3 test cases implement the test algorithms specified in the TSS&TP document oneM2M TS0018 [7], including verdict logic that allows pass/fail diagnosis.

The test algorithms use the interfaces defined in [1] and [2] (mca, mcc) in order to:

  1. control the test event to be sent towards the IUT; and
  2. observe the test events received from the IUT.

In TTCN-3 these two interfaces have been implemented through a set of logical TTCN-3 ports (mcaPort and mcaPortIn for mca interface, and mccPort and mccPortIn for mcc interface) which allows oneM2M message primitives exchange with the IUT.

Figure 5.3-2: oneM2M Test Architecture

Figure 5.3-2: oneM2M Test Architecture

The oneM2M primitive messages have been mapped into TTCN-3 structure. Through this mapping, the TTCN-3 is able to build and send these messages, as well as receive them via the ports defined above.

Additionally, the test cases are able to control and configure the test platform through a dedicated port called acPort while port utPort enables oneM2M TTCN-3 Test Component module to trigger specific action or behaviour on IUT. TTCN3 Test Components can also exchange information through a dedicated port called infoPort.

To build up a tester, the test platform needs to be also developed (out of scope). This test platform is composed of three adaptation layers:

  • PA (Platform Adaptor) layer functionality implements the communication between the TTCN-3 modules and external elements that constitute the test tool such as timers and external functions. The External functions are a powerful resources supported by TTCN-3 language. An External function is a function declared at the TTCN-3 level but implemented at the native level.

  • SA (System Adaptor) layer functionality is divided into two modules:

    • oneM2M lower layers stack module implements the communication with the IUT and carries out the oneM2M primitives messages sent to or received from the IUT. This module is based on TCP or UDP depending on the binding supported by the IUT. The binding is a system adaptor parameter.
    • Upper Tester Transport module implements functions that enable triggering specific actions or behaviour on the IUT.

  • CODECS layer is the part of the tester to encode and decode messages between the TTCN-3 abstract internal data representation and the format required by the related base standard which the IUT understands. Several CODECS are required in oneM2M tester to cope with the bindings considered in oneM2M (HTTP, CoAP, MQTT) and the serialization methods (xml, json).