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 Copyright ASD-STAN Provided by IHS under license with AECMA Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-prEN 4660-003:2009 (E) 2 Contents Page Foreword3 0 Introduction4 0.1 Purpose.4 0.2 Document
8、structure.5 1 Scope 5 1.1 Relationship with other ASAAC Standards 6 2 Normative references 6 3 Terms, Definitions and Abbreviations.7 3.1 Terms and definitions .7 3.2 Abbreviations.7 4 Network Definition .8 4.1 Overview .8 4.2 Specific Network Requirements.9 4.3 MOS - Communications Services Interfa
9、ce . 12 4.4 Module Physical Interface 12 4.5 Module Logical Interface 12 4.6 MLI - Network Properties . 13 5 Discussion of Issues related to the Network . 17 5.1 Issues relating to the Network Structure . 17 5.2 Issues related to the MOS Communication Services 18 5.3 Issues relating to the Overall N
10、etwork . 19 Figures Figure 1 ASAAC Standards Documentation Hierarchy. 4 Figure 2 Software and Communications Model. 9 Figure 3 ASAAC Communication Interfaces 16 Tables Table 1 Architecture Requirements. 9 Table 2 System Requirements. 11 Copyright ASD-STAN Provided by IHS under license with AECMA Not
11、 for ResaleNo reproduction or networking permitted without license from IHS-,-,-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 rules of ASD-STAN
12、defined in ASD-STANs General Process Manual, this standard has received approval for Publication. Copyright ASD-STAN Provided by IHS under license with AECMA Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-prEN 4660-003:2009 (E) 4 0 Introduction 0.1 Purpose This do
13、cument 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 the model appropriate for the network being used. The following provide defi
14、nitions 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 a
15、re necessary for basic communication. Copyright ASD-STAN Provided by IHS under license with AECMA Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-prEN 4660-003:2009 (E) 18 The Network Characteristics (see 4.6.2) identify generally applicable parameters which must b
16、e 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 int
17、eractions 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
18、 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 independence. The MOS Communica
19、tion 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
20、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, communications processors and firmware
21、), 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 proc
22、essor 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
23、 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 t
24、he 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 call
25、ed 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 M
26、OS 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 resource
27、s 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. Copyright ASD-STAN
28、Provided by IHS under license with AECMA Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-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 s
29、ignal 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 serv
30、ices 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.
31、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 5 of the Guidelines for Systems Issues see ASAAC2-GUI-32450-001-CPG
32、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 overall implementation of a network to meet specific system requirements. 5.3.1 Topologies With any network, different topologies w
33、ill 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 C
34、FM. 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 h
35、ave 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 t
36、ransferred 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 commerc
37、ial 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 solut
38、ion 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 t
39、o 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 cen
40、tralised 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. Copyright ASD-STAN Provided by IHS under license with AECMA Not for
41、 ResaleNo reproduction or networking permitted without license from IHS-,-,-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 avionic networks. As well as only having
42、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 remot
43、e 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 managemen
44、t 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 pro
45、grammable 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 coun
46、ter-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 confi
47、guration 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). Alth
48、ough 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 be
49、tween 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 to
