BS EN 4660-003-2011 Aerospace series Modular and open avionics architectures Communications Network《航空航天系列 模块化和开放式航空电子体系结构 通信 网络》.pdf

《BS EN 4660-003-2011 Aerospace series Modular and open avionics architectures Communications Network《航空航天系列 模块化和开放式航空电子体系结构 通信 网络》.pdf》由会员分享，可在线阅读，更多相关《BS EN 4660-003-2011 Aerospace series Modular and open avionics architectures Communications Network《航空航天系列 模块化和开放式航空电子体系结构 通信 网络》.pdf（24页珍藏版）》请在麦多课文档分享上搜索。

1、raising standards worldwideNO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAWBSI Standards PublicationBS EN 4660-003:2011Aerospace series Modular and Open AvionicsArchitecturesPart 003: Communications/NetworkBS EN 4660-003:2011 BRITISH STANDARDNational forewordThis British Standa

2、rd is the UK implementation of EN 4660-003:2011.The UK participation in its preparation was entrusted to TechnicalCommittee ACE/6, Aerospace avionic electrical and fibre optictechnology.A list of organizations represented on this committee can beobtained on request to its secretary.This publication

3、does not purport to include all the necessaryprovisions of a contract. Users are responsible for its correctapplication. BSI 2011ISBN 978 0 580 62443 8ICS 49.090Compliance with a British Standard cannot confer immunity fromlegal obligations.This British Standard was published under the authority of

4、theStandards Policy and Strategy Committee on 31 March 2011.Amendments issued since publicationDate Text affectedBS EN 4660-003:2011EUROPEAN STANDARD NORME EUROPENNE EUROPISCHE NORM EN 4660-003 February 2011 ICS 49.090 English Version Aerospace series - Modular and Open Avionics Architectures - Part

5、 003: Communications/Network Srie arospatiale - Architectures Avioniques Modulaires et Ouvertes - Partie 003: Communication/Rseau Luft- und Raumfahrt - Modulare und offene Avionikarchitekturen - Teil 003: Kommunikation/Netzwerk This European Standard was approved by CEN on 26 June 2010. CEN members

6、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 t

7、o 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

8、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,

9、Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom. EUROPEAN COMMITTEE FOR STANDARDIZATION COMIT EUROPEN DE NORMALISATION EUROPISCHES KOMITEE FR NORMUNG Management Centre: Avenue Marnix 17, B-1000 Brussels 2011 CEN All rights of exploitation in any f

10、orm and by any means reserved worldwide for CEN national Members. Ref. No. EN 4660-003:2011: EBS EN 4660-003:2011EN 4660-003:2011 (E) 2 Contents Page Foreword 30 Introduction 40.1 Purpose .40.2 Document structure .51 Scope 51.1 Relationship with other ASAAC Standards 62 Normative references 63 Terms

11、, Definitions and Abbreviations .73.1 Terms and definitions .73.2 Abbreviations .74 Network Definition .84.1 Overview .84.2 Specific Network Requirements .94.3 MOS - Communications Services Interface . 124.4 Module Physical Interface 124.5 Module Logical Interface 124.6 MLI - Network Properties . 13

12、5 Discussion of Issues related to the Network . 175.1 Issues relating to the Network Structure . 175.2 Issues related to the MOS Communication Services 185.3 Issues relating to the Overall Network . 19Figures Figure 1 ASAAC Standards Documentation Hierarchy . 4 Figure 2 Software and Communications M

13、odel . 9 Figure 3 ASAAC Communication Interfaces 16 Tables Table 1 Architecture Requirements. 9 Table 2 System Requirements . 11 BS EN 4660-003:2011EN 4660-003:2011 (E) 3 Foreword This document (EN 4660-003:2011) has been prepared by the Aerospace and Defence Industries Association of Europe - Stand

14、ardization (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

15、 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 documen

16、t 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: Aus

17、tria, 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.

18、 BS EN 4660-003:2011EN 4660-003:2011 (E) 4 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 these parameters would then be rearranged in accordance with

19、 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

20、 encapsulation of information to allow remote peer-entity extraction, which are necessary for basic communication. BS EN 4660-003:2011EN 4660-003:2011 (E) 18 The Network Characteristics (see 4.6.2) identify generally applicable parameters which must be exhibited, which the system designer will assum

21、e 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 undertakin

22、g 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

23、 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 transfe

24、rs 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

25、 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 do not (including hardware, communications processors and firmware), the latter will be referred to as the Networ

26、k 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

27、 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 f

28、unctions (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 fro

29、m 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 se

30、rvice 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 buf

31、fer 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, t

32、he 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. BS EN 4660-003:2011EN 4660-003:2011 (E) 19 5.2.5 Fragmented Transf

33、ers 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 c

34、onstraints 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 a

35、nd 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

36、 for time distribution in an IMA system is given in Volume 5 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 do not apply directly to any of the communications / network standards but, rather, to the over

37、all 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

38、 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, bandw

39、idth, 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 us

40、e 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

41、 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 netwo

42、rks 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-t

43、ime 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 du

44、e 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 t

45、o be sacrificed in order to achieve latency predictability. BS EN 4660-003:2011EN 4660-003:2011 (E) 20 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

46、 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 remo

47、te 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 manageme

48、nt 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 pr

49、ogrammable 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 networ