EN 4660-003:2011

SLOVENSKI STANDARD
01-december-2011
Aeronavtika - Modularne in odprte letalske elektronske arhitekture - 003. del:
Komunikacije/omrežje
Aerospace series - Modular and Open Avionics Architectures - Part 003:
Communications/Network
Luft- und Raumfahrt - Modulare und offene Avionikarchitekturen - Teil 003:
Kommunikation/Netzwerk
Série aérospatiale - Architectures Avioniques Modulaires et Ouvertes - Partie 003:
Communication/Réseau
Ta slovenski standard je istoveten z: EN 4660-003:2011
ICS:
49.090 2SUHPDLQLQVWUXPHQWLY On-board equipment and
]UDþQLKLQYHVROMVNLKSORYLOLK instruments
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD
EN 4660-003
NORME EUROPÉENNE
EUROPÄISCHE NORM
February 2011
ICS 49.090
English Version
Aerospace series - Modular and Open Avionics Architectures -
Part 003: Communications/Network
Série aérospatiale - Architectures Avioniques Modulaires et Luft- und Raumfahrt - Modulare und offene
Ouvertes - Partie 003: Communication/Réseau Avionikarchitekturen - Teil 003: Kommunikation/Netzwerk
This European Standard was approved by CEN on 26 June 2010.

CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European
Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references concerning such national
standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN member.

This European Standard exists in three official versions (English, French, German). A version in any other language made by translation
under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management Centre has the same
status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland,
Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.

EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2011 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 4660-003:2011: E
worldwide for CEN national Members.

Contents Page
Foreword .3
0 Introduction .4
0.1 Purpose .4
0.2 Document structure .5
1 Scope .5
1.1 Relationship with other ASAAC Standards .6
2 Normative references .6
3 Terms, Definitions and Abbreviations .7
3.1 Terms and definitions .7
3.2 Abbreviations .7
4 Network Definition .8
4.1 Overview .8
4.2 Specific Network Requirements .9
4.3 MOS - Communications Services Interface . 12
4.4 Module Physical Interface . 12
4.5 Module Logical Interface . 12
4.6 MLI - Network Properties . 13
5 Discussion of Issues related to the Network . 17
5.1 Issues relating to the Network Structure . 17
5.2 Issues related to the MOS Communication Services. 18
5.3 Issues relating to the Overall Network . 19
Figures
Figure 1 — ASAAC Standards Documentation Hierarchy . 4
Figure 2 — Software and Communications Model . 9
Figure 3 — ASAAC Communication Interfaces . 16
Tables
Table 1 — Architecture Requirements. 9
Table 2 — System Requirements . 11

Foreword
This document (EN 4660-003:2011) has been prepared by the Aerospace and Defence Industries Association
of Europe - Standardization (ASD-STAN).
After enquiries and votes carried out in accordance with the rules of this Association, this Standard has
received the approval of the National Associations and the Official Services of the member countries of ASD,
prior to its presentation to CEN.
This European Standard shall be given the status of a national standard, either by publication of an identical
text or by endorsement, at the latest by August 2011, and conflicting national standards shall be withdrawn at
the latest by August 2011.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent rights.
According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following
countries are bound to implement this European Standard: Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech
Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia,
Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain,
Sweden, Switzerland and the United Kingdom.

0 Introduction
0.1 Purpose
This document was produced under the ASAAC Phase II Contract.
The purpose of the ASAAC Programme is to define and validate a set of open architecture standards,
concepts & guidelines for Advanced Avionics Architectures (A3) in order to meet the three main ASAAC
drivers. The standards, concepts and guidelines produced by the Programme are to be applicable to both new
aircraft and update programmes
The three main goals for the ASAAC Programme are:
1. Reduced life cycle costs.
2. Improved mission performance.
3. Improved operational performance.
The ASAAC Standards are organised as a set of documents including:
A set of agreed standards that describe, using a top down approach, the Architecture overview to all
interfaces required to implement the core within avionics system.
The guidelines for system implementation through application of the standards.
The document hierarchy is given hereafter: (in this figure the document is highlighted)

Standard for Architecture
Guidelines for System Issues
Standard for Software
• System Management
• Fault Management
• Initialisation / Shutdown
• Configuration / Reconfiguration
• Time Management
Standard for Packaging
• Security
• Safety
Standard for Communications and
Network
Standard for Common Functional Modules

Figure 1 — ASAAC Standards Documentation Hierarchy
0.2 Document structure
The document contains the following clauses:
Clause 1, Scope of the document
Clause 2, Normative references
Clause 3, Terms, definitions and abbreviations,
Clause 4, Network definition
Clause 5, Discussion of issues related to the network.
1 Scope
This standard details the functionality and principle interfaces for the ASAAC (Allied Standard Avionics
Architecture Council) Network to ensure the interoperability of Common Functional Modules and design
guidelines to assist in implementation of such a network. It is one of a set of standards that define an ASAAC
Integrated Modular Avionics (IMA) System.
The purpose of this standard is to establish by means of well defined interfaces and functionality, a network
design that is technology transparent, that is open to a multi-vendor market and that can make the best use of
Commercial Off The Shelf (COTS) technologies. Therefore, the associated data communication network
topology, protocols and technologies are not identified in this document. For these items the document
identifies the issues that should be considered when defining a specific network implementation to support the
ASAAC architecture and provides guidelines to assist.
Although the physical organisation and implementation of the network shall remain the System Designers
choice, in accordance with the best use of the current technology, it is necessary to define interfaces and
parameter sets in order to achieve a logical definition of the network with a defined functionality. This definition
includes:
 The generic functionality applicable to all networks.
 The logical interfaces to the Operating System and Module Support Layers.
 The physical interfaces to the Common Functional Modules (CFM).
The ASAAC Standards are intended to be independent of specific technologies, including network
technologies. This document identifies the principle interfaces for the Network, in Clause 4, and where
appropriate, provides requirements on network parameters to be defined. The interfaces relevant to the
network are the Module Support Layer to Operating System (MOS), Module Physical Interface (MPI) and
Module Logical Interface (MLI). The MOS and MPI are generically defined elsewhere (Standards for Software
see EN 4660-005 and Packaging see EN 4660-004). The MLI is clearly a function of the selected network.
The MOS and MPI definitions are generic and will need to be supported by network specific information.
There is no network-dependent information in the Software or Packaging standards. So a future network
specification will not only define the particular MLI, but will also need to define the specific aspects of the MPI,
topologies, system properties etc.
1.1 Relationship with other ASAAC Standards
The definition of the complete Communications and Network Interfaces is partitioned and is covered by the
following ASAAC standards:
 Network physical Interfaces – ASAAC Standards for Packaging.
 Module to Module Communication functions – ASAAC Standards for Software.
 Operating System to Network interface – ASAAC Standards for Software.
 CFM Software Architecture – ASAAC Standards for Software.
 Network physical requirements and properties that define the capability and behaviour required to support
CFM to CFM communications – This document.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO/IEC 7498-1, Open System Interconnect Basic Reference Model
EN 4660-001, Aerospace series — Modular and Open Avionics Architectures — Part 001: Architecture
EN 4660-002, Aerospace series — Modular and Open Avionics Architectures — Part 002: Common
Functional Modules
EN 4660-004, Aerospace series — Modular and Open Avionics Architectures — Part 004: Packaging
EN 4660-005, Aerospace series — Modular and Open Avionics Architectures — Part 005: Software
MIL-STD-1553B, Multiplex Data Bus
1)
ASAAC2-GUI-32450-001-CPG Issue 01, Final Draft of Guidelines for System Issues.
— Volume 1 — System Management.
— Volume 2 — Fault Management.
— Volume 3 — Initialisation and Shutdown.
— Volume 4 — Configuration / Reconfiguration.
— Volume 5 — Time Management.
— Volume 6 — Security.
— Volume 7 — Safety.
1) In preparation at the date of publication of this standard.
3 Terms, Definitions and Abbreviations
3.1 Terms and definitions
Use of “shall”, “should” and “may” within the standards observe the following rules:
 The word SHALL in the text expresses a mandatory requirement of the standard.
 The word SHOULD in the text expresses a recommendation or advice on implementing such a
requirement of the standard. It is expected that such recommendations or advice will be followed unless
good reasons are stated for not doing so.
 The word MAY in the text expresses a permissible practice or action. It does not express a requirement of
the standard.
3.2 Abbreviations
APOS Application to Operating System [interface]
ASAAC Allied Standard Avionics Architecture Council
BER Bit Error Rate
CFM Common Functional Module
COTS Commercial Off The Shelf
DMA Direct Memory Access
Gbps Giga bits per second
GLI GSM Logical Interface
GSM Generic System Manager
IEC International Electrotechnical Commission
IMA Integrated Modular Avionics
ISO International Standards Organisation
ISR Interrupt Service Routine
LCC Life Cycle Cost
Mbps Mega bits per second
MLI Module Logical Interface
MOS Module Support Layer to Operating System [interface]
MPI Module Physical Interface
MMU Memory Management Unit
MRM Module Resource Manager
MSL Module Support Layer
MSU Module Support Unit
NIU Network Interface Unit
NSM Network Support Module
OLI OS Logical Interface
OS Operating System
OSI Open Systems Interconnect
OSL Operating System Layer
QoS Quality of Service
RTBP Run Time Blueprint
SMBP System Management to Blueprint [interface]
SMLI System Management Logical Interface
SMOS System Management to Operating System [interface]
TC Transfer Connection
TLS Three-Layer Stack
VC Virtual Channel
4 Network Definition
4.1 Overview
The communications over an ASAAC network are defined and managed by a set of ASAAC interfaces, these
being:
• The Module Support Layer to Operating System Layer (MOS) interface
• The Module Physical Interface (MPI)
• The Module Logical Interface (MLI)
These are illustrated in the ASAAC Software model diagram in Figure 2. Each of the interfaces is discussed in
this standard and where appropriate, references to the ASAAC standards where they are specified in full, are
provided. This software model presents the appearance of a single network to the application software.
App App
App App App App
Mgr Mgr
SMLI SMLI
APOS APOS
Run Time Run Time
Blue Prints Blue Prints
GSM GSM
Operating Operating
GLI
System System
OLI
MOS MOS Comms Services MOS
Module Network Network Module
MLI
Resources Interface Unit Interface Unit Resources
MPI
MPI
Network
Interconnect
Fabric
Figure 2 — Software and Communications Model
It shall be noted that the ASAAC Standards are independent of specific technologies and therefore the data
communication network topology, protocols and technologies are not defined by this document. The
definitions for the Interfaces in the following subclauses, however, discuss some of the parameters which are
not covered by the ASAAC Standards but which will need to be specified for each system design.
4.2 Specific Network Requirements
There are a number of specific network requirements having an impact on the network design. These are
shown as architectural requirements in Table 1 and system requirements in Table 2.
Table 1 — Architecture Requirements
Title Description
ASAAC network Only used to transfer digital information within the ASAAC core
Open standards No proprietary standards, processes or components shall be specified
Scalability The network shall be scaleable for all system sizes
Single logical network The network shall appear to be a single network to application software
Network connections The network should support a high level of inter-connectivity
---- " ---- The network should support minimum interconnections between racks &
sensors/effectors e.g. to minimise wing root wiring
continued
SMOS APOS
SMBP
SMBP
SMOS APOS
Table 1 — Architecture Requirements (concluded)
Title Description
Station separation Inter-node distances up to 200 metres shall be supported
The network shall distribute time as described in Volume 5,
Time distribution
see ASAAC2-GUI-32450-001-CPG Issue 01.
Network requirements should not introduce a proliferation of Commom
Minimal module set
Functional Module (CFM) types.
Interchangeability There shall be full Form, Fit, and Function interchangeability of CFMs.
Initialisation The network shall initialise to a predefined state
Growth capability The network shall support system growth
---- " ---- The network shall support technology insertion
Security The network shall be capable of supporting different levels of secure data
Security The network shall not prevent key variable erasure on aircrew ejection
The network shall support the security policy defined for each particular
---- " ----
system
Life Cycle Cost The network shall support widespread re-use of components in systems
The network shall make maximum use of Commercial Off The Shelf
---- " ----
(COTS) standards & technologies
---- " ---- Network Standards selection should be based on maximum longevity
---- " ---- Network re-use across platforms & nations shall be supported
Availability/Fault tolerance The network shall be reconfigurable for fault tolerance purposes
No tools or equipment shall be required to remove/replace the Network
Test & Maintenance
Support Module (NSM)
No special tools or test equipment shall be required to remove/replace the
---- " ----
backplane
---- " ---- 1st line repairs shall be by module substitution
It shall be possible to determine system health without interruption of network
---- " ----
links
---- " ---- No network calibration shall be required
Mechanical constraints The network components shall be compatible with EN 4660-004
Environmental Components shall be compatible with EN 4660-004.
Software in Operating System layer (OSL) and Application Layer shall be
Technology Independence
independent from communications hardware
Certification The network shall not prevent certification of the system
The network shall route information to only the intended process(es) in a
Routing
reliable way
Table 2 — System Requirements
Title Description
Data loading The network shall support system initialisation and data loading
Control, Test & Maintenance The network shall support Control and Test & Maintenance traffic without
traffic affecting normal traffic
Payload Content The network shall ignore payload content
Data Equivalence The network shall not provide data equivalence
Retransmission No autonomous retries shall be required by the network
Network Stations At least 256 nodes shall be supported
Network Interconnection Network interconnections shall be reconfigurable
---- " ---- Interconnect configuration changes shall be made only by system software
Interconnect configuration changes shall take less than 10ms
---- " ----
Multicast Multicast transfers shall be supported
Communications Service The network shall support connection-oriented inter-process communications
Data streaming at > 2 Gbps shall be supported, message passing at > 200 Mbps
Data Rates
shall be supported
---- " ---- The network media shall support data rates up to 10Gbps
Predictability Delivery deadlines shall be guaranteed
Data Reception Software shall be informed of data receipt via maskable interrupts
Test & Maintenance Built In Test shall diagnose faults to network segment level
Network Initialisation The network shall initialise & execute a bootstrap loader facility
The network shall support safety-critical comms
Safety
The network shall support mixed criticalities
---- " ----
The network shall support partitioning into two or more independent physical
Safety
parts
---- " ---- Partitioning shall be maintained after reconfiguration
---- " ---- Network reliability shall be commensurate with criticality being supported
Network faults No fault in one node shall affect any other node(s)
---- " ---- The network should time stamp its own fault reports
Personnel Safety Optical sources shall present no safety hazards to personnel

4.3 MOS - Communications Services Interface
The Standard for Software (see EN 4660-005) includes the MOS interface definition, which includes
communications services for a network independent interface. These are the MOS Communication Services.
These services allow the software to establish and monitor communications. The MOS service definition does
not require any network specific parameters to be defined.
4.4 Module Physical Interface
The Module Physical Interface, specified in EN 4660-004, defines the module connector interface which
provides interconnection between the Common Functional Module and the network medium.
There are, however, additional properties that shall be defined by the System Designer, probably in a project-
specific ‘System Design Specification’, that are network specific and therefore outside the scope of the MPI
and the other ASAAC standards. These properties define the Physical Layer of the network and the properties
listed below shall be provided as a minimum in the case of an optical network:
• Optical fibre geometry and mode of operation (multimode or singlemode) – The MPI only specifies a
fibre outer dimension.
• Optical fibre Numerical Aperture (Acceptance angle), Spectral Width and Index Profile. (Ideally the
same optical fibre type should be used throughout the system to reduce optical losses).
• Number and arrangement of optical fibres within the optical contacts.
• Optical input sensitivities, optical output powers and maximum return loss. (This also forms part of the
MLI definition for the network properties).
The definition of a new MPI per project should be discouraged, since maximisation of Life Cycle Cost (LCC)
benefits from IMA are expected through the reuse of common components. The definition of an MPI should
consider factors concerned with evolution of technology and possible future communications requirements.
The following parameters shall be separately defined for each sub-network:
 Data rate - The rate at which data information is transferred.
 Modulation - The method of encoding used to transfer the information.
 Signalling rate - A measure of the rate at which the driving devices change state
...