BS EN 4660-005-2011 Aerospace series Modular and open avionics architectures Software《航空航天系列 模块化和开放式航空电子体系结构 软件》.pdf

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

1、raising standards worldwideNO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAWBSI Standards PublicationBS EN 4660-005:2011Aerospace series Modular and Open AvionicsArchitecturesPart 005: SoftwareBS EN 4660-005:2011 BRITISH STANDARDNational forewordThis British Standard is the UK i

2、mplementation of EN 4660-005: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 does not purpo

3、rt to include all the necessaryprovisions of a contract. Users are responsible for its correctapplication. BSI 2011ISBN 978 0 580 62445 2ICS 49.090Compliance with a British Standard cannot confer immunity fromlegal obligations.This British Standard was published under the authority of theStandards P

4、olicy and Strategy Committee on 31 May 2011.Amendments issued since publicationDate Text affectedBS EN 4660-005:2011EUROPEAN STANDARD NORME EUROPENNE EUROPISCHE NORM EN 4660-005 May 2011 ICS 49.090 English Version Aerospace series - Modular and Open Avionics Architectures - Part 005: Software Srie a

5、rospatiale - Architectures Avioniques Modulaires et Ouvertes - Partie 005: Software Luft- und Raumfahrt - Modulare und offene Avionikarchitekturen - Teil 005: Software This European Standard was approved by CEN on 26 June 2010. CEN members are bound to comply with the CEN/CENELEC Internal Regulation

6、s 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 to the CEN-CENELEC Management Centre or to any CEN member. Th

7、is 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 Centre has the same status as the official versions. CEN mem

8、bers 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, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain

9、, 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 form and by any means reserved worldwide for CEN national Mem

10、bers. Ref. No. EN 4660-005:2011: EBS EN 4660-005:2011EN 4660-005:2011 (E) 2 Contents Page 0 Introduction . 11 0.1 Purpose 11 0.2 Document structure 12 1 Scope . 12 1.1 Software Architecture Overview . 12 1.2 Software Architectural Components 13 2 Normative references . 15 3 Terms, definitions and ab

11、breviations . 16 3.1 Terms and definitions 16 3.2 Abbreviations 16 4 System Functions . 19 4.1 System Management Function 19 4.2 Communication . 26 4.3 Security Management . 45 4.4 Module Management 49 4.5 Mass Memory Management . 50 4.6 Graphics Management . 54 4.7 Power Management 56 4.8 Network M

12、anagement . 58 4.9 Time Management. 61 5 Software Architecture Definition . 65 5.1 MSL 66 5.2 OSL . 71 5.3 RTBP 107 5.4 Application Layer 110 6 Direct Interfaces Definitions 117 6.1 APOS 117 6.2 MOS 189 6.3 SMBP 270 6.4 SMOS . 296 7 Logical Interfaces Definitions 341 7.1 OLI 341 7.2 GLI 348 7.3 SMLI

13、 . 373 7.4 MLI 381 8 Data Type Definitions . 439 8.1 IDL 439 8.2 Data Types . 441 9 Tailoring . 487 BS EN 4660-005:2011EN 4660-005:2011 (E) 3 Annex A (normative) AGL . 496 A.1 The Concept . 496 A.2 Graphical Command Set . 496 A.2.1 Overview . 496 A.2.2 Command Listings 497 A.2.3 Auxiliary Library (A

14、L) Definition 501 A.2.4 Video Library (VL) Definition 502 A.2.5 Texture Mapping Constraints . 503 A.2.6 Display Frame and Synchronisation . 505 A.2.7 Command Responses and Delays . 505 Figures Page Figure 1 ASAAC Standard Documentation Hierarchy . 11 Figure 2 ASAAC Three Layer Software Architecture

15、. 12 Figure 3 The Software Architecture Model 13 Figure 4 Hierarchical Organisation of the System Management 20 Figure 5 GSM Decomposition for RE-Management (Example) . 21 Figure 6 IA Application Control (Example) 22 Figure 7 GSM Decomposition for Module Management (Example) 23 Figure 8 Hierarchical

16、 Organisation of the AM (Example) 24 Figure 9 The ASAAC Communication Stack . 27 Figure 10 Types of Data Transfer . 29 Figure 11 Communication Concept . 30 Figure 12 Between AL Communication Routing 31 Figure 13 ASAAC Message in BMC Data Transfer . 33 Figure 14 Multicast Scheme With a Single TC 34 F

17、igure 15 Multicast Scheme With Multiple Simple TCs 35 Figure 16 Data Parallelism 36 Figure 17 Corner Turn . 36 Figure 18 Corner Turn in Three Dimensions. 37 Figure 19 Illustration of the Involved Services in DSP1 38 Figure 20 Data Representation . 41 Figure 21 GSM Interfaces 46 BS EN 4660-005:2011EN

18、 4660-005:2011 (E) 4 Figure 22 Main Security Related Architectural Components . 47 Figure 23 VC transferring Data Requiring Encryption IA1 controlling the IA managers IA2 and IA3; IA2, IA3, and IA4 each controlling 2 REs ACIA1IA2IA2IA3 IA4App1App2App3App4App4 App4Figure 6 IA Application Control (Exa

19、mple) Application configuration control (Figure 6): An AC manager controlling IA1 and IA4; IA1 controlling IA2 and IA3; IA2 controlling the applications App1 and App2; IA3 controlling the applications App3 and App4 (redundant); IA4 controlling the redundant application App4. BS EN 4660-005:2011EN 46

20、60-005:2011 (E) 23 ACIA1IA2 IA3 IA4 PCMMMM DPMNSMPCMMMM DPMSPMRACK 2 RACK 1 GPMDPMMODULEFigure 7 GSM Decomposition for Module Management (Example) Application configuration control (Figure 7): An AC manager controlling IA1 and IA4; IA1 controlling IA2 and IA3; IA2 controlling the applications App1 a

21、nd App2; IA3 controlling the applications App3 and App4 (redundant); IA4 controlling the redundant application App4. Configuration Data: The configuration data is obtained from the RTBP via SMBP. The reconfiguration is defined through dedicated sequences obtained via SMBP. Initialisation and Shut-Do

22、wn: Initialisation and shut-down is performed on three different levels: Application, System, Module. 4.1.2 AM Function The AM function is responsible for the management and control of all AC dependent functions (functional applications) on the Application Layer (AL). It acts as an interface between

23、 the functional applications and a dedicated instantiation of the GSM. Hierarchical Organisation: The AM should only be located on the AC- and IA-levels, as the RE level is resource-oriented, whereas the AC and IA levels are function-oriented. An example for the hierarchical organisation of the AM s

24、howing the assignment of functional applications to IAs is depicted in Figure 8: BS EN 4660-005:2011EN 4660-005:2011 (E) 24 GSM AM IA2 (Radar IA) IA3 (EW IA) IA1 (RF-IA) AC IA4 (Nav IA)Applications Air to Air Mode Air to Surface Mode Applications Threat WarningJammingApplications Flight Plan Map Dis

25、play GSMAMGSM AM GSMAM GSMAM Applications DASS Mgmt Applications Pilot Interaction Figure 8 Hierarchical Organisation of the AM (Example) Internal Interfaces: The standardised internal interface of the AM is the System Management Logical Interface (SMLI.) The SMLI includes a request-response protoco

26、l for the change of the logical configuration. External Interfaces: There are no standardised external interfaces of the AM. All external interfaces are application-dependent. 4.1.3 Error Handling ASAAC compliant systems require that software developers write their functional application code to int

27、erface with the underlying OS using the standardised service calls that comprise the APOS interface (6.1). However, it is possible at run-time for an APOS service not to perform correctly and to actually return an error status to the calling Application Process. This might be due to a real fault in

28、the underlying system or by misuse of the APOS interfaces themselves (e.g. posting a semaphore before it has been created). In either case the fault is handled through a standardised process (see ASAAC2-GUI-32450-001-CPG Issue 01) in which the precise error identification is passed to the Health Mon

29、itoring function within the GSM. Any error handling shall be subject to the decisions made by the fault management function. In handling the error, the fault management function may delegate the error handling back to a functional Application Process by invoking the error handler thread of the Appli

30、cation Process. In this case, the complete error information shall be accessible to this error handler thread. BS EN 4660-005:2011EN 4660-005:2011 (E) 25 The error information shall be accessible to the application itself, but used for debugging purposes only. Exceptions to this rule are timeouts an

31、d resources, which are managed by the application. Note however that functional Application Processes shall handle situations where a called APOS service has timed out. In this case, the application calling a service shall be informed by means of a return value. 4.1.4 Built-In Test The BIT Services

32、provide the ability to execute module built-in tests and read their results. The built-in-test component provides access to all built-in-test routines available on the module. There are three different types of built-in test: Power-up built-in-test (PBIT), Continuous built-in-test (CBIT), Initiated

33、built-in-test (IBIT). The OS provides the GSM with Services related to the BIT Management at the SMOS interface that are paired with services at the MOS interface: Get PBIT Result: Retrieves the stored PBIT result, Start CBIT: Runs the CBIT processing and then returns. It allows a specific type of t

34、est to be run, or all tests to be run, Get CBIT Result: Retrieves the CBIT result, Start IBIT: Starts the IBIT processing, Get IBIT Result: Retrieves the stored IBIT result. 4.1.4.1 Power-up Built-In Test (PBIT) PBIT is used to check the state of the module hardware as part of the boot process. The

35、tests are run autonomously as part of the MSL before any control is applied from outside the module. The result of these tests is recorded in the MSL for retrieval by a GSM on a controlling module via the MLI. It is also available via a MOS/SMOS call to the local GSM. 4.1.4.2 Continuous Built-In Tes

36、t (CBIT) CBIT is used to continuously check the health of the module during normal operation. CBIT is non-intrusive. The tests can be run either: Autonomously, if no processor support is required to perform the test, Under the command of the GSM, if processor support is required to perform the test.

37、 Test results can also be obtained using two mechanisms: Callback, Polled, either as part of the calling mechanism or as a separate call. BS EN 4660-005:2011EN 4660-005:2011 (E) 26 The various combinations of CBIT behaviour are described below: Table 2 CBIT Modes Run method Result Method Behaviour A

38、utonomous Callback CBIT runs autonomously and does not require control from outside the MSL. When a test fails, the indication of this is flagged to the OSL using a callback. The service getCbitResult is then used to retrieve the detailed information about the failure. Autonomous Polled CBIT runs au

39、tonomously and does not require control from outside the MSL. When a test fails, the result is stored internally in the MSL. No indication is given to the OSL. GetCbitResult is then used periodically to retrieve any failure information. If no failure has occurred, no action is taken. If a failure ha

40、s occurred, the detailed information about the failure is returned. Commanded Callback CBIT runs under the control of the OSL. When a test fails, the indication of this is flagged to the OSL using a callback. GetCbitResult is then used to retrieve the detailed information about the failure. Commande

41、d Polled CBIT runs under the control of the OSL. The time allowed to perform CBIT each time the service startCbit is called, is MSL specific. When a failure is detected, GetCbitResult is then used to retrieve the detailed information about the failure. 4.1.4.3 Initiated Built-In Test (IBIT) IBIT is

42、used to check the state of the module hardware as part of the fault management process. It performs a comprehensive test of the module in order to help during fault localisation. The tests can be run remotely under the control of a GSM on a controlling module via the MLI, or via a MOS/SMOS call (sta

43、rtIbit) from the local GSM when it is available. IBIT can be destructive in its operation. This means that the current configuration of the module cannot be guaranteed when the tests have been completed. Care must therefore be taken to ensure the system is not compromised when IBIT is used. Also, in

44、 the case of destructive testing, its use should be restricted to invocation via the MLI. The result of these tests is recorded in the MSL for retrieval by a GSM on a controlling module via the MLI or via a MOS/SMOS call (getIbitResult) from the local GSM if it started IBIT. 4.2 Communication 4.2.1

45、ASAAC Communication Model 4.2.1.1 Principle The ASAAC Communication stack (see Figure 9) shall be supported by: VCs (provided by OSL), Transfer Connections (TC) (provided by MSL, hardware independent), Network Channels (NC) (provided by MSL, hardware dependent). BS EN 4660-005:2011EN 4660-005:2011 (

46、E) 27 Virtual ChannelTransfer ConnectionNetwork ChannelVirtual ChannelTransfer ConnectionNetwork ChannelPeer to Peer CommunicationDirectInterfaceFigure 9 The ASAAC Communication Stack The ASAAC Communication shall support: One sender to one receiver (1:1), Multicast (one sender to n receivers (1:N),

47、 the case one sender to one receiver is a sub-set of the previous one (1:1), Distributed multi-cast (applicable to signal processing applications (M: N). 4.2.1.2 VC Inter-process communication is based on VCs. VCs show the following properties: Unidirectional, Message-oriented (i.e. one message defi

48、nition is assigned to a VC), Managed by OSL (creation, deletion, routing), Predictable in terms of time and resource consumption. The concept allows a single transmitting process to send data to one or more receiving processes. A receiving process may be resident on the same Processing Element, the

49、same CFM or even a different CFM to the sending process. The sending process has no knowledge of any receiving process; it merely outputs certain data onto a particular VC. Similarly, a receiving process has no knowledge of the sending process; it merely receives certain data from certain VCs. BS EN 4660-005:2011EN 4660-005:2011 (E) 28 The source and destination processes, the data items to be transmitted between them, and the VCs, over which they are trans