BS EN 4660-003:2011 BSI Standards Publication Aerospace series — Modular and Open Avionics Architectures Part 003: Communications/Network NO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAW raising standards worldwide™ BS EN 4660-003:2011 BRITISH STANDARD National foreword This British Standard is the UK implementation of EN 4660-003:2011 The UK participation in its preparation was entrusted to Technical Committee ACE/6, Aerospace avionic electrical and fibre optic technology A list of organizations represented on this committee can be obtained on request to its secretary This publication does not purport to include all the necessary provisions of a contract Users are responsible for its correct application © BSI 2011 ISBN 978 580 62443 ICS 49.090 Compliance with a British Standard cannot confer immunity from legal obligations This British Standard was published under the authority of the Standards Policy and Strategy Committee on 31 March 2011 Amendments issued since publication Date Text affected BS EN 4660-003:2011 EN 4660-003 EUROPEAN STANDARD 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 Ouvertes - Partie 003: Communication/Réseau Luft- und Raumfahrt - Modulare und offene 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 worldwide for CEN national Members Ref No EN 4660-003:2011: E BS EN 4660-003:2011 EN 4660-003:2011 (E) Contents Page Foreword 3 0 0.1 0.2 Introduction 4 Purpose 4 Document structure .5 1 1.1 Scope 5 Relationship with other ASAAC Standards 6 2 Normative references 6 3 3.1 3.2 Terms, Definitions and Abbreviations 7 Terms and definitions 7 Abbreviations 7 4 4.1 4.2 4.3 4.4 4.5 4.6 Network Definition 8 Overview 8 Specific Network Requirements 9 MOS - Communications Services Interface 12 Module Physical Interface 12 Module Logical Interface 12 MLI - Network Properties 13 5 5.1 5.2 5.3 Discussion of Issues related to the Network 17 Issues relating to the Network Structure 17 Issues related to the MOS Communication Services 18 Issues relating to the Overall Network 19 Figures Figure — ASAAC Standards Documentation Hierarchy Figure — Software and Communications Model Figure — ASAAC Communication Interfaces 16 Tables Table — Architecture Requirements Table — System Requirements 11 BS EN 4660-003:2011 EN 4660-003:2011 (E) 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 BS EN 4660-003:2011 EN 4660-003:2011 (E) 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: Reduced life cycle costs Improved mission performance 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 Standard for Software Guidelines for System Issues • • • • Standard for Packaging • • • System Management Fault Management Initialisation / Shutdown Configuration / Reconfiguration Time Management Security Safety Standard for Communications and Network Standard for Common Functional Modules Figure — ASAAC Standards Documentation Hierarchy BS EN 4660-003:2011 EN 4660-003:2011 (E) 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 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 BS EN 4660-003:2011 EN 4660-003:2011 (E) 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 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 ASAAC2-GUI-32450-001-CPG Issue 01, Final Draft of Guidelines for System Issues 1) — Volume — System Management — Volume — Fault Management — Volume — Initialisation and Shutdown — Volume — Configuration / Reconfiguration — Volume — Time Management — Volume — Security — Volume — Safety 1) In preparation at the date of publication of this standard BS EN 4660-003:2011 EN 4660-003:2011 (E) 3.1 Terms, Definitions and Abbreviations 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 BS EN 4660-003:2011 EN 4660-003:2011 (E) 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 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 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 BS EN 4660-003:2011 EN 4660-003:2011 (E) App App App Mgr SMLI App Mgr SMLI App APOS Run Time Blue Prints GSM SMOS GSM APOS Run Time Blue Prints SMBP APOS SMBP APOS SMOS Operating System App GLI Operating System OLI Module Resources MOS MOS Comms Services MOS Network Interface Unit Network Interface Unit MLI MPI Module Resources MPI Network Interconnect Fabric Figure — 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 and system requirements in Table Table — 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 BS EN 4660-003:2011 EN 4660-003:2011 (E) Table — Architecture Requirements (concluded) Title Station separation Inter-node distances up to 200 metres shall be supported Time distribution The network shall distribute time as described in Volume 5, see ASAAC2-GUI-32450-001-CPG Issue 01 Minimal module set Network requirements should not introduce a proliferation of Commom Functional Module (CFM) types Interchangeability There shall be full Form, Fit, and Function interchangeability of CFMs Initialisation Growth capability The network shall initialise to a predefined state 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 Test & Maintenance No tools or equipment shall be required to remove/replace the Network 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 Environmental Technology Independence Certification Routing 10 Description The network components shall be compatible with EN 4660-004 Components shall be compatible with EN 4660-004 Software in Operating System layer (OSL) and Application Layer shall be independent from communications hardware The network shall not prevent certification of the system The network shall route information to only the intended process(es) in a reliable way BS EN 4660-003:2011 EN 4660-003:2011 (E) Table — System Requirements Title Data loading Control, Test & Maintenance traffic Description The network shall support system initialisation and data loading The network shall support Control and Test & Maintenance traffic without affecting normal traffic Payload Content The network shall ignore payload content Data Equivalence The network shall not provide data equivalence Retransmission Network Stations Network Interconnection No autonomous retries shall be required by the network At least 256 nodes shall be supported 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 Data Rates " -Predictability Data Reception The network shall support connection-oriented inter-process communications Data streaming at > Gbps shall be supported, message passing at > 200 Mbps shall be supported The network media shall support data rates up to 10Gbps Delivery deadlines shall be guaranteed 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 Safety " -Safety The network shall support safety-critical comms The network shall support mixed criticalities The network shall support partitioning into two or more independent physical parts " Partitioning shall be maintained after reconfiguration " Network reliability shall be commensurate with criticality being supported Network faults " -Personnel Safety No fault in one node shall affect any other node(s) The network should time stamp its own fault reports Optical sources shall present no safety hazards to personnel 11 BS EN 4660-003:2011 EN 4660-003:2011 (E) 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 projectspecific ‘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 at the medium interface This is a function of the data rate and the modulation scheme Bandwidth.Length product - The product of signalling rate and the maximum path length In the case of an optical implementation the following parameters shall also be defined for each sub-network: Wavelength - The range of optical wavelengths at which communications is performed Power Budget - The optical signal characteristics for reliable communications (transmit and receive) 4.5 Module Logical Interface To enable interoperability between CFMs of a different type or between different implementations of the same CFM type, the Module Logical Interface (MLI) is defined This comprises two parts: 12 BS EN 4660-003:2011 EN 4660-003:2011 (E) • The Module Logical Interface for Network Properties This specifies the format, protocol, control and characteristics of the communication across the Network, between Network Interface Units (NIU) on different CFM • The Module Logical Interface for Communications This defines the data presentation and Virtual Channel communications format between instances of the Communications Manager in the Operating System Layer through the MOS interface, as shown in Figure These logical communications support: • Module and System Initialisation • Module Resource Management • Time Management • Network Management The generic services available are defined in EN 4660-005, but the MLI specification will be required to specify the use of such calls and the parameters that are passed 4.6 MLI - Network Properties The MLI Network Properties are not defined in the ASAAC Standards Therefore, for each system implementation that is based on the ASAAC architecture definition, the designer shall define a set of MLI Network Properties The following information provides an indication of the necessary content for this definition The definition of a new set of MLI Network Properties per project should be discouraged, since maximisation of LCC benefits from IMA is expected through the reuse of common components The definition of the MLI Network Properties should consider factors concerned with evolution of technology and possible future communications requirements In the following, the possible commonality between MLI Network Properties is considered 4.6.1 Data Formats The possibility of frame commonality between different network standards exists, although not large, and is not expected to be a primary focus for standardisation between MLI versions 4.6.1.1 Required Formats Frame Format - May be defined at many levels (see the OSI Reference Model, see ASAAC2-GUI-32450-001-CPG Issue 01.for an example of how different layers may be defined) The lower level formats (e.g link or network) are separately defined for each sub-network, but higher level formats could be generally defined for the communication network 4.6.1.2 Optional Formats The following are options in the above-required formats that may be separately defined for each sub-network or common to the whole communications network: Information/ Destination Identification - The representation of the intended destination (e.g process, processing element, module) May not be needed if resources are dedicated to the transfer Information Length - The amount of information being sent as a packet / block May not be needed if always a fixed size or information delimiters are used Information Type - Indicates the structure of information in the frame Error Detection - The technique for detecting transfer errors May not be needed if the underlying transfer service is sufficiently reliable or the user of the transfer takes responsibility for any unreliability 13 BS EN 4660-003:2011 EN 4660-003:2011 (E) Source Identification - The representation of the providing source (e.g process, processing element, module) May not be needed if resources are dedicated to the transfer 4.6.2 Data Link properties The MOS communications services defined in the ASAAC Standard for CFM see EN 4660-002 provide generic services to provide the software with a level of network independence However, the system designer must be aware that the characteristics of the overall system design are dependent on the characteristics of any particular network implementation So the designer must take into account the implications of network choice on various system properties including timeliness, reconfigurability, safety, security and fault management As in the case of changing a module, the contents of the blueprints will need to change if the network is changed, but as the network integrates the system, the impact on the system characteristics is greater These characteristics may also be affected by a simple change in network topology (i.e a change from point-to-point links to a broadcast bus, ring or switched network) Therefore, the characteristics of a specific network implementation must be carefully defined, as they heavily influence the characteristics of the overall system It should also be recognised that these characteristics cannot be associated with any specific component or layer in a communications model 4.6.2.1 Required Characteristics All the following characteristics are separately defined for each sub-network Bit Error Rate (BER) - The maximum rate at which bit errors can be expected to occur under fault-free conditions Data Integrity - The probability of receiving corrupt data and accepting it as correct Routing Integrity - The probability of information being misrouted Full Availability - The probability that the communication network will be able to deliver the information to the requisite location at the correct time Latency - The time to transfer information (network topology will be an important factor) Latency is usually expressed as the minimum value (see ‘jitter’ below) Jitter - The range between minimum and maximum values of latency Bandwidth - The maximum possible definable rate at which information can be transferred (network topology will be an important factor) Multicast - The ability to efficiently transfer information to multiple destinations via a single transfer request 4.6.2.2 Optional Characteristics All the following characteristics are separately defined for each sub-network Data Separation - The integrity with which separation of different transfers can be maintained Data Flow Separation - The ability to associate a specific bandwidth policy to a data flow Transfer Authentication - The ability to verify the correct source of a transfer Eavesdropping - The ability to prevent unauthorised access to transfers 14 BS EN 4660-003:2011 EN 4660-003:2011 (E) Interference - The ability to prevent unauthorised actions that impact the operation or performance of the network Secure Transfer Availability - The probability that the communication network will be able to deliver the classified information to the requisite location, and only this location, at the correct time 4.6.3 4.6.3.1 Control Functions Required Functions There are no required functions - all functions are optional 4.6.3.2 Optional Functions All the following functions are separately defined for each sub-network Medium Access - The means by which sources obtain access to a shared communication resource If the resource is not shared then this is not appropriate Inter-Link Routing - The means by which information is transferred from one network link to one of many others available at a point, according to its ultimate destination Not necessary if only a single link is used Latency Control - The means by which the order of disparate information transfers is controlled to provide improved performance for certain transfers Not necessary if platform network and traffic are designed within the constraints of the network capabilities Flow Restriction - The placement of a constraint on the rate at which information for the transfer is released to the network Not necessary if platform network and traffic are designed within the constraints of the network capabilities Local Resource Allocation - The means by which control is exerted over the interaction of disparate transfers to ensure sufficient resources are available to each, in order to provide the required bandwidth and latency 4.6.4 4.6.4.1 Monitoring Functions Required Functions There are no required functions - all functions are optional 4.6.4.2 Optional Functions The following monitoring functions are available to identify errors in the communications and should be separately defined for each sub-network (this list is not definitive): Frame traffic policing - This ensures that resources follow their allocated bandwidth contracts and that the periodicity of their transfers is correct and retained (this aides the capture application and operational errors) Frame format monitoring - This ensures that transmitted frames are correctly formatted and of the correct lengths (this aides the capture of data transmission errors from Application to Network Interface Unit) 4.6.5 Transfer Protocols Protocols may be introduced at various layers in the architecture, as described below and illustrated in Figure 3: 15 BS EN 4660-003:2011 EN 4660-003:2011 (E) Application Generic System Manager APOS GLI VC Manager OLI OSL MOS Module Resource Manager TC Manager MLI - Communications MSL Network Interface MPI Figure — ASAAC Communication Interfaces Applications Protocols supplied by the applications, such as encryption, are outside the scope of the ASAAC Standards VC Manager Puts on a protocol required for OSL to OSL transfers i.e OS Logical Interface (OLI) The flexible header allows a number of optional characteristics for this protocol GSM The GSM uses a protocol on top of the OLI TC Manager Puts on a protocol required for MSL to MSL transfers i.e MLI for Communications The MLI is split across processing elements (TC) and Module Support Unit (MSU) (routing) MRM Provides a module resource protocol which sits on top of the MLI and provides services at MSL level These are fully defined in EN 4660-005 Network Interface The physical interface defined by the MLI Network Properties, specific to the chosen network, which is not ASAAC-specific All protocols shall be unidirectional, and hence there is no default acknowledgement Acknowledgement may be provided by the use of a second TC (or VC), but this is outside the scope of the data network domain 4.6.5.1 Optional Protocols All the following protocols are separately defined for each sub-network Source Checking - The means by which the destination is able to identify the source of the information This may be provided as part of the OLI (see EN 4660-005) 16 BS EN 4660-003:2011 EN 4660-003:2011 (E) Flow Control - The means by which a destination can reduce the rate at which the source transfers the information Sending Policy - The means by which a TC Manager schedules the transmission of multiple messages on TCs (e.g with different priority levels) Shared Resource Allocation - The means by which remote resources are allocated to particular transfers (e.g a switch routing table) May be over a different network Segmentation/ Reassembly - The means by which large information blocks are transferred piecemeal to maintain network characteristics Multicast - The ability to efficiently transfer information to multiple destinations via a single transfer request Acknowledgement - The means by which the sink confirms the transfer completion to the source May be used to improve fault detection and recovery Only covers the transfer path to the entity responding (i.e an application must provide this if the whole path is to be covered) Discussion of Issues related to the Network This clause contains a discussion of issues related to the design and specification of the data network and gives explanations of the context of network definition Since, for durability, this Standard is technology transparent, certain parameters of the network which are technology-specific will need to be specified for each network implementation Advice is offered to assist in the specification of such parameters consistent with the concepts of IMA This clause should be read in conjunction with Clause 5.1 Issues relating to the Network Structure The description of the network structure should begin with an overview of the network(s) being used and the elements of importance to its implementation (e.g support modules necessary and provision of interconnects between the modules / racks) Although not based upon the implementation of them, reference can be made to the ISO OSI Reference Model ISO/IEC 7498-1 layers to (Physical, Data Link, Network and Transport) for the functions that will be performed and their possible structuring It should be noted that the full network implementation (the communication network) may comprise more than one separate network (a sub-network) which work in combination to provide the full communication capability required The exact provision of attribute definitions will vary from version to version of the network, but each version must provide the capability necessary to support the MOS Communication Services and their defined characteristics (i.e not all attributes will be required by all MLI versions, as indicated) The network may be divided into six parts Each part is defined as a fixed set of required parameters and a flexible set of optional parameters These must be assessed for each MLI to determine the specific set of parameters applicable to the network implementation being defined; these parameters would then be rearranged in accordance with the model appropriate for the network being used The following provide definitions for the attribute checklist: The Medium Attributes (see 4.4) provide the exact physical characteristics of the module interconnections, which are necessary for basic communication The Formats (see 4.6.1) define the encapsulation of information to allow remote peer-entity extraction, which are necessary for basic communication 17 BS EN 4660-003:2011 EN 4660-003:2011 (E) The Network Characteristics (see 4.6.2) identify generally applicable parameters which must be exhibited, which the system designer will assume during the specification of the platform The Control Functions (see 4.6.3) are communication process interactions that are necessary for either basic communication or QoS provision The Monitoring Functions (see 4.6.4) are communication process interactions that assist QoS provision by undertaking traffic policing as well as fault detection and fault localisation The Protocols (see 4.6.5) define the information to be transferred between peer entities and the actions to be taken, which are necessary for Quality of Service (QoS) provision 5.2 Issues related to the MOS Communication Services The MOS Services and a set of guidelines for their use are defined in EN 4660-005 These guidelines are supplemented by the following subclauses 5.2.1 Terminology The MOS is the software interface that provides hardware independence The MOS Communication Services provide the communication transfers and comms/network resource management The MSL routines associated with these services instigate the required communications functionality Thereafter, other resources on a three layer stack (TLS) processor / processing element / module (including a separate processor such as the MSU) may be used to complete the necessary activity In order to distinguish between the MSL software executed on a TLS processor, which consumes scheduled processor time, and those other resources that not (including hardware, communications processors and firmware), the latter will be referred to as the Network Interface Unit (NIU) 5.2.2 Synchronism The overall design of the MOS Communication Services is assumed to be asynchronous: that is, parameters are passed by the service call and then acted upon by dedicated communications resources allowing a TLS processor to continue to execute the Application/OS process The CFM designer can thus make efficient use of hardware resources with the OSL overlapping computations with communications To allow this asynchronism, the callback handler may be used to notify the OSL of the service call completion If the OSL needs to perform synchronous or blocking functions (i.e it cannot proceed until the information is provided), this can be easily achieved by the process waiting on the callback completion (e.g active wait, semaphore) 5.2.3 Callback Handlers A callback handler is a piece of code provided by the OSL which may be executed through a call from the MSL upon an MSL event occurring which interrupts the processor Care must be taken when writing callback handlers to catch asynchronous events from the MSL No assumptions should be made about the context in which the callback handler will be called forth: it could be in a special interrupt service routine (ISR) execution context or in the standard MSL execution context The callback handler must also be re-entrant to allow multiple callbacks to be handled simultaneously 5.2.4 Addresses and Execution Context Some parameters passed through MOS service calls represent the address of a buffer containing data (to be sent or received) Since the MSL / NIU are not aware of processes’ execution contexts, all the addresses provided must be in a unified execution context (e.g kernel context) Since the MSL may need to program hardware resources such as Direct Memory Access (DMA) engines, the MMU will be used to translate between the MSL execution context addresses and physical addresses when necessary The NIU will have direct memory access (i.e no mapping) with limits placed on the memory areas that can be accessed 18 BS EN 4660-003:2011 EN 4660-003:2011 (E) 5.2.5 Fragmented Transfers These calls are potentially dangerous if misused, since the purpose is to offer a service of direct memory access between signal processing applications Satisfying such a high performance, low overhead and low latency service needed for systematic signal processing is contradictory to typical constraints for critical real-time applications 5.2.6 Reconfiguration This may make use of the communication configuration services available in the MOS, according to the extent of the network reconfiguration necessary The full use of the configuration service in the MOS is defined in EN 4660-005 and the re-configuration process is described in the ASAAC Guidelines for Systems Issues see ASAAC2-GUI-32450-001-CPG Issue 01 5.2.7 Time Distribution The system designer needs to be aware that the network properties effect the quality of the time distribution A full description of the requirements for time distribution in an IMA system is given in Volume of the Guidelines for Systems Issues see ASAAC2-GUI-32450-001-CPG Issue 01 5.3 Issues relating to the Overall Network The following guidelines not apply directly to any of the communications / network standards but, rather, to the overall implementation of a network to meet specific system requirements 5.3.1 Topologies With any network, different topologies will be possible (e.g multiple point-to-point links as well as multiplex bus/switch) which will give different characteristics that may be of importance to the system ASAAC places no restrictions on the use of a particular network or of the multiple network interfaces available on each processing CFM It is up to the system designer to make use of the available flexibility to match the network characteristics to those required by the system, considering latency, bandwidth, resource sharing, transfer integrity, safety and security concerns As such, any network used in an ASAAC system should have topology options identified with an indication of their benefits and drawbacks 5.3.2 Network Scheduling Initial use of multiplex networks within avionic systems made use of the central processing architecture to provide central control of the transfers (e.g MIL-STD-1553B) where data was only transferred when it was needed With increasing distribution of processing the trend was towards data flow architectures, where data was transmitted when it was available, in order to improve network efficiency and reduce reliance on any one subsystem This made use of techniques prevalent in commercial networks, but has resulted in increasingly complex analysis to ensure hard deadlines are maintained under all conditions (something not necessary on the commercial networks where “best effort” was sufficient) It is now seen that something between these two extremes is needed However, the solution is not in the network domain, but in the system design itself The data network should not be seen as a real-time network, but rather as a network that supports a real-time system Therefore, the system designer can use his understanding of the software processes and the network predictability to schedule the start of each message transmission at each network interface The designer can also verify that delivery deadlines will be met, without loss of information due to buffer-overflow, before embodiment in the aircraft system As a result, the network can have a distributed rather than centralised control (i.e there is no equivalent of the bus controller function in MIL-STD-1553) This network philosophy accepts that the efficient use of bandwidth may need to be sacrificed in order to achieve latency predictability 19 BS EN 4660-003:2011 EN 4660-003:2011 (E) 5.3.3 Fault Detection and Reporting The ASAAC network concepts, exemplified by the network concept baseline, are considerably different to those of existing avionic networks As well as only having generic management software (in the OSL) to control the network (whatever protocol/topologies are used), there may be some intelligence within the communication resources aiding the detection and location of faults Within the network concept baseline, for example, the NSM, which is physically remote from the OSL controlling software, can detect faults and autonomously communicate this information over the network 5.3.4 NSM Architecture The implemented network may not require a NSM, or the NSM implementation could simply use point-to-point connections or a hub that does not need any management capability The NSM may be implemented without a TLS The NSM is simply a remote communication resource Whilst it is recognised that the presence of a TLS processor on the NSM could allow more intelligent fault detection and greater flexibility in operation, the use of hardware without a user programmable processor should not be prevented The TLS is intended to allow applications software to be independent of the underlying hardware There is no hardware independent software on an NSM so there is no requirement for a TLS processor Any potential flexibility of a TLS could be more than counter-balanced by increased complexity, cost and volume 5.3.5 Network Configuration and Blueprints Different network configuration data will be required for systems employing different network implementations However, for a particular network technology it is beneficial to use the same network configuration data whatever the implementation Accepting that the NSM implementation could vary, it is necessary to ensure that this implementation does not affect the way in which the NSM is configured (i.e standards must be defined for the structure of the data configuring the NSM connectivity) Although these standards could be defined as part of the MLI or the MOS Communication Services, it was determined as preferable to have this definition within the Run-Time Blueprint 5.3.6 Interaction with Backplane Implementation The backplane, for an IMA system, is required to route all the signals between functional modules within each avionic rack as well as provide all the connections to other modules located in other racks and connections to external sub-systems that are required to build a complete system The complexity of the backplane interconnect and the precise routing of the interconnect within the backplane will naturally depend on the particular system design This will include the topology of the system, the size and distribution of the integration areas, the security and redundancy requirements of the system and the distribution of hardware around the airframe A number of optical backplane technologies are available that meet the standards These technologies do, however, impose their own restrictions on the overall network design, which must be appreciated by the system designer 20 This page deliberately left blank British Standards Institution (BSI) BSI is the independent national body responsible for preparing British Standards and other standards-related publications, information and services It presents the UK view on standards in Europe and at the international level It is incorporated by Royal Charter Revisions Information on standards British Standards are updated by amendment or revision Users of British Standards should make sure that they possess the latest amendments or editions It is the constant aim of BSI to improve the quality of our products and services We would be grateful if anyone finding an inaccuracy or ambiguity while using this British Standard would inform the Secretary of the technical committee responsible, the identity of which can be found on the inside front cover Tel: +44 (0)20 8996 9001 Fax: +44 (0)20 8996 7001 BSI provides a wide range of information on national, European and international standards through its Knowledge Centre BSI offers Members an individual updating service called PLUS which ensures that subscribers automatically receive the latest editions of standards Tel: +44 (0)20 8996 7669 Fax: +44 (0)20 8996 7001 Email: plus@bsigroup.com Buying standards You may buy PDF and hard copy versions of standards directly using a credit card from the BSI Shop on the website www.bsigroup.com/shop In addition all orders for BSI, international and foreign standards publications can be addressed to BSI Customer Services Tel: +44 (0)20 8996 9001 Fax: +44 (0)20 8996 7001 Email: orders@bsigroup.com In response to orders for international standards, it is BSI policy to supply the BSI implementation of those that have been published as British Standards, unless otherwise requested Tel: +44 (0)20 8996 7004 Fax: +44 (0)20 8996 7005 Email: knowledgecentre@bsigroup.com Various BSI electronic information services are also available which give details on all its products and services Tel: +44 (0)20 8996 7111 Fax: +44 (0)20 8996 7048 Email: info@bsigroup.com BSI Subscribing Members are kept up to date with standards developments and receive substantial discounts on the purchase price of standards For details of these and other benefits contact Membership Administration Tel: +44 (0)20 8996 7002 Fax: +44 (0)20 8996 7001 Email: membership@bsigroup.com Information regarding online access to British Standards via British Standards Online can be found at www.bsigroup.com/BSOL Further information about BSI is available on the BSI website at www.bsigroup.com/standards Copyright Copyright subsists in all BSI publications BSI also holds the copyright, in the UK, of the publications of the international standardization bodies Except as permitted under the Copyright, Designs and Patents Act 1988 no extract may be reproduced, stored in a retrieval system or transmitted in any form or by any means – electronic, photocopying, recording or otherwise – without prior written permission from BSI This does not preclude the free use, in the course of implementing the standard of necessary details such as symbols, and size, type or grade designations If these details are to be used for any other purpose than implementation then the prior written permission of BSI must be obtained Details and advice can be obtained from the Copyright & Licensing Manager Tel: +44 (0)20 8996 7070 Email: copyright@bsigroup.com BSI Group Headquarters 389 Chiswick High Road London W4 4AL UK Tel +44 (0)20 8996 9001 Fax +44 (0)20 8996 7001 www.bsigroup.com/standards raising standards worldwide™