There are a few drawbacks in the structure of TTCN as it has been presented thus far. The limits pertain to the fact that behavior is not always suited to be defined in a strict sequence and that tests are not always self-contained. To make the use of TTCN more flexible, there are two additions to the language. These are as follows:

• concurrent TTCN
• modular TTCN

Concurrent TTCN
One of the major obstacles in writing tests for large and complex systems is that the multitude of entities operating on the application generates an enormous test. Consider a telephone switch that will operate hundreds of extensions. With only a reasonably complex service in the switch, the size of the test will be insurmountable. This is because the tests are going to describe the combination of the simpler behavior at each extension. The lower tester will take on the joint behavior of all the telephones.

Concurrent TTCN allows for the expression of behavior in a distributed way. This is the most natural way in most cases, as the behavior is normally divided between the upper and lower tester. Instead of running a single threaded test case, parallel test components (PTCs) are introduced. These are capable of running behavior concurrently. The actual test case is executed in the master test component (MTC), responsible for creating the other components and issuing the final verdict, depending on the other test components. While this division into test components reflects the normal division in behavior, it inflicts some difficulties that must be resolved.

The first is synchronization. In most cases the upper and lower tester have some kind of synchronization. This is an implicit property of the test and comes from the fact that the application has interleaved behavior on the two interfaces. The correct value of a signal received on the lower tester will often depend on a previous signal from the upper tester. The lower tester must obviously be notified of this, and in ordinary nonconcurrent TTCN this is done implicitly in the behavior tree by interleaving the statements.

In concurrent TTCN, the behavior is separated in different trees and the synchronization must be added explicitly. To do this, the concept of coordination points and coordination messages is introduced. In most, these resemble PCOs and ASPs in the communication with the IUT, but in this case the information is passed internally within the test.

Modular TTCN
The second extension is modular TTCN. This adds the concepts of reuse and sharing into the TTCN language. With ordinary nonmodular tests, the entire test was contained within the test suite. The problem with this was not only having multiple test script writers working on the same test suite, but also the fact that protocols of today are getting more and more modular in the sense that they are composites, built up by other protocols. To maintain tests in this environment, the tests must be built up the same way. To enable that, modular TTCN introduces a new set of concepts. These are as follows:

• the TTCN module—The module is a part of a test suite. It contains definitions and behavior but does not need for its declarations to be self-contained. Entities not present can be stated to be imported from some other module. This way it is possible to reuse definitions in creating tests and actually use that fact in defining the test by simply referring to another standard.
• import—The import part of the test suite or the TTCN module specifies the externally defined objects used in the test suite. They are referenced in the import table in the module.
• export—The export table in a TTCN module references all objects made visible by it.