NTOnTrack TRDP High Layer
Comfort API for TCNOpen TRDP Stack
High level extension for TCNOpen TRDP Light API
NTOnTrack TRDP High Layer simplifies the usage of the lower level C-API of the TRDP light stack and allows for a lean TCN application development. Functionality only rudimentarily supported by the TCNOpen TRDP Stack is fully available such as XML based configuration, train inauguration awareness and thread handling. It makes your system directly compatible to ECN requirements demanded for in the IEC 65375 2-3 standard.
In addition, the NTOnTrack TRDP High Layer C-API is accessible via a PYTHON Scripting Interface to conveniently build up your PYTHON test applications enabling usage of the same API for development and test. The NTOnTrack TRDP High Layer package consists of the complete source code with build environments for Windows and Posix (make, Visual Studio and Qmake) linking directly to the TCNOpen TRDP Stack.
Consists of
- Simple C-API for TCMS Applications
- Python Scripting API
- Build environments: Visual Studio or Makefile
Customer benefits
- A more compact and comprehensive TRDP API
- Communication setup via XML without intervention of the application.
- Available for Windows and Linux
- Easily portable to other OS/HW targets (e.g. freeRTOS) via VOS layer
- Part of the NTOnTrack TRDP Responder
TRDP comfort layer in detail
The comfort layer can be configured by an XML file, which holds the exchange parameters and Dataset definitions necessary for marshalling as well as the information necessary to configure publishers, subscribers and listeners. The XML file will be parsed and the configuration database is populated with the relevant entries. Especially for small applications or if no XML file is available, configurations can also be added by the application itself. It is still possible to call the functions of the TCNOpen stack directly.
The automatically created communication thread handles the reception of the ECSP originated PD and MD packets, which indicate an inauguration respectively indicate the validity of the topology counters and of the train-wide IP addresses. Upon a topology counter change, the process and message data receivers and transmitters configured by the application are updated automatically.
MD telegram reception is optimized by using callbacks which are inherently created during set up of the listeners and message queuing is facilitated. DNR resolving is also handled in a dedicated thread.
System overview
Key features
- Simplification of the TCNOpen TRDP Light stack API
- Support of URI addressing (TCN-DNS)
- Recognizing train inauguration (with automatic reinitialisation of train wide communication)
- Providing a separate communication thread for PD and MD
- Providing XML-based configuration for automatic (de)marshalling of user data
- Each application session contains its own communication thread,
configuration and communication databases - SIL2 readiness with SDTv2