Mil-std-1553b bus

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 IEEE-1394A 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_AN.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:
  
  • 
    AFDX End Systems
    
  • 
    AFDX Switches
    
  • 
    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
  
  • 
    Invalid Frames are discarded
    
  • 
    Sequence Number Check
    
• 
  Redundancy Management
  
  • 
    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 on-board 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
  

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 on-module 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 full-speed 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