ImageVerifierCode 换一换
格式:PDF , 页数:20 ,大小:107.35KB ,
资源ID:421582      下载积分:5000 积分
快捷下载
登录下载
邮箱/手机:
温馨提示:
如需开发票,请勿充值!快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。
如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝扫码支付 微信扫码支付   
注意:如需开发票,请勿充值!
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【http://www.mydoc123.com/d-421582.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(AECMA 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)为本站会员(sumcourage256)主动上传,麦多课文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知麦多课文库(发送邮件至master@mydoc123.com或直接QQ联系客服),我们立即给予删除!

AECMA 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

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

copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
备案/许可证编号:苏ICP备17064731号-1