ASD-STAN PREN 4660-003-2009 Aerospace series Modular and Open Avionics Architectures Part 003 Final Draft of Proposed Standards for Communications Network (Edition P 1)《航空航天系列 模块化和.pdf

《ASD-STAN PREN 4660-003-2009 Aerospace series Modular and Open Avionics Architectures Part 003 Final Draft of Proposed Standards for Communications Network (Edition P 1)《航空航天系列 模块化和.pdf》由会员分享，可在线阅读，更多相关《ASD-STAN PREN 4660-003-2009 Aerospace series Modular and Open Avionics Architectures Part 003 Final Draft of Proposed Standards for Communications Network (Edition P 1)《航空航天系列 模块化和.pdf（20页珍藏版）》请在麦多课文档分享上搜索。

1、ASD STANDARD NORME ASD ASD NORM prEN 4660-003 Edition P 1 July 2009 PUBLISHED BY THE AEROSPACE AND DEFENCE INDUSTRIES ASSOCIATION OF EUROPE - STANDARDIZATIONAvenue de Tervuren, 270 - B-1150 Brussels - Tel. + 32 2 775 8126 - Fax. + 32 2 775 8131 - www.asd-stan.orgICS: Descriptors: ENGLISH VERSION Aer

2、ospace series Modular and Open Avionics Architectures Part 003: Final Draft of Proposed Standards for Communications/Network Srie arospatiale Architectures Avioniques Modulaires et Ouvertes Partie 003 : Dernire proposition des standards pour communication/rseau Luft- und Raumfahrt Modulare und offen

3、e Avionikarchitekturen Teil 003: Endgltiger Entwurf des Standards fr Kommunikation/Netzwerk This “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

4、European Aerospace Industry. It has been technically approved by the experts of the concerned Domain 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,

5、without re-identification of the standard. After examination and review by users and formal agreement of ASD-STAN, it 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 natio

6、nal members have then to implement the EN at national level by giving the EN the status of a national standard and by withdrawing any national standards conflicting with the EN. Edition approved for publication 31 July 2009 Comments should be sent within six months after the date of publication to A

7、SD-STAN Engineering Procedures Domain Copyright 2009 by ASD-STAN prEN 4660-003:2009 (E) 2 Contents Page Foreword3 0 Introduction4 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

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

9、e 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 Communicat

10、ion Interfaces 16 Tables Table 1 Architecture Requirements. 9 Table 2 System Requirements. 11 prEN 4660-003:2009 (E) 3 Foreword This standard was reviewed by the Domain Technical Coordinator of ASD-STANs Engineering Procedures Domain. After inquiries and votes carried out in accordance with the rule

11、s of ASD-STAN defined in ASD-STANs General Process Manual, this standard has received approval for Publication. prEN 4660-003:2009 (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

12、 architecture standards, concepts 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 int

13、erconnections, 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. prEN 4660-003:2009 (E) 18 The Network Characteristics (see 4.6.2) identify generally applic

14、able 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) a

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

16、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 sections. 5.2.1 Terminology The MOS is the software interface that provides hardware ind

17、ependence. 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 el

18、ement / 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 do not (including hardware, communicat

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

20、esources 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 ser

21、vice 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

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

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

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

25、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 a

26、ccessed. prEN 4660-003:2009 (E) 19 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

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

28、nfiguration 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

29、 time distribution. A full description of the requirements 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 c

30、ommunications / 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 char

31、acteristics 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 t

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

33、l 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 architect

34、ures, 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 c

35、onditions (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-ti

36、me 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 deli

37、very 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 philoso

38、phy accepts that the efficient use of bandwidth may need to be sacrificed in order to achieve latency predictability. prEN 4660-003:2009 (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

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

40、xample, 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

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

42、on, 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 fl

43、exibility 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 i

44、s 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 da

45、ta 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 syste

46、m, 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 interconnec

47、t 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.