VSI Bridge

Vetronic systems are consisted predominantly from real-time and distributed networks. The integration of repeaters, gateways, and bridges in this type of environments requires the use of deterministic components that function coherently with the overall system, not to disrupt the operation of the network. The VSI Bridge system is based on this requirement, initially designed to transparently inter-connect vetronic segments based on MilCAN over a combination of MilCAN and Ethernet backbones. The VSI Bridge is a highly configurable system that can be managed remotely while providing direct access to its attached networks remotely. The accomplishment of a single multi-role system was achieved through a structured design that accommodates all requirements while providing flexibility and expandability.

Function isolation and abstraction combined with object oriented structure are the key design elements of the VSI Bridge. To achieve inter-operability with the external systems the standardisation of key elements were introduced. Elements such as the MilCAN frame are abstracted, unrestricting the use from within a dedicated context to a wider application area. Custom protocols were introduced to accommodate the inter-communication between multiple VSI Bridge instances within a single network.

The internal structure of a real-time bridge component is essential to the integrity of the network. Customised internal communication systems make it possible to achieve the requirements imposed by the MilCAN protocol by offering prioritised data transfers between the internal components. The modular design of the VSI Bridge uses a number of separate components that are linked together through this abstracted and prioritised communication mechanism.

Intelligent bridging of networks is achieved through the dynamic configuration capabilities of the VSI Bridge. The key component to the routing capabilities of the system is a routing engine based on the characteristics of the MilCAN protocol. A custom rule based configuration allows the user a high level of control to the bridging operation of the system. The rule set is designed to accommodate the features of MilCAN frames, while the engine is fully configured remotely through a customised protocol that allows external agents to access and modify the configuration in real time.

Being an evaluation platform, an internal performance monitoring system is in-place, coupled within the internal components of the VSI Bridge. Through the developed system the performance of the individual components can be monitored, along with the overall performance. The system's capabilities are implemented to support the distribution of the collected measurements to remote agents, allowing the real-time monitoring of a whole network consisting of multiple VSI Bridges.

Internal design and layout

The system consists of 3 basic components, the NAT, the NCC, and the Interfaces. The NAT processes the bridged MilCAN frames according to the filtering and routing rules that are stored in an internal database. The NCC does the internal system monitoring and control, while the Interfaces provide an abstraction layer where the various network sub-interfaces are connected. The communication between them is done using a two level token-based system, one used for prioritised communication (for transferring MilCAN frames), and one for low-priority bulk data transfers (database operations, internal data transfers, etc).

The modular design gives the ability to use multiple blocks of the same component in system where redundancy is required or parallel processing is available. The component interconnect could be implemented in hardware allowing the functional blocks to be spread to individual processors, thus reducing latencies and allowing complete hardware/software redundancy.

In order to operate closely to the MilCAN deterministic specifications, the system is designed around the MilCAN prioritisation scheme. Both the inter-communication and the processing of the MilCAN frames within each component are done based on their priority. This has as a result all outgoing frames to be in a priority-sorted flow.

Internal communication

The communication between the Bridge components is handled by a custom token passing interface that uses prioritised queues (Mailer) for transferring SVI frames, and a general-purpose communication mechanism (Courier) for control data transfers.

MilCAN frames that enter the Bridge, in the form of SVI frames, are stored in the memory and a token is created. This token is then passed via the Mailer interface between each of the components that process the frame until it is either expunged or sent to an interface.

The Mailer interface provides a prioritised backplane communication mechanism that handles sorting and forwarding of SVI frames between the Bridge components. In order to maintain the prioritisation scheme of MilCAN, customised internal queues (MQueues) were implemented.

An MQueue consists of 8 FIFO, one used for each MilCAN priority. SVI frame tokens when enter an MQueue are stored to the FIFO of their specific priority, while they exit highest priority first. This indirectly generates a prioritised processing flow of the SVI frames within the VSI Bridge.

The Courier is used as a communication channel for control commands between the VSI Bridge components. As it is not frequently used, mainly during system configuration/monitoring, no prioritisation scheme is included. The internal buffers are dynamic allowing the transfer of arbitrary sized commands without the need for modifications, in contrast with the MQueue that is fixed for SVI frames only.

Interfaces

The Interfaces component of the VSI Bridge connects the modules that manage the communication of the backbone networks and the MilCAN segments to the internal components. These modules (sub-interfaces) operate their individual network protocol stack, and also handle the transport of SVI frames to/from the other end of the network link, either directly or by converting them to their own packet format (if required).

Simple glue logic merges the two-way streams of all the sub-interfaces to the single stream of the component's Mailer interface, which then redirects the SVI frames to the NAT component to handle their routing based on the defined rules.

The internal structure was designed to accommodate the plugability of sub-interfaces that can be created independently and then added to the system without any further modifications. The sub-interfaces use MQueues to transfer the MilCAN messages using SVI frames to and from the Interfaces Mailer, while maintaining their functionality transparent to the rest of the system. Addition and removal of sub-interfaces can also be done at run-time, allowing the dynamic configuration of a network with multiple VSI Bridges and MilCAN segments. Access to the Courier mechanism is also possible for sub-interfaces that require additional functionality (GUI, Ethernet).

NAT

The NAT component handles the routing of MilCAN frames based on a set of user-defined rules that are stored in an internal database. SVI frames from the Interfaces component are forwarded to the NAT where they go through the rule-set. Each rule contains a set of conditions that are checked against each frame, and a command that is executed if a match is found. Internally the NAT component consists of a Mailer interface, the routing engine, and a small database that stores the rules in an ordered fashion that denotes their execution sequence.

SVI frames arrive from the Interfaces component through the Mailer's incoming MQueue in a single stream. Starting from the beginning of the rule-set chain each frame is checked sequentially with the existing rules. Depending on the rules found to be applicable to the specific frame, their respective commands are executed. When the end of the chain is reached the frame is forwarded to an interface (if a rule was found that set the destination Interface) through the Mailer interface, or it is discarded. The rule-set execution flow can also be interrupted if a terminal command is executed (for example when a rule requires a specific frame to be dropped, the parsing of the rule-set chain will immediately stop and the frame will be expunged).

Each rule consists of a pair of mask/match fields and the command. The mask/match fields are used to match a bitwise combination of any of the MilCAN fields (message priority, node address, etc, except payload contents) and source/destination interfaces of the Bridge. SVI frame fields are bitwise masked, with the current rule's mask field, while the result is checked against the match field. If they match then the command of the rule is applied on the SVI frame.

The internal database stores the list of rules that are to be applied to all the MilCAN frames that pass through the Bridge. The rules are stored with a sequence number that controls the order by which they are parsed. This list is configured through the GUI that allows the addition, removal, and view of the rules, and also through the flooding mechanism of MilCAN that allows a Bridge to retrieve a list of MilCAN message IDs that are active within a subnet. With the usage of flooding a dynamic list of rules can be generated to forward frames to their destined MilCAN subnet without requiring the intervention of a user to set the proper rules.

VSI GUI

Since the VSI Bridges allow the configuration over a wide range of adjustments for MilCAN parameters, the user tools are envisaged to anticipate this advantage not only for providing the means for configuring and auditing the system, but also to provide the basis for VSI network management. The user front-end tool (VSI GUI) utilises the Application Interface of the local VSI Bridge to communicate with the rest of the network. The main concept is that the tool can be plugged in to a network to configure and/or interact with the system, and then to be removed in an ad-hoc basis leaving the system to continue operating. This can be visualised in practise, on a vehicle carrying a number of MilCAN segments and VSI Bridges interconnecting them. An operator can plug in the VSI GUI to the vehicle, execute the needed operations, and then disconnect leaving the system running. The tool is made to provide the basis for off-line network planning and configuration, allowing the feasibility for potential alternative visualisation for any future applications. A database system is designed to back the tools for information about the network and scheduling information.

Performance

The performance of the VSI Bridge can be seen in the following figures, where a MilCAN traffic flow of frames with multiple priorities (0: highest - 7: lowest) is routed through the VSI Bridge.

The bandwidth utilisation of the lower priority frames is much higher than the high priority ones. An un-prioritised FIFO based application would be overwhelmed by the high flow of low priority frames and thus affect the latency of the high priority ones.

The prioritised design of the VSI Bridge solves this problem as the data frames are processed based on their priority and thus the high priority data are not affected by the high throughput of the low priority ones.