ASD-STAN PREN 4660-003-2018 Aerospace series - Modular and Open Avionics Architectures - Part 003 Communications Network (Edition P 2).pdf

《ASD-STAN PREN 4660-003-2018 Aerospace series - Modular and Open Avionics Architectures - Part 003 Communications Network (Edition P 2).pdf》由会员分享，可在线阅读，更多相关《ASD-STAN PREN 4660-003-2018 Aerospace series - Modular and Open Avionics Architectures - Part 003 Communications Network (Edition P 2).pdf（14页珍藏版）》请在麦多课文档分享上搜索。

1、 ASD-STAN STANDARD NORME ASD-STAN ASD-STAN NORM ASD-STAN prEN 4660-003 Edition P2 April 2018 PUBLISHED BY THE AEROSPACE AND DEFENCE INDUSTRIES ASSOCIATION OF EUROPE - STANDARDIZATION Rue Montoyer 10 - 1000 Brussels - Tel. + 32 2 775 8126 - Fax. + 32 2 775 8131 - www.asd-stan.org ICS: Descriptors: EN

2、GLISH VERSION Aerospace series Modular and Open Avionics Architectures Part 003: Communications/Network Luft- und Raumfahrt Modulare und offene Avionikarchitekturen Teil 003: Kommunikation/Netzwerk Srie arospatiale Architectures Avioniques Modulaires et Ouvertes Partie 003 : Communication/Rseau This

3、 “Aerospace Series“ Prestandard has been drawn up under the responsibility of ASD-STAN (The AeroSpace and Defence Industries Association of Europe - Standardization). It is published for the needs of the European Aerospace Industry. It has been technically approved by the experts of the concerned Do

4、main following member comments. Subsequent to the publication of this Prestandard, the technical content shall not be changed to an extent that interchangeability is affected, physically or functionally, without re-identification of the standard. After examination and review by users and formal agre

5、ement of ASD-STAN, the ASD-STAN prEN will be submitted as a draft European Standard (prEN) to CEN (European Committee for Standardization) for formal vote and transformation to full European Standard (EN). The CEN national members have then to implement the EN at national level by giving the EN the

6、status of a national standard and by withdrawing any national standards conflicting with the EN. ASD-STAN Technical Committee approves that: “This document is published by ASD-STAN for the needs of the European Aerospace Industry. The use of this standard is entirely voluntary, and its applicability

7、 and suitability for any particular use, including any patent infringement arising therefrom, is the sole responsibility of the user.” ASD-STAN reviews each standard and technical report at least every five years at which time it may be revised, reaffirmed, stabilized or cancelled. ASD-STAN invites

8、you to send your written comments or any suggestions that may arise. All rights reserved. No parts of this publication may be reproduced, stored in a retrieval system or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without prior written per

9、mission of ASD-STAN. Order details: E-mail: salesasd-stan.org Web address: http:/www.asd-stan.org/ Edition approved for publication 1stApril 2018 Comments should be sent within six months after the date of publication to ASD-STAN General Domain prEN 4660-003:2018 (E) 2 Contents Page 1 Scope 3 2 Norm

10、ative references 4 3 Terms and definitions and Abbreviations . 4 3.1 Terms and definitions . 4 3.2 Abbreviations . 4 4 Network Definition . 6 4.1 Overview 6 4.2 Specific Network Requirements 6 4.3 Module Physical Interface 7 4.4 Optional Module Logical Interface 8 4.5 Optional MLI - Network Properti

11、es 9 4.5.1 General 9 4.5.2 Data Formats . 9 4.5.3 Data Link properties . 10 4.5.4 Control Functions . 11 4.5.5 Monitoring Functions . 11 4.5.6 Transfer Protocols . 12 (informative) Standard Evolution Form 14 Annex AFigures Figure 1 MOAA Standard Documentation Hierarchy . 3 Figure 2 MOAA Communicatio

12、n Interfaces . 12 Tables Table 1 Architecture Requirements 6 Table 2 System Requirements . 7 Table A.1 Main changes to previous editions . 14 prEN 4660-003:2018 (E) 3 1 Scope The purpose of this MOAA standard is to define a set of open architecture standards, concepts Module Resource Management; Tim

13、e Management; Network Management. prEN 4660-003:2018 (E) 9 The generic services available are defined in the MOAA Standard for Software EN 4660-005, but the MLI specification will be required to specify the use of such calls and the parameters that are passed. 4.5 Optional MLI - Network Properties 4

14、.5.1 General The MLI Network Properties are not defined in the MOAA Standards. Therefore, for each system implementation that is based on the MOAA architecture definition, the designer shall define a set of MLI Network Properties. The following information provides an indication of the necessary con

15、tent 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 evolu

16、tion of technology and possible future communications requirements. In the following, the possible commonality between MLI Network Properties is considered. 4.5.2 Data Formats 4.5.2.1 General The possibility of frame commonality between different network standards exists, although not large, and is

17、not expected to be a primary focus for standardisation between MLI versions. 4.5.2.2 Required Formats Frame Format May be defined at many levels (see the OSI Reference Model ISO/IEC 7498-1 for an example of how different layers may be defined). The lower level formats (e.g. link or network) are sepa

18、rately defined for each sub-network, but higher level formats could be generally defined for the communication network. 4.5.2.3 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:

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

20、ed 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 responsibilit

21、y for any unreliability. 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. prEN 4660-003:2018 (E) 10 4.5.3 Data Link properties 4.5.3.1 General The MOS communications services def

22、ined in the MOAA Standard for CFM 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 impleme

23、ntation. 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 ch

24、anged, 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 characteristi

25、cs 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.5.3.2 Required Charac

26、teristics 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 Integ

27、rity 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). Latenc

28、y 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 t

29、ransfer information to multiple destinations via a single transfer request. 4.5.3.3 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 Separati

30、on The ability to associate a specific bandwidth policy to a data flow. Transfer Authentication The ability to verify the correct source of a transfer. prEN 4660-003:2018 (E) 11 Eavesdropping The ability to prevent unauthorised access to transfers. Interference The ability to prevent unauthorised ac

31、tions 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.5.4 Control Functions 4.5.4.1 Requir

32、ed Functions There are no required functions all functions are optional. 4.5.4.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 t

33、his 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 inf

34、ormation 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 r

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

36、order to provide the required bandwidth and latency. 4.5.5 Monitoring Functions 4.5.5.1 Required Functions There are no required functions all functions are optional. 4.5.5.2 Optional Functions The following monitoring functions are available to identify errors in the communications and should be se

37、parately 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 fo

38、rmat 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). prEN 4660-003:2018 (E) 12 4.5.6 Transfer Protocols 4.5.6.1 General Protocols may be introduced at v

39、arious layers in the architecture, as described below and illustrated in Figure 2: Figure 2 MOAA Communication Interfaces Applications Protocols supplied by the applications, such as encryption, are outside the scope of the MOAA Standards. VC Manager Puts on a protocol required for OSL to OSL transf

40、ers 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 eleme

41、nts (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 ne

42、twork, which is not MOAA-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. prEN 4660-003:2018 (E) 13 4.5.6.2 Optional Protocols A

43、ll 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). Flow Control The means by which a destination can reduce the rate a

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

45、ch 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. Ac

46、knowledgement 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). prEN 4660-003:2018 (E) 14

47、Annex A(informative) Standard Evolution Form Table A.1 Main changes to previous editions EN Number Edition Publication Date Modification Reason and Validation see attached Change Sheets 4660-003 P2 2017 Editorial: Replace Reconfiguration by Configuration ASD-STAN D1 WG2 EN 4660-003_01 4660-003 P2 20

48、17 No Tools for NSM Replacement required ASD-STAN D1 WG2 EN 4660-003_02 4660-003 P2 2017 No Special Tools for Replacement of Backplane ASD-STAN D1 WG2 EN 4660-003_03 4660-003 P2 2017 No Network Maintenance Calibration ASD-STAN D1 WG2 EN 4660-003_04 4660-003 P2 2017 Delete Mechanical Constraints ASD-

49、STAN D1 WG2 EN 4660-003_05 4660-003 P2 2017 Delete Environmental Conditions ASD-STAN D1 WG2 EN 4660-003_06 4660-003 P2 2017 Expand Number of Nodes ASD-STAN D1 WG2 EN 4660-003_07 4660-003 P2 2017 Expand Performance ASD-STAN D1 WG2 EN 4660-003_08 4660-003 P2 2017 Replace: “maskable interrupts” by “event mechanisms rather than polling” ASD-STAN D1 WG2 EN 4660-003_09 4660-003 P2 2017 Delete “Hazards by Optical Sources” ASD-STAN D1 WG2 EN 4660-003_10 4660-003 P2 2017 Change Clause 5 to inf