Back to IEEE 1473-L Frequently Asked Questions
Last Updated: December 01, 2002
Tethering customers to proprietary network designs is no longer an accepted way of doing business. Today, it is essential every network be open, interoperable, and conform to industry standards and best practices. Benefits to an open interoperable network design include:
While networks for trains are no exception, train networks normally have additional requirements, This is because many train networks must dynamically reconfigure themselves when cars couple and uncouple or parts are replaced. It is also inconvenient and often impractical in many rail shops to require first line maintainers to operate a computer to reconfigure and re-commission a network. Therefore, to help ensure a good network design with flexibility and ease of maintenance the following recommendations and guidelines are provided to assist buyers, specifiers and designers. A list of questions is also provided to help determine whether an existing IEEE-1473-L network conforms to open interoperable standards and current "best practices." If a network appears not to conform to open industry standards simply a clearer agreement on what is meant by an "open system" can result in minor changes to a network design so that it does.
1. Use Routers and Avoid Gateways
When interconnecting devices on any network routers are always the preferred choice over gateways. The exception to this rule is when a gateway cannot be avoided such as when interconnecting existing devices with incompatible protocols. Unlike routers, gateways are frequently a source of interface problems because gateways are custom devices that must be modified whenever new devices or new data are added or the network changes. Thus, gateways severely limit flexibility and this is why experienced train network designers avoid gateways whenever possible. Gateways can also be hard to build. For example, RTVISC has been working for several years to develop a gateway between TCN and LonWorks and to date has not succeeded. Part of the difficulty is that for a gateway to function everything on both sides of the gateway must be completely defined in advance because translation is a gateway's primary job. This is need to predefine everything in advance is unnecessary with routers because the network data is independent of the routing function. With routers devices and data can be added or changed without requiring changes to the routers. For additional information see: gateway.
2. Use a Network Manager
A good network management scheme is essential for any network. Unfortunately, this fact is not always recognized. This is especially true with train networks because railcars may frequently need to couple and uncouple. In addition, when vehicle subsystems are replaced, a shop environment is frequently not conducive to using traditional network tools such as notebook computers. Thus, good specifications that fully consider the buyers environment often wisely preclude the use of external computers or special equipment when components on a network replaced "in kind" or added. Such specification functional requirements can be addressed with a network manager that has a well designed network management scheme. Dedicated network managers are available as cost effective commercial off the shelf products or they can be developed as part of a custom embedded computer system.
In summary, a well-designed network management scheme simplifies everyone's job and offers many benefits to everyone. Think of a network manager as a dedicated "electronic shepherd" that manages and commissions all devices on a train network and verifies health with little or no manual intervention. Think of a train network without a good management scheme as herding cats.
To address these issues and to help ensure a train network is open and interoperable rail car buyers from California to New York are deploying train networks to industry standards and specifications consistent with requirements such as these:
The network shall comply with IEEE standard IEEE 473-L for physical device connectivity.
Networked devices shall communicate using Standard Network Variable Types (SNVTs)
Use of explicit messages is prohibited. This prohibition applies to secondary interfaces, as well.
Application logic in networked devices shall comply with open interoperable LonMark Guidelines
Networked devices shall be LonMark certified or LonMark-compatible for future device certification
"As-built" documentation shall be provided for all network interconnections and shall include all application software, databases, or configuration files necessary to reproduce network connections
Network design, installation, test, debug, and maintenance shall be based upon commercial off-the-shelf hardware and software tools
The network shall continually detect added or removed networked devices and dynamically reconfigure the network
The network management scheme shall permit easy system upgrades without the need to alter hard-coded addresses
Under no circumstance shall a node's application software be allowed to update its own network address, domain table, network variable table or address table entries.
Can
third party network management software install all devices on the
network?
Do
all network variables that are not Standard Network Variable Types (SNVTs)
have LonMark resource files?
Does the onboard Network Manager support the ability to update configuration properties through LonMark FTP file transfer or direct memory read/write?
Given just the XIF file can the network install any third party device?
Does
the network keep track of the health of all nodes?
Does
a node's firmware write to a Neuron domain, address or Network Variable
Tables?
Correct answers for Open Systems
Questions 1-6: Yes. Question 7: No