Founded in 1958, the client has a long-standing tradition and experience in developing, designing, manufacturing, and marketing Power Semiconductor, Power Electronic Equipments, and Railway Transportation Equipments. They are a major supplier of inverters for AC coaches and converters for locomotives. Gauranga has expertise in developing products and projects using various standard protocols in the industry, such as CAN, RS485, RS232, SPI, I2C, etc. Gauranga also provides Internet Of things (IoT) enabled IO devices and Modbus alert modules.

The Requirement

The MVB bus stands for Multifunction Vehicle Bus, is used in railways to interconnect equipment of a consist. This bus operates on a two-wire Optic Glass Fibre (OGF) cable and has a fixed data transfer rate of 1.5 Mbit/sec (Manchester II encoding). The bus has two major components for communication, viz. Process Data is used for cyclic data circulation and Message Data is used for low-priority event-based communication.

The Client, in the process of enhancing its product portfolio, was in the new development of an auxiliary 3x130KVA converter project, for which they needed help in implementing the message data component of the MVB protocol, while the process data component was implemented by a third party. The process data component was implemented with a hardware unit that only processed data compliant, so the requirement also included identifying a hardware component that will enable the system to be message data compliant. Also, there was the unavailability of appropriate documentation from the Railways so the task expected re-engineering in the locomotive’s MVB communication with the existing auxiliary converter and thus identify the packets to be sent by the new auxiliary system.

The Opportunity

Gauranga saw an opportunity to extend its offering to its clients and work on a new protocol, i.e. MVB which leads Gauranga into the Train Communication Network (TCN) protocol further. TCN is used in Europe in trains and locomotives for communication among its various modules. This was being introduced in India too and there is a huge opportunity in this domain in India, which Gauranga planned to seize.

The Solution

Hardware Selection

The Duagon’s D429 was selected as it had the following required capabilities in it:

1. MVB message data enabled
2. DSW – Device status word enabled
3. BA – Bus administrator enabled
4. CAN port – Control Area network port
5. RS232 serial port – Serial port for RS232 communication for enabling console port of the device.

The solution was realized by going through two approaches.

First Approach

CAN to MVB – The initial approach was to develop a layer between the MVB optical interface and the CAN interface of the 3x130kva system. It was an assumption that the details of the CAN interface of the 3x130kva system will be made available by the 3rd party who had developed the process data and the 3x130kva system. But it turned out that the CAN interface was an internal protocol and was not available and also decoding the same was not a feasible task either.

Second Approach

Serial to MVB – So the next approach, a challenge was to be overcome to analyze a serial protocol that was implemented in the system. This serial port was used by the system to send diagnostics data to PC-based software, so most of the background data values, required for the message data implementation were available on this port. This data on the serial port needed to be decoded.

The decoding was accomplished by connecting a Y cable to the port and collecting the commands being sent by the PC-based application to the system. These commands were recorded so that the same can be sent from the D429 device’s serial port to the serial port of the 3x130kva system. Upon receiving these commands the 3x130kva system responds with the respective information. This information was decoded by simulating various signals on the inputs of the system and verifying the various changes in the data received.

The other step was to identify the packets that needed to be sent by the auxiliary 3x130kva system as message data packets for each Diagnostics Data Set (DDS) on the locomotive’s MVB network for the DIA (Diagnostic Processor) unit to receive the same, store in memory and display on the user interface. This was accomplished by replacing the DIA with the D429, and the D429 has the DIA’s device ID. A lab setup in Railways, where a network of the major components of the locomotive, had been set up for research purposes. In this setup, the DIA was removed and D429 was placed with a code reading out all the packets being received by it from the MVB network. These packets were studied and decoded to identify various packets for different DDS that they mapped to. These were recorded and accordingly implemented in the application code for the D429.

The event of triggering each DDS was based on process data signals called ADINF bits. These bits would be sourced on the MVB network by the 3x130kva system and sunk (read) by the D429. Upon receiving a true value for an ADINF and some predefined logic combination of the parameters read on the serial port, respective DDS is triggered. The data from the serial port was also used as background data, a part of the DDS.

The Resources

1. Intellectual
   1. Design engineers for decoding the serial protocol from the 3X130kva system and for decoding the MVB message data DDS packets.
   2. Design engineers for Hardware selection of D429.
   3. Test engineers for testing the implementation in the field.

2. Computer/Electronics
   1. Duagon D429
   2. Lab setup for decoding DDS packets
   3. 3x130kva system setup in LAB for decoding serial protocol
   4. Locomotive for final testing with 3x130kva system installed in it.

The Process

The process includes the following steps:

1. 1. Proposal defining the high-level architecture diagram.
   2. Upon project approval, selection of the Message data compliant hardware component (D429) that will allow the system to become message data enabled.
   3. Visiting the Research LAB in Railways, for decoding the DDS data sets
   4. Working in the client’s lab for decoding the serial protocol values.
   5. Integrating the DDS with ADINF bits and serial protocol values and implementing the same in the D429 code to send DDS on the MVB network.
   6. Verify the DDS being received by the DIA in the locomotive and also being read by the LDS (Locomotive Diagnostic System)

Facilitating Factors

1. Availability of LAB at railways, Bhilai loco shed for DDS dataset decoding.
2. Availability of LAB setup at client’s end for serial data decoding.
3. Availability of Locomotive for sufficient duration to test the implementation of the DDS in the D429

Challenges Overcome

1. Serial protocol decoding was a challenging task and it imposed a block if the protocol had been more complex than it was found after decoding.
2. Similarly, initially, there seemed no way to decode the DDS data sets, but in a brainstorming session, it was realized that replacing the DIA unit with the D429 can get us the DDS data set information. This actually helped us overcome the challenge.

Results Observed

MVB DDS data sets were successfully sent to the DIA, which further sent them to local storage. Later the data is downloaded from the locomotive using the LDS (Locomotive Diagnostic system). The whole set of DDS with background data can be analyzed on the LDS.

Lessons Learned

1. For early expedition of project it is very important to get the dependencies clarified early on so that there would be no surprises.

2. When we have an identified challenge such as decoding the DDS data set, more brain storming sessions must be arranged to expedite the solution.