MIL-STD-1553B Bus
The MIL-STD-1553B Bus is a widely supported data bus for avionics applications
and compatible with most of the avionics equipment. However, its low data rate (1
Mbps) and command-response architecture are not suitable for many modern
applications such as on-board autonomy. Therefore, the avionics industry recently
has been interested in adopting the IEEE 1394A Bus as the next generation avionics
bus. The IEEE 1394A Bus has a minimum bandwidth of 100 Mbps, which is two
orders of magnitude faster than the 1553B Bus. In addition, its sophisticated
protocol and multi-master capability can support distributed processing in
advanced applications. One major obstacle in adopting the IEEE 1394A Bus is its
compatibility with heritage equipment that is mostly compatible only with the
1553B Bus. It might take many years and large investments for the aerospace
industry to convert all 1553B based equipment to the IEEE 1394A Bus.
The objective of this task is to solidify the IEEE-1394A standard in spacecraft
engineering by providing backward compatibility with MIL-STD-1553B. This
backward compatibility allows heterogeneous communications between the IEEE1394A and MIL-STD-1553B buses, so that both heritage and modern components
can share a common bus architecture. Hence, this backward compatibility would
shorten the time to acceptance of the IEEE 1394A Bus.
In Phase I of this STTR, the functional requirements of the bridge and formats of
the embedded commands have been defined. A software testbed has also been
successfully implemented to demonstrate the read and write commands. In Phase II,
a single board level implementation of the bridge will be designed, built and
evaluated. This will provide the basis for further integration and miniaturization in
a potential Phase III.
POTENTIAL COMMERCIAL APPLICATION(S) (LIMIT 200 WORDS)
Many future NASA flight projects and commercial spacecraft, are considering the
IEEE 1394 Bus as their baseline. These projects include the Mars Science
Laboratory (MSL), the Europa Orbiter, and the next generation weather satellite
program NPOESS. The science objectives of these missions require advanced
application software such as on-board autonomy, real time hazard avoidance and
precise landing. These advanced application software demand processing capability
beyond current flight-qualified processors (e.g. the Rad 750). Therefore, distributed
multiprocessor architectures have to be developed to support these applications.
In contrast, many instruments such as the inertial measure units (IMU) and the
Small Deep Space Transponder (SDST) that are being considered by these missions,
are compatible only with the MIL-STD-1553B bus. In the avionics industry, as the
next generation unmanned aircraft are developed with more sophisticated
processing, they will require a more advanced bus architecture, but they still use
many heritage sensors.
With this bridge, much heritage equipment can be made compatible with the IEEE
1394 Bus without redesign.
ETHERNET
“In late 1972, Metcalfe and his Xerox PARC colleagues developed the first experimental
Ethernet system to interconnect the Xerox Alto, a personal workstation with a graphical
user interface. The experimental Ethernet was used to link Altos to one another, and to
servers and laser printers. The signal clock for the experimental Ethernet interface was
derived from the Alto's system clock, which resulted in a data transmission rate on the
experimental Ethernet of 2.94 Mbps.
Metcalfe's first experimental network was called the Alto Aloha Network. In 1973
Metcalfe changed the name to "Ethernet," to make it clear that the system could support
any computer--not just Altos--and to point out that his new network mechanisms had
evolved well beyond the Aloha system. He chose to base the name on the word "ether" as
a way of describing an essential feature of the system: the physical medium (i.e., a cable)
carries bits to all stations, much the same way that the old "luminiferous ether" was once
thought to propagate electromagnetic waves through space. Thus, Ethernet was born.”
http://www.pcmag.com/encyclopedia_term/0,2542,t=Ethernet&i=42781,00.asp
The standard local area network (LAN) access method. A specification for "LAN,"
"LAN connection" or "network card" automatically implies Ethernet without saying so.
Ethernet connects devices to a company or home network as well as to a cable
modem or DSL modem for Internet access. Ethernet is defined by the IEEE as the
802.3 standard (see 802.3).
Almost all PCs and Macs come with 10/100 Ethernet ports that connect internally to
circuits on the motherboard. Ethernet can be added to older machines by plugging in
a network adapter via PCI, PC Card or USB.
Megabits Per Second: 10, 100 or 1000
A 10/100 Ethernet port supports two speeds: 10 Mbps (10BaseT) and 100 Mbps
(100BaseT). Computers also come with 10/100/1000 ports, which includes Gigabit
Ethernet at 1 Gbps. Gigabit Ethernet (GigE) is commonly used as a high-speed link
between switches and servers. Ethernet devices negotiate with each other and
transmit at the highest speed possible. However, if a 100 Mbps switch is
communicating with a 10 Mbps client, the slower speed is used.
Shared or Switched
Ethernet is wired in a star configuration with a hub or switch in the middle. Hubs,
which predated switches, are shared media devices. All stations attached to the hub
share the total bandwidth. Switches provide each sender and receiver pair with the
full bandwidth and are significantly faster than hubs (see switched Ethernet). Like
the client machines, Ethernet switches and hubs also support 10/100 and
10/100/1000 speeds.
Most Ethernets Use Twisted Pairs
Ethernet uses economical twisted pair cables and standard RJ-45 connectors (see
cable categories). Sometimes, spare telephone wires in a building may be used, but
often only at the lowest speed. To extend distances, fiber-optic cable is also used
(see 100BaseT, Gigabit Ethernet and FOIRL). The first versions of Ethernet used
coaxial cable (see 10Base5 and 10Base2).
Ethernet Frames
Ethernet transmits variable length frames from 72 to 1518 bytes in length, each
containing a header with the addresses of the source and destination stations and a
trailer that contains error correction data. Higher-level protocols, such as IP and IPX,
fragment long messages into the frame size required by the Ethernet network being
employed (see MTU).
Collision Detection
Ethernet uses the CSMA/CD technology to broadcast each frame onto the physical
medium (wire, fiber, etc.). All stations attached to the Ethernet are "listening," and
the station with the matching destination address accepts the frame and checks for
errors. Ethernet is a data link protocol (MAC layer protocol) and functions at layers 1
and 2 of the OSI model.
History
Invented by Robert Metcalfe and David Boggs at Xerox PARC in 1973, Ethernet first
ran at 2.94 Mbps. Metcalfe later joined Digital where he facilitated a joint venture
between Digital, Intel and Xerox to collaborate further on Ethernet. Version 1 was
finalized in 1980, and products shipped in the following year. In 1983, the IEEE
approved the Ethernet 802.3 standard. See 100BaseT, Gigabit Ethernet, 10 Gigabit
Ethernet and switched Ethernet.
http://en.wikipedia.org/wiki/Ethernet
Ethernet is a family of frame-based computer networking technologies for local area
networks (LANs). The name comes from the physical concept of the ether. It defines a
number of wiring and signaling standards for the physical layer, through means of
network access at the Media Access Control (MAC)/Data Link Layer, and a common
addressing format.
Ethernet is standardized as IEEE 802.3. The combination of the twisted pair versions of
Ethernet for connecting end systems to the network, along with the fiber optic versions
for site backbones, is the most widespread wired LAN technology. It has been in use
from the 1990s to the present, largely replacing competing LAN standards such as token
ring, FDDI, and ARCNET. In recent years, Wi-Fi, the wireless LAN standardized by
IEEE 802.11, is prevalent in home and small office networks and augmenting Ethernet in
larger installations.
Ethernet was originally based on the idea of computers communicating over a shared
coaxial cable acting as a broadcast transmission medium. The methods used show some
similarities to radio systems, although there are fundamental differences, such as the fact
that it is much easier to detect collisions in a cable broadcast system than a radio
broadcast. The common cable providing the communication channel was likened to the
ether and it was from this reference that the name "Ethernet" was derived.
From this early and comparatively simple concept, Ethernet evolved into the complex
networking technology that today underlies most LANs. The coaxial cable was replaced
with point-to-point links connected by hubs and/or switches to reduce installation costs,
increase reliability, and enable point-to-point management and troubleshooting. StarLAN
was the first step in the evolution of Ethernet from a coaxial cable bus to a hub-managed,
twisted-pair network. The advent of twisted-pair wiring dramatically lowered installation
costs relative to competing technologies, including the older Ethernet technologies.
Above the physical layer, Ethernet stations communicate by sending each other data
packets, blocks of data that are individually sent and delivered. As with other IEEE 802
LANs, each Ethernet station is given a single 48-bit MAC address, which is used both to
specify the destination and the source of each data packet. Network interface cards
(NICs) or chips normally do not accept packets addressed to other Ethernet stations.
Adapters generally come programmed with a globally unique address, but this can be
overridden, either to avoid an address change when an adapter is replaced, or to use
locally administered addresses.
Despite the significant changes in Ethernet from a thick coaxial cable bus running at 10
Mbit/s to point-to-point links running at 1 Gbit/s and beyond, all generations of Ethernet
(excluding early experimental versions) share the same frame formats (and hence the
same interface for higher layers), and can be readily interconnected.
Due to the ubiquity of Ethernet, the ever-decreasing cost of the hardware needed to
support it, and the reduced panel space needed by twisted pair Ethernet, most
manufacturers now build the functionality of an Ethernet card directly into PC
motherboards, obviating the need for installation of a separate network card.
IEEE 802.3
http://www.ieee802.org/3/
AFDX
Testing and proving the new AFDX (Avionics Full Duplexed Switched
Ethernet) based Avionics Databus Systems on board the AIRBUS Industries
A380 requires highly specialized test, simulation and monitoring equipment
for the development phase through to in service support.
AFDX is being used as the main avionics databus network on board the A380
and is based on commercial 10/100Mbit switched Ethernet. AFDX uses a
special protocol to provide deterministic timing and redundancy management
providing secure and reliable communications of critical and non critical data.
AFDX communication protocols have been derived from commercial databus
standards (IEEE802.3 Ethernet MAC addressing, Internet Protocol IP, User
Datagram UDP) to achieve the required deterministic behaviour for avionics
applications. End Systems (or LRU’s) communicate based on ‘Virtual Links’
with ‘Traffic Shaping’ by use of Bandwidth Allocation Gaps (BAG’s). Switches
incorporate functions for Filtering and Policing, Switching (based on
configuration tables), End-System and network Monitoring.
During the past 3 years, AIM has been working as an associated partner to
EADS Airbus, Toulouse with the definition, development and implementation
of AFDX test tools on two EU (European Union) funded programs known as
‘PAMELA’ and ‘VICTORIA’. AIM was originally approached for its expert
knowledge as a specialist European manufacturer of Avionics Databus Test &
Simulation products for ARINC429, MILSTD1553 and STANAG3910
databuses.
As a result, AIM has now available a complete range of powerful AFDX
Databus Test & Simulation modules (PMC, PCI, CPCI, VME & VXI)
complimented with advanced Windows based Network Analyser/ Visualiser
software packages, commercially known as fdXplorer/ ParaView.
AIM’s AFDX databus modules take advantage of its innovative ‘Common
Core’ hardware design using multiple RISC processors, an on board
Application Support Processor, Scalable Memory, and an IRIG-B Time Code
Decoder/ Processor. A proprietary MAC design gives the flexibility to provide
full error injection/ detection, programmable payload generation and store
modes with full AFDX databus conformance verification.
For testing the End Systems and Switches AIM’s modules have two or four
ports and incorporate many important test and integration features. These
include precise control of timing and sequencing of the AFDX frames and
skew between ports, configurable redundancy management, traffic shaping
on transmit, traffic shaping verification on receive, powerful filtering/
complex trigger facilities, physical reply of all recorded AFDX traffic and
comprehensive port/network statistics. Time stamping and synchronization is
available using extended IRIG-B time (1us) and relative time measurements
are made with a 40ns resolution.
Included with all AIM’s AFDX databus modules is a BSP (Board Software
Package) providing full function driver software with a common API
(Application Programming Interface) and functionality across all platforms.
This gives users maximum flexibility and significant cost saving advantages
when building various test benches or test systems.
Furthermore, AIM’s optional AFDX network analyser software, fdXplorer,
supports multiple network capabilities with an ‘easy to use’ and configurable
user interface for Windows. ParaView is also on offer to provide a payload
oriented visualiser with parameter control with support for multiple avionics
bus standards such as ARINC429 etc.
Future enhancements to the fdXplorer/ ParaView products which include an
interface to the A380 ISDB, SNMP/ TFTP support, ARINC615A loading, Test
Scripting, an RT-Tester Interface (from Verified Systems International) plus a
Re-Routing and Data Pollution function (REROS).
Due to the total commitment to the AFDX market and the A380 programme,
AIM has gained the enviable position as the market leader of AFDX databus
tools (modules and analysers) having now been selected by the Airbus
partner divisions in France, Germany and the UK plus the majority of the
A380 sub-contractors in Europe and the USA.
AIM has direct sales and support offices in Germany, UK and the USA and
works in conjunction with a network of exclusive Representatives world-wide,
who together provide expert technical support for all AFDX databus
applications.
AFDX Tutorial
http://www.aim-online.com/abs/afdx/afdx-tutorial.htm
As AFDX is a propriety databus standard we are unable to provide an AFDX
Tutorial for download. However, if you would like to know more about AFDX
and AIM's range of AFDX databus products please contact one of our
representatives.
What is AFDX?
http://www.actel.com/documents/AFDX_Solutions_A
N.pdf
AFDX (Avionics Full Duplex Switched Ethernet)





ARINC-664 Standard adopts the key elements from AFDX standardize
a deterministic Network for aircraft
AFDX is used on the Airbus A380 as main avionics databus & on the
A400M
AFDX is based on IEEE 802.3 standard (commercial Ethernet using
wire) with either 10Mbits/s or 100Mbits/s
AFDX uses a special protocol to provide deterministic timing and
redundancy management
The main elements of an AFDX network are:
o AFDX End Systems
o AFDX Switches
o AFDX Links
AFDX Network Topology Overview








AFDX is rather a network than a bus
There are two types of devices on the bus Switches and End Systems
All connections are full-duplex 10Mbits/s or 100MBit/s (no dedicated
backbone bus for Inter-Switch communication)
Redundancy is achieved by duplication of the connections (wires) and
the Switches
AFDX uses special extensions to provide deterministic timing and
redundancy
End Systems (E/S) exchange Frames through Virtual Links (VL)
A VL defines the unidirectional connection from one source E/S to one
or more destination E/s(s)
An E/S performs Traffic policing, Integrity Checking and Redundancy
Management on a per VL basis
AFDX Traffic Policing


The E/S controls the flow for each VL in accordance with the
Bandwidth Allocation Gap (BAG)
BAG values are in ms: 1,2 4,8, 16, 32, 64, 128
AFDX Redundancy




The ports, links and switches are duplicated for redundancy
Frames are transmitted concurrently on both networks
Integrity Checking is done per VL and per Network
o Invalid Frames are discarded
o Sequence Number Check
Redundancy Management
o On receiving E/S the 'First valid Frames wins'
Advanced Generation of AFDX Interface Modules and
AFDX Databus Analyzer Software.
AIM - is the Premier supplier of AFDX test & simulation products for the
AIRBUS, A380 programme.
AIM's modules are available in PMC, PC-Card, PCI, CPCI, VME and VXI
formats with 2 or 4 AFDX ports, each implementing a 10/100Mbit full duplex
Ethernet interface for the test, simulation, monitoring and verification of End
Systems and Switch testing. Our AFDX modules provide Traffic Generation
with full logical & physical error injection and Receive Operation with full
error detection plus sophisticated trigger & Filtering capabilities, with an onboard Application Support Processor and IRIG-B Time Decoder.
AFDX Product Features
General Features
AIM's new ultra high performance intelligent modules offer full function test,
simulation, monitoring and analyzer functions for AFDX (Avionics Full Duplex
Switched Ethernet) networks. Our unique on board processing capability,
memory resources, customized AFDX MACs and IRIG-B time code decoder/
generator gives AFDX users unparallel features for the most demanding
AFDX applications.
The each module provides two or four AFDX ports being configured as two/
four singles or one/two dual redundant ports each implementing a
10/100Mbit Full Duplex Ethernet interface.
Ports can operate concurrently in Traffic Simulator or Receiver/ Monitor
modes with support for AFDX port related Frame Statistics. Virtual Link (VL)
packet capturing and monitoring features are complimented with powerful
triggering and filtering capabilities.
Our modules field proven 'Common Core' hardware design utilizes two
advanced RISC processors, one acting as Bus Interface Unit processor and
one as Application Support Processor (ASP). The vast memory resources on
board allow to implement large receive buffers and Complex Transmit
scenarios on-board. An AFDX specific Physical Bus Interface implements two
full duplex ports for connection to AFDX networks.
All AIM's AFDX modules are available with the optional fdXplorer, the AFDX
Network Analyzer Software and the ParaView, the Parameter Visualiser
Software for Windows.

Two advanced 600 MHz XSCALE Processors on board
Designed for applications such as:
Test & Verification of 'End Systems'
'Switch' Testing
Monitoring of traffic between 'End Systems' & 'Switch'
Inter Switch Traffic Analysis
Multi Stream High Level System Integration
Programmable Ports - Traffic Simulator and Receiver/Monitor
Concurrently
128MB On-Board Memory + 2MB MAC Bust Buffer
Synchronized Timing across Multiple Modules
Driver Software for WindowsLinux, VxWorks and LynxOS
o
o
o
o
o
o




Traffic Generation
AIM's AFDX modules provide real time traffic generation on both ports
concurrently. Transmitter operation allows users to fully programme all fields
of the AFDX Frame including the Virtual Link Identifier, MAC Source Address,
IP Structure, UDP Structure, Payload and Sequence number. Multiple modes
of transmit sequencing are supported, these being Generic / Replay and UDP
Port oriented shaped Transmissions. Users can programme Payload Data with
User Defined or Fixed Data. Inserting the Time Tag in the Payload Data
provides an elegant solution to measure frame transmit delays through the
network. Synchronization of transmissions across multiple ports is achieved
by using Strobe Inputs/Outputs.








Programmable Timing & Sequencing of Frames
Physical Error Injection - CRC, Gap, Size, Alignment
Logical Error Injection on Layers 2, 3, 4
Timing ErrInjection - Violation of Bandwidth Allocation Gap (BAG)
UDP Port Simulation with Traffic Shaping & Sequence Numbering
On-board support for AFDX sampling and queuing ports
Physical Replay mode support with accurate timing reconstruction
Generic Transmission mode based on Frame lists, with programmable
timing down to 40ns IFG resolution
UDP/ VL oriented Receive Mode
AIM's AFDX module ports can be configured to work in UDP / VL oriented
receive mode. In this mode each UDP port has a separate buffer queue.
Received frames are stored with frame headers containing time tag and
status information. Frame header information can be stored and payload data
optionally discarded for the testing of Switches and the complete network.
With the Traffic shaping verification enabled, any violations are reported as
errors in related frame headers.


VL oriented Filtering
Second Level Filtering on Generic Frame Parameter







Time Stamping of Received Packets with extended IRIG-B time code
(1µs)
Physical Error detection, Frame Level - CRC, Gap, Size and Alignment
AFDX Specific Error Detection
Traffic Shaping Verification
Verification of MAC, IP and UDP Headers
VL oriented Integrity Checking
UDP Port Receive Mode for AFDX Sampling and Queuing Ports
Chronological Receive Mode
AIM's AFDX module ports can be configured in Chronological Receive Mode to
sequentially receive frames and store them in a circular buffer. The payload
data can be discarded to optimize the use of the buffer for frame capture and
analysis. Powerful Filtering, Triggering, Complex Triggering and Capture
Modes allow users to select only the frames, data and errors of interest.
Monitor Mode also provides activity monitoring and statistics for each VL
recorded by the module. The interface modules report the number of frames
received and the number of errors detected globally and in VL orientated
format.









VL Orientated Receive and Filtering
Second level filtering on Generic Frame Parameters
Chronological Monitor with Time Stamping to 1µs
Massive on-board Monitor Buffer
Inter frame Gap time measurements with 40 nsec resolution
Comprehensive Triggering / Filtering / Capturing
Programmable Data Capture Modes - Trace after Trigger & Recording
Physical Error Detection - CRC, Gap, Size and Alignment
AFDX Specific Error Detection
Re-Routing function
AIM's AFDX Module are supporting AFDX Traffic Re-Routing functionality, in
order to receive frames, modify frame data (full access to all bytes) and/or to
re-transmit frames on same or other ports or boards, mounted on the same
backplane (PCI only) with constant configurable delay.
Application Support Processor
The 600 MHz Application Support Processor (ASP) provides unique onmodule processing functions typically provided by host PC processing
systems.


IP and UDP layer of the AFDX protocol
Driver Software Execution on the board


Loop / Pollution between Rx and Tx port
running a Real Time operating system
IRIG-B Time Code Decoder
An on board IRIG-B Time Code decoder and generator allows synchronization
of multiple AFDX ports using multiple AIM AFDX modules. Modules can be
synchronized using an external IRIG-B time source or the on-board Time
code generator of one module as the reference for accurate correlation of
data across multiple AFDX ports.
Physical Bus Interface
AIM's AFDX modules provide two or four AFDX ports which can be used as
two or four single channels or as one or two dual redundant channel AFDX
specific Physical Bus Interface





Customized Media Access Controllers (MAC's) implemented in FPGA
optimized for AFDX
2 MByte MAC Transmit / Receive Burst Buffer
Physical Interface and Magnetics (COTS)
8-socket Network Interface connectors - RJ45
Trigger, Strobe and Time Code I/O connector
Driver Software Support
All AIM AFDX modules are supplied with an Application Programming
Interface (API) and Drivers compatible with Windows, Linux, LynxOS,
VxWorks and others.
AFDX Databus Analyzer and Visualiser Software
Our powerful full function fdXplorer/ ParaView Databus Analyser/
Visualiser Software for Windows, supports multiple Avionics Bus streams and
is available for networked Client/Server configurations.
AIM's family of AFDX, ARINC-664, ARINC429, MIL-STD-1553B,
STANAG3910/EFEx, PANAVIA Serial and Fibre Channel Avionics Databus
Products provide unparalleled capabilities for your entire Test, Simulation,
Monitoring and Physical Bus replay needs.
Avionics Full-Duplex Switched Ethernet (AFDX) is Part 7 of the ARINC 664
Specification which defines how Commercial Off-the-Shelf (COTS) networking
technology will be used for future generation Aircraft Data Networks (ADN). AFDX is
an Airbus trademark, the equivalent Boeing product is known as CDN or Common Data
Network. AFDX defines a low-level network and protocol to communicate between
avionics (referred to as End-System) devices in aircraft. It is based on Ethernet, and like
all full-duplex networks uses dedicated outgoing and incoming channels to allow fullspeed transmission in both directions at the same time. AFDX extends standard Ethernet
to provide high data integrity and deterministic timing. It specifies interoperable
functional elements at the following OSI Reference Model layers:




Data Link (MAC and Virtual Link addressing concept);
Network (IP and ICMP);
Transport (UDP and optionally TCP)
Application (Network) (Sampling, Queuing, SAP, TFTP and SNMP).
The Physical layer is not defined as part of ARINC 664 Part 7 (AFDX) but can be any of
the solutions defined in ARINC 664 Part 2, including:



10BASE-T to support traffic at 10Mbit/s;
100BASE-TX and 100BASE-FX to support traffic at 100 Mbit/s; and
provisions for growth to 1000 Mbit/s operations.
deterministic timing and redundancy management