- Home
- Products
- Summary & Overview
- Bus Analyzer
- Interface Cards
- Connectivity
- FireRepeater
- Cables and Harnesses
- IP Cores
- Software
- Accessories
- Solutions
- Support
- News
- Contact
- Company
- Mil1394
- Sitemap
- Search
DapTechnology’s new Mil1394 Topology Engine significantly alters the traditional view of the traditional IEEE1394 topology visualization. While an IEEE1394 topology is entirely rendered based on well-established IEEE1394 concepts (i.e. the nodeIDs, root identification as well as parent/child relationships) the Mil1394 rendering approach transitions the common bus topology visualization to an approach that is more familiar to individuals thinking in terms of AS5643 (i.e. aircraft, …) implementations. Respective needs focus on hierarchical topology structuring based on the device functionality (VMC versus RIOs), Port error indication, loop breaking. An example of such an A&D topology is shown in the AS5643 specification and will be very familiar to individuals familiar with their program specific ICDs. The enhanced conceptual approach consisting of two main improvements has been addressed in the new Mil1394 package and is conceptually demonstrated below. [1]
This feature focuses on enhancements made for the visualization of the IEEE1394 bus topology. Fig.1 shows a classical approach displaying the root (highest numbered node) at the top of the tree and child nodes at the bottom of box representing a device (bus node) and engineers have become quite familiar with this type of presentation.
Yet for the usage within A&D the approach is not “ideal” as it differs from renderings often used in other topology visualization. The issue here is that in the “classical” approach all child nodes – irrelevant on whether a node is a leaf node or a part of a daisy chain – would always be drawn below a parent node. The consequence is that for a sample topology using three port nodes this results in a rather “wide” topology tree rendering. Those familiar with the technology will immediately understand that the tree would be even wider for nodes with port counts greater than 3.
This can be immediately improved with introducing a new leaf-node position option (i.e. position leaf nodes to the side of a node). Fig.2 clearly visualizes the improvement for the same topology. It needs to be understood that the related algorithms are significantly more complex as the topology position of a child now not only depends on its relation to its “up-stream” parent but also on the potential existence on any “down-stream” children.
When interconnecting multiple Mil1394 devices understanding a topology can be confusing. The resulting topologies tend to not look anything like one would expect from having studied mentioned technology specification or the ICD document(s). Typically, a series of questions arise: ‟Do I see all devices that I expect to see? Are any devices missing and if so which ones? Where did the loop break? How can I quickly check on the reliability of the specific device-device connection which I have just built?” Or even worse: “Where do all the BusResets originate from?”
DapTechnology has listened to these reoccurring issues and has developed “Reference Topology comparison/verification (“CompResTopo”) methodology. The result is a comprehensive and very effective way to compare a live topology against what is expected. The methodology can be used to identify missing nodes, identify unexpected nodes, indicate temporary items like node replacements (e.g. Repeaters), identify locations of loop resolutions) and much more.
At the base of the innovation lies DapTechnology’s newly defined “Reference Topology” (RefTopo) concept. It utilizes a topology baseline which the live topologies will be compared against. And an enhanced display rendering engine visualizes any detected differences.
In order to establish this baseline a reference topology has to be defined by a user/admin/supervisor/… familiar enough with the overall bus architecture by using DapTechnology’s innovative and dedicated design tool. It would include all definitions (node-node connections, tree locations, anticipated loop position(s), …) as well as device attributes (names, colors, identifiers, …) and more to be expected for a specific aircraft state. Obviously, multiple reference topologies can be created to resemble a multitude of these states (e.g. different stages during the aircraft build process, service and maintenance steps, etc.).
An example of a resulting reference topology is shown in Fig.3. A series of nodes had been specified according to the mentioned parameters and attributes. [2]
Such a pre-defined RefTopo allows to elevate the analysis to new possibilities as it enables the comparison of the actual topology (ActualTopo) with the predefined RefTopo. A few examples of the resulting Comparison Result Topology (CompResTopo) are discussed below:
As shown below the two topologies include the same devices and the loop-resolution is the same as is in RefTopo, disabled connection is displayed as dotted red line with red PortConnectionStatus indicators.
While the live topology changes significantly the CompResTopo does not change in shape due to the new approach discussed Mil1394 representation of the tree and displays where the loop is broken (red dotted line, red PortConnectionStatus indicators) compared to the expected resolution location (purple line).
Case3: LiveTopo has one additional and one missing node compared to RefTopo as well as a loop break in location different from expected, note that one node was added (bright red border) to and one node is missing (faded) with loop breaking in a different location
An interesting challenge on the Mil1394 level is a reliable Device Identification mechanism. Images shown above depict device rendering with unique attributes (name, rendering, …). But how can a bus node be uniquely identified to be a specific device (i.e. a VMC, a specific RIO, …)?
Classical IEEE1394 offers a defined methodology for this as any device is supposed to have a Global Unique Identifier (GUID) as part of its ConfigROM. This 64-bit unique ID can be access at a defined address offset and – as shown on Fig.7 – can be used to identify a specific device. However, in AS5643 this GUID is optional only and hardly used. And if it is supported then special attention relating to devices access needs to be paid in order to not interfere with the time scheduling of ASM data traffic. In Fig.7 it was assumed that only three devices have implemented ConfigROMs and support GUID read access.
Another approach to this problem is to link channel number (ch#) and nodeID derived from the ASM packet headers with device attributes via a pre-defined lookup table. Unfortunately, not all Mil1394 devices properly populate their ASM messages with ch# and NodeID and therefore the methodology is not deterministic and guaranteed.
Luckily the discussed reference topology methodology offers a solution to this problem as it allows for the possibility to link IEEE1394 nodeIDs to virtual deviceIDs. This process consists of various steps correlating live locations within the topology under consideration of RefTopo definitions of parent/child relations and device attributes (name, … and offers a reliable mechanism for a deterministic device identification.
[1] Please note that for displaying the concepts of the presented enhancements a very simplistic form of device rendering has been chosen. The new engine also features full customization of device renderings (shape, attributes, details, …)
[2] Please note that the choice of colors/lines/… used in this representation is for visualization purposes of this paper only. In the actual tool these rendering attributes are customizable entirely.