The development of the TCN (Train Communication Network) standard started in 1990 as a cooperation between IEC and UIC. The work was carried out in IEC by the Working Group 22. The standard finally included 2 parts: the TCN Specification and the TCN Conformance Testing. The network architecture is on two levels: the consist level, within a vehicle or some permanently coupled vehicles, and the train level, ensuring communication between the different vehicles of the train. Some upper layers (Real Time Protocols) ensure end-to-end communication between devices. Network Management functions are included as well.

It took about ten years until the main document (part 1) was published as International Standard in 1999. Part 2 followed a little bit later. After that, WG22 was dismantled and the maintenance of the standard was assigned to WG43.

The Working Group 43 main tasks are to review the already existing TCN parts, while at the same time defining new specifications which had been approved as new parts of the standard. Therefore the new version includes a wider range of networking solutions, like the CAN bus and a complete Ethernet based high-speed solution at both consist (ECN) and train (ETB) level. A communication link between the onboard network and systems on the ground is included, as well as upper layers for end-to-end communication (Communication Profile) and application interface (Application Profile). Finally, a subgroup has been added for preparing a Technical Report (TR) for a wireless train backbone solution.

Many parts of such structure are completely new and many of them are approaching their final approval (see table below: n.a. means not applicable, as not all steps are mandatory). Therefore they will need to be implemented by all companies wishing to use the standard in their products. This can be a strong effort even for big companies, not to speak about small and medium enterprises (SMEs).

TCNOpen was created in order to tackle some of the technical and commercial problems related to the implementation of the new railway standards.

An Open Source initiative appears to be appropriate for the development of standards, as:
  1. It allows to share the development effort and costs
  2. It avoids to have multiple implementations, possibly diverging in minor details, so that to hinder interoperability between resulting products
  3. It ensures a wider test platform and therefore a better software quality, summing up experiences and improvements from all involved partners.

Proof of this is the rapid growth of the number of involved participants (full Partners or Observers) since the founding of the initiative from a group of 5 core partners, at the beginning of 2012.